Redis Sentinel 基本架构
【Monitoring】
Sentinel 可以监控 Redis 节点的状态。
【Notification】
Sentinel 可以通过 API 进行集群状态通知。
【Automatic failover】
Sentinel 实现故障自动切换。
【Configuration provider】
Sentinel 为 client 提供发现 master 节点的发现功能，如果发生了切换，Sentinel 会通知 client 新的 master 地址。
【实现细节】
1. Sentinel 的选举是 Raft 算法
2. Sentinel 是独立运行的程序，但不是独立的代码
Sentinel 架构模式1 - 双节点 (1/2)
正常：两台服务器，每台服务器上分别部署 Sentinel和 Redis 节点。
• Quorum：Sentinel 对 master 故障达成一致意见的投票数。
• Majority：Sentinel 之间选举 leader 需要的投票数。
• 故障场景1：Master 挂掉，Sentinel 都正常。
• 故障影响：Replica 被提升为 Master。
Sentinel 架构模式1 - 双节点 (2/2)
• 故障场景2：服务器1挂掉，quorum=1，majority=2。
• 故障影响：无论服务器2是否挂掉，集群都宕机。
• 故障场景3：服务器1和服务器2的连接挂掉，quorum=1，majority=1。
• 故障影响：双主（脑裂）。
Sentinel 架构模式2 - 三节点(1/2)
正常：三台服务器，每台服务器上分别部署 Sentinel 和Redis 节点。
• 故障场景1：Master 挂掉，Sentinel 都正常。
• 故障影响：其中1个 Replica 被提升为 Master。
Sentinel 架构模式2 - 三节点(2/2)
• 故障场景2：服务器1挂掉，quorum = 2，majority=2。
• 故障影响：其中1个 Replica 被提升为 Master。
• 故障场景3：服务器1与服务器2和服务器3断连。
• 故障影响：其中1个 Replica 被提升为 Master，可能出现双主。
• 解决方案：min-replicas-to-write(最小写入副本数) 1; min-replicas-max-lag(最小副本最大滞后) 10
Sentinel 架构模式3 - 分离部署(1/3)
正常：Sentinel 和 Redis 分开部署，可以将 Sentinel 和 Redis 客户端所在的应用部署在一起，也可以独立部署。
Sentinel 架构模式3 - 分离部署(2/3)
• 故障场景1：Master 挂掉，Sentinel 都正常。
• 故障影响：其中1个 Replica 被提升为 Master。
Sentinel 架构模式3 - 分离部署(3/3)
• 故障场景2：服务器1和服务器4形成分区，剩余的服务器形成另外一个分区。
• 故障影响：双主（脑裂）。
• 解决方案：min-replicas-to-write 1; min-replicas-max-lag 10
Redis 集群架构模式对比
MongoDB Replication 基本架构
基本实现：
1. Primary 处理所有 Write 请求，Secondary可以处理 Read 请求，或者只复制数据。
2. 异步复制，复制的是 oplog。
3. 选举算法：3.2.0 以前基于 bully 算法，3.2.0开始基于 Raft 算法。
4. 最多50个节点，但最多只有7个节点参与选举。
新节点同步流程
基本实现：
1. 第1步：寻找同步源，MongoDB 支持级联复制，复制源不一定是 Primary，而是通过算法选出来的。
2. 第2步：全量复制数据和 oplog。
3. 第3步：同步全量复制后的增量数据，异步复制oplog。