龙果学院高并发与高性能大型缓存架构学习第三天：哨兵sentinal
1.高可用是什么？总时间 = 系统可用时间+系统故障时间，可用性 = 系统可用时间/总时间
2.sentinal 烧饼好吃
烧饼的功能：
（1）集群监控，负责监控redis matser和slave是否正常工作
（2）消息通知，有故障，报警通知给管理员
（3）故障转移，如果master node挂掉了，会自动转移到slave node上
（4）配置中心，通知client新的master地址
烧饼本身也是分布式： 故障转移：涉及到分布式选举问题 只能保证redis集群的高可用性 至少需要3个实例
3.经典的3节点烧饼集群
为什么redis只有两个节点没法工作？
2的majority=2
3的majority=2
5的majority=3
4的majority=2。什么逻辑啊？
2个节点挂掉一个，没法满足majority=2 啊
经典的3节点烧饼集群：
Configuration: quorum = 2，majority
如果M1所在机器宕机了，那么三个哨兵还剩下2个，S2和S3可以一致认为master宕机，然后选举出一个来执行故障转移
同时3个哨兵的majority是2，所以还剩下的2个哨兵运行着，就可以允许执行故障转移
4.数据丢失的情况以及解决方案
（1）异步复制导致的数据丢失
（2）脑裂导致的数据丢失 网络原因--->master脱离slave的连接--->slave选举new master--->client没有切换 继续向old master写
--->old master转变为slave，new master数据覆盖old matser--->数据的丢失
解决异步复制和脑裂导致的数据的丢失：
min-slaves-to-write 1
min-slaves-max-lag 10
在脑裂场景下，最多丢失10秒的数据
5.redis烧饼多个核心底层原理的深入解析
1>sdown和odown转换机制
sdown是主观宕机、一个烧饼发觉master宕机了，那么就是主管宕机
odown是客观宕机，如果quorum数量的烧饼都觉得matser宕机了，那么就是客观宕机
sdown打成的条件：一个烧饼ping一个master，超过is-master-down-after-milliseconds指定的毫秒数之后，主观认为master宕机了
sdown到odown转换的条件：如果一个烧饼在指定的时间内，收到quorum指定数量的其他烧饼也认为master是sdown，那么就认为odown了，客观认为master宕机
2>烧饼集群的自动发现机制
烧饼互相之间的发现，
是通过redis的pub/sub系统实现的，sentinel:hello这个channel是烧饼沟通的桥梁，
沟通的内容是自己的host、ip、runid还有对master的监控配置
每个烧饼还会跟其他烧饼交换对matser的监控配置，互相进行监控配置同步
3>slave配置的自动纠正
烧饼会负责自动纠正slave的一些配置，比如slave如果成为潜在的matster候选人，烧饼会确保slave在复制现有matser 的数据；如果slave连接到一个错误的matser上，比如故障转移之后，那么烧饼会确保他们连接到正确的amtser上
4>slave->master选举算法
投票确认是否odown，开始主备切换，首先要选举一个slave来
（1）和matser断开连接的时常
（2）slave的优先级
（3）复制offset
（4）run id
如果一个slave跟master断开连接已经超过了down-after-milliseconds的10倍，外加master宕机的时长，那么slave就被认为不适合选举为master
(down-after-milliseconds * 10) + milliseconds_since_master_is_in_SDOWN_state
接下来会对slave进行排序：
（1）按照slave优先级进行排序，slave priority越低，优先级就越高
（2）如果slave priority相同，那么看replica offset，哪个slave复制了越多的数据，offset越靠后，优先级就越高
（3）如果上面两个条件都相同，那么选择一个run id比较小的那个slave
5>quorum和majority
主备切换，首先quorum数量的烧饼认为odown，然后选举出一个烧饼来切换，这个烧饼还得得到majority烧饼的授权，才能正式切换
总之选取quorum和majority中的较大值进行授权
6>configuration epoch
哨兵会对一套redis master+slave进行监控，有相应的监控的配置
执行切换的那个哨兵，会从要切换到的新master（salve->master）那里得到一个configuration epoch，这就是一个version号，每次切换的version号都必须是唯一的
如果第一个选举出的哨兵切换失败了，那么其他哨兵，会等待failover-timeout时间，然后接替继续执行切换，此时会重新获取一个新的configuration epoch，作为新的version号
7>configuration传播
哨兵完成切换之后，会在自己本地更新生成最新的master配置，然后同步给其他的哨兵，就是通过之前说的pub/sub消息机制
这里之前的version号就很重要了，因为各种消息都是通过一个channel去发布和监听的，所以一个哨兵完成一次新的切换之后，新的master配置是跟着新的version号的
其他的哨兵都是根据版本号的大小来更新自己的master配置
6.动手实践时刻
发布订阅模式：一个client向channel发布消息，其他订阅者都能收到消息
启动哨兵进程：
在eshop-cache01、eshop-cache02、eshop-cache03三台机器上，分别启动三个哨兵进程，组成一个集群，观察一下日志的输出
redis-sentinel /etc/sentinal/5000.conf
redis-server /etc/sentinal/5000.conf --sentinel
日志里会显示出来，每个哨兵都能去监控到对应的redis master，并能够自动发现对应的slave
哨兵之间，互相会自动进行发现，用的就是之前说的pub/sub，消息发布和订阅channel消息系统和机制
问题：+sdown master mymaster 172.16.55.131 6379 直接都没连上啊 汗死?
redis-cli -h 172.16.55.132 -p 6379
还得配置密码
客户端连接时候： ./redis-cli -h 127.0.0.1 -p 6379 -a Passw0rd
哨兵配置中： sentinel auth-pass mymaster tomredis.123
检查哨兵状态：
redis-cli -h 192.168.31.187 -p 5000
sentinel master my master
SENTINEL slaves mymaster
SENTINEL sentinels mymaster
SENTINEL get-master-addr-by-name mymaster
7.项目哨兵的管理以及高可用redis集群的容灾演练
增加sentinal会自动发现 基于pub/sub模式
删除sentinal步骤：
（1）停止sentinal步骤
（2）SENTINEL RESET *，清理所有master状态
（3）SENTINEL MASTER mastername，在所有sentinal上执行，查看所有sentinal对数量是否达成了一致
slave的永久下线：让master摘除某个已经下线的slave：SENTINEL RESET mastername，在所有的哨兵上面执行
slave slave-priority，值越小优先级越高
安全认证：每个slave都有可能切换成master，
so，
master上启用安全认证，requirepass，
master连接口令，masterauth
sentinal，sentinel auth-pass
问题： -failover-abort-no-good-slave master mymaster 172.16.55.131 6379
已解决 所有的redis.conf 的bind 127.0.0.1 改为bind 0.0.0.0 从节点bind没有重新写 汗死 重启解决
最终效果：
172.16.55.132:5000> SENTINEL get-master-addr-by-name mymaster
1) "172.16.55.132"
2) "6379"
日志信息如下：
2393:X 16 May 02:15:49.999 # +sdown master mymaster 172.16.55.131 6379
2393:X 16 May 02:15:50.056 # +odown master mymaster 172.16.55.131 6379 #quorum 2/2
2393:X 16 May 02:15:50.056 # +new-epoch 36
2393:X 16 May 02:15:50.056 # +try-failover master mymaster 172.16.55.131 6379
2393:X 16 May 02:15:50.057 # +vote-for-leader eedffa138a3e566ffba2fbfbac91517b27ea6a85 36
2393:X 16 May 02:15:50.061 # 91f01119e790d4879566ac8267c3aa544fc76786 voted for eedffa138a3e566ffba2fbfbac91517b27ea6a85 36
2393:X 16 May 02:15:50.142 # +elected-leader master mymaster 172.16.55.131 6379
2393:X 16 May 02:15:50.142 # +failover-state-select-slave master mymaster 172.16.55.131 6379
2393:X 16 May 02:15:50.208 # +selected-slave slave 172.16.55.132:6379 172.16.55.132 6379 @ mymaster 172.16.55.131 6379
2393:X 16 May 02:15:50.209 +failover-state-send-slaveof-noone slave 172.16.55.132:6379 172.16.55.132 6379 @ mymaster 172.16.55.131 6379
2393:X 16 May 02:15:50.285 +failover-state-wait-promotion slave 172.16.55.132:6379 172.16.55.132 6379 @ mymaster 172.16.55.131 6379
2393:X 16 May 02:15:50.723 # +promoted-slave slave 172.16.55.132:6379 172.16.55.132 6379 @ mymaster 172.16.55.131 6379
2393:X 16 May 02:15:50.723 # +failover-state-reconf-slaves master mymaster 172.16.55.131 6379
2393:X 16 May 02:15:50.777 # +failover-end master mymaster 172.16.55.131 6379
2393:X 16 May 02:15:50.777 # +switch-master mymaster 172.16.55.131 6379 172.16.55.132 6379
2393:X 16 May 02:15:50.777 * +slave slave 172.16.55.131:6379 172.16.55.131 6379 @ mymaster 172.16.55.132 6379
2393:X 16 May 02:16:20.780 # +sdown slave 172.16.55.131:6379 172.16.55.131 6379 @ mymaster 172.16.55.132 6379
对应的过程如下：
（1）三个哨兵进程都认为master是sdown了
（2）超过quorum指定的哨兵进程都认为sdown之后，就变为odown
（3）哨兵1是被选举为要执行后续的主备切换的那个哨兵
（4）哨兵1去新的master（slave）获取了一个新的config version
（5）尝试执行failover
（6）投票选举出一个slave区切换成master，每个哨兵都会执行一次投票
（7）让salve，slaveof noone，不让它去做任何节点的slave了; 把slave提拔成master; 旧的master认为不再是master了
（8）哨兵就自动认为之前的187:6379变成了slave了，19:6379变成了master了
（9）哨兵去探查了一下187:6379这个salve的状态，认为它sdown了
重新启动旧的mater：旧的matser已经变成slave
2486:X 16 May 02:16:20.856 # +sdown slave 127.0.0.1:6379 127.0.0.1 6379 @ mymaster 172.16.55.132 6379
2486:X 16 May 02:29:07.761 # -sdown slave 127.0.0.1:6379 127.0.0.1 6379 @ mymaster 172.16.55.132 6379
2486:X 16 May 02:29:17.711 * +convert-to-slave slave 127.0.0.1:6379 127.0.0.1 6379 @ mymaster 172.16.55.132 6379