redis哨兵

目录

• 主从复制高可用
• 基本架构
• 实现原理
• 配置
• 安装
• 主观下线跟客观下线
• 3个定时任务
• 运维

主从复制高可用

主从复制实际就是对主服务器提供了一个数据备份； 同时可以实现分流作用（读写分离）；主从服务如果主服务器出现故障，需要手动去实现故障的转移，手动故障转移就是从从节点中选取（选取过程为那个从节点的数据量比较齐全，或手动配置权重）一个作为主节点，其他从节点去复制选出的这个从节点
手动复制比较繁琐，很多需要考虑，所有redis提供了sentinel来实现了高可用

基本架构

sentinel 也是一个进程，但是它不会存储任何的数据，它主要就是监控各个节点是否有问题，然后实现故障转移，然后通知客户端。

• 故障转移原理
  1. 需要多个sentinl确认master节点是否有问题
  2. 选出一个sentinel作为领导去实现故障的转移
  3. 选取一个slave作为master（选取过程可看选取原理）
  4. 通知其余的slave选出来的slave作为新的master
  5. 通知客户端主从的变化
  6. 老的master如果复活将会成为新的slave

配置

• sentinel monitor <masterName> <ip> <port> <quorum>
  • masterName: 多套master节点的名字
  • quorum: 法定数（多少sentinel节点认可数实现客观下线， 一边建议为sentinel数的一半加一，为基数）
• sentinel down-after-milliseconds <masterName> <timeout>
  • Sentinel节点通过定期发送ping命令来判断Redis数据节点和其余Sentinel节点是否可达， 如果超过了down-after-milliseconds配置的时间且没有有效的回复， 则判定节点不可达， （ 单位为毫秒） 就是超时时间。 这个配置是对节点失败判定的重要依据。
• sentinel parallel-syncs mymaster 1
  • 当Sentinel节点集合对主节点故障判定达成一致时， Sentinel领导者节点会做故障转移操作， 选出新的主节点， 原来的从节点会向新的主节点发起复制操作， parallel-syncs就是用来限制在一次故障转移之后， 每次向新的主节点发起复制操作的从节点个数。 如果这个参数配置的比较大， 那么多个从节点会向新的主节点同时发起复制操作， 尽管复制操作通常不会阻塞主节点，但是同时向主节点发起复制， 必然会对主节点所在的机器造成一定的网络和磁盘IO开销。
• sentinel failover-timeout mymaster 180000
  • failover-timeout通常被解释成故障转移超时时间， 但实际上它作用于故障转移的各个阶段：选出合适从节点;晋升选出的从节点为主节点;命令其余从节点复制新的主节点;等待原主节点恢复后命令它去复制新的主节点;
• sentinel auth-pass <master-name> <password&>
  • 如果Sentinel监控的主节点配置了密码， sentinel auth-pass配置通过添加主节点的密码， 防止Sentinel节点对主节点无法监控
• sentinel notification-script <master-name> <script-path>
  • sentinel notification-script的作用是在故障转移期间， 当一些警告级别的Sentinel事件发生（ 指重要事件， 例如-sdown： 客观下线、 -odown： 主观下线） 时， 会触发对应路径的脚本， 并向脚本发送相应的事件参数。该脚本会接收每个Sentinel节点传过来的事件参数， 可以利用这些参数作为邮件或者短信报警依据
• sentinel client-reconfig-script <master-name> <script-path>
  • entinel client-reconfig-script的作用是在故障转移结束后， 会触发对应路径的脚本， 并向脚本发送故障转移结果的相关参数。

安装

1. 配置开启主从节点

   主节点基本配置：(文件名为：redis-7000.conf)
   port 7000
   daemonize yes
   pidfile /var/run/redis-7000.pid
   logfile "7000.log"
   dir "/opt/soft/redis/data/"
   dbfilename dump-7000.rdb
   
   两个从节点基本配置: (文件分别为: redis-7001.conf跟redis-7002.conf)
   port 7001
   daemonize yes
   pidfile /var/run/redis-7001.pid
   logfile "7001.log"
   dir "/opt/soft/redis/data/"
   dbfilename dump-7001.rdb
   slaveof 127.0.0.1 7000
   
   port 7002
   daemonize yes
   pidfile /var/run/redis-7002.pid
   logfile "7002.log"
   dir "/opt/soft/redis/data/"
   dbfilename dump-7002.rdb
   slaveof 127.0.0.1 7000
   
   然后分别开启服务:
   redis-server redis-7000.conf
   redis-server redis-7001.conf
   redis-server redis-7002.conf
   可通过"ps -ef | grep redis | grep 700" 查看服务是否启动成功
   
   root@vagrant-ubuntu-trusty-64:/opt/soft/redis/config# ps -ef | grep redis | grep 700
   root      5504     1  0 07:22 ?        00:00:01 /redis-5.0.3/src/redis-server *:7000
   root      5672     1  0 07:34 ?        00:00:00 /redis-5.0.3/src/redis-server *:7001
   root      5678     1  0 07:34 ?        00:00:00 /redis-5.0.3/src/redis-server *:7002
   

2. 配置开启sentinel监控主节点（sentinel就是特殊的服务）

   sentinel基本配置：
   port ${port}
   daemonize yes
   dir "/opt/soft/redis/data/"
   logfile "sentinel-${port}.log"
   sentinel monitor mymaster 127.0.0.1 7000 2
   sentinel down-after-milliseconds mymaster 30000
   sentinel parallel-syncs mymaster 1
   sentinel failover-timeout mymaster 180000
   
   
   本次开启3个sentinel服务（配置文件分别为redis-sentinel-26379.conf,redis-sentinel-26380.conf,redis-sentinel-26381.conf）;开启服务：
   redis-sentinel redis-sentinel-26379.conf
   redis-sentinel redis-sentinel-26380.conf
   redis-sentinel redis-sentinel-26381.conf
   

主观下线跟客观下线

• 主管下线：每个sentine对slave节点的判断（可能是sentinel跟slave节点网络问题）
• 客观下线：所有sentinel节点对redis节点失败“达成共识”（超过 quorum个一样）

3个定时任务

1. 每10秒每个sentinel对master和slave执行info
   • 发现slave节点
   • 确认主从关系
2. 每2秒每个sentinel通过master节点的channel交换信息（pub/sub）
   • 通过__sentinel__:hello频道交互
   • 交互对节点的“看法”和自身信息
3. 每1秒每个sentinel对其他sentinel和redis执行ping
   • 心跳检测，失败判断依据

领导者选举

• 原因：只有一个sentinel节点完成故障转移
• 选举：通过sentinel is-master-down-by-addr命令都希望成为领导者
  1. 每个做主观下线的sentinel节点向其他sentinel节点发送命令，要求将它设置为领导者。
  2. 收到命令的sentinel节点如果没有同意通过其他的sentinel节点发送的命令，那么将同意该请求，否则拒绝
  3. 如果该sentinel节点发现自己的票数已经超过sentinel集合半数且超过quorum，那么它将成为领导者。
  4. 如果此过程有多个sentinel节点成为了领导者，那么将等待一段时间重新进行选举。

故障转移（sentinel领导者节点执行）

1. 从slave节点中选出一个节点作为新的master
   • 如何选择slave节点：
   1. 选择slave-priority(slave节点优先级)最高的slave节点，如果存在则返回，不存在则继续。
   2. 选择复制偏移量最大的slave节点(复制的最完整),如果存在则返回，不存在则继续。
   3. 选择runId最小的slave节点。
2. 对上面的slave节点执行slaveof no one 命令让其成为master
3. 向剩余的slave节点发送命令，让它们成为新master节点的slave的节点，复制规制跟parallel-syncs（允许同时可有多少slave进行主从复制）参数有关
4. 更新对原来master节点配置为slave，并保持着对其关注，当其恢复后命令它去复制新的master节点

运维

• sentinel failover [masterName]
  当服务器故障、性能等问题需要主动下线主节点的时候，再sentinel服务输入此命令实现主动故障转移
• 节点上线
  • 主节点：sentinel failover进行替换
  • 从节点： slaveof即可，sentinel节点可以感知
  • sentinel节点：参考其他sentinel节点启动即可