Redis架构演进
一主二从
这也是常用的架构,,MASTER用于写服务,SLAVE提供读服务 但是存在弊端, 就是主MASTER宕机后, SLAVE无法升级, 导致无法提供写服务
哨兵监控
为了解决主从架构的MASTER宕机问题, 架构引入哨兵监控机制, 一般哨兵也是集群,最少节点为3, 为什么呢
故障转移-主观下线
应为单哨兵, 可能存在主观下线问题, 因为网络的延迟波动, 导致单哨兵主观认为MASTER节点宕机, 导致其被强制下线, 但是其实是应为网络波动的问题, MASTER并没有问题
故障转移-客观下线
为了解决主观下线问题, 所以需要哨兵节点至少为3, 而确认需要配置为2, 只有哨兵集群中2个哨兵同时认为MASTER节点宕机, MASTER才会被下线, 解决了单哨兵的主观下线问题, 从而达到故障转移, 多哨兵, 那么由谁去做故障转移呢, 那么就会设计到哨兵的Leader选举机制
哨兵Leader选举机制
采用投票机制, 3个哨兵中, 谁获得的票数高, 谁就会成为Leader, 进行故障准一的工作
当leader对其中一台SLAVE升级之后, 其他的SLAVE会将MASTER切换为当前新上任的MASTER, 并且新MASTER会给所有的SLAVE进行数据同步,, 并且哨兵集群将继续监控
原MASTER恢复
当原来的MASTER被修复后,重新复活, 被哨兵检测到, 会自动将其降级成SLAVE并加入当前的集群中, 然后新MASTER对其进行数据同步, 复活的MASTER并不会成为MASTER, 而是服从新MASTER的安排, 自身为SLAVE
部署约定
- 哨兵节点至少要有3个或者3 (奇数)个节点
- 客观下线的投票数量的计算方式为: 哨兵数量/2 1, 至少要超过半数的哨兵投票
- 哨兵分布式的部署在不同的计算机节点
- 一组哨兵只监听一组主从
