二、哨兵集群
前面redis的集群已经搭好了，但是主redis宕机了，并不会容灾切换，所以就需要配置哨兵。至于为什么需要3个哨兵，此时就有的说道了，哈哈哈~~~~~~~
首先说说什么是redis Sentinel：
哨兵在redis集群架构中是一个非常重要的组件，其主要功能有下面这些：
- 集群监控，即时刻监控着redis的master和slave进程是否是在正常工作。
- 消息通知，就是说当它发现有redis实例有故障的话，就会发送消息给管理员
- 故障自动转移，如果redis master 节点宕机了的话，它就会将请求转到slave 节点上，slave升为master。
- 充当配置中心，如果发生了故障转移，它会通知将master的新地址写在配置中心告诉客户端。
sentinel 本身也是分布式部署的，是一个集群去运行的并且节点间相互协调工作，那它是怎么来监控redis的呢？
(1)，当发生故障转移的时候，只有大部分哨兵节点同意才会判断你这个master是真的宕机了
(2)，如果哨兵部分节点挂了的话，整个哨兵集群依然能工作，这也是确保自身能高可用。
需要知道的哨兵核心点
哨兵集群至少要 3 个节点，来确保自己的健壮性。
redis主从 + sentinel的架构，是不会保证数据的零丢失的，它是为了保证redis集群的高可用。
在部署redis主从 + sentinel 架构之前，我们要在测试环境多测试，尽量模拟线上环境。
架构图：
说道关键,为什么需要3个哨兵，因为sentinel的分布式选举，如果哨兵集群仅仅部署了个2个哨兵实例，那么它的majority就是2（2的majority=2，3的majority=2，5的majority=3，4的majority=2），如果其中一个哨兵宕机了，就无法满足majority>=2这个条件，那么在master发生故障的时候也就无法进行主从切换。
启动哨兵：
cd /home/zmoon/redis-5.0.12/bin
./redis-sentinel //home/zmoon/redis-5.0.12/etc/sentinel.conf
主从都启动后，可以查看sentinel.conf文件，如图：
红框里面的内容是哨兵启动后，redis自动写入的主从关系，可以看到，master是谁。
当master挂了后，根据配置文件，会在3秒内把slave切换成主。至于把那个slave切换成主，根据master选举算法：
（1）跟master断开连接的时长
（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
