Redis主从复制(读写分离)

一、什么是主从复制

  • 主从复制,就是主机数据更新后根据配置和策略,自动同步到备机的master/slaver机制,Master以写为主,Slave以读为主。
  • 优点:读写分离,性能扩展,容灾快速恢复
  • 需要注意的时:在Redis2.6以后,slave只读模式是默认开启的,我们可以通过配置文件中的slave-read-only选项配置是否开启只读模式
    在这里插入图片描述
    同时,从机下面也还能有自己的从机。
    在这里插入图片描述

二、主从复制的方式

  1. 当master服务器与slave服务器正常连接时,master服务器会发送数据命令流给slave服务器,将自身数据的改变复制到slave服务器。
  2. 当因为各种原因master服务器与slave服务器断开后,slave服务器在重新连上master服务器时会尝试重新获取断开后未同步的数据即部分同步,或者称为部分复制
  3. 如果无法部分同步(比如初次同步),则会请求进行全量同步,这时master服务器会将自己的rdb文件发送给slave服务器进行数据同步,并记录同步期间的其他写入,再发送给slave服务器,以达到完全同步的目的,这种方式称为全量复制

三、主从复制工作原理

  • 工作原理:
    master服务器会记录一个replicationId的伪随机字符串,用于标识当前的数据集版本,还会记录一个当数据集的偏移量offset,不管master是否有配置slave服务器,replication Id和offset会一直记录并成对存在,我们可以通过以下命令查看replication Id和offset:
> info repliaction

当master与slave正常连接时,slave使用PSYNC命令向master发送自己记录的旧master的replication id和offset,而master会计算与slave之间的数据偏移量,并将缓冲区中的偏移数量同步到slave,此时master和slave的数据一致。而如果slave引用的replication太旧了,master与slave之间的数据差异太大,则master与slave之间会使用全量复制的进行数据同步。之后每次主机的写操作,都会立刻发送给从机,从机执行相同的命令。

四、配置主从复制(两种方式)

假设主机地址:192.168.0.101

  1. 客户端发送同步命令
# 向客户端
saveof 192.168.1.101 6379
  1. slave服务器配置主服务器
    在这里slave服务器的redis.conf文件通过saveof选项,可以指定master服务器:
slaveof 192.168.1.101 6379
  1. 若master要求验证
    上面配置的是master服务器没有设置密码的情况,如果master设置了密码,则可以在连接到slave服务器的redis-cli执行下面的命令:
config set masterauth 密码

或者在slave服务器的redis.conf中配置下面的选项:

masterauth 密码

五、避免slave被清空

slave会被清空?slave不用同步了master的数据吗?备份的数据怎么会清空了呢?
当master服务器关闭了持久化时,如果发生故障后自动重启时,由本地没有保存持久化的数据,重启的Redis内存数据为空,而slave会自动同步master的数据,这时候,slave服务器的数据也会被清空。
如何避免slave被清空呢?

如果条件允许(一般都可以的),master服务器还是要开启持久化,这样master故障重启时,可以快速恢复数据,而同步这台master的slave数据也不会被清空。
如果master不能开启持久化,则不应该设置让master发生故障后重启(有些机器会配置自动重启),而是将某个slave服务器升级为master服务器,对外继续提供服务。

这就是后面会讲的哨兵机制。

六、主从复制中的key过期问题

我们都知道Redis可以通过设置key的过期时间来限制key的生存时间,Redis处理key过期有惰性删除和定期删除两种机制,而在配置主从复制后,slave服务器就没有权限处理过期的key,这样的话,对于在master上过期的key,在slave服务器就可能被读取,所以master会累积过期的key,积累一定的量之后,发送del命令到slave,删除slave上的key。
如果slave服务器升级为master服务器 ,则它将开始独立地计算key过期时间,而不需要通过master服务器的帮助。

七、哨兵机制

  1. 什么是哨兵机制
    在这里插入图片描述
    完整的哨兵机制体系
    在这里插入图片描述
  2. 为什么会出现哨兵机制(主从复制的问题存在问题)
    当master节点发生故障时,需要手动进行故障转移,写能力与存储能力受限,写能力和存储能力都依赖于master节点
  3. 哨兵机制的主要功能
    Sentinel 的主要功能包括:主节点存活检测、主从运行情况检测、自动故障转移 (failover)、主从切换。Redis 的 Sentinel 最小配置是 一主一从。
    Redis 的 Sentinel 系统可以用来管理多个 Redis 服务器,该系统可以执行以下四个任务:

1.监控
Sentinel 会不断的检查 主服务器 和 从服务器 是否正常运行。
2.通知 当被监控的某个 Redis服务器出现问题,Sentinel 通过 API 脚本 向 管理员 或者其他的 应用程序 发送通知。
3.自动故障转移
当主节点不能正常工作时,Sentinel会开始一次自动的故障转移操作,它会将与失效主节点是主从关系的其中一个从节点 升级为新的主节点,并且将其他的 从节点 指向 新的主节点。
4. 配置提供者
在 Redis Sentinel 模式下,客户端应用 在初始化时连接的是 Sentinel 节点集合,从中获取主节点的信息。

  1. 主观下线和客观下线
    默认情况下,每个 Sentinel 节点会以 每秒一次 的频率对 Redis 节点和 其它 的 Sentinel 节点发送 PING 命令,并通过节点的 回复 来判断节点是否在线。

主观下线

主观下线 适用于所有 主节点 和 从节点。如果在 down-after-milliseconds 毫秒内,Sentinel 没有收到目标节点 的有效回复,则会判定 该节点 为 主观下线。

客观下线

客观下线 只适用于 主节点。如果 主节点 出现故障,Sentinel 节点会通过 sentinel
is-master-down-by-addr 命令,向其它 Sentinel 节点询问对该节点的 状态判断。如果超过
个数的节点判定 主节点 不可达,则该 Sentinel 节点会判断 主节点 为 客观下线。

  1. 哨兵机制原理
    在这里插入图片描述
    更详细的哨兵机制介绍参考大佬文章
    本文参考文章
评论 1
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值