作者:Dark_King_
blog.csdn.net/b379685397/article/details/109147469
主从复制就是我们建立数据存档的时候,将一份数据进行复制保存多分存储在不同的机器上。
在redis持久化机制一文中,我们已经提到为了防止数据丢失,redis提供了RDB和AOF两种方式持久化数据,将内存的数据持久化到磁盘上。但是当出现服务器出现故障,比如服务磁盘坏掉导致数据不可恢复时。那又该怎么办呢?
那么为了避免单点故障,我们需要将数据复制多份部署在多台不同的服务器上,即使有一台服务器出现故障其他服务器依然可以继续提供服务。这就要求当一台服务器上的数据更新后,自动将更新的数据同步到其他服务器上,这就是主从复制。
当我们主节点压力比较大时,那么我们可以通过读写分离的方式,对复制的节点数据进行读操作,以增加我们的服务性能
总结来讲使用主从复制有以下原因
数据备份,容灾恢复
业务数据读写分离
redis实现主从很简单,只需要增加启动脚本或者配置文件中配置slaveof命令即可
启动redis服务时,后面新增 redis-server --slaveof ip(主redisip) port。
该配置到5.0版本以上改为了 replicaof,Redis 作者在 GitHub 上发起了一个“用其他词汇代替 Redis 的主从复制术语”的 issue因为有人认为 Redis 中的术语 master/slave (主人 / 奴隶)冒犯到了别人(果然歪果仁们对这还是敏感啊,哈哈),要求 Redis 作者 ANTIREZ 修改这个术语,甚至连 ruby on rails 的作者 DHH 都在表态。
环境两台机器:148.70.47.76(主),111.229.169.46(从)
1、148.70.47.76直接启动redis
2、修改111.229.169.46redis配置,新增slaveof 148.70.47.76 6379 配置或者使用replicaof配置
5.0以上
3、启动111.229.169.46 的redis
4、查看148.70.47.76 redis状态,发现role 为master主节点,有一个从节点,从节点ip为111.229.169.46(该信息很重要,哨兵机制会用到)
查看111.229.169.46 redis状态,发现role 为slave从节点,有一个主节点,主节点ip为148.70.47.76.
配置主从为了安全性可以修改配置文件的masterauth属性来增加同步密码
从节点建议用只读模式slave-read-only=yes, 若从节点修改数据,主从数据不一致.
传输延迟:主从一般部署在不同机器上,复制时存在网络延时问题,redis 提供repl-disable-tcp-nodelay 参数决定是否关闭TCP_NODELAY,默认为关闭.参数关闭时:无论大小都会及时发布到从节点,占带宽,适用于主从网络好的场景.参数启用时:主节点合并所有数据成TCP 包节省带宽,默认为40 毫秒发一次,取决于内核,主从的同步延迟40 毫秒,适用于网络环境复杂或带宽紧张,如跨机房
redis主从主要流程如下:
redis的数据同步主要分为全量同步和增量同步
Redis全量复制一般发生在Slave初始化阶段,这时Slave需要将Master上的所有数据都复制一份。
master服务器会开启一个后台进程用于将redis中的数据生成一个rdb文件,与此同时,服务器会缓存所有接收到的来自客户端的写命令(包含增、删、改),当后台保存进程处理完毕后,会将该rdb文件传递给slave服务器,而slave服务器会将rdb文件保存在磁盘并通过读取该文件将数据加载到内存,在此之后master服务器会将在此期间缓存的命令通过redis传输协议发送给slave服务器,然后slave服务器将这些命令依次作用于自己本地的数据集上最终达到数据的一致性。
具体步骤如下:
从服务器连接主服务器,发送SYNC命令;
主服务器接收到SYNC命名后,开始执行BGSAVE命令生成RDB文件并使用缓冲区记录此后执行的所有写命令;
主服务器BGSAVE执行完后,向所有从服务器发送快照文件,并在发送期间继续记录被执行的写命令;
从服务器收到快照文件后丢弃所有旧数据,载入收到的快照;
主服务器快照发送完毕后开始向从服务器发送缓冲区中的写命令;
从服务器完成对快照的载入,开始接收命令请求,并执行来自主服务器缓冲区的写命令;
Redis增量复制是指Slave初始化后开始正常工作时主服务器发生的写操作同步到从服务器的过程。
增量复制的过程主要是主服务器每执行一个写命令就会向从服务器发送相同的写命令,从服务器接收并执行收到的写命令。
主从刚刚连接的时候,进行全量同步;全同步结束后,进行增量同步。当然,如果有需要,slave 在任何时候都可以发起全量同步。redis策略是,无论如何,首先会尝试进行增量同步,如不成功,要求从机进行全量同步。
用于主节点故障转移从节点,当主节点的“写”命令并发高且需要持久化,可以只在从节点开启AOF(主节点不需要),增加主节点性能,主节点异常时可以通过从节点备份进行恢复。
针对“读”较多的场景,“读”由多个从节点来分担,但节点越多,主节点同步到多节点的次数也越多,影响带宽,也加重主节点的稳定
一主多从的缺点(主节点推送次数多压力大)可用些方案解决,主节点只推送一次数据到从节点1,再由从节点2推送到11,减轻主节点推送的压力
关注微信公众号:互联网架构师,在后台回复:2T,可以获取我整理的教程,都是干货。
猜你喜欢
1、GitHub 标星 3.2w!史上最全技术人员面试手册!FackBoo发起和总结
2、如何才能成为优秀的架构师?
3、从零开始搭建创业公司后台技术栈
4、程序员一般可以从什么平台接私活?
5、37岁程序员被裁,120天没找到工作,无奈去小公司,结果懵了...
6、滴滴业务中台构建实践,首次曝光
7、不认命,从10年流水线工人,到谷歌上班的程序媛,一位湖南妹子的励志故事
8、15张图看懂瞎忙和高效的区别
9、2T架构师学习资料干货分享