一引言
上一篇文章我们详细的讲解了 Redis 的主从集群模式, 其实这个集群模式配置很简单, 只需要在 Slave 的节点上进行配置, Master 主节点的配置不需要做任何更改, 但是有一点, Master 和 Slave 两个节点的持久化配置尽量保持一致, 否则会有奇怪的问题出现从今天开始我们开始讲 Redis 集群模式的第二模式, 也就是哨兵模式, 该模式是从 Redis 的 2.6 版本开始提供的, 但是当时这个版本的模式是不稳定的, 直到 Redis 的 2.8 版本以后, 这个哨兵模式才稳定下来, 在生产环境中, 如果想要使用 Redis 的哨兵模式, 也会尽量使用 Redis 的 2.8 版本之后的版本无论是主从模式, 还是哨兵模式, 这两个模式都有一个问题, 不能水平扩容, 并且这两个模式的高可用特性都会受到 Master 主节点内存的限制还有一点, 实现哨兵模式的配置也不简单, 甚至可以说有些繁琐, 所以在工业场景里这两个模式都不建议使用, 如果要使用必须有相关的问题的解决方案, 以免后续带来的问题
二 Redis Sentinel 简介
Sentinel(哨兵)进程是用于监控 redis 集群中 Master 主服务器工作的状态, 在 Master 主服务器发生故障的时候, 可以实现 Master 和 Slave 服务器的切换, 保证系统的高可用, 其已经被集成在 redis2.6 + 的版本中, Redis 的哨兵模式到了 2.8 版本之后就稳定了下来一般在生产环境也建议使用 Redis 的 2.8 版本的以后版本哨兵 (Sentinel) 是一个分布式系统, 你可以在一个架构中运行多个哨兵(sentinel) 进程, 这些进程使用流言协议(gossipprotocols) 来接收关于 Master 主服务器是否下线的信息, 并使用投票协议 (Agreement Protocols) 来决定是否执行自动故障迁移, 以及选择哪个 Slave 作为新的 Master 每个哨兵 (Sentinel) 进程会向其它哨兵 (Sentinel)MasterSlave 定时发送消息, 以确认对方是否活着, 如果发现对方在指定配置时间(可配置的) 内未得到回应, 则暂时认为对方已掉线, 也就是所谓的主观认为宕机 , 英文名称: Subjective Down, 简称 SDOWN 有主观宕机, 肯定就有客观宕机当哨兵群中的多数 Sentinel 进程在对 Master 主服务器做出 SDOWN 的判断, 并且通过 SENTINEL is-master-down-by-addr 命令互相交流之后, 得出的 Master Server 下线判断, 这种方式就是客观宕机, 英文名称是: Objectively Down, 简称 ODOWN 通过一定的 vote 算法, 从剩下的 slave 从服务器节点中, 选一台提升为 Master 服务器节点, 然后自动修改相关配置, 并开启故障转移(failover)
哨兵(sentinel) 虽然有一个单独的可执行文件 redis-sentinel , 但实际上它只是一个运行在特殊模式下的 Redis 服务器, 你可以在启动一个普通 Redis 服务器时通过给定 --sentinel 选项来启动哨兵(sentinel), 哨兵(sentinel) 的一些设计思路和 zookeeper 非常类似
Sentinel 集群之间会互相通信, 沟通交流 redis 节点的状态, 做出相应的判断并进行处理, 这里的主观下线状态和客观下线状态是比较重要的状态, 它们决定了是否进行故障转移, 可以 通过订阅指定的频道信息, 当服务器出现故障得时候通知管理员, 客户端可以将 Sentinel 看作是一个只提供了订阅功能的 Redis 服务器, 你不可以使用 PUBLISH 命令向这个服务器发送信息, 但你可以用 SUBSCRIBE 命令或者 PSUBSCRIBE 命令, 通过订阅给定的频道来获取相应的事件提醒一个频道能够接收和这个频道的名字相同的事件 比如说, 名为 +sdown 的频道就可以接收所有实例进入主观下线 (SDOWN) 状态的事件
1Sentinel(哨兵)进程的作用:
1 监控(Monitoring): 哨兵(sentinel) 会不断地检查你的 Master 和 Slave 是否运作正常
2 提醒(Notification): 当被监控的某个 Redis 节点出现问题时, 哨兵(sentinel) 可以通过 API 向管理员或者其他应用程序发送通知
3 自动故障迁移(Automatic failover): 当一个 Master 不能正常工作时, 哨兵(sentinel) 会开始一次自动故障迁移操作, 它会将失效 Master 的其中一个 Slave 升级为新的 Master, 并让失效 Master 的其他 Slave 改为复制新的 Master; 当客户端试图连接失效的 Master 时, 集群也会向客户端返回新 Master 的地址, 使得集群可以使用现在的 Master 替换失效 MasterMaster 和 Slave 服务器切换后, Master 的 redis.confSlave 的 redis.conf 和 sentinel.conf 的配置文件的内容都会发生相应的改变, 即, Master 主服务器的 redis.conf 配置文件中会多一行 slaveof 的配置, sentinel.conf 的监控目标会随之调换
2Sentinel(哨兵)进程的工作方式:
1 每个 Sentinel(哨兵)进程以每秒钟一次的频率向整个集群中的 Master 主服务器, Slave 从服务器以及其他 Sentinel(哨兵)进程发送一个 PING 命令
2 如果一个实例 (instance) 距离最后一次有效回复 PING 命令的时间超过 down-after-milliseconds 选项所指定的值, 则这个实例会被 Sentinel(哨兵)进程标记为主观下线(SDOWN)
3 如果一个 Master 主服务器被标记为主观下线 (SDOWN), 则正在监视这个 Master 主服务器的所有 Sentinel(哨兵) 进程要以每秒一次的频率确认 Master 主服务器的确进入了主观下线状态
4 当有足够数量的 Sentinel(哨兵)进程 (大于等于配置文件指定的值) 在指定的时间范围内确认 Master 主服务器进入了主观下线状态(SDOWN), 则 Master 主服务器会被标记为客观下线(ODOWN)
5 在一般情况下, 每个 Sentinel(哨兵)进程会以每 10 秒一次的频率向集群中的所有 Master 主服务器 Slave 从服务器发送 INFO 命令
6 当 Master 主服务器被 Sentinel(哨兵)进程标记为客观下线 (ODOWN) 时, Sentinel(哨兵)进程向下线的 Master 主服务器的所有 Slave 从服务器发送 INFO 命令的频率会从 10 秒一次改为每秒一次
7 若没有足够数量的 Sentinel(哨兵)进程同意 Master 主服务器下线, Master 主服务器的客观下线状态就会被移除若 Master 主服务器重新向 Sentinel(哨兵)进程发送 PING 命令返回有效回复, Master 主服务器的主观下线状态就会被移除
3 哨兵模式的环境:
1Master 主服务器配置信息: IP:192.168.127.128, Port:6379,OS:Linux
2Slave 从服务器的配置信息: IP:192.168.127.129 Port:6379,OS:Linux
3 在 Slave 从服务器上安装了一个哨兵进程(Sentinel), 在 Master 服务器也安装了一个哨兵进程(Sentinel)
由于两个 Redis 服务器都是安装在 Linux 操作系统上, 而且这两个 Redis 服务器会在 Master 主服务器发生故障的时候会进行切换, 必须保证两个 Redis 服务器的端口号已经增加进了防火墙, 或者把两个 Linux 操作系统的防火墙关闭, 否则会提示 Master-link-Status:down, 没有连接上 Master 主服务器解决办法有两个: 第一个办法是关闭两个 Linux 操作系统的防火墙; 第二个办法是把各个 Redis 服务的端口号增加到防火墙里面, 允许通过该端口号进行通信可以先使用命令 firewall-cmd --query-port=6379/tcp, 如果结果是 No, 那就继续执行以下命令 firewall-cmd --add-port=6379/tcp, 命令执行后, 返回 Success, 表示增加成功这样两个 Linux 系统上的 Redis 服务器就可以顺利切换, 执行哨兵模式的操作
三哨兵模式的配置
下面是我使用的配置, 需要修改的配置项我写了出来, 没有更改的配置项就是用默认值, 就不会写出来:
- 1###### Master config(redis.conf)
- 1.1### NETWORK 设置:
- bind 192.168.127.128 // 绑定 IP 地址, 可以通过 ifconfig 获取 Ip 地址(在 Linux 系统下)
- port 6379 // 保持默认值, 也可以修改
- timeout 30 //Client 端空闲断开连接的时间
- 1.2### GENERAL 设置:
- daemonize yes // 默认值是 no, 把值修改为 yes, 以后台模式运行
- logfile /root/application/program/redis-tool/logs/redis.log // 日志文件的位置
- 1.3### SNAPSHOTTING 设置:
- dir /root/application/program/redis-tool/datas //SNAPSHOTTING 文件的路径
- 1.4### APPEND ONLY MODE 设置:
- appendonly yes // 默认值是 No, 意思是不使用 AOF 增量持久化的方式, 使用 RDB 全量持久化的方式把 No 值改成 Yes, 使用 AOF 增量持久化的方式
- appendfsync always
- 2###### Slave Config(redis.conf)
- 2.1### NETWORK 设置:
- bind 192.168.127.129 // 绑定 IP 地址, 可以通过 ifconfig 获取 Ip 地址(在 Linux 系统下)
- port 6379 // 保持默认值, 也可以修改
- timeout 30 //Client 端空闲断开连接的时间
- 2.2### GENERAL 设置:
- daemonize yes // 默认值是 no, 把值修改为 yes, 以后台模式运行
- logfile /root/application/program/redis/logs/redis.log // 日志文件的位置
- 2.3### SNAPSHOTTING 设置:
- dir /root/application/program/redis/datas //SNAPSHOTTING 文件的路径
- 2.4### REPLICATION 设置:
- slaveof 192.168.127.128 6379 // 主服务器的 Ip 地址和 Port 端口号
- slave-serve-stale-data no // 如果 slave 无法与 master 同步, 设置成 slave 不可读, 方便监控脚本发现问题
- 2.5### APPEND ONLY MODE 设置:
- appendonly yes // 默认值是 No, 意思是不使用 AOF 增量持久化的方式, 使用 RDB 全量持久化的方式把 No 值改成 Yes, 使用 AOF 增量持久化的方式
- appendfsync always
- 3###### Sentinel Config(sentinel.conf,192.168.127.129 Slave 从服务器)
- 3.1 ### Port 设置:
- port 26379 // 哨兵端口号保持不变, 可以修改, 但是我没有修改
- 3.2### dir 设置:
- dir /root/application/program/redis/sentinel/ // 哨兵程序的日志路径
- 3.3### Sentinel Monitor 设置:
- sentinel monitor mymaster 192.168.127.129 6379 1
- 3.4### Down-After-Milliseconds 设置:
- sentinel down-after-milliseconds mymaster 5000
- // 哨兵程序每 5 秒检测一次 Master 是否正常
- 3.5### Parallel-Syncs 设置:
- sentinel parallel-syncs mymaster 1
- 3.5### Failover-Timeout 设置:
- sentinel failover-timeout mymaster 60000
- 3.5### 启动: redis-sentinel
- redis-server sentinel.conf --sentinel & //(& 有这可以 Ctrl +C 退到命令行, 没有这个就直接退出哨兵进程)
- redis-sentinel /path/to/sentinel.conf & // 对于 redis-sentinel 程序, 你可以用以下命令来启动 Sentinel 系统
- 3.6### 关闭: redis-sentinel
- pkill redis-server // 这个会关掉 Redis 服务器和 Sentinel(哨兵)进程
kill 进程号 // 可以关掉指定进程号的进程
4###### 模式测试
4.1 在 Sentinel.conf 配置文件设置 sentinel monitor:
4.2 在 Sentinel.conf 配置文件设置 sentinel down-after-milliseconds:
4.3 在 Sentinel.conf 配置文件设置 sentinel parallel-syncs:
4.4Master 主服务器的配置详情:
4.5Slave 从服务器配置详情:
4.6 启动 Sentinel(哨兵)进程, 开始对 Master 主服务器进行监控:
4.7 我们人为模仿 Master 主服务器宕机:
4.8 实现 Master 主服务器和 Slave 从服务器的切换:
4.9 主从切换后, 主服务器变成了 Slave 从服务器, 详情如下:
4.10 主从切换后, 从服务器变成了 Master 主服务器, 详情如下:
注意:
INFO
sentinel 的基本状态信息
SENTINEL masters
列出所有被监视的主服务器, 以及这些主服务器的当前状态
SENTINEL slaves
列出给定主服务器的所有从服务器, 以及这些从服务器的当前状态
SENTINEL get-master-addr-by-name
返回给定名字的主服务器的 IP 地址和端口号
SENTINEL reset
重置所有名字和给定模式 pattern 相匹配的主服务器重置操作清除主服务器目前的所有状态, 包括正在执行中的故障转移, 并移除目前已经发现和关联的, 主服务器的所有从服务器和 Sentinel
SENTINEL failover
当主服务器失效时, 在不询问其他 Sentinel 意见的情况下, 强制开始一次自动故障迁移, 但是它会给其他 sentinel 发送一个最新的配置, 其他 sentinel 会根据这个配置进行更新
四主观下线和客观下线
下面我们来解释一下两个下线的概念, 一个是主观下线, 另一个就是客观下线
主观下线 (Subjectively Down, 简称 SDOWN) 指的是单个 Sentinel 实例对服务器做出的下线判断
客观下线 (Objectively Down, 简称 ODOWN) 指的是多个 Sentinel 实例在对同一个服务器做出 SDOWN 判断, 并且通过 SENTINEL is-master-down-by-addr 命令互相交流之后, 得出的服务器下线判断(一个 Sentinel 可以通过向另一个 Sentinel 发送 SENTINEL is-master-down-by-addr 命令来询问对方是否认为给定的服务器已下线)
如果一个服务器没有在 master-down-after-milliseconds 选项所指定的时间内, 对向它发送 PING 命令的 Sentinel(哨兵)进程返回一个有效回复 (valid reply), 那么 Sentinel(哨兵) 进程就会将这个服务器标记为主观下线
服务器对 PING 命令的有效回复可以是以下三种回复的其中一种:
1 返回 +PONG
2 返回 -LOADING 错误
3 返回 -MASTERDOWN 错误
如果服务器返回除以上三种回复之外的其他回复, 又或者在指定时间内没有回复 PING 命令, 那么 Sentinel(哨兵)进程认为服务器返回的回复无效(non-valid)
如果一个服务器在 master-down-after-milliseconds 毫秒内, 一直返回无效回复才会被 Sentinel 标记为主观下线
举个例子, 如果 master-down-after-milliseconds 选项的值为 30000 毫秒(30 秒), 那么只要服务器能在每 29 秒之内返回至少一次有效回复, 这个服务器就仍然会被认为是处于正常状态的
从主观下线状态切换到客观下线状态并没有使用严格的法定人数算法 (strong quorum algorithm), 而是使用了流言协议, 该协议解释为: 如果 Sentinel(哨兵) 进程在给定的时间范围内, 从其他 Sentinel(哨兵)进程那里接收到了足够数量的主服务器下线报告, 那么 Sentinel(哨兵)进程就会将主服务器的状态从主观下线改变为客观下线如果之后其他 Sentinel(哨兵)进程不再报告主服务器已下线, 那么客观下线状态就会被移除
客观下线条件只适用于主服务器: 对于任何其他类型的 Redis 实例, Sentinel(哨兵)进程在将它们判断为下线前不需要进行协商, 所以 Slave 从服务器或者其他 Sentinel(哨兵)进程永远不会达到客观下线条件
只要有一个 Sentinel(哨兵)进程发现某个主服务器进入了客观下线状态, 这个 Sentinel(哨兵)进程就可能会被其他 Sentinel(哨兵)进程推选出, 并对失效的主服务器执行自动故障迁移操作
五 Sentinel(哨兵)配置文件简介
在 Redis 的源码中包含了一个名为 sentinel.conf 的文件, 这个文件就是带有注释的 Sentinel(哨兵)的配置文件的示例
如果想要运行一个哨兵程序, 以下配置项是最少配置:
- sentinel monitor mymaster 127.0.0.1 6379 1
- sentinel down-after-milliseconds mymaster 60000
- sentinel failover-timeout mymaster 180000
- sentinel parallel-syncs mymaster 1
第一行配置表示 Sentinel(哨兵)进程去监视一个名为 mymaster 的主服务器, 这个主服务器的 IP 地址为 127.0.0.1 , 端口号为 6379, 而将这个主服务器判断为失效至少需要 1 个 Sentinel(哨兵)进程的同意如果在架构系统中已经配置类多个 Sentinel(哨兵)进程, 在同意 Master 主服务器下线的 Sentinel(哨兵)进程的数量不达标的情况下, Sentinel(哨兵)进程就不会执行自动故障迁移在设置多 Sentinel(哨兵)进程的情况下, 无论设置多少个 Sentinel(哨兵)进程同意才能判断一个服务器失效, 一个 Sentinel 都需要获得架构系统中多数 Sentinel(哨兵)进程的支持, 才能发起一次自动故障迁移, 并预留一个给定的配置纪元 (configuration Epoch , 一个配置纪元就是一个新主服务器配置的版本号)如果您只配置了一个 Sentinel(哨兵)进程来做监控, 那一个 Sentinel(哨兵)进程也可以决定 Master 主服务器是否下线
其他选项的基本格式如下: sentinel <选项的名字> <主服务器的名字> <选项的值>
配置选项的解释如下:
1down-after-milliseconds : Sentinel(哨兵)进程判断服务器已经掉线所需的毫秒数
如果被监控的服务器在给定的毫秒数之内, 并没有返回 Sentinel(哨兵)进程发送的 PING 命令的回复, 或者返回一个错误, 那么 Sentinel(哨兵)进程将这个服务器标记为主观下线 (subjectively down, 简称 SDOWN ) 如果在架构系统中配置了多个 Sentinel(哨兵)进程的情况下, 只有一个 Sentinel(哨兵)进程将服务器标记为主观下线并不一定会引起服务器的自动故障迁移, 只有在足够数量的 Sentinel(哨兵)进程都将一个服务器标记为主观下线之后, 服务器才会被标记为客观下线 (objectively down, 简称 ODOWN ), 这时才回执行自动故障迁移另外一种情况是, 在架构系统中只配置了一个 Sentinel(哨兵) 进程的话, 那这 Sentinel(哨兵)进程也可以决定被监控的服务器的是否下线
将服务器标记为客观下线所需的 Sentinel(哨兵)进程数量由对主服务器的配置决定
2parallel-syncs : 在执行故障转移时, 最多可以有多少个从服务器同时对新的主服务器进行同步, 这个数字越小, 完成故障转移所需的时间就越长
如果 Slave 从服务器被设置为允许使用过期数据集(参见对 redis.conf 文件中对 slave-serve-stale-data 选项的说明), 那么你可能不希望所有 Slave 从服务器都在同一时间向新的 Master 主服务器发送同步请求, 因为尽管复制过程的绝大部分步骤都不会阻塞 Slave 从服务器, 但 Slave 从服务器在载入 Master 主服务器发来的 RDB 文件时, 仍然会造成 Slave 从服务器在一段时间内不能处理命令请求, 如果全部 Slave 从服务器一起对新的 Master 主服务器进行同步, 那么就可能会造成所有 Slave 从服务器在短时间内全部不可用的情况出现
你可以通过将这个值设为 1 来保证每次只有一个 Slave 从服务器处于不能处理命令请求的状态
3failover-timeout: 实现主从切换, 完成故障转移的所需要的最大时间值若 Sentinel(哨兵)进程在该配置值内未能完成故障转移的操作(即故障时 master/slave 自动切换), 则认为本次故障转移操作失败
4notification-script: 指定 Sentinel(哨兵)进程检测到 Master-Name 所指定的 Master 主服务器的实例异常的时候, 所要调用的报警脚本该配置项可选, 但线上系统建议配置
六哨兵模式的优缺点
优点:
1 哨兵集群模式是基于主从模式的, 所有主从的优点, 哨兵模式同样具有
2 主从可以切换, 故障可以转移, 系统可用性更好
3 哨兵模式是主从模式的升级, 系统更健壮, 可用性更高
缺点:
1Redis 较难支持在线扩容, 在集群容量达到上限时在线扩容会变得很复杂为避免这一问题, 运维人员在系统上线时必须确保有足够的空间, 这对资源造成了很大的浪费
七结束
今天就写到这里了, Redis 的哨兵模式是以主从模式为基础的, 所以说, 主从模式拥有的一些缺点, 在哨兵模式下也具有哨兵模式主要是监控 Master 主服务器的运行情况, 当然也会监控 Slave 从服务器的运行情况, 如果 Master 主服务器发生了故障, 该模式可以保证 Slave 从服务器顺利升级为 Master 主服务器继续提供服务, 以此提高系统的高可用性虽然哨兵模式比主从模式提高了不少系统的高可用性, 但是该模式不能水平扩容, 不能动态的增删节点, 这也是限制哨兵模式广泛应用的主要原因 Redis 也看到了这个情况, 所在在 Redis 的 3.x 以后的版本提供了一个更加强大集群模式, 那就是 Cluster 集群模式, 这个模式也是我们下一篇文章的主题
来源: https://www.cnblogs.com/PatrickLiu/p/8444546.html