Redis（六）——哨兵
Redis哨兵（Sentinel） 是一个分布式监控系统，专门用于管理Redis主从架构，实现自动故障检测和故障转移。就是为了解决我们上一篇说到的主从复制的痛点，只要主机挂了那么他的小弟会一直等待老大回来，不然只能提供读取的服务。如果老大彻底死了，那么只能天道力量手动介入了，不然这个社团没办法再正常运作了。
redis哨兵是一个redis服务器，但是他只负责监控，以及选举新的话事人，向客户端发送主机故障的报告信息等等，不能读写数据等哦。而且只要一使用哨兵监控那么都是最少三台哨兵服务器，因为我们都是社会主义，讲究的就是民主，讲究的就是少数服从多数，使用一般都是奇数，这样才能保证选择的正常，另外就是哨兵也是人，也可能生病，那么如果太少了万一流感一下不就全完了，所以保证这两个需求，最少就是三台redis哨兵。
怎么配置哨兵
我们的redis数据库服务器的配置文件叫redis.conf,那么哨兵的配置文件就是sentinel.conf，其实大多数配置和redis数据库配置是一样的，主要就是以下几个参数：
配置项 | 语法 | 默认值 | 作用 | 示例 |
|---|---|---|---|---|
监控主节点 |
| - | 监控Redis主节点 |
|
故障检测时间 |
| 30000 | 故障检测超时(毫秒) |
|
故障转移超时 |
| 180000 | 故障转移超时(毫秒) |
|
并行同步数 |
| 1 | 并行同步从节点数 |
|
认证密码 |
| - | Redis节点密码 |
|
配置纪元 |
| - | 配置纪元(自动) |
|
当前纪元 |
| - | 当前纪元(自动) |
|
sentinel monitor <name> <ip> <port> <quorum>
我们先来看这个命令，前面的不用多说了，我们直接说<quorum>这个，这个参数表示的就是客观下线的投票数，如果我们设置为2，那么只要2个哨兵投票认为主机挂了，那么就开始选举新的老大了，为什么会有客观，因为网络是有波动的，网络出现问题就会让个别哨兵认为老大去了，所以必须设置数量，不然老大挂的实在是莫名其妙了。只有大家都认为挂了才挂了，这个叫客观。
那么主观是什么？个人认为他挂了呗。sentinel down-after-milliseconds <name> <ms>
这个就是检查主机是否真的死了的配置，默认30秒，要是30秒还没回应那么就认为他真的去了，当然还是需要投票表决的和上面的命令相关，还是老样子民主。
sentinel failover-timeout <name> <ms> 这个命令就是故障转移的时间，意思就是从选举到新老大登基的时间，如果超过了这个时间本次选举就作废了，要重新选举，这个name配置就是逻辑名称，其实没啥用处，因为这个时候的主机是谁我们启动前的配置并不知道。
怎么选老大
基本的流程我们知道了，那到底怎么选呢？首先我们的redis数据库服务器里不管是主机还是从机都要配置masterauth而且这个密码通常一样，如果想不一样就写到哨兵的脚本里面，因为我们也不知道谁是谁会成为老大，写到配置里就太假了。关于如何启动哨兵就不多说了，就是和redis启动的时候一样，只是从redis-service 变成了redis-sentinel 配置文件。
1.只要主机下线了，通过哨兵的选举后，旧老大再回来也只能做臣子了，新皇帝定多叫你太上皇，但是权利旧老大还是没用的，只能读不能写。
2.选举过程中或者选举后，一般都需要重新链接服务器，不然可能会报server closed the connection，或者broken pipe，不用惊慌等待片刻后重新链接就可以了。
3.只要启动哨兵后，哨兵会自动给自己的配置文件以及redis服务器的配置文件进行修改，哨兵的配置会增加一些主从复制的信息，而主机变小弟后配置文件是会动态写入新老大的配置的，而新老大也会被哨兵把旧老大的信息给删除掉，总结一句话就是哨兵会动态修改配置文件，不然你以为小弟变老大，其他人怎么找到老大的啊。
4.哨兵是可以监控多个主机的，也就是多个主从复制架构，配置还是一样，只是端口号名称不同就可以了，而且哨兵一般都是分布在不同的服务器上的，这个本应该也是这样，不然也不会出现某个哨兵网络波动的问题，主要是因为在一台服务器上的多个哨兵意义不大，因为哨兵也是会挂的，放一起不就一锅端了。
注意事项
进行投票的是确定是否让当前主机下台，而不是选举谁到新皇帝哦，这个是要注意的，选举的流程是这样的：
1，先是哨兵检查到主机下线了，心跳在故障检查时间内都没有回复，那么这个时候发现的哨兵A投了一票说主机死了，等到其他哨兵投票，确定挂了后。
2.在哨兵中进行投票，选择一个兵王，还是一样少数服从多数。
3.兵王选出来后，由这个兵王来选择谁来做老大，这个时候是不投票的，兵王选谁就是谁，其他的只能做小弟。
好，那这个兵王是怎么选的呢？怎么投票的呢？使用的就是Raft算法，简单来说就是先到先得，再没有收到其他哨兵想当兵王的情况下，会发送给其他哨兵说自己想当兵王，如果再发之前接到了其他哨兵想当兵王的申请，那么就只能同意了，这个就是先到先得Raft算法。
那兵王又是怎么选新皇帝的呢？总不能里面有黑幕吧？其实是这样的，
首先看权限，看看权限是否是一样的，但是通常情况下都是一样的，除非是上篇说的ABC了，也就是A是B的主机，B是C的主机，那么A挂了C都没资格出来选，都不是一辈的人。
然后，如果权限相同就选择偏移量大的，为什么？这个偏移量大表示的就是从老皇帝哪里复制的东西多，尽可能保证新皇登基不影响之前的数据，这个很好理解吧。
最后，然后还是相同就看runid了，也就是谁先启动谁当老大，太子嘛肯定优先是长子对不对。
既然皇帝选出来了，那么接下来肯定就是登基叩拜了，兵王会给新皇发送slaveof no one命令，同时会给小弟发送slaveof 新皇ip 端口，完成朝代更替，就算这个时候老皇帝来了也没用了，也会被兵王发送slaveof 新皇ip 端口成为臣子。同时写入到各种的配置文件中，下次启动还是这个皇帝，总不能让老皇帝复辟吧。
好了这个就是哨兵监控的无人运维，无需天道之力干涉了，非常的方便啊铁子们。
建议
这里再重申一下使用哨兵监控的建议：
1.哨兵一旦使用就是集群，就应该是多个，这样才有意义。
2.哨兵一般使用奇数，因为少数服从多数，偶数容易势均力敌而打架。
3.哨兵部署一般在不同服务器，保证服务的高可用，总不能一锅端吧。
4.哨兵各种的配置最好都一样，不能一个用6G一个用64G吧，那还公平吗？网络延迟什么的肯定不一样。
5.现在都是docker部署，一定要确定端口的正确映射。
6.哨兵+主从复制并不能保证数据不丢失，因为哨兵只保证选新老大，再新老大选出来的这段时间，写服务也好，复制服务也好都会停摆，数据肯定会丢失的，只是丢失多少的问题，所以这个时候就需要我们的集群了，这个我们下篇说。
总结
本篇主要讲的就是redis哨兵，以及哨兵配合主从复制的流程。