Redis进阶笔记03：Redis的哨兵机制与容灾实践

主备切换的数据丢失问题
1. 2种情况导致数据丢失
  1. 异步复制
    因为master -> slave的复制是异步的，所以可能有部分数据还没复制到slave，master就宕机了，此时这些部分数据就丢失了
  2. 脑裂
    1. 脑裂指的是，某个master所在机器突然脱离了正常的网络，跟其他slave机器不能连接，但是实际上master还运行着（客户端数据还在写入，却没能同步到slave node上），此时哨兵可能就会认为master宕机了，然后开启选举，将其他slave切换成了master，这个时候，集群里就会有两个master，也就是所谓的脑裂。
    2. 这种情况下，虽然某个slave被切换成了master，但是可能客户端还没来得及切换到新的master，还继续写向旧master的数据可能也丢失了，因此旧master再次恢复的时候，会被作为一个slave挂到新的master上去，自己的数据会清空，重新从新的master复制数据
2. 解决异步复制和脑裂导致的数据丢失
  1. 配置：
```
# 要求至少有1个slave，数据复制和同步的延迟不能超过10秒
min-slaves-to-write 1
min-slaves-max-lag 10
```
    如果说一旦所有的slave，数据复制和同步的延迟都超过了10秒钟，那么这个时候，master就不会再接收任何请求了
  2. 在异步复制中的作用：
    一旦slave复制数据和ack延时太长，就认为可能master宕机后损失的数据太多了，那么就拒绝写请求，这样可以把master宕机时由于部分数据未同步到slave导致的数据丢失降低的可控范围内
  3. 在脑裂中的作用：
    如果一个master出现了脑裂，跟其他slave丢了连接，那么上面两个配置可以确保，如果不能继续给指定数量的slave发送数据，而且slave超过10秒没有给自己ack消息，那么就直接拒绝客户端的写请求。这样脑裂后的旧master就不会接受client的新数据，也就避免了后续数据丢失，最多就丢失10秒的数据。
（redis哨兵）工作原理分析
1. sdown和odown转换机制
  1. sdown和odown是两种失败状态：
    1. sdown是主观宕机（Subject Down），就一个哨兵如果自己觉得master宕机了，那么就是主观宕机
    2. odown是客观宕机（Object Down），如果quorum数量的哨兵都觉得一个master宕机了，那么就是客观宕机
  2. sdown达成的条件：如果一个哨兵ping一个master，超过了is-master-down-after-milliseconds指定的毫秒数之后，就主观认为master宕机
  3. sdown到odown转换的条件：如果一个哨兵在指定时间内，收到了quorum指定数量的其他哨兵也认为那个master是sdown了，那么就认为是odown了
2. 哨兵集群的自动发现机制
  1. 哨兵互相之间的发现，是通过redis的pub/sub系统实现的，每隔两秒钟，每个哨兵都会往自己监控的某个master+slaves集群对应的__sentinel__:hello channel里发送一个消息，内容是自己的host、ip和runid还有对这个master的监控配置，
  2. 每个哨兵也会去监听自己监控的每个master+slaves对应的__sentinel__:hello channel，然后去感知到同样在监听这个master+slaves的其他哨兵的存在
  3. 每个哨兵还会跟其他哨兵交换对master的监控配置，互相进行监控配置的同步
3. slave配置的自动纠正
  哨兵会负责自动纠正slave的一些配置，比如slave如果要成为潜在的master候选人，哨兵会确保slave在复制现有master的数据; 如果slave连接到了一个错误的master上（比如故障转移之后）那么哨兵会确保它们连接到正确的master上
4. 从slave变为的master选举算法
  1. 如果一个master被认为odown了，而且majority数量的哨兵都允许了主备切换，那么某个哨兵就会执行主备切换操作，此时首先要选举一个slave来，而在选举时会考虑slave的一些信息
    1. 跟master断开连接的时长
      1. 如果一个slave跟master断开连接已经超过了down-after-milliseconds的10倍，外加master宕机的时长，那么slave就被认为不适合选举为master，对应的公式是：
        (down-after-milliseconds * 10) + milliseconds_since_master_is_in_SDOWN_state
    2. slave优先级：按照slave优先级进行排序，slave priority越低，优先级就越高
    3. 复制offset：哪个slave复制了越多的数据，offset越靠后，优先级就越高
    4. run id（取较小的）
5. 名词解释：quorum（自由配置）、majority（依据slave node的数量自动计算）
  1. 每次一个哨兵要做主备切换，首先需要quorum数量的哨兵认为odown，然后选举出一个哨兵来做切换，这个哨兵还得得到majority数量的哨兵授权，才能正式执行切换
  2. 如果quorum < majority，比如5个哨兵，majority就是3，quorum设置为2，那么就3个哨兵授权就可以执行切换
  3. 如果quorum >= majority，那么必须quorum数量的哨兵都授权，比如5个哨兵，quorum是5，那么必须5个哨兵都同意授权，才能执行切换
6. 关于configuration epoch
  1. 哨兵会对一套redis master+slave进行监控，有相应的监控的配置。执行切换的那个哨兵，会从要切换到的新master（原salve node）那里得到一个configuration epoch，这就是一个version号，每次切换的version号都必须是唯一的
  2. 如果第一个选举出的哨兵切换失败了，那么其他哨兵，会等待failover-timeout时间，然后接替刚才执行切换失败的哨兵，继续执行切换，此时会重新获取一个新的configuration epoch，作为新的version号
7. configuraiton传播（在哨兵中的传播）
  1. 哨兵完成切换之后，会在自己本地更新生成最新的master配置，然后同步给其他的哨兵（通过redis的pub/sub消息机制）。这里之前的version号就很重要了，因为各种消息都是通过一个channel去发布和监听的，所以一个哨兵完成一次新的切换之后，新的master配置是跟着新的version号的。其他的哨兵都是根据版本号（是否与自己当前记录的版本号一致）来更新自己的master配置的
实战演练：搭建三节点的哨兵集群（生产级别）
1. 环境概况：基于一主三从的redis集群，准备在三个从节点上配置并启动哨兵服务
2. redis服务启动情况：启动了一个主节点与一个从节点的redis服务，另外2个从节点的redis服务未启动
3. 在三个从节点上配置并启动哨兵服务
  1. 将redis目录下的sentinel.conf移动至/etc/sentinel，并重命名为5000.conf（即：/etc/sentinel/5000.conf）
  2. 更改/etc/sentinel/5000.conf的如下配置
```
# 端口号
port 5000
# 本机ip方式访问
bind 192.168.0.112
# 数据文件目录（对应文件夹要手动创建）
dir /var/sentinel/5000
# sentinel monitor master-group-name master-hostname master-port quorum
sentinel monitor mymaster 192.168.0.111 6379 2
# 含义：超过多少毫秒跟一个redis实例断了连接，哨兵就可能认为这个redis实例宕机（不改动，采用默认值）
sentinel down-after-milliseconds mymaster 30000
# 含义：新的master别切换之后，同时有多少个slave被切换至新master，重新做同步，数字越低，花费的时间越多（不改动，采用默认值）
sentinel parallel-syncs mymaster 1
# 含义：执行故障转移的timeout超时时长（超时了就换个哨兵重新执行故障转移。不改动，采用默认值）
sentinel failover-timeout mymaster 180000
```
  3. 创建哨兵的数据文件目录：mkdir -p /var/sentinel/5000
  4. 临时测试方式启动哨兵服务
    1. 方式一：
```
redis-sentinel /etc/sentinal/5000.conf
```
    2. 方式二：
```
redis-server /etc/sentinal/5000.conf --sentinel
```
  5. 生产环境下的哨兵节点启动：
    1. 新增配置项：
```
    daemonize yes
    logfile /var/log/sentinal/5000
```
    2. 启动：
```
redis-sentinel /etc/sentinel/5000.conf
```
4. 效果：
  1. 从节点01的哨兵控制台信息：
  2. 从节点02的哨兵控制台信息：
  3. 从节点03的哨兵控制台信息：
5. 检查哨兵状态的命令（通过redis-cli端口号5000登录到redis后查看：redis-cli -h 192.168.0.112 -p 5000）
```
# SENTINEL get-master-addr-by-name mymaster
sentinel master mymaster
sentinel slaves mymaster
sentinel sentinels mymaster
```
6. 哨兵节点的增加和删除
  1. 增加单个哨兵接待：哨兵集群会自动检测，无需人为操作
  2. 删除单个哨兵接待：
    1. 停止sentinal进程
    2. SENTINEL RESET *，在所有sentinal上执行，清理所有的master状态
    3. SENTINEL MASTER mastername，在所有sentinal上执行，查看所有sentinal对数量是否达成了一致
7. 让某个slave node的永久下线（哨兵集群不再监测其是否在线、离线）
  让master摘除某个已经下线的slave：SENTINEL RESET mastername，在所有的哨兵上面执行
8. slave切换为Master的优先级
  slave->master选举优先级：slave-priority(redis5.0中对应的配置项：replica-priority)，值越小优先级越高
9. 基于哨兵集群架构下的安全认证
  1. 每个slave都有可能切换成master，所以每个实例都要配置两个指令
  2. master上启用安全认证，requirepass xxx
  3. slave node上配置master的连接口令，masterauth xxx
  4. sentinal：sentinel auth-pass <master-group-name> <pass>
实战演练：容灾演练
1. redis 集群的运行情况：运行了1主3从，启动了3台从机的上的哨兵服务
2. 模拟故障：命令行kill掉redis的master node
3. 可以看到，经过哨兵集群的选举，推选了ip尾号0.113的从节点作为新的master node：
4. 原master node重连后，也自动转变为新的slave node
5. 各哨兵节点、redis服务的配置文件在新的master node诞生时，已被热更改：
6. 原来的数据依旧可以访问，不受到原master宕机的影响：