1. 首页
  2. IT资讯

一文带你了解Redis哨兵模式和高可用集群解析(万字长文)

“u003Cpu003Eu003Cstrongu003E前言u003Cu002Fstrongu003Eu003Cu002Fpu003Eu003Cpu003Eu003Cstrongu003E Redis u003Cu002Fstrongu003E的 u003Cstrongu003E主从复制u003Cu002Fstrongu003E 模式下,一旦 u003Cstrongu003E主节点u003Cu002Fstrongu003E 由于故障不能提供服务,需要手动将 u003Cstrongu003E从节点u003Cu002Fstrongu003E 晋升为 u003Cstrongu003E主节点u003Cu002Fstrongu003E,同时还要通知 u003Cstrongu003E客户端u003Cu002Fstrongu003E 更新 u003Cstrongu003E主节点地址u003Cu002Fstrongu003E,这种故障处理方式从一定程度上是无法接受的。Redis 2.8 以后提供了 u003Cstrongu003ERedis Sentinel 哨兵机制u003Cu002Fstrongu003E 来解决这个问题。u003Cu002Fpu003Eu003Cdiv class=”pgc-img”u003Eu003Cimg src=”http:u002Fu002Fp1.pstatp.comu002Flargeu002Fpgc-imageu002F01e976c8c73645cb913dfbef62b34b46″ img_width=”1772″ img_height=”591″ alt=”一文带你了解Redis哨兵模式和高可用集群解析(万字长文)” inline=”0″u003Eu003Cp class=”pgc-img-caption”u003Eu003Cu002Fpu003Eu003Cu002Fdivu003Eu003Ch1u003Eu003Cstrongu003E正文u003Cu002Fstrongu003Eu003Cu002Fh1u003Eu003Ch1u003Eu003Cstrongu003E1. Redis高可用概述u003Cu002Fstrongu003Eu003Cu002Fh1u003Eu003Cpu003E在 Web 服务器中,u003Cstrongu003E高可用u003Cu002Fstrongu003E 是指服务器可以 u003Cstrongu003E正常访问u003Cu002Fstrongu003E 的时间,衡量的标准是在 u003Cstrongu003E多长时间u003Cu002Fstrongu003E 内可以提供正常服务(99.9%、99.99%、99.999% 等等)。在 Redis 层面,u003Cstrongu003E高可用u003Cu002Fstrongu003E 的含义要宽泛一些,除了保证提供 u003Cstrongu003E正常服务u003Cu002Fstrongu003E(如 u003Cstrongu003E主从分离u003Cu002Fstrongu003E、u003Cstrongu003E快速容灾技术u003Cu002Fstrongu003E 等),还需要考虑 u003Cstrongu003E数据容量扩展u003Cu002Fstrongu003E、u003Cstrongu003E数据安全u003Cu002Fstrongu003E 等等。u003Cu002Fpu003Eu003Cpu003E在 Redis 中,实现 u003Cstrongu003E高可用u003Cu002Fstrongu003E 的技术主要包括 u003Cstrongu003E持久化u003Cu002Fstrongu003E、u003Cstrongu003E复制u003Cu002Fstrongu003E、u003Cstrongu003E哨兵u003Cu002Fstrongu003E 和 u003Cstrongu003E集群u003Cu002Fstrongu003E,下面简单说明它们的作用,以及解决了什么样的问题:u003Cu002Fpu003Eu003Cul class=””u003Eu003Cliu003Eu003Cstrongu003E持久化u003Cu002Fstrongu003E:持久化是 u003Cstrongu003E最简单的u003Cu002Fstrongu003E 高可用方法。它的主要作用是 u003Cstrongu003E数据备份u003Cu002Fstrongu003E,即将数据存储在 u003Cstrongu003E硬盘u003Cu002Fstrongu003E,保证数据不会因进程退出而丢失。u003Cu002Fliu003Eu003Cliu003Eu003Cstrongu003E复制u003Cu002Fstrongu003E:复制是高可用 Redis 的基础,u003Cstrongu003E哨兵u003Cu002Fstrongu003E 和 u003Cstrongu003E集群u003Cu002Fstrongu003E 都是在 u003Cstrongu003E复制基础u003Cu002Fstrongu003E 上实现高可用的。复制主要实现了数据的多机备份以及对于读操作的负载均衡和简单的故障恢复。缺陷是故障恢复无法自动化、写操作无法负载均衡、存储能力受到单机的限制。u003Cu002Fliu003Eu003Cliu003Eu003Cstrongu003E哨兵u003Cu002Fstrongu003E:在复制的基础上,哨兵实现了 u003Cstrongu003E自动化u003Cu002Fstrongu003E 的 u003Cstrongu003E故障恢复u003Cu002Fstrongu003E。缺陷是 u003Cstrongu003E写操作u003Cu002Fstrongu003E 无法 u003Cstrongu003E负载均衡u003Cu002Fstrongu003E,u003Cstrongu003E存储能力u003Cu002Fstrongu003E 受到 u003Cstrongu003E单机u003Cu002Fstrongu003E 的限制。u003Cu002Fliu003Eu003Cliu003Eu003Cstrongu003E集群u003Cu002Fstrongu003E:通过集群,Redis 解决了 u003Cstrongu003E写操作u003Cu002Fstrongu003E 无法 u003Cstrongu003E负载均衡u003Cu002Fstrongu003E 以及 u003Cstrongu003E存储能力u003Cu002Fstrongu003E 受到 u003Cstrongu003E单机限制u003Cu002Fstrongu003E 的问题,实现了较为 u003Cstrongu003E完善u003Cu002Fstrongu003E 的 u003Cstrongu003E高可用方案u003Cu002Fstrongu003E。u003Cu002Fliu003Eu003Cu002Fulu003Eu003Ch1u003Eu003Cstrongu003E2. Redis Sentinel的基本概念u003Cu002Fstrongu003Eu003Cu002Fh1u003Eu003Cpu003ERedis Sentinel 是 Redis u003Cstrongu003E高可用u003Cu002Fstrongu003E 的实现方案。Sentinel 是一个管理多个 Redis 实例的工具,它可以实现对 Redis 的 u003Cstrongu003E监控u003Cu002Fstrongu003E、u003Cstrongu003E通知u003Cu002Fstrongu003E、u003Cstrongu003E自动故障转移u003Cu002Fstrongu003E。下面先对 Redis Sentinel 的 u003Cstrongu003E基本概念u003Cu002Fstrongu003E 进行简单的介绍。u003Cu002Fpu003Eu003Cpu003E基本名词说明:u003Cu002Fpu003Eu003Cdiv class=”pgc-img”u003Eu003Cimg src=”http:u002Fu002Fp1.pstatp.comu002Flargeu002Fpgc-imageu002F08e9cb34b1b04a4dab4802f88ea22c31″ img_width=”605″ img_height=”312″ alt=”一文带你了解Redis哨兵模式和高可用集群解析(万字长文)” inline=”0″u003Eu003Cp class=”pgc-img-caption”u003Eu003Cu002Fpu003Eu003Cu002Fdivu003Eu003Cpu003E如图所示,Redis 的 u003Cstrongu003E主从复制模式u003Cu002Fstrongu003E 和 Sentinel u003Cstrongu003E高可用架构u003Cu002Fstrongu003E 的示意图:u003Cu002Fpu003Eu003Cpu003E u003Cu002Fpu003Eu003Cdiv class=”pgc-img”u003Eu003Cimg src=”http:u002Fu002Fp1.pstatp.comu002Flargeu002Fpgc-imageu002Fa0276d62804e44659e9328ff4d215bec” img_width=”1033″ img_height=”601″ alt=”一文带你了解Redis哨兵模式和高可用集群解析(万字长文)” inline=”0″u003Eu003Cp class=”pgc-img-caption”u003Eu003Cu002Fpu003Eu003Cu002Fdivu003Eu003Cpu003E u003Cu002Fpu003Eu003Ch1u003Eu003Cstrongu003E3. Redis主从复制的问题u003Cu002Fstrongu003Eu003Cu002Fh1u003Eu003Cpu003ERedis u003Cstrongu003E主从复制u003Cu002Fstrongu003E 可将 u003Cstrongu003E主节点u003Cu002Fstrongu003E 数据同步给 u003Cstrongu003E从节点u003Cu002Fstrongu003E,从节点此时有两个作用:u003Cu002Fpu003Eu003Col start=”1″u003Eu003Cliu003E一旦 u003Cstrongu003E主节点宕机u003Cu002Fstrongu003E,u003Cstrongu003E从节点u003Cu002Fstrongu003E 作为 u003Cstrongu003E主节点u003Cu002Fstrongu003E 的 u003Cstrongu003E备份u003Cu002Fstrongu003E 可以随时顶上来。u003Cu002Fliu003Eu003Cliu003E扩展 u003Cstrongu003E主节点u003Cu002Fstrongu003E 的 u003Cstrongu003E读能力u003Cu002Fstrongu003E,分担主节点读压力。u003Cu002Fliu003Eu003Cu002Folu003Eu003Cpu003E u003Cu002Fpu003Eu003Cdiv class=”pgc-img”u003Eu003Cimg src=”http:u002Fu002Fp3.pstatp.comu002Flargeu002Fpgc-imageu002Fafa0683067174bebb27a15691a510a34″ img_width=”394″ img_height=”338″ alt=”一文带你了解Redis哨兵模式和高可用集群解析(万字长文)” inline=”0″u003Eu003Cp class=”pgc-img-caption”u003Eu003Cu002Fpu003Eu003Cu002Fdivu003Eu003Cpu003E u003Cu002Fpu003Eu003Cpu003Eu003Cstrongu003E主从复制u003Cu002Fstrongu003E 同时存在以下几个问题:u003Cu002Fpu003Eu003Col start=”1″u003Eu003Cliu003E一旦 u003Cstrongu003E主节点宕机u003Cu002Fstrongu003E,u003Cstrongu003E从节点u003Cu002Fstrongu003E 晋升成 u003Cstrongu003E主节点u003Cu002Fstrongu003E,同时需要修改 u003Cstrongu003E应用方u003Cu002Fstrongu003E 的 u003Cstrongu003E主节点地址u003Cu002Fstrongu003E,还需要命令所有 u003Cstrongu003E从节点u003Cu002Fstrongu003E去 u003Cstrongu003E复制u003Cu002Fstrongu003E 新的主节点,整个过程需要 u003Cstrongu003E人工干预u003Cu002Fstrongu003E。u003Cu002Fliu003Eu003Cliu003Eu003Cstrongu003E主节点u003Cu002Fstrongu003E 的 u003Cstrongu003E写能力u003Cu002Fstrongu003E 受到 u003Cstrongu003E单机的限制u003Cu002Fstrongu003E。u003Cu002Fliu003Eu003Cliu003Eu003Cstrongu003E主节点u003Cu002Fstrongu003E 的 u003Cstrongu003E存储能力u003Cu002Fstrongu003E 受到 u003Cstrongu003E单机的限制u003Cu002Fstrongu003E。u003Cu002Fliu003Eu003Cliu003Eu003Cstrongu003E原生复制u003Cu002Fstrongu003E 的弊端在早期的版本中也会比较突出,比如:Redis u003Cstrongu003E复制中断u003Cu002Fstrongu003E 后,u003Cstrongu003E从节点u003Cu002Fstrongu003E 会发起 psync。此时如果 u003Cstrongu003E同步不成功u003Cu002Fstrongu003E,则会进行 u003Cstrongu003E全量同步u003Cu002Fstrongu003E,u003Cstrongu003E主库u003Cu002Fstrongu003E 执行 u003Cstrongu003E全量备份u003Cu002Fstrongu003E 的同时,可能会造成毫秒或秒级的 u003Cstrongu003E卡顿u003Cu002Fstrongu003E。u003Cu002Fliu003Eu003Cu002Folu003Eu003Ch1u003Eu003Cstrongu003E4. Redis Sentinel深入探究u003Cu002Fstrongu003Eu003Cu002Fh1u003Eu003Cpu003Eu003Cstrongu003E4.1. Redis Sentinel的架构u003Cu002Fstrongu003Eu003Cu002Fpu003Eu003Cdiv class=”pgc-img”u003Eu003Cimg src=”http:u002Fu002Fp1.pstatp.comu002Flargeu002Fpgc-imageu002Fa687c724da924800a8756b956118556a” img_width=”478″ img_height=”550″ alt=”一文带你了解Redis哨兵模式和高可用集群解析(万字长文)” inline=”0″u003Eu003Cp class=”pgc-img-caption”u003Eu003Cu002Fpu003Eu003Cu002Fdivu003Eu003Cpu003E u003Cu002Fpu003Eu003Cpu003Eu003Cstrongu003E4.2. Redis Sentinel的主要功能u003Cu002Fstrongu003Eu003Cu002Fpu003Eu003Cpu003ESentinel 的主要功能包括 u003Cstrongu003E主节点存活检测u003Cu002Fstrongu003E、u003Cstrongu003E主从运行情况检测u003Cu002Fstrongu003E、u003Cstrongu003E自动故障转移u003Cu002Fstrongu003E (failover)、u003Cstrongu003E主从切换u003Cu002Fstrongu003E。Redis 的 Sentinel 最小配置是 u003Cstrongu003E一主一从u003Cu002Fstrongu003E。u003Cu002Fpu003Eu003Cpu003ERedis 的 Sentinel 系统可以用来管理多个 Redis 服务器,该系统可以执行以下四个任务:u003Cu002Fpu003Eu003Cul class=””u003Eu003Cliu003Eu003Cstrongu003E监控u003Cu002Fstrongu003Eu003Cu002Fliu003Eu003Cu002Fulu003Eu003Cpu003ESentinel 会不断的检查 u003Cstrongu003E主服务器u003Cu002Fstrongu003E 和 u003Cstrongu003E从服务器u003Cu002Fstrongu003E 是否正常运行。u003Cu002Fpu003Eu003Cul class=””u003Eu003Cliu003Eu003Cstrongu003E通知u003Cu002Fstrongu003Eu003Cu002Fliu003Eu003Cu002Fulu003Eu003Cpu003E当被监控的某个 Redis 服务器出现问题,Sentinel 通过 API u003Cstrongu003E脚本u003Cu002Fstrongu003E 向 u003Cstrongu003E管理员u003Cu002Fstrongu003E 或者其他的 u003Cstrongu003E应用程序u003Cu002Fstrongu003E 发送通知。u003Cu002Fpu003Eu003Cul class=””u003Eu003Cliu003Eu003Cstrongu003E自动故障转移u003Cu002Fstrongu003Eu003Cu002Fliu003Eu003Cu002Fulu003Eu003Cpu003E当 u003Cstrongu003E主节点u003Cu002Fstrongu003E 不能正常工作时,Sentinel 会开始一次 u003Cstrongu003E自动的u003Cu002Fstrongu003E 故障转移操作,它会将与 u003Cstrongu003E失效主节点u003Cu002Fstrongu003E 是 u003Cstrongu003E主从关系u003Cu002Fstrongu003E 的其中一个 u003Cstrongu003E从节点u003Cu002Fstrongu003E 升级为新的 u003Cstrongu003E主节点u003Cu002Fstrongu003E,并且将其他的 u003Cstrongu003E从节点u003Cu002Fstrongu003E 指向 u003Cstrongu003E新的主节点u003Cu002Fstrongu003E。u003Cu002Fpu003Eu003Cul class=””u003Eu003Cliu003Eu003Cstrongu003E配置提供者u003Cu002Fstrongu003Eu003Cu002Fliu003Eu003Cu002Fulu003Eu003Cpu003E在 Redis Sentinel 模式下,u003Cstrongu003E客户端应用u003Cu002Fstrongu003E 在初始化时连接的是 Sentinel u003Cstrongu003E节点集合u003Cu002Fstrongu003E,从中获取 u003Cstrongu003E主节点u003Cu002Fstrongu003E 的信息。u003Cu002Fpu003Eu003Cpu003Eu003Cstrongu003E4.3. 主观下线和客观下线u003Cu002Fstrongu003Eu003Cu002Fpu003Eu003Cpu003E默认情况下,u003Cstrongu003E每个u003Cu002Fstrongu003E Sentinel 节点会以 u003Cstrongu003E每秒一次u003Cu002Fstrongu003E 的频率对 Redis 节点和 u003Cstrongu003E其它u003Cu002Fstrongu003E 的 Sentinel 节点发送 PING 命令,并通过节点的 u003Cstrongu003E回复u003Cu002Fstrongu003E 来判断节点是否在线。u003Cu002Fpu003Eu003Cul class=””u003Eu003Cliu003Eu003Cstrongu003E主观下线u003Cu002Fstrongu003Eu003Cu002Fliu003Eu003Cu002Fulu003Eu003Cpu003Eu003Cstrongu003E主观下线u003Cu002Fstrongu003E 适用于所有 u003Cstrongu003E主节点u003Cu002Fstrongu003E 和 u003Cstrongu003E从节点u003Cu002Fstrongu003E。如果在 down-after-milliseconds 毫秒内,Sentinel 没有收到 u003Cstrongu003E目标节点u003Cu002Fstrongu003E 的有效回复,则会判定 u003Cstrongu003E该节点u003Cu002Fstrongu003E 为 u003Cstrongu003E主观下线u003Cu002Fstrongu003E。u003Cu002Fpu003Eu003Cul class=””u003Eu003Cliu003Eu003Cstrongu003E客观下线u003Cu002Fstrongu003Eu003Cu002Fliu003Eu003Cu002Fulu003Eu003Cpu003Eu003Cstrongu003E客观下线u003Cu002Fstrongu003E 只适用于 u003Cstrongu003E主节点u003Cu002Fstrongu003E。如果 u003Cstrongu003E主节点u003Cu002Fstrongu003E 出现故障,Sentinel 节点会通过 sentinel is-master-down-by-addr命令,向其它 Sentinel 节点询问对该节点的 u003Cstrongu003E状态判断u003Cu002Fstrongu003E。如果超过 <quorum> 个数的节点判定 u003Cstrongu003E主节点u003Cu002Fstrongu003E 不可达,则该 Sentinel 节点会判断 u003Cstrongu003E主节点u003Cu002Fstrongu003E 为 u003Cstrongu003E客观下线u003Cu002Fstrongu003E。u003Cu002Fpu003Eu003Cpu003Eu003Cstrongu003E4.4. Sentinel的通信命令u003Cu002Fstrongu003Eu003Cu002Fpu003Eu003Cpu003ESentinel 节点连接一个 Redis 实例的时候,会创建 cmd 和 pubu002Fsub 两个 u003Cstrongu003E连接u003Cu002Fstrongu003E。Sentinel 通过 cmd 连接给 Redis发送命令,通过 pubu002Fsub 连接到 Redis 实例上的其他 Sentinel 实例。u003Cu002Fpu003Eu003Cp class=””u003ESentinel 与 Redis u003Cstrongu003E主节点u003Cu002Fstrongu003E 和 u003Cstrongu003E从节点u003Cu002Fstrongu003E 交互的命令,主要包括:u003Cu002Fpu003Eu003Cdiv class=”pgc-img”u003Eu003Cimg src=”http:u002Fu002Fp1.pstatp.comu002Flargeu002Fpgc-imageu002F5e9dccee9911448692b6629036ac5348″ img_width=”685″ img_height=”236″ alt=”一文带你了解Redis哨兵模式和高可用集群解析(万字长文)” inline=”0″u003Eu003Cp class=”pgc-img-caption”u003Eu003Cu002Fpu003Eu003Cu002Fdivu003Eu003Cpu003ESentinel 与 Sentinel 交互的命令,主要包括:u003Cu002Fpu003Eu003Cdiv class=”pgc-img”u003Eu003Cimg src=”http:u002Fu002Fp3.pstatp.comu002Flargeu002Fpgc-imageu002F415622cfca0e4e9095e78a6beae98cc4″ img_width=”691″ img_height=”138″ alt=”一文带你了解Redis哨兵模式和高可用集群解析(万字长文)” inline=”0″u003Eu003Cp class=”pgc-img-caption”u003Eu003Cu002Fpu003Eu003Cu002Fdivu003Eu003Cpu003Eu003Cstrongu003E4.5. Redis Sentinel的工作原理u003Cu002Fstrongu003Eu003Cu002Fpu003Eu003Cpu003E每个 Sentinel 节点都需要 u003Cstrongu003E定期执行u003Cu002Fstrongu003E 以下任务:u003Cu002Fpu003Eu003Cul class=””u003Eu003Cliu003E每个 Sentinel 以 u003Cstrongu003E每秒钟u003Cu002Fstrongu003E 一次的频率,向它所知的 u003Cstrongu003E主服务器u003Cu002Fstrongu003E、u003Cstrongu003E从服务器u003Cu002Fstrongu003E 以及其他 Sentinel u003Cstrongu003E实例u003Cu002Fstrongu003E 发送一个 PING 命令。u003Cu002Fliu003Eu003Cu002Fulu003Eu003Cdiv class=”pgc-img”u003Eu003Cimg src=”http:u002Fu002Fp1.pstatp.comu002Flargeu002Fpgc-imageu002F5b49f8e032424be9b8c588cf5784aeee” img_width=”692″ img_height=”493″ alt=”一文带你了解Redis哨兵模式和高可用集群解析(万字长文)” inline=”0″u003Eu003Cp class=”pgc-img-caption”u003Eu003Cu002Fpu003Eu003Cu002Fdivu003Eu003Cpu003E u003Cu002Fpu003Eu003Col start=”2″u003Eu003Cliu003E如果一个 u003Cstrongu003E实例u003Cu002Fstrongu003E(instance)距离 u003Cstrongu003E最后一次u003Cu002Fstrongu003E 有效回复 PING 命令的时间超过 down-after-milliseconds 所指定的值,那么这个实例会被 Sentinel 标记为 u003Cstrongu003E主观下线u003Cu002Fstrongu003E。u003Cu002Fliu003Eu003Cu002Folu003Eu003Cdiv class=”pgc-img”u003Eu003Cimg src=”http:u002Fu002Fp9.pstatp.comu002Flargeu002Fpgc-imageu002Fd5fa70466e684b6093d9a6eabbcb1c64″ img_width=”692″ img_height=”521″ alt=”一文带你了解Redis哨兵模式和高可用集群解析(万字长文)” inline=”0″u003Eu003Cp class=”pgc-img-caption”u003Eu003Cu002Fpu003Eu003Cu002Fdivu003Eu003Cpu003E u003Cu002Fpu003Eu003Col start=”3″u003Eu003Cliu003E如果一个 u003Cstrongu003E主服务器u003Cu002Fstrongu003E 被标记为 u003Cstrongu003E主观下线u003Cu002Fstrongu003E,那么正在 u003Cstrongu003E监视u003Cu002Fstrongu003E 这个 u003Cstrongu003E主服务器u003Cu002Fstrongu003E 的所有 Sentinel 节点,要以 u003Cstrongu003E每秒一次u003Cu002Fstrongu003E 的频率确认 u003Cstrongu003E主服务器u003Cu002Fstrongu003E 的确进入了 u003Cstrongu003E主观下线u003Cu002Fstrongu003E 状态。u003Cu002Fliu003Eu003Cu002Folu003Eu003Cdiv class=”pgc-img”u003Eu003Cimg src=”http:u002Fu002Fp1.pstatp.comu002Flargeu002Fpgc-imageu002Fca4a882f2c0a4cb8928e4379512ca8bd” img_width=”692″ img_height=”521″ alt=”一文带你了解Redis哨兵模式和高可用集群解析(万字长文)” inline=”0″u003Eu003Cp class=”pgc-img-caption”u003Eu003Cu002Fpu003Eu003Cu002Fdivu003Eu003Cpu003E u003Cu002Fpu003Eu003Col start=”4″u003Eu003Cliu003E如果一个 u003Cstrongu003E主服务器u003Cu002Fstrongu003E 被标记为 u003Cstrongu003E主观下线u003Cu002Fstrongu003E,并且有 u003Cstrongu003E足够数量u003Cu002Fstrongu003E 的 Sentinel(至少要达到 u003Cstrongu003E配置文件u003Cu002Fstrongu003E 指定的数量)在指定的 u003Cstrongu003E时间范围u003Cu002Fstrongu003E 内同意这一判断,那么这个 u003Cstrongu003E主服务器u003Cu002Fstrongu003E 被标记为 u003Cstrongu003E客观下线u003Cu002Fstrongu003E。u003Cu002Fliu003Eu003Cu002Folu003Eu003Cdiv class=”pgc-img”u003Eu003Cimg src=”http:u002Fu002Fp1.pstatp.comu002Flargeu002Fpgc-imageu002F7598bdb17969438e8d9a5a1ed28773d8″ img_width=”692″ img_height=”521″ alt=”一文带你了解Redis哨兵模式和高可用集群解析(万字长文)” inline=”0″u003Eu003Cp class=”pgc-img-caption”u003Eu003Cu002Fpu003Eu003Cu002Fdivu003Eu003Cpu003E u003Cu002Fpu003Eu003Col start=”5″u003Eu003Cliu003E在一般情况下, 每个 Sentinel 会以每 10 秒一次的频率,向它已知的所有 u003Cstrongu003E主服务器u003Cu002Fstrongu003E 和 u003Cstrongu003E从服务器u003Cu002Fstrongu003E 发送 INFO 命令。当一个 u003Cstrongu003E主服务器u003Cu002Fstrongu003E 被 Sentinel 标记为 u003Cstrongu003E客观下线u003Cu002Fstrongu003E 时,Sentinel 向 u003Cstrongu003E下线主服务器u003Cu002Fstrongu003E 的所有 u003Cstrongu003E从服务器u003Cu002Fstrongu003E 发送 INFO 命令的频率,会从 10 秒一次改为 u003Cstrongu003E每秒一次u003Cu002Fstrongu003E。u003Cu002Fliu003Eu003Cu002Folu003Eu003Cdiv class=”pgc-img”u003Eu003Cimg src=”http:u002Fu002Fp3.pstatp.comu002Flargeu002Fpgc-imageu002F241f753608b14a3f9396999842708efd” img_width=”752″ img_height=”511″ alt=”一文带你了解Redis哨兵模式和高可用集群解析(万字长文)” inline=”0″u003Eu003Cp class=”pgc-img-caption”u003Eu003Cu002Fpu003Eu003Cu002Fdivu003Eu003Cpu003E u003Cu002Fpu003Eu003Col start=”6″u003Eu003Cliu003ESentinel 和其他 Sentinel 协商 u003Cstrongu003E主节点u003Cu002Fstrongu003E 的状态,如果 u003Cstrongu003E主节点u003Cu002Fstrongu003E 处于 SDOWN 状态,则投票自动选出新的 u003Cstrongu003E主节点u003Cu002Fstrongu003E。将剩余的 u003Cstrongu003E从节点u003Cu002Fstrongu003E 指向 u003Cstrongu003E新的主节点u003Cu002Fstrongu003E 进行 u003Cstrongu003E数据复制u003Cu002Fstrongu003E。u003Cu002Fliu003Eu003Cu002Folu003Eu003Cdiv class=”pgc-img”u003Eu003Cimg src=”http:u002Fu002Fp3.pstatp.comu002Flargeu002Fpgc-imageu002F229dfb40ca074a69baa5c7c161fb995c” img_width=”752″ img_height=”569″ alt=”一文带你了解Redis哨兵模式和高可用集群解析(万字长文)” inline=”0″u003Eu003Cp class=”pgc-img-caption”u003Eu003Cu002Fpu003Eu003Cu002Fdivu003Eu003Cpu003E u003Cu002Fpu003Eu003Col start=”7″u003Eu003Cliu003E当没有足够数量的 Sentinel 同意 u003Cstrongu003E主服务器u003Cu002Fstrongu003E 下线时, u003Cstrongu003E主服务器u003Cu002Fstrongu003E 的 u003Cstrongu003E客观下线状态u003Cu002Fstrongu003E 就会被移除。当 u003Cstrongu003E主服务器u003Cu002Fstrongu003E 重新向 Sentinel 的 PING 命令返回 u003Cstrongu003E有效回复u003Cu002Fstrongu003E 时,u003Cstrongu003E主服务器u003Cu002Fstrongu003E 的 u003Cstrongu003E主观下线状态u003Cu002Fstrongu003E 就会被移除。u003Cu002Fliu003Eu003Cu002Folu003Eu003Cdiv class=”pgc-img”u003Eu003Cimg src=”http:u002Fu002Fp3.pstatp.comu002Flargeu002Fpgc-imageu002Fa49888526a4f4b338a6dfb8528b36acd” img_width=”1280″ img_height=”489″ alt=”一文带你了解Redis哨兵模式和高可用集群解析(万字长文)” inline=”0″u003Eu003Cp class=”pgc-img-caption”u003Eu003Cu002Fpu003Eu003Cu002Fdivu003Eu003Cblockquoteu003Eu003Cpu003E 注意:一个有效的 PING 回复可以是:+PONG、-LOADING 或者 -MASTERDOWN。如果 u003Cstrongu003E服务器u003Cu002Fstrongu003E 返回除以上三种回复之外的其他回复,又或者在 u003Cstrongu003E指定时间u003Cu002Fstrongu003E 内没有回复 PING 命令, 那么 Sentinel 认为服务器返回的回复 u003Cstrongu003E无效u003Cu002Fstrongu003E(non-valid)。u003Cu002Fpu003Eu003Cu002Fblockquoteu003Eu003Ch1u003Eu003Cstrongu003E5. Redis Sentinel搭建u003Cu002Fstrongu003Eu003Cu002Fh1u003Eu003Cpu003Eu003Cstrongu003E5.1. Redis Sentinel的部署须知u003Cu002Fstrongu003Eu003Cu002Fpu003Eu003Col start=”1″u003Eu003Cliu003E一个稳健的 Redis Sentinel 集群,应该使用至少 u003Cstrongu003E三个u003Cu002Fstrongu003E Sentinel 实例,并且保证讲这些实例放到 u003Cstrongu003E不同的机器u003Cu002Fstrongu003E 上,甚至不同的 u003Cstrongu003E物理区域u003Cu002Fstrongu003E。u003Cu002Fliu003Eu003Cliu003ESentinel 无法保证 u003Cstrongu003E强一致性u003Cu002Fstrongu003E。u003Cu002Fliu003Eu003Cliu003E常见的 u003Cstrongu003E客户端应用库u003Cu002Fstrongu003E 都支持 Sentinel。u003Cu002Fliu003Eu003Cliu003ESentinel 需要通过不断的 u003Cstrongu003E测试u003Cu002Fstrongu003E 和 u003Cstrongu003E观察u003Cu002Fstrongu003E,才能保证高可用。u003Cu002Fliu003Eu003Cu002Folu003Eu003Cpu003Eu003Cstrongu003E5.2. Redis Sentinel的配置文件u003Cu002Fstrongu003Eu003Cu002Fpu003Eu003Cpreu003E# 哨兵sentinel实例运行的端口,默认26379 u003Cbru003Eport 26379u003Cbru003E# 哨兵sentinel的工作目录u003Cbru003Edir .u002Fu003Cbru003Eu003Cbru003E# 哨兵sentinel监控的redis主节点的 u003Cbru003E## ip:主机ip地址u003Cbru003E## port:哨兵端口号u003Cbru003E## master-name:可以自己命名的主节点名字(只能由字母A-z、数字0-9 、这三个字符".-_"组成。)u003Cbru003E## quorum:当这些quorum个数sentinel哨兵认为master主节点失联 那么这时 客观上认为主节点失联了 u003Cbru003E# sentinel monitor <master-name> <ip> <redis-port> <quorum> u003Cbru003Esentinel monitor mymaster 127.0.0.1 6379 2u003Cbru003Eu003Cbru003E# 当在Redis实例中开启了requirepass <foobared>,所有连接Redis实例的客户端都要提供密码。u003Cbru003E# sentinel auth-pass <master-name> <password> u003Cbru003Esentinel auth-pass mymaster 123456 u003Cbru003Eu003Cbru003E# 指定主节点应答哨兵sentinel的最大时间间隔,超过这个时间,哨兵主观上认为主节点下线,默认30秒 u003Cbru003E# sentinel down-after-milliseconds <master-name> <milliseconds>u003Cbru003Esentinel down-after-milliseconds mymaster 30000 u003Cbru003Eu003Cbru003E# 指定了在发生failover主备切换时,最多可以有多少个slave同时对新的master进行同步。这个数字越小,完成failover所需的时间就越长;反之,但是如果这个数字越大,就意味着越多的slave因为replication而不可用。可以通过将这个值设为1,来保证每次只有一个slave,处于不能处理命令请求的状态。u003Cbru003E# sentinel parallel-syncs <master-name> <numslaves>u003Cbru003Esentinel parallel-syncs mymaster 1 u003Cbru003Eu003Cbru003E# 故障转移的超时时间failover-timeout,默认三分钟,可以用在以下这些方面:u003Cbru003E## 1. 同一个sentinel对同一个master两次failover之间的间隔时间。 u003Cbru003E## 2. 当一个slave从一个错误的master那里同步数据时开始,直到slave被纠正为从正确的master那里同步数据时结束。 u003Cbru003E## 3. 当想要取消一个正在进行的failover时所需要的时间。u003Cbru003E## 4.当进行failover时,配置所有slaves指向新的master所需的最大时间。不过,即使过了这个超时,slaves依然会被正确配置为指向master,但是就不按parallel-syncs所配置的规则来同步数据了u003Cbru003E# sentinel failover-timeout <master-name> <milliseconds> u003Cbru003Esentinel failover-timeout mymaster 180000u003Cbru003Eu003Cbru003E# 当sentinel有任何警告级别的事件发生时(比如说redis实例的主观失效和客观失效等等),将会去调用这个脚本。一个脚本的最大执行时间为60s,如果超过这个时间,脚本将会被一个SIGKILL信号终止,之后重新执行。u003Cbru003E# 对于脚本的运行结果有以下规则: u003Cbru003E## 1. 若脚本执行后返回1,那么该脚本稍后将会被再次执行,重复次数目前默认为10。u003Cbru003E## 2. 若脚本执行后返回2,或者比2更高的一个返回值,脚本将不会重复执行。 u003Cbru003E## 3. 如果脚本在执行过程中由于收到系统中断信号被终止了,则同返回值为1时的行为相同。u003Cbru003E# sentinel notification-script <master-name> <script-path> u003Cbru003Esentinel notification-script mymaster u002Fvaru002Fredisu002Fnotify.shu003Cbru003Eu003Cbru003E# 这个脚本应该是通用的,能被多次调用,不是针对性的。u003Cbru003E# sentinel client-reconfig-script <master-name> <script-path>u003Cbru003Esentinel client-reconfig-script mymaster u002Fvaru002Fredisu002Freconfig.shu003Cu002Fpreu003Eu003Cpu003Eu003Cbru002Fu003Eu003Cstrongu003E5.3. Redis Sentinel的节点规划u003Cu002Fstrongu003Eu003Cu002Fpu003Eu003Cdiv class=”pgc-img”u003Eu003Cimg src=”http:u002Fu002Fp3.pstatp.comu002Flargeu002Fpgc-imageu002F36f9069ae31148999e95eab4800f02a0″ img_width=”311″ img_height=”274″ alt=”一文带你了解Redis哨兵模式和高可用集群解析(万字长文)” inline=”0″u003Eu003Cp class=”pgc-img-caption”u003Eu003Cu002Fpu003Eu003Cu002Fdivu003Eu003Cpu003Eu003Cstrongu003E5.4. Redis Sentinel的配置搭建u003Cu002Fstrongu003Eu003Cu002Fpu003Eu003Cpu003Eu003Cstrongu003E5.4.1. Redis-Server的配置管理u003Cu002Fstrongu003Eu003Cu002Fpu003Eu003Cpu003E分别拷贝三份 redis.conf 文件到 u002Fusru002Flocalu002Fredis-sentinel 目录下面。三个配置文件分别对应 master、slave1 和 slave2 三个 Redis 节点的 u003Cstrongu003E启动配置u003Cu002Fstrongu003E。u003Cu002Fpu003Eu003Cpreu003E$ sudo cp u002Fusru002Flocalu002Fredis-4.0.11u002Fredis.conf u002Fusru002Flocalu002Fredis-sentinelu002Fredis-16379.confu003Cbru003E$ sudo cp u002Fusru002Flocalu002Fredis-4.0.11u002Fredis.conf u002Fusru002Flocalu002Fredis-sentinelu002Fredis-26379.confu003Cbru003E$ sudo cp u002Fusru002Flocalu002Fredis-4.0.11u002Fredis.conf u002Fusru002Flocalu002Fredis-sentinelu002Fredis-36379.confu003Cu002Fpreu003Eu003Cpu003E分别修改三份配置文件如下:u003Cu002Fpu003Eu003Cul class=””u003Eu003Cliu003E主节点:redis-16379.confu003Cu002Fliu003Eu003Cu002Fulu003Eu003Cpreu003Edaemonize yesu003Cbru003Epidfile u002Fvaru002Frunu002Fredis-16379.pidu003Cbru003Elogfile u002Fvaru002Flogu002Fredisu002Fredis-16379.logu003Cbru003Eport 16379u003Cbru003Ebind 0.0.0.0u003Cbru003Etimeout 300u003Cbru003Edatabases 16u003Cbru003Edbfilename dump-16379.dbu003Cbru003Edir .u002Fredis-workdiru003Cbru003Emasterauth 123456u003Cbru003Erequirepass 123456u003Cu002Fpreu003Eu003Cul class=””u003Eu003Cliu003E从节点1:redis-26379.confu003Cu002Fliu003Eu003Cu002Fulu003Eu003Cpreu003Edaemonize yesu003Cbru003Epidfile u002Fvaru002Frunu002Fredis-26379.pidu003Cbru003Elogfile u002Fvaru002Flogu002Fredisu002Fredis-26379.logu003Cbru003Eport 26379u003Cbru003Ebind 0.0.0.0u003Cbru003Etimeout 300u003Cbru003Edatabases 16u003Cbru003Edbfilename dump-26379.dbu003Cbru003Edir .u002Fredis-workdiru003Cbru003Emasterauth 123456u003Cbru003Erequirepass 123456u003Cbru003Eslaveof 127.0.0.1 16379u003Cu002Fpreu003Eu003Cul class=””u003Eu003Cliu003E从节点2:redis-36379.confu003Cu002Fliu003Eu003Cu002Fulu003Eu003Cpreu003Edaemonize yesu003Cbru003Epidfile u002Fvaru002Frunu002Fredis-36379.pidu003Cbru003Elogfile u002Fvaru002Flogu002Fredisu002Fredis-36379.logu003Cbru003Eport 36379u003Cbru003Ebind 0.0.0.0u003Cbru003Etimeout 300u003Cbru003Edatabases 16u003Cbru003Edbfilename dump-36379.dbu003Cbru003Edir .u002Fredis-workdiru003Cbru003Emasterauth 123456u003Cbru003Erequirepass 123456u003Cbru003Eslaveof 127.0.0.1 16379u003Cu002Fpreu003Eu003Cpu003E u003Cu002Fpu003Eu003Cblockquoteu003Eu003Cpu003E如果要做 u003Cstrongu003E自动故障转移u003Cu002Fstrongu003E,建议所有的 redis.conf 都设置 masterauth。因为 u003Cstrongu003E自动故障u003Cu002Fstrongu003E 只会重写 u003Cstrongu003E主从关系u003Cu002Fstrongu003E,即 slaveof,不会自动写入 masterauth。如果 Redis 原本没有设置密码,则可以忽略。u003Cu002Fpu003Eu003Cu002Fblockquoteu003Eu003Cpu003Eu003Cstrongu003E5.4.2. Redis-Server启动验证u003Cu002Fstrongu003Eu003Cu002Fpu003Eu003Cpu003E按顺序分别启动 16379,26379 和 36379 三个 Redis 节点,启动命令和启动日志如下:u003Cu002Fpu003Eu003Cpu003ERedis 的启动命令:u003Cu002Fpu003Eu003Cpreu003E$ sudo redis-server u002Fusru002Flocalu002Fredis-sentinelu002Fredis-16379.confu003Cbru003E$ sudo redis-server u002Fusru002Flocalu002Fredis-sentinelu002Fredis-26379.confu003Cbru003E$ sudo redis-server u002Fusru002Flocalu002Fredis-sentinelu002Fredis-36379.confu003Cu002Fpreu003Eu003Cpu003E查看 Redis 的启动进程:u003Cu002Fpu003Eu003Cpreu003E$ ps -ef | grep redis-serveru003Cbru003E 0 7127 1 0 2:16下午 ?? 0:01.84 redis-server 0.0.0.0:16379 u003Cbru003E 0 7133 1 0 2:16下午 ?? 0:01.73 redis-server 0.0.0.0:26379 u003Cbru003E 0 7137 1 0 2:16下午 ?? 0:01.70 redis-server 0.0.0.0:36379 u003Cu002Fpreu003Eu003Cpu003E u003Cu002Fpu003Eu003Cpreu003E u003Cu002Fpreu003Eu003Cpu003E查看 Redis 的启动日志:u003Cu002Fpu003Eu003Cul class=””u003Eu003Cliu003E节点 redis-16379u003Cu002Fliu003Eu003Cu002Fulu003Eu003Cpreu003E$ cat u002Fvaru002Flogu002Fredisu002Fredis-16379.log u003Cbru003E7126:C 22 Aug 14:16:38.907 # oO0OoO0OoO0Oo Redis is starting oO0OoO0OoO0Oou003Cbru003E7126:C 22 Aug 14:16:38.908 # Redis version=4.0.11, bits=64, commit=00000000, modified=0, pid=7126, just startedu003Cbru003E7126:C 22 Aug 14:16:38.908 # Configuration loadedu003Cbru003E7127:M 22 Aug 14:16:38.910 * Increased maximum number of open files to 10032 (it was originally set to 256).u003Cbru003E7127:M 22 Aug 14:16:38.912 * Running mode=standalone, port=16379.u003Cbru003E7127:M 22 Aug 14:16:38.913 # Server initializedu003Cbru003E7127:M 22 Aug 14:16:38.913 * Ready to accept connectionsu003Cbru003E7127:M 22 Aug 14:16:48.416 * Slave 127.0.0.1:26379 asks for synchronizationu003Cbru003E7127:M 22 Aug 14:16:48.416 * Full resync requested by slave 127.0.0.1:26379u003Cbru003E7127:M 22 Aug 14:16:48.416 * Starting BGSAVE for SYNC with target: disku003Cbru003E7127:M 22 Aug 14:16:48.416 * Background saving started by pid 7134u003Cbru003E7134:C 22 Aug 14:16:48.433 * DB saved on disku003Cbru003E7127:M 22 Aug 14:16:48.487 * Background saving terminated with successu003Cbru003E7127:M 22 Aug 14:16:48.494 * Synchronization with slave 127.0.0.1:26379 succeededu003Cbru003E7127:M 22 Aug 14:16:51.848 * Slave 127.0.0.1:36379 asks for synchronizationu003Cbru003E7127:M 22 Aug 14:16:51.849 * Full resync requested by slave 127.0.0.1:36379u003Cbru003E7127:M 22 Aug 14:16:51.849 * Starting BGSAVE for SYNC with target: disku003Cbru003E7127:M 22 Aug 14:16:51.850 * Background saving started by pid 7138u003Cbru003E7138:C 22 Aug 14:16:51.862 * DB saved on disku003Cbru003E7127:M 22 Aug 14:16:51.919 * Background saving terminated with successu003Cbru003E7127:M 22 Aug 14:16:51.923 * Synchronization with slave 127.0.0.1:36379 succeededu003Cu002Fpreu003Eu003Cpu003E 以下两行日志日志表明,redis-16379 作为 Redis 的 u003Cstrongu003E主节点u003Cu002Fstrongu003E,redis-26379 和 redis-36379 作为 u003Cstrongu003E从节点u003Cu002Fstrongu003E,从 u003Cstrongu003E主节点u003Cu002Fstrongu003E 同步数据。u003Cu002Fpu003Eu003Cpreu003E7127:M 22 Aug 14:16:48.416 * Slave 127.0.0.1:26379 asks for synchronizationu003Cbru003E7127:M 22 Aug 14:16:51.848 * Slave 127.0.0.1:36379 asks for synchronizationu003Cu002Fpreu003Eu003Cul class=””u003Eu003Cliu003E节点 redis-26379u003Cu002Fliu003Eu003Cu002Fulu003Eu003Cpreu003E$ cat u002Fvaru002Flogu002Fredisu002Fredis-26379.log u003Cbru003E7132:C 22 Aug 14:16:48.407 # oO0OoO0OoO0Oo Redis is starting oO0OoO0OoO0Oou003Cbru003E7132:C 22 Aug 14:16:48.408 # Redis version=4.0.11, bits=64, commit=00000000, modified=0, pid=7132, just startedu003Cbru003E7132:C 22 Aug 14:16:48.408 # Configuration loadedu003Cbru003E7133:S 22 Aug 14:16:48.410 * Increased maximum number of open files to 10032 (it was originally set to 256).u003Cbru003E7133:S 22 Aug 14:16:48.412 * Running mode=standalone, port=26379.u003Cbru003E7133:S 22 Aug 14:16:48.413 # Server initializedu003Cbru003E7133:S 22 Aug 14:16:48.413 * Ready to accept connectionsu003Cbru003E7133:S 22 Aug 14:16:48.413 * Connecting to MASTER 127.0.0.1:16379u003Cbru003E7133:S 22 Aug 14:16:48.413 * MASTER <-> SLAVE sync startedu003Cbru003E7133:S 22 Aug 14:16:48.414 * Non blocking connect for SYNC fired the event.u003Cbru003E7133:S 22 Aug 14:16:48.414 * Master replied to PING, replication can continue…u003Cbru003E7133:S 22 Aug 14:16:48.415 * Partial resynchronization not possible (no cached master)u003Cbru003E7133:S 22 Aug 14:16:48.417 * Full resync from master: 211d3b4eceaa3af4fe5c77d22adf06e1218e0e7b:0u003Cbru003E7133:S 22 Aug 14:16:48.494 * MASTER <-> SLAVE sync: receiving 176 bytes from masteru003Cbru003E7133:S 22 Aug 14:16:48.495 * MASTER <-> SLAVE sync: Flushing old datau003Cbru003E7133:S 22 Aug 14:16:48.496 * MASTER <-> SLAVE sync: Loading DB in memoryu003Cbru003E7133:S 22 Aug 14:16:48.498 * MASTER <-> SLAVE sync: Finished with successu003Cu002Fpreu003Eu003Cul class=””u003Eu003Cliu003E节点 redis-36379u003Cu002Fliu003Eu003Cu002Fulu003Eu003Cpreu003E$ cat u002Fvaru002Flogu002Fredisu002Fredis-36379.log u003Cbru003E7136:C 22 Aug 14:16:51.839 # oO0OoO0OoO0Oo Redis is starting oO0OoO0OoO0Oou003Cbru003E7136:C 22 Aug 14:16:51.840 # Redis version=4.0.11, bits=64, commit=00000000, modified=0, pid=7136, just startedu003Cbru003E7136:C 22 Aug 14:16:51.841 # Configuration loadedu003Cbru003E7137:S 22 Aug 14:16:51.843 * Increased maximum number of open files to 10032 (it was originally set to 256).u003Cbru003E7137:S 22 Aug 14:16:51.845 * Running mode=standalone, port=36379.u003Cbru003E7137:S 22 Aug 14:16:51.845 # Server initializedu003Cbru003E7137:S 22 Aug 14:16:51.846 * Ready to accept connectionsu003Cbru003E7137:S 22 Aug 14:16:51.846 * Connecting to MASTER 127.0.0.1:16379u003Cbru003E7137:S 22 Aug 14:16:51.847 * MASTER <-> SLAVE sync startedu003Cbru003E7137:S 22 Aug 14:16:51.847 * Non blocking connect for SYNC fired the event.u003Cbru003E7137:S 22 Aug 14:16:51.847 * Master replied to PING, replication can continue…u003Cbru003E7137:S 22 Aug 14:16:51.848 * Partial resynchronization not possible (no cached master)u003Cbru003E7137:S 22 Aug 14:16:51.850 * Full resync from master: 211d3b4eceaa3af4fe5c77d22adf06e1218e0e7b:14u003Cbru003E7137:S 22 Aug 14:16:51.923 * MASTER <-> SLAVE sync: receiving 176 bytes from masteru003Cbru003E7137:S 22 Aug 14:16:51.923 * MASTER <-> SLAVE sync: Flushing old datau003Cbru003E7137:S 22 Aug 14:16:51.924 * MASTER <-> SLAVE sync: Loading DB in memoryu003Cbru003E7137:S 22 Aug 14:16:51.927 * MASTER <-> SLAVE sync: Finished with successu003Cu002Fpreu003Eu003Cpu003Eu003Cstrongu003E5.4.3. Sentinel的配置管理u003Cu002Fstrongu003Eu003Cu002Fpu003Eu003Cpu003E分别拷贝三份 redis-sentinel.conf 文件到 u002Fusru002Flocalu002Fredis-sentinel 目录下面。三个配置文件分别对应 master、slave1 和 slave2 三个 Redis 节点的 u003Cstrongu003E哨兵配置u003Cu002Fstrongu003E。u003Cu002Fpu003Eu003Cpreu003E$ sudo cp u002Fusru002Flocalu002Fredis-4.0.11u002Fsentinel.conf u002Fusru002Flocalu002Fredis-sentinelu002Fsentinel-16380.confu003Cbru003E$ sudo cp u002Fusru002Flocalu002Fredis-4.0.11u002Fsentinel.conf u002Fusru002Flocalu002Fredis-sentinelu002Fsentinel-26380.confu003Cbru003E$ sudo cp u002Fusru002Flocalu002Fredis-4.0.11u002Fsentinel.conf u002Fusru002Flocalu002Fredis-sentinelu002Fsentinel-36380.confu003Cu002Fpreu003Eu003Cul class=””u003Eu003Cliu003E节点1:sentinel-16380.confu003Cu002Fliu003Eu003Cu002Fulu003Eu003Cpreu003Eprotected-mode nou003Cbru003Ebind 0.0.0.0u003Cbru003Eport 16380u003Cbru003Edaemonize yesu003Cbru003Esentinel monitor master 127.0.0.1 16379 2u003Cbru003Esentinel down-after-milliseconds master 5000u003Cbru003Esentinel failover-timeout master 180000u003Cbru003Esentinel parallel-syncs master 1u003Cbru003Esentinel auth-pass master 123456u003Cbru003Elogfile u002Fvaru002Flogu002Fredisu002Fsentinel-16380.logu003Cu002Fpreu003Eu003Cul class=””u003Eu003Cliu003E节点2:sentinel-26380.confu003Cu002Fliu003Eu003Cu002Fulu003Eu003Cpreu003Eprotected-mode nou003Cbru003Ebind 0.0.0.0u003Cbru003Eport 26380u003Cbru003Edaemonize yesu003Cbru003Esentinel monitor master 127.0.0.1 16379 2u003Cbru003Esentinel down-after-milliseconds master 5000u003Cbru003Esentinel failover-timeout master 180000u003Cbru003Esentinel parallel-syncs master 1u003Cbru003Esentinel auth-pass master 123456u003Cbru003Elogfile u002Fvaru002Flogu002Fredisu002Fsentinel-26380.logu003Cu002Fpreu003Eu003Cul class=””u003Eu003Cliu003E节点3:sentinel-36380.confu003Cu002Fliu003Eu003Cu002Fulu003Eu003Cpreu003Eprotected-mode nou003Cbru003Ebind 0.0.0.0u003Cbru003Eport 36380u003Cbru003Edaemonize yesu003Cbru003Esentinel monitor master 127.0.0.1 16379 2u003Cbru003Esentinel down-after-milliseconds master 5000u003Cbru003Esentinel failover-timeout master 180000u003Cbru003Esentinel parallel-syncs master 1u003Cbru003Esentinel auth-pass master 123456u003Cbru003Elogfile u002Fvaru002Flogu002Fredisu002Fsentinel-36380.logu003Cu002Fpreu003Eu003Cpu003E u003Cstrongu003E5.4.4. Sentinel启动验证u003Cu002Fstrongu003Eu003Cu002Fpu003Eu003Cpu003E按顺序分别启动 16380,26380 和 36380 三个 Sentinel 节点,启动命令和启动日志如下:u003Cu002Fpu003Eu003Cpreu003E$ sudo redis-sentinel u002Fusru002Flocalu002Fredis-sentinelu002Fsentinel-16380.confu003Cbru003E$ sudo redis-sentinel u002Fusru002Flocalu002Fredis-sentinelu002Fsentinel-26380.confu003Cbru003E$ sudo redis-sentinel u002Fusru002Flocalu002Fredis-sentinelu002Fsentinel-36380.confu003Cu002Fpreu003Eu003Cpu003E 查看 Sentinel 的启动进程:u003Cu002Fpu003Eu003Cpreu003E$ ps -ef | grep redis-sentinelu003Cbru003E 0 7954 1 0 3:30下午 ?? 0:00.05 redis-sentinel 0.0.0.0:16380 [sentinel] u003Cbru003E 0 7957 1 0 3:30下午 ?? 0:00.05 redis-sentinel 0.0.0.0:26380 [sentinel] u003Cbru003E 0 7960 1 0 3:30下午 ?? 0:00.04 redis-sentinel 0.0.0.0:36380 [sentinel] u003Cu002Fpreu003Eu003Cpu003E 查看 Sentinel 的启动日志:u003Cu002Fpu003Eu003Cul class=””u003Eu003Cliu003E节点 sentinel-16380u003Cu002Fliu003Eu003Cu002Fulu003Eu003Cpreu003E$ cat u002Fvaru002Flogu002Fredisu002Fsentinel-16380.log u003Cbru003E7953:X 22 Aug 15:30:27.245 # oO0OoO0OoO0Oo Redis is starting oO0OoO0OoO0Oou003Cbru003E7953:X 22 Aug 15:30:27.245 # Redis version=4.0.11, bits=64, commit=00000000, modified=0, pid=7953, just startedu003Cbru003E7953:X 22 Aug 15:30:27.245 # Configuration loadedu003Cbru003E7954:X 22 Aug 15:30:27.247 * Increased maximum number of open files to 10032 (it was originally set to 256).u003Cbru003E7954:X 22 Aug 15:30:27.249 * Running mode=sentinel, port=16380.u003Cbru003E7954:X 22 Aug 15:30:27.250 # Sentinel ID is 69d05b86a82102a8919231fd3c2d1f21ce86e000u003Cbru003E7954:X 22 Aug 15:30:27.250 # +monitor master master 127.0.0.1 16379 quorum 2u003Cbru003E7954:X 22 Aug 15:30:32.286 # +sdown sentinel fd166dc66425dc1d9e2670e1f17cb94fe05f5fc7 127.0.0.1 36380 @ master 127.0.0.1 16379u003Cbru003E7954:X 22 Aug 15:30:34.588 # -sdown sentinel fd166dc66425dc1d9e2670e1f17cb94fe05f5fc7 127.0.0.1 36380 @ master 127.0.0.1 16379u003Cu002Fpreu003Eu003Cpu003E sentinel-16380 节点的 Sentinel ID 为 69d05b86a82102a8919231fd3c2d1f21ce86e000,并通过 Sentinel ID 把自身加入 sentinel 集群中。u003Cu002Fpu003Eu003Cul class=””u003Eu003Cliu003E节点 sentinel-26380u003Cu002Fliu003Eu003Cu002Fulu003Eu003Cpreu003E$ cat u002Fvaru002Flogu002Fredisu002Fsentinel-26380.log u003Cbru003E7956:X 22 Aug 15:30:30.900 # oO0OoO0OoO0Oo Redis is starting oO0OoO0OoO0Oou003Cbru003E7956:X 22 Aug 15:30:30.901 # Redis version=4.0.11, bits=64, commit=00000000, modified=0, pid=7956, just startedu003Cbru003E7956:X 22 Aug 15:30:30.901 # Configuration loadedu003Cbru003E7957:X 22 Aug 15:30:30.904 * Increased maximum number of open files to 10032 (it was originally set to 256).u003Cbru003E7957:X 22 Aug 15:30:30.905 * Running mode=sentinel, port=26380.u003Cbru003E7957:X 22 Aug 15:30:30.906 # Sentinel ID is 21e30244cda6a3d3f55200bcd904d0877574e506u003Cbru003E7957:X 22 Aug 15:30:30.906 # +monitor master master 127.0.0.1 16379 quorum 2u003Cbru003E7957:X 22 Aug 15:30:30.907 * +slave slave 127.0.0.1:26379 127.0.0.1 26379 @ master 127.0.0.1 16379u003Cbru003E7957:X 22 Aug 15:30:30.911 * +slave slave 127.0.0.1:36379 127.0.0.1 36379 @ master 127.0.0.1 16379u003Cbru003E7957:X 22 Aug 15:30:36.311 * +sentinel sentinel fd166dc66425dc1d9e2670e1f17cb94fe05f5fc7 127.0.0.1 36380 @ master 127.0.0.1 16379u003Cu002Fpreu003Eu003Cpu003Esentinel-26380 节点的 Sentinel ID 为 21e30244cda6a3d3f55200bcd904d0877574e506,并通过 Sentinel ID 把自身加入 sentinel 集群中。此时 sentinel 集群中已有 sentinel-16380 和 sentinel-26380 两个节点。u003Cu002Fpu003Eu003Cul class=””u003Eu003Cliu003E节点 sentinel-36380u003Cu002Fliu003Eu003Cu002Fulu003Eu003Cpreu003E$ cat u002Fvaru002Flogu002Fredisu002Fsentinel-36380.log u003Cbru003E7959:X 22 Aug 15:30:34.273 # oO0OoO0OoO0Oo Redis is starting oO0OoO0OoO0Oou003Cbru003E7959:X 22 Aug 15:30:34.274 # Redis version=4.0.11, bits=64, commit=00000000, modified=0, pid=7959, just startedu003Cbru003E7959:X 22 Aug 15:30:34.274 # Configuration loadedu003Cbru003E7960:X 22 Aug 15:30:34.276 * Increased maximum number of open files to 10032 (it was originally set to 256).u003Cbru003E7960:X 22 Aug 15:30:34.277 * Running mode=sentinel, port=36380.u003Cbru003E7960:X 22 Aug 15:30:34.278 # Sentinel ID is fd166dc66425dc1d9e2670e1f17cb94fe05f5fc7u003Cbru003E7960:X 22 Aug 15:30:34.278 # +monitor master master 127.0.0.1 16379 quorum 2u003Cbru003E7960:X 22 Aug 15:30:34.279 * +slave slave 127.0.0.1:26379 127.0.0.1 26379 @ master 127.0.0.1 16379u003Cbru003E7960:X 22 Aug 15:30:34.283 * +slave slave 127.0.0.1:36379 127.0.0.1 36379 @ master 127.0.0.1 16379u003Cbru003E7960:X 22 Aug 15:30:34.993 * +sentinel sentinel 21e30244cda6a3d3f55200bcd904d0877574e506 127.0.0.1 26380 @ master 127.0.0.1 16379 u003Cu002Fpreu003Eu003Cpu003Esentinel-36380 节点的 Sentinel ID 为 fd166dc66425dc1d9e2670e1f17cb94fe05f5fc7,并通过 Sentinel ID 把自身加入 sentinel 集群中。此时 sentinel 集群中已有 sentinel-16380,sentinel-26380 和 sentinel-36380 三个节点。u003Cu002Fpu003Eu003Cpu003Eu003Cstrongu003E5.4.5. Sentinel配置刷新u003Cu002Fstrongu003Eu003Cu002Fpu003Eu003Cul class=””u003Eu003Cliu003E节点1:sentinel-16380.confu003Cu002Fliu003Eu003Cu002Fulu003Eu003Cpu003Esentinel-16380.conf 文件新生成如下的配置项:u003Cu002Fpu003Eu003Cpreu003E# Generated by CONFIG REWRITEu003Cbru003Edir "u002Fusru002Flocalu002Fredis-sentinel"u003Cbru003Esentinel config-epoch master 0u003Cbru003Esentinel leader-epoch master 0u003Cbru003Esentinel known-slave master 127.0.0.1 36379u003Cbru003Esentinel known-slave master 127.0.0.1 26379u003Cbru003Esentinel known-sentinel master 127.0.0.1 26380 21e30244cda6a3d3f55200bcd904d0877574e506u003Cbru003Esentinel known-sentinel master 127.0.0.1 36380 fd166dc66425dc1d9e2670e1f17cb94fe05f5fc7u003Cbru003Esentinel current-epoch 0 u003Cu002Fpreu003Eu003Cpu003E可以注意到,sentinel-16380.conf 刷新写入了 Redis 主节点关联的所有 u003Cstrongu003E从节点u003Cu002Fstrongu003E redis-26379 和 redis-36379,同时写入了其余两个 Sentinel 节点 sentinel-26380 和 sentinel-36380 的 IP 地址,u003Cstrongu003E端口号u003Cu002Fstrongu003E 和 Sentinel ID。u003Cu002Fpu003Eu003Cpreu003E# Generated by CONFIG REWRITEu003Cbru003Edir "u002Fusru002Flocalu002Fredis-sentinel"u003Cbru003Esentinel config-epoch master 0u003Cbru003Esentinel leader-epoch master 0u003Cbru003Esentinel known-slave master 127.0.0.1 26379u003Cbru003Esentinel known-slave master 127.0.0.1 36379u003Cbru003Esentinel known-sentinel master 127.0.0.1 36380 fd166dc66425dc1d9e2670e1f17cb94fe05f5fc7u003Cbru003Esentinel known-sentinel master 127.0.0.1 16380 69d05b86a82102a8919231fd3c2d1f21ce86e000u003Cbru003Esentinel current-epoch 0u003Cu002Fpreu003Eu003Cpu003E可以注意到,sentinel-26380.conf 刷新写入了 Redis 主节点关联的所有 u003Cstrongu003E从节点u003Cu002Fstrongu003E redis-26379 和 redis-36379,同时写入了其余两个 Sentinel 节点 sentinel-36380 和 sentinel-16380 的 IP 地址,u003Cstrongu003E端口号u003Cu002Fstrongu003E 和 Sentinel ID。u003Cu002Fpu003Eu003Cpreu003E# Generated by CONFIG REWRITEu003Cbru003Edir "u002Fusru002Flocalu002Fredis-sentinel"u003Cbru003Esentinel config-epoch master 0u003Cbru003Esentinel leader-epoch master 0u003Cbru003Esentinel known-slave master 127.0.0.1 36379u003Cbru003Esentinel known-slave master 127.0.0.1 26379u003Cbru003Esentinel known-sentinel master 127.0.0.1 16380 69d05b86a82102a8919231fd3c2d1f21ce86e000u003Cbru003Esentinel known-sentinel master 127.0.0.1 26380 21e30244cda6a3d3f55200bcd904d0877574e506u003Cbru003Esentinel current-epoch 0 u003Cu002Fpreu003Eu003Cpu003E可以注意到,sentinel-36380.conf 刷新写入了 Redis 主节点关联的所有 u003Cstrongu003E从节点u003Cu002Fstrongu003E redis-26379 和 redis-36379,同时写入了其余两个 Sentinel 节点 sentinel-16380 和 sentinel-26380 的 IP 地址,u003Cstrongu003E端口号u003Cu002Fstrongu003E 和 Sentinel ID。u003Cu002Fpu003Eu003Cpu003Eu003Cstrongu003E5.5. Sentinel时客户端命令u003Cu002Fstrongu003Eu003Cu002Fpu003Eu003Cul class=””u003Eu003Cliu003E检查其他 Sentinel 节点的状态,返回 PONG 为正常。u003Cu002Fliu003Eu003Cu002Fulu003Eu003Cpreu003E> PING sentinelu003Cu002Fpreu003Eu003Cul class=””u003Eu003Cliu003E显示被监控的所有 u003Cstrongu003E主节点u003Cu002Fstrongu003E 以及它们的状态。u003Cu002Fliu003Eu003Cu002Fulu003Eu003Cpreu003E> SENTINEL mastersu003Cu002Fpreu003Eu003Cul class=””u003Eu003Cliu003E显示指定 u003Cstrongu003E主节点u003Cu002Fstrongu003E 的信息和状态。u003Cu002Fliu003Eu003Cu002Fulu003Eu003Cpreu003E> SENTINEL master <master_name>u003Cu002Fpreu003Eu003Cul class=””u003Eu003Cliu003E显示指定 u003Cstrongu003E主节点u003Cu002Fstrongu003E 的所有 u003Cstrongu003E从节点u003Cu002Fstrongu003E 以及它们的状态。u003Cu002Fliu003Eu003Cu002Fulu003Eu003Cpreu003E> SENTINEL slaves <master_name>u003Cu002Fpreu003Eu003Cpu003E返回指定 u003Cstrongu003E主节点u003Cu002Fstrongu003E 的 IP 地址和 u003Cstrongu003E端口u003Cu002Fstrongu003E。如果正在进行 failover 或者 failover 已经完成,将会显示被提升为 u003Cstrongu003E主节点u003Cu002Fstrongu003E 的 u003Cstrongu003E从节点u003Cu002Fstrongu003E 的 IP 地址和 u003Cstrongu003E端口u003Cu002Fstrongu003E。u003Cu002Fpu003Eu003Cpreu003E> SENTINEL get-master-addr-by-name <master_name>u003Cu002Fpreu003Eu003Cul class=””u003Eu003Cliu003E重置名字匹配该 u003Cstrongu003E正则表达式u003Cu002Fstrongu003E 的所有的 u003Cstrongu003E主节点u003Cu002Fstrongu003E 的状态信息,清除它之前的 u003Cstrongu003E状态信息u003Cu002Fstrongu003E,以及 u003Cstrongu003E从节点u003Cu002Fstrongu003E 的信息。u003Cu002Fliu003Eu003Cu002Fulu003Eu003Cpreu003E> SENTINEL reset <pattern>u003Cu002Fpreu003Eu003Cul class=””u003Eu003Cliu003E强制当前 Sentinel 节点执行 failover,并且不需要得到其他 Sentinel 节点的同意。但是 failover 后会将 u003Cstrongu003E最新的配置u003Cu002Fstrongu003E 发送给其他 Sentinel 节点。 u003Cu002Fliu003Eu003Cu002Fulu003Eu003Cpreu003E>SENTINEL failover <master_name>u003Cu002Fpreu003Eu003Ch1u003Eu003Cstrongu003E6. Redis Sentinel故障切换与恢复u003Cu002Fstrongu003Eu003Cu002Fh1u003Eu003Cpu003Eu003Cstrongu003E6.1. Redis CLI客户端跟踪u003Cu002Fstrongu003Eu003Cu002Fpu003Eu003Cpu003E上面的日志显示,redis-16379 节点为 u003Cstrongu003E主节点u003Cu002Fstrongu003E,它的进程 ID 为 7127。为了模拟 Redis 主节点故障,强制杀掉这个进程。u003Cu002Fpu003Eu003Cpreu003E$ kill -9 7127u003Cu002Fpreu003Eu003Cpu003E使用 redis-cli 客户端命令进入 sentinel-16380 节点,查看 Redis u003Cstrongu003E节点u003Cu002Fstrongu003E 的状态信息。u003Cu002Fpu003Eu003Cpreu003E$ redis-cli -p 16380u003Cu002Fpreu003Eu003Cul class=””u003Eu003Cliu003E查看 Redis 主从集群的 u003Cstrongu003E主节点u003Cu002Fstrongu003E 信息。可以发现 redis-26379 晋升为 u003Cstrongu003E新的主节点u003Cu002Fstrongu003E。u003Cu002Fliu003Eu003Cu002Fulu003Eu003Cpreu003E127.0.0.1:16380> SENTINEL master masteru003Cbru003E 1) "name"u003Cbru003E 2) "master"u003Cbru003E 3) "ip"u003Cbru003E 4) "127.0.0.1"u003Cbru003E 5) "port"u003Cbru003E 6) "26379"u003Cbru003E 7) "runid"u003Cbru003E 8) "b8ca3b468a95d1be5efe1f50c50636cafe48c59f"u003Cbru003E 9) "flags"u003Cbru003E10) "master"u003Cbru003E11) "link-pending-commands"u003Cbru003E12) "0"u003Cbru003E13) "link-refcount"u003Cbru003E14) "1"u003Cbru003E15) "last-ping-sent"u003Cbru003E16) "0"u003Cbru003E17) "last-ok-ping-reply"u003Cbru003E18) "588"u003Cbru003E19) "last-ping-reply"u003Cbru003E20) "588"u003Cbru003E21) "down-after-milliseconds"u003Cbru003E22) "5000"u003Cbru003E23) "info-refresh"u003Cbru003E24) "9913"u003Cbru003E25) "role-reported"u003Cbru003E26) "master"u003Cbru003E27) "role-reported-time"u003Cbru003E28) "663171"u003Cbru003E29) "config-epoch"u003Cbru003E30) "1"u003Cbru003E31) "num-slaves"u003Cbru003E32) "2"u003Cbru003E33) "num-other-sentinels"u003Cbru003E34) "2"u003Cbru003E35) "quorum"u003Cbru003E36) "2"u003Cbru003E37) "failover-timeout"u003Cbru003E38) "180000"u003Cbru003E39) "parallel-syncs"u003Cbru003E40) "1" u003Cu002Fpreu003Eu003Cpu003Eu003Cstrongu003E6.2. Redis Sentinel日志跟踪u003Cu002Fstrongu003Eu003Cu002Fpu003Eu003Cpu003E查看任意 Sentinel 节点的日志如下:u003Cu002Fpu003Eu003Cpreu003E7954:X 22 Aug 18:40:22.504 # +tilt #tilt mode enteredu003Cbru003E7954:X 22 Aug 18:40:32.197 # +tilt #tilt mode enteredu003Cbru003E7954:X 22 Aug 18:41:02.241 # -tilt #tilt mode exitedu003Cbru003E7954:X 22 Aug 18:48:24.550 # +sdown master master 127.0.0.1 16379u003Cbru003E7954:X 22 Aug 18:48:24.647 # +new-epoch 1u003Cbru003E7954:X 22 Aug 18:48:24.651 # +vote-for-leader fd166dc66425dc1d9e2670e1f17cb94fe05f5fc7 1u003Cbru003E7954:X 22 Aug 18:48:25.678 # +odown master master 127.0.0.1 16379 #quorum 3u002F2u003Cbru003E7954:X 22 Aug 18:48:25.678 # Next failover delay: I will not start a failover before Wed Aug 22 18:54:24 2018u003Cbru003E7954:X 22 Aug 18:48:25.709 # +config-update-from sentinel fd166dc66425dc1d9e2670e1f17cb94fe05f5fc7 127.0.0.1 36380 @ master 127.0.0.1 16379u003Cbru003E7954:X 22 Aug 18:48:25.710 # +switch-master master 127.0.0.1 16379 127.0.0.1 26379u003Cbru003E7954:X 22 Aug 18:48:25.710 * +slave slave 127.0.0.1:36379 127.0.0.1 36379 @ master 127.0.0.1 26379u003Cbru003E7954:X 22 Aug 18:48:25.711 * +slave slave 127.0.0.1:16379 127.0.0.1 16379 @ master 127.0.0.1 26379u003Cbru003E7954:X 22 Aug 18:48:30.738 # +sdown slave 127.0.0.1:16379 127.0.0.1 16379 @ master 127.0.0.1 26379u003Cbru003E7954:X 22 Aug 19:38:23.479 # -sdown slave 127.0.0.1:16379 127.0.0.1 16379 @ master 127.0.0.1 26379 u003Cu002Fpreu003Eu003Cul class=””u003Eu003Cliu003E分析日志,可以发现 redis-16329 节点先进入 sdown u003Cstrongu003E主观下线u003Cu002Fstrongu003E 状态。u003Cu002Fliu003Eu003Cu002Fulu003Eu003Cpreu003E+sdown master master 127.0.0.1 16379u003Cu002Fpreu003Eu003Cul class=””u003Eu003Cliu003E哨兵检测到 redis-16329 出现故障,Sentinel 进入一个 u003Cstrongu003E新纪元u003Cu002Fstrongu003E,从 0 变为 1。u003Cu002Fliu003Eu003Cu002Fulu003Eu003Cpreu003E+new-epoch 1u003Cu002Fpreu003Eu003Cul class=””u003Eu003Cliu003E三个 Sentinel 节点开始协商 u003Cstrongu003E主节点u003Cu002Fstrongu003E 的状态,判断其是否需要 u003Cstrongu003E客观下线u003Cu002Fstrongu003E。u003Cu002Fliu003Eu003Cu002Fulu003Eu003Cpreu003E+vote-for-leader fd166dc66425dc1d9e2670e1f17cb94fe05f5fc7 1u003Cu002Fpreu003Eu003Cul class=””u003Eu003Cliu003E超过 quorum 个数的 Sentinel 节点认为 u003Cstrongu003E主节点u003Cu002Fstrongu003E 出现故障,redis-16329 节点进入 u003Cstrongu003E客观下线u003Cu002Fstrongu003E 状态。u003Cu002Fliu003Eu003Cu002Fulu003Eu003Cpreu003E+odown master master 127.0.0.1 16379 #quorum 3u002F2u003Cu002Fpreu003Eu003Cul class=””u003Eu003Cliu003ESentinal 进行 u003Cstrongu003E自动故障切换u003Cu002Fstrongu003E,协商选定 redis-26329 节点作为新的 u003Cstrongu003E主节点u003Cu002Fstrongu003E。u003Cu002Fliu003Eu003Cu002Fulu003Eu003Cpreu003E+switch-master master 127.0.0.1 16379 127.0.0.1 26379u003Cu002Fpreu003Eu003Cul class=””u003Eu003Cliu003Eredis-36329 节点和已经 u003Cstrongu003E客观下线u003Cu002Fstrongu003E 的 redis-16329 节点成为 redis-26479 的 u003Cstrongu003E从节点u003Cu002Fstrongu003E。u003Cu002Fliu003Eu003Cu002Fulu003Eu003Cpreu003E7954:X 22 Aug 18:48:25.710 * +slave slave 127.0.0.1:36379 127.0.0.1 36379 @ master 127.0.0.1 26379u003Cbru003E7954:X 22 Aug 18:48:25.711 * +slave slave 127.0.0.1:16379 127.0.0.1 16379 @ master 127.0.0.1 26379u003Cu002Fpreu003Eu003Cpu003Eu003Cstrongu003E6.3. Redis的配置文件u003Cu002Fstrongu003Eu003Cu002Fpu003Eu003Cpu003E分别查看三个 redis 节点的配置文件,发生 u003Cstrongu003E主从切换u003Cu002Fstrongu003E 时 redis.conf 的配置会自动发生刷新。u003Cu002Fpu003Eu003Cul class=””u003Eu003Cliu003E节点 redis-16379u003Cu002Fliu003Eu003Cu002Fulu003Eu003Cpreu003Edaemonize yesu003Cbru003Epidfile "u002Fvaru002Frunu002Fredis-16379.pid"u003Cbru003Elogfile "u002Fvaru002Flogu002Fredisu002Fredis-16379.log"u003Cbru003Eport 16379u003Cbru003Ebind 0.0.0.0u003Cbru003Etimeout 300u003Cbru003Edatabases 16u003Cbru003Edbfilename "dump-16379.db"u003Cbru003Edir "u002Fusru002Flocalu002Fredis-sentinelu002Fredis-workdir"u003Cbru003Emasterauth "123456"u003Cbru003Erequirepass "123456" u003Cu002Fpreu003Eu003Cul class=””u003Eu003Cliu003E节点 redis-26379u003Cu002Fliu003Eu003Cu002Fulu003Eu003Cpreu003Edaemonize yesu003Cbru003Epidfile "u002Fvaru002Frunu002Fredis-26379.pid"u003Cbru003Elogfile "u002Fvaru002Flogu002Fredisu002Fredis-26379.log"u003Cbru003Eport 26379u003Cbru003Ebind 0.0.0.0u003Cbru003Etimeout 300u003Cbru003Edatabases 16u003Cbru003Edbfilename "dump-26379.db"u003Cbru003Edir "u002Fusru002Flocalu002Fredis-sentinelu002Fredis-workdir"u003Cbru003Emasterauth "123456"u003Cbru003Erequirepass "123456"u003Cu002Fpreu003Eu003Cul class=””u003Eu003Cliu003E节点 redis-36379u003Cu002Fliu003Eu003Cu002Fulu003Eu003Cpreu003Edaemonize yesu003Cbru003Epidfile "u002Fvaru002Frunu002Fredis-36379.pid"u003Cbru003Elogfile "u002Fvaru002Flogu002Fredisu002Fredis-36379.log"u003Cbru003Eport 36379u003Cbru003Ebind 0.0.0.0u003Cbru003Etimeout 300u003Cbru003Edatabases 16u003Cbru003Edbfilename "dump-36379.db"u003Cbru003Edir "u002Fusru002Flocalu002Fredis-sentinelu002Fredis-workdir"u003Cbru003Emasterauth "123456"u003Cbru003Erequirepass "123456"u003Cbru003Eslaveof 127.0.0.1 26379u003Cu002Fpreu003Eu003Cblockquoteu003Eu003Cpu003Eu003Cstrongu003E分析u003Cu002Fstrongu003E:redis-26379 节点 slaveof 配置被移除,晋升为 u003Cstrongu003E主节点u003Cu002Fstrongu003E。redis-16379 节点处于 u003Cstrongu003E宕机状态u003Cu002Fstrongu003E。redis-36379 的 slaveof 配置更新为 127.0.0.1 redis-26379,成为 redis-26379 的 u003Cstrongu003E从节点u003Cu002Fstrongu003E。u003Cu002Fpu003Eu003Cu002Fblockquoteu003Eu003Cpu003E重启节点 redis-16379。待正常启动后,再次查看它的 redis.conf 文件,配置如下:u003Cu002Fpu003Eu003Cpreu003Edaemonize yesu003Cbru003Epidfile "u002Fvaru002Frunu002Fredis-16379.pid"u003Cbru003Elogfile "u002Fvaru002Flogu002Fredisu002Fredis-16379.log"u003Cbru003Eport 16379u003Cbru003Ebind 0.0.0.0u003Cbru003Etimeout 300u003Cbru003Edatabases 16u003Cbru003Edbfilename "dump-16379.db"u003Cbru003Edir "u002Fusru002Flocalu002Fredis-sentinelu002Fredis-workdir"u003Cbru003Emasterauth "123456"u003Cbru003Erequirepass "123456"u003Cbru003E# Generated by CONFIG REWRITEu003Cbru003Eslaveof 127.0.0.1 26379u003Cu002Fpreu003Eu003Cpu003E节点 redis-16379 的配置文件新增一行 slaveof 配置属性,指向 redis-26379,即成为 u003Cstrongu003E新的主节点u003Cu002Fstrongu003E 的 u003Cstrongu003E从节点u003Cu002Fstrongu003E。u003Cu002Fpu003Eu003Ch1u003Eu003Cstrongu003E小结u003Cu002Fstrongu003Eu003Cu002Fh1u003Eu003Cpu003E本文首先对 u003Cstrongu003ERedis u003Cu002Fstrongu003E实现高可用的几种模式做出了阐述,指出了u003Cstrongu003E Redis 主从复制u003Cu002Fstrongu003E 的不足之处,进一步引入了 u003Cstrongu003ERedis Sentinel 哨兵模式u003Cu002Fstrongu003E 的相关概念,深入说明了 Redis Sentinel 的 u003Cstrongu003E具体功能u003Cu002Fstrongu003E,u003Cstrongu003E基本原理u003Cu002Fstrongu003E,u003Cstrongu003E高可用搭建u003Cu002Fstrongu003E 和 u003Cstrongu003E自动故障切换u003Cu002Fstrongu003E 验证等。u003Cu002Fpu003Eu003Cpu003E当然,Redis Sentinel 仅仅解决了 u003Cstrongu003E高可用u003Cu002Fstrongu003E 的问题,对于 u003Cstrongu003E主节点u003Cu002Fstrongu003E 单点写入和单节点无法扩容等问题,还需要引入 u003Cstrongu003ERedis Cluster 集群模式u003Cu002Fstrongu003E 予以解决。u003Cu002Fpu003Eu003Cpu003Eu003Cbru002Fu003Eu003Cu002Fpu003E”

原文始发于:一文带你了解Redis哨兵模式和高可用集群解析(万字长文)

主题测试文章,只做测试使用。发布者:程序员,转转请注明出处:http://www.cxybcw.com/26384.html

联系我们

13687733322

在线咨询:点击这里给我发消息

邮件:1877088071@qq.com

工作时间:周一至周五,9:30-18:30,节假日休息

QR code