按关键词阅读：
作者:与昊
出处:
Redis的主从复制模式下 ， 一旦主节点由于故障不能提供服务 ， 需要人工将从节点晋升为主节点 ， 同时还要通知应用方更新主节点地址 ， 对于很多应用场景这种故障处理的方式是无法接受的 。 Redis从2.8版本开始正式提供了Redis Sentinel（哨兵）架构来解决这个问题 。
基本概念
文章插图
文章插图
主从复制的问题Redis的主从复制模式可以将主节点的数据改变同步给从节点 ， 这样从节点就可以起到两个作用：第一 ， 作为主节点的一个备份 ， 一旦主节点出了故障不可达的情况 ， 从节点可以作为后备“顶”上来 ， 并且保证数据尽量不丢失（主从复制是最终一致性） 。 第二 ， 从节点可以扩展主节点的读能力 ， 一旦主节点不能支撑住大并发量的读操作 ， 从节点可以在一定程度上帮助主节点分担读压力 。
但是主从复制也带来了以下问题：
- 一旦主节点出现故障 ， 需要手动将一个从节点晋升为主节点 ， 同时需要修改应用方的主节点地址 ， 还需要命令其他从节点去复制新的主节点 ， 整个过程都需要人工干预 。
- 主节点的写能力受到单机的限制 。
- 主节点的存储能力受到单机的限制 。
高可用Redis主从复制模式下 ， 一旦主节点出现了故障不可达 ， 需要人工干预进行故障转移 ， 无论对于Redis的应用方还是运维方都带来了很大的不便 。 对于应用方来说无法及时感知到主节点的变化 ， 必然会造成一定的写数据丢失和读数据错误 ， 甚至可能造成应用方服务不可用 。 对于Redis的运维方来说 ， 整个故障转移的过程是需要人工来介入的 ， 故障转移实时性和准确性上都无法得到保障 。
考虑到这点 ， 有些公司把故障转移流程自动化了 ， 但是仍然存在如下问题：第一 ， 判断节点不可达的机制是否健全和标准 。 第二 ， 如果有多个从节点 ， 怎样保证只有一个被晋升为主节点 。 第三 ， 通知客户端新的主节点机制是否足够健壮 。 Redis Sentinel正是用于解决这些问题 。
Redis Sentinel的高可用性Redis Sentinel是一个分布式架构 ， 其中包含若干个Sentinel节点和Redis数据节点 ，每个Sentinel节点会对数据节点和其余Sentinel节点进行监控 ， 当它发现节点不可达时 ， 会对节点做下线标识 。 如果被标识的是主节点 ， 它还会和其他Sentinel节点进行“协商” ， 当大多数Sentinel节点都认为主节点不可达时 ， 它们会选举出一个Sentinel节点来完成自动故障转移的工作 ， 同时会将这个变化实时通知给Redis应用方。 整个过程完全是自动的 ， 不需要人工来介入 ， 所以这套方案很有效地解决了Redis的高可用问题 。
从逻辑架构上看 ， Sentinel节点集合会定期对所有节点进行监控 ， 特别是对主节点的故障实现自动转移 。 下面以1个主节点、2个从节点、3个Sentinel节点组成的Redis Sentinel为例子进行说明 ， 拓扑结构如图所示 。
文章插图整个故障转移的处理逻辑有下面4个步骤：
- 主节点出现故障 ， 此时两个从节点与主节点失去连接 ， 主从复制失败 。
- 每个Sentinel节点通过定期监控发现主节点出现了故障 。
- 多个Sentinel节点对主节点的故障达成一致 ， 选举出sentinel-3节点作为领导者负责故障转移 。
- Sentinel领导者节点执行了故障转移 ， 整个过程是自动化完成的 。
文章插图通过上面介绍的Redis Sentinel逻辑架构以及故障转移的处理 ， 可以看出Redis Sentinel具有以下几个功能：
- 监控 ：Sentinel节点会定期检测Redis数据节点、其余Sentinel节点是否可达 。
- 通知 ：Sentinel节点会将故障转移的结果通知给应用方 。
- 主节点故障转移 ：实现从节点晋升为主节点并维护后续正确的主从关系 。
- 配置提供者 ：在Redis Sentinel结构中 ， 客户端在初始化的时候连接的是Sentinel节点集合 ， 从中获取主节点信息 。
- 对于节点的故障判断是由多个Sentinel节点共同完成 ， 这样可以有效地防止误判 。
稿源：(未知)
【傻大方】网址：http://www.shadafang.com/c/111T31c12020.html
标题：「Redis-多机功能」Sentinel