Redis架构第三天：哨兵模式理论+实践总结

michellc

　　龙果学院高并发与高性能大型缓存架构学习第三天：哨兵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>　　如果一个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>　　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