参考网址:
https://tech.souyunku.com6844903663362637832
https://tech.souyunku.com6844903726142996494
1. Redis高可用概述
Redis高可用特性实现技术主要包括:持久化
、复制
、哨兵
和集群
。下面简单介绍下这几项技术概念:
- 持久化:主要作用是数据备份,将数据及时备份到硬盘上,防止由于由于服务宕机等原因丢失数据。
- 复制:复制是高可用Redis的基础,哨兵和集群模式都是复制模式基础上实现高可用的。复制主要实现了多机备份、读操作的负载均衡和简单的故障恢复。
- 哨兵:哨兵模式主要是在复制基础上实现了自动化的故障恢复。缺点是:写操作无法负载均衡和存储能力受单机限制。
- 集群:集群模式通过部署多台主服务器,解决了写操作无法负载均衡、和存储能力受单机限制的缺点,实现了较为完善的高可用方案。
2. 复制模式(Replication)
- 复制模式中,官网都使用了replica instance来描述,为了方便,还是称为从服务器。
2.1 概念
Redis支持多个从服务器复制主服务器的数据,实现多机备份、读操作负载均衡和简单故障恢复。
- 备注:主从复制模式,读操作请求会打到从服务器上?未验证。
2.2 同步过程
参考网址:
https://redis.io/topics/replication
https://tech.souyunku.com6844903726142996494#heading-8
https://tech.souyunku.com/manmanrenshenglu/p/9013151.html
主从服务之间同步数据包括两种方式:完全重同步
、部分重同步
和命令传播
。
2.2.1 命令传播
当主从服务器间正常链接时,主服务器会向从服务器发送写命令,从服务器接收写命令后执行相应写操作。
- 备注:写命令还包括键值过期等。
2.2.2 部分重同步
当主从服务器之间连接断开、或因网络原因发生超时,使用部分重同步来实现高效同步。在从服务器重新连接上主服务器时,从服务器会向发送PSYNC
命令,并报告偏移量,主服务器会根据偏移量发送连接断开期间的写命令序列(命令会存储在复制积压缓冲区),执行部分重同步
。
2.2.3 完全重同步
在部分重同步不可用、或初次建立连接的情况下(启动时就会),会使用完全重同步。从服务器会向主服务器发送SYNC
命令,主服务器需要进行如下操作:
- (1)使用
BGSAVE
进行全量持久化(RDB),并使用缓冲区存储现在开始的写命令; - (2)将生成的RDB文件发送给从服务器;
- (3)接着发送写命令序列给从服务器。
从服务器接收和载入来自主服务器的RDB文件,并执行写命令。
从服务器完全重同步日志
下图展示了从服务器启动时完全重同步的日志,可以看出发送SYNC命令后,接收RDB文件并载入,然后接收写命令序列,并写入AOF文件。
主服务器完全重同步日志
下图展示了主服务器完全重同步日志,可以看出收到SYNC命令后,进行全量持久化,并发送给从服务器。
2.3 特点
优点
- 多机备份:从服务器数据由主服务器复制过去,主从服务器数据一致;
- 读请求负载均衡:主服务器负责接收写请求,多台从服务器接收读请求,可以进行负载均衡。(未验证)
- 简单故障恢复:在主服务器不可用时,可以通过人工干预,将从服务器变成主服务器,需要修改客户端以及其它从服务器连接主服务器的地址。
缺点
- 主节点存储能力受限;
- 主节点写能力受限;
- 不能自动恢复;
3. 哨兵模式(Sentinel)
参考网址:
https://redis.io/topics/sentinel
https://tech.souyunku.com6844903663362637832
https://tech.souyunku.com6844903730786074638
3.1 概念
在主从复制模式基础上,增加哨兵节点(至少3个),用于进行节点存活检测和主从切换,用于实现自动化故障恢复。
整体上看,哨兵模式提供以下能力:
- 监控:每个哨兵节点会以每秒一次的频率向Redis主从节点节点、及Sentinel发送
PING
命令,根据回复判断其它节点是否在线。 - 通知:当某个被监控节点出现问题时,哨兵节点可以通过API向其它应用程序通知该事件。
- 故障转移:在主节点下线后,能够将从节点升级为主节点,保证服务的可用性。
- 配置提供:理解是主从切换后可以自动修改Redis节点配置文件。
3.2 节点存活检测
3.2.1 主观下线
如果在down-after-milliseconds
时间(默认30s)内主节点对哨兵节点的PING
命令都是无效回复,那么认为该主节点主观下线
(即当前哨兵节点主观认为该主节点下线)。
sentinel down-after-milliseconds <master-name> <milliseconds>
3.2.2 客观下线
在哨兵模式中,至少存在3个哨兵节点。
在某个哨兵节点判断主节点主管下线后,需要发送命令给其它哨兵节点,多个哨兵节点间进行投票,当超过quorum
个哨兵节点认为主节点下线,那么这时候认为主节点客观下线
。接下来会执行故障转移操作。
sentinel monitor <master-name> <ip> <redis-port> <quorum>
sentinel monitor mymaster 127.0.0.1 7102 2
3.3 选举领头哨兵
在检测出客观下线后,各个哨兵节点需要选举领头哨兵,由领头哨兵执行故障转移操作
。
选举策略暂未深入研究
3.4 故障转移
故障转移的操作主要可以分为以下步骤,这些步骤会修改哨兵节点和Redis节点配置文件。
- 从主节点的从节点中选取一台作为新的主节点;
- 其它从节点复制新的主节点,哨兵节点监听新的主节点;
- 已经下线的主节点重新连接时,使其变成从节点,并且复制新的主节点。
选取从节点的策略暂未研究。
故障转移过程参考图
(1)检测出客观下线
(2)选举领头哨兵,并选举新的主服务器
(3)旧主节点重连,成为从节点
3.5 故障转移实战
哨兵节点启动时
(1)哨兵节点日志
从三个哨兵节点日志中均可以观察到,监听主节点的信息,如下:
(2)连接redis节点查看主从信息
使用redis-cli
连接redis节点,使用info replication
命令可以查看当前节点角色、主节点信息,如下图:
(3)连接哨兵节点查看哨兵、主从节点信息
使用redis-cli
连接redis节点,使用info sentinel
命令可以查看主节点信息、哨兵数目、从节点数目,如下图:
关闭主节点后
通过关闭主节点,来观察哨兵模式自动故障恢复(主从切换)效果。
(1)哨兵节点日志
关闭主节点后,观察哨兵节点日志,可以发现经过了主节点客观下线 -> 选择新的主节点 —> 其它节点复制新的主节点 的三个过程。
(2)哨兵节点配置文件
此时,观察发现哨兵节点的配置文件也已经被修改。
主节点信息:
从节点信息:
(3)连接哨兵/redis节点查看主从信息
连接哨兵节点,观察到主节点已改变
连接redis节点,观察到主节点已改变
(4)查看redis节点配置文件
观察到配置文件已经被修改
(5)查看redis节点日志文件
观察到 同步主节点失败 -> 复制新的主节点 -> 进行部分重同步
3.6 特点
优点
- 高可用,能够自动故障恢复。
缺点
- 主节点写能力受单机限制。
- 主节点存储能力受单机限制。