9.1.1 主从复制的问题
主从复制模式的作用:
- 备份, 当主节点出故障, 从节点可以顶上来, 保证数据尽量不丢失
- 扩展主节点的读能力
主从复制带来的问题:
- 主节点出故障时, 需要手动将从节点晋升为主节点, 同时需要修改应用方的主节点地址, 还要命令其他从节点复制新主节点 (整个过程都需要人工干预)
- 主节点的写能力受到单机的限制
- 主节点的存储能力受到单机的限制
其中第一个问题就是 Redis 高可用问题, 第二、三个问题属于Redis的分布式问题
9.1.2 高可用
1主2从的 Redis 主从复制模式下的故障转移过程:
- 主节点发生故障后, 客户端 (client) 连接主节点失败, 两个从节点与主节点连接失败造成复制中断
图9-1 主节点发生故障
- 如果主节点无法正常启动, 需要选出一个从节点 (slave-1), 对其执行 slaveof no one 命令使其成为新的主节点
- 原来的从节点 (slave-1) 成为新的主节点后, 更新应用方的主节点信息,重新启动应用方
- 客户端命令另一个从节点 (slave-2) 去复制新的主节点 (new-master)
- 待原来的主节点恢复后, 让它去复制新的主节点
上述处理过程就可以认为整个服务或者架构的设计不是高可用的:
- 第一, 判断节点不可达的机制是否健全和标准。
- 第二, 如果有多个从节点,怎样保证只有一个被晋升为主节点。
- 第三, 通知客户端新的主节点机制是否足够健壮
9.1.3 Redis Sentinel 的高可用性
当主节点出现故障时, Redis Sentinel 能自动完成故障发现和故障转移, 并通知应用方, 从而实现真正的高可用。
Redis Sentinel 与 Redis 主从复制模式只是多了若干 Sentinel 节点, 所以 Redis Sentinel 并没有针对 Redis 节点做了特殊处理:
以1个主节点、2个从节点、3个 Sentinel 节点组成的 Redis Sentinel 为例子进行说明:
整个故障转移的处理逻辑有下面4个步骤:
- 主节点出现故障, 此时两个从节点与主节点失去连接, 主从复制失败
- 每个 Sentinel 节点通过定期监控发现主节点出现了故障
- 多个 Sentinel 节点对主节点的故障达成一致, 选举出 sentinel-3 节点作为领导者负责故障转移
- Sentinel 领导者节点执行了故障转移, 整个过程和9.1.2节介绍的是完全一致的
- 故障转移后整个 Redis Sentinel 的拓扑结构
图9-12 故障转移后的拓扑结构
Redis Sentinel 具有以下几个功能:
- 监控: Sentinel 节点会定期检测 Redis 数据节点、其余 Sentinel 节点是否可达
- 通知: Sentinel 节点会将故障转移的结果通知给应用方
- 主节点故障转移: 实现从节点晋升为主节点并维护后续正确的主从关系
- 配置提供者: 在 Redis Sentinel 结构中, 客户端在初始化的时候连接的是 Sentinel 节点集合, 从中获取主节点信息
Redis Sentinel 包含了若个 Sentinel 节点, 这样做也带来了两个好处:
- 对节点故障的判断由多个 Sentinel 节点共同完成, 防止误判
- Sentinel 节点集合是由若干个 Sentinel 节点组成的, 这样即使个别 Sentinel节点不可用, 整个 Sentinel 节点集合依然是健壮的