Redis Sentinel设计技巧

Redis Sentinel基本架构

Monitoring

Sentinel可以监控Redis节点的状态

Notification

Sentinel可以通过API进行集群状态通知

Automatic failover

Sentinel实现故障自动切换

Configuration provider

Sentinel为client提供发现master节点的发现功能，如果发生了切换，Sentinel会通知client新的master地址

实现细节

1. Sentinel的选举是Raft算法
2. Sentinel是独立运行的程序，但不是独立的代码：redis-server /path/to/sentinel.conf --sentinel

Sentinel架构模式

模式1-双节点

正常：两台服务器，每台服务器上分别部署Sentinel和Redis节点

Quorum：Sentinel对master故障达成一致意见的投票数

Majority：Sentinel之间选举leader需要的投票数

故障场景1：Master挂掉，Sentinel都正常

故障影响：Replica被提升为Master

故障场景2：服务器1挂掉，quorum=1，majority=2

故障影响：无论服务器2是否挂掉，集群都宕机

故障场景3：服务器1和服务器2的连接挂掉，quorum=1，majority=1

故障影响：双主（脑裂）

模式2-三节点

正常：三台服务器，每台服务器上分别部署Sentinel和Redis节点

故障场景1：Master挂掉，Sentinel都正常

故障影响：其中1个Replica被提升为Master

故障场景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

模式3-分离部署

正常：Sentinel和Redis分开部署，可以将Sentinel和Redis客户端所在的应用部署在一起，也可以独立部署

故障场景1：Master挂掉，Sentinel都正常

故障影响：其中1个Replica被提升为Master

故障场景2：服务器1和服务器4形成分区，剩余的服务器形成另外一个分区

故障影响：双主（脑裂）

解决方案：min-replicas-to-write 1; min-replicas-max-lag 10

Redis集群架构模式对比

MongoDB Replication设计技巧

MongoDB Replication基本架构

基本实现

1. Primary处理所有Write请求，Secondary可以处理Read请求，或者只复制数据
2. 异步复制，复制的是oplog
3. 选举算法：3.2.0以前基于bully算法，3.2.0开始基于Raft算法
4. 最多50个节点，但最多只有7个节点参与选举

MongoDB Replication-新节点同步流程

基本实现

1. 第1步：寻找同步源，MongoDB支持级联复制，复制源不一定是Primary，而是通过算法选出来的
2. 第2步：全量复制数据和oplog
3. 第3步：同步全量复制后的增量数据，异步复制oplog

MongoDB Replication架构技巧

技巧1-Read preference

基本实现

1. 默认读Primary，指定read preference来读取Secondary
2. 可能读不到最新数据
3. 事务必须读Primary
4. 包含5种preference：primary, primaryPreferred, secondary, secondaryPreferred, nearest
5. 通过API或者连接配置参数

技巧2-Arbiter

基本实现

1. Arbiter只投票，不复制数据
2. Arbiter永远是Arbiter，相当于“仲裁者”