Redis Sentinel设计技巧
Redis Sentinel基本架构
Monitoring
Sentinel可以监控Redis节点的状态
Notification
Sentinel可以通过API进行集群状态通知
Automatic failover
Sentinel实现故障自动切换
Configuration provider
Sentinel为client提供发现master节点的发现功能,如果发生了切换,Sentinel会通知client新的master地址
实现细节
- Sentinel的选举是Raft算法
- 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集群架构模式对比
架构模式 | 硬件成本 | 架构复杂度 | 双主 | 故障处理能力 |
---|---|---|---|---|
双节点 | 2台服务器 | 低 | 是,Majority=1 | 只能支持Master节点故障,其他故障不支持 |
三节点 | 3台服务器 | 中 | 是,网络分区,可以通过 min-replicas-to-write, min-replicas-max-lag 来避免 | 支持Master节点故障,Sentinel节点故障 |
分离部署 | 多台服务器,Sentinel可以和业务服务器公用 | 高 | 是,网络分区,可以通过 min-replicas-to-write, min-replicas-max-lag 来避免 | 支持Master节点故障,Sentinel节点故障 |
MongoDB Replication设计技巧
MongoDB Replication基本架构
基本实现
- Primary处理所有Write请求,Secondary可以处理Read请求,或者只复制数据
- 异步复制,复制的是oplog
- 选举算法:3.2.0以前基于bully算法,3.2.0开始基于Raft算法
- 最多50个节点,但最多只有7个节点参与选举
MongoDB Replication-新节点同步流程
基本实现
- 第1步:寻找同步源,MongoDB支持级联复制,复制源不一定是Primary,而是通过算法选出来的
- 第2步:全量复制数据和oplog
- 第3步:同步全量复制后的增量数据,异步复制oplog
MongoDB Replication架构技巧
技巧1-Read preference
基本实现
- 默认读Primary,指定read preference来读取Secondary
- 可能读不到最新数据
- 事务必须读Primary
- 包含5种preference:primary, primaryPreferred, secondary, secondaryPreferred, nearest
- 通过API或者连接配置参数
技巧2-Arbiter
基本实现
- Arbiter只投票,不复制数据
- Arbiter永远是Arbiter,相当于“仲裁者”