Redis Sentinel（Redis哨兵）

这篇笔记是继前面redis主从配置写的，主从配置我就按照前面已经配好的主从进行哨兵配置。

1、为什么要进行哨兵配置？

在前面实践了redis的主从配置，我们可以看到配置好的master-slave，master与slave之间可以很好的同步数据，但数据只能从master同步到slave上。在我们读写分离的时候，一旦master宕机了，整个数据集群将无法正常进行读写操作，后果很严重，我们就需要一个解决方案来解决这个问题，这时候我们就可以采用哨兵模式来解决这个问题。主从+哨兵模式，既热部署进行主从切换，当master宕机，哨兵自动将其他slave中的一个提升为主数据库，即使之前的主数据库恢复正常工作，哨兵也会将其改为从数据库，做到了高可用、热部署。

2、哨兵机制

Redis的哨兵(sentinel) 系统用于管理多个 Redis 服务器,该系统执行以下三个任务:

监控(Monitoring): 哨兵(sentinel) 会不断地检查你的Master和Slave是否运作正常，以选举投票的方式判断master是否正常工作。
提醒(Notification):当被监控的某个 Redis出现问题时, 哨兵(sentinel) 可以通过 API 向管理员或者其他应用程序发送通知。

自动故障迁移(Automatic failover):当一个Master不能正常工作时，哨兵(sentinel) 会开始一次自动故障迁移操作,它会将失效Master的其中一个Slave升级为新的Master, 并让失效Master的其他Slave改为复制新的Master; 当客户端试图连接失效的Master时,集群也会向客户端返回新Master的地址,使得集群可以使用Master代替失效Master。

3、哨兵主要配置项

sentinel monitor <master-name> <ip> <port> <quorum>

这个配置表达的是哨兵节点定期监控名字叫做 <master-name> 并且 IP 为 <ip> 端口号为 <port> 的主节点。<quorum> 表示的是哨兵判断主节点是否发生故障的票数。也就是说如果我们将<quorum>设置为2就代表至少要有两个哨兵认为主节点故障了，才算这个主节点是客观下线的了，一般是设置为sentinel节点数的一半加一。

sentinel down-after-milliseconds <master-name> <times>

每个哨兵节点会定期发送ping命令来判断Redis节点和其余的哨兵节点是否是可达的，如果超过了配置的<times>时间没有收到pong回复，就主观判断节点是不可达的,<times>的单位为毫秒。

sentinel parallel-syncs <master-name> <nums>

当哨兵节点都认为主节点故障时，哨兵投票选出的leader会进行故障转移，选出新的主节点，原来的从节点们会向新的主节点发起复制，这个配置就是控制在故障转移之后，每次可以向新的主节点发起复制的节点的个数，最多为<nums>个，因为如果不加控制会对主节点的网络和磁盘IO资源很大的开销。

sentinel failover-timeout <master-name> <times>

这个代表哨兵进行故障转移时如果超过了配置的<times>时间就表示故障转移超时失败。

sentinel auth-pass <master-name> <password>

如果主节点设置了密码，则需要这个配置，否则哨兵无法对主节点进行监控。

4、哨兵配置

复制sentinel.conf与master-slave的配置文件到同一目录

配置端口(我配置的26379)