redis哨兵模式
redis主从虽然解决了单点导致的数据丢失问题，但是还是没有解决无缝的故障转移，也就是说在主库宕机后，从库无法自动切换为主库，需要手工去切换，在这一瞬间会对后端数据库造成极大的负载，可能直接导致后端数据宕机。
哨兵主要作用
哨兵模式是一种特殊的模式，首先Redis提供了哨兵的命令，哨兵是一个独立的进程，作为进程，它会独立运行。其原理是哨兵通过发送命令，等待Redis服务器响应，从而监控运行的多个Redis实例。
监控：监控redis主库及从库运行状态；
通知：如果redis发生故障转移，可以通过邮件通知管理员；
自动故障转移：当哨兵监测到master宕机，会自动将slave切换成master，然后通过发布订阅模式通知其他的从服务器，修改配置文件，让它们切换主机。
然而一个哨兵进程对Redis服务器进行监控，可能会出现问题，为此，我们可以使用多个哨兵进行监控。各个哨兵之间还会进行监控，这样就形成了多哨兵模式。
工作原理
哨兵(sentinel) 是一个分布式系统，你可以在一个架构中运行多个哨兵(sentinel) 进程，这些进程使用流言协议(gossipprotocols)来接收关于Master是否下线的信息，并使用投票协议(agreement protocols)来决定是否执行自动故障迁移，以及选择哪个Slave作为新的Master。
每个哨兵(sentinel) 会向其它哨兵(sentinel)、master、slave定时发送消息，以确认对方是否”活”着，如果发现对方在指定时间(可配置)内未回应，则暂时认为对方宕机了，这就是所谓的”主观认为宕机”Subjective Down,简称sdown)。
若“哨兵群”中的多数sentinel，都报告某一master没响应，系统才认为该master真正宕机，即客观上认为宕机，Objective Down,简称odown)，通过一定的vote算法，从剩下的slave节点中，选一台提升为master，然后自动修改相关配置。
用文字描述一下故障切换（failover）的过程。假设主服务器宕机，哨兵1先检测到这个结果，系统并不会马上进行failover过程，仅仅是哨兵1主观的认为主服务器不可用，这个现象成为主观下线。当后面的哨兵也检测到主服务器不可用，并且数量达到一定值时，那么哨兵之间就会进行一次投票，投票的结果由一个哨兵发起，进行failover操作。切换成功后，就会通过发布订阅模式，让各个哨兵把自己监控的从服务器实现切换主机，这个过程称为客观下线。这样对于客户端而言，一切都是透明的。
Redis配置哨兵模式
配置3个哨兵和1主2从的Redis服务器来演示这个过程。
| 服务类型 | 是否是主服务器 | IP地址 | 端口 |
|---|---|---|---|
| Redis | 是 | 192.168.179.102 | 6379 |
| Redis | 否 | 192.168.179.103 | 6379 |
| Redis | 否 | 192.168.179.104 | 6379 |
| Sentinel | - | 192.168.179.102 | 26379 |
| Sentinel | - | 192.168.179.103 | 26379 |
| Sentinel | - | 192.168.179.104 | 26379 |
