通过本文快速掌握：

1、快速了解Redis的高可用部署方式

2、不同的部署模式的优缺点

3、什么是哨兵模式

4、Redis的哨兵模式故障切换过程

总结：

Redis常见的高可用部署模式以及优劣

基于复制的特性，reids的高可用模式有3种：主从复制、哨兵模式、redis-cluster模式

主从复制保障了数据的冗余、可以实现读写分离，提升性能，是高可用的基础，但是缺点是需要人工介入，手动切换从节点为主节点，从而引入了哨兵模式，监控我们节点的健康状态以及完成故障切换。哨兵模式的也存在着缺点 ，①只有一个Master节点。当并发写请求较大时，哨兵模式并不能缓解写压力。②未能最大化利用磁盘的存储，就是说多台机器存储的是同一份数据，有点浪费资源，进而衍生出了Redis-cluster集群模式(分片模式)，通过算法将数据分布在不同的机器上，而且多主多从，提升请求的负载能力，同时也方便redis实例的扩容和缩容。

Redis故障切换的过程

主要讲解三部分

• 第一步：先说明什么是主观下线、客观下线

• 主观下线：指单个sentinel实例对服务器做出的下线判断（有可能是某个哨兵接收不到订阅、或者网络不通等原因），就主观的认为这个master不可用了。
• 客观下线：需要一定的数量，多个哨兵达成一致的意见，才能认为一个master客观上已经下线

• 第二步：哨兵leader的选举过程

• 当节点被判断客观下线之后，各个哨兵会进行协商，先选举出一个领导者哨兵节点，并且由该节点进行faiover(故障迁移)
• 哨兵节点有那么多，选哨兵leader的理由是什么呢？主要是运用了raft算法，raft算法的核心思想是先提出先得，具体步骤

• 称霸：当哨兵节点认为主节点是客观下线时，会向其他哨兵节点发送命令，要求将自己设置为leader
• 选举：收到命令的哨兵节点，如果没有同意过其他哨兵节点的请求，就同意该请求，否则拒接
• 判断：发送命令的哨兵节点发现自己的票数已经大于等于quorum和哨兵节点数量/2+1，那么它将成为领导者
• 重来：上述过程没有没有选举出leader或者选举出多个，将重新进行一次选举

• 第三步：选出新的master，完成故障切换，有两个从节点，到底选哪个作为新的master呢？？？
• 过滤节点：过滤掉"“不健康”(主观下线、断线)、没及时响应心跳的节点；
• 选择节点：按照优先级 -> 复制偏移量最大(复制最完整) -> runid最小的逻辑(先按照优先级找，没找到，再按照复制偏移量找，找到了就选择这个从节点了，依次类推)来选择一个从节点
• 执行命令：对选出来的从节点，执行slaveof no one命令让其成为主节点
• 发送命令：向剩余的从节点发送slaveof ip port命令，让它们成为新主节点的从节点
• 恢复旧主：哨兵节点对旧主节点保持关注，当其恢复后发送slaveof ip port命令将其设置为从节点，并去同步数据

下边为了解相关的知识点

主从复制

从机只允许读，不允许写

从机掉了之后，重启之后，会不会补回相关的key。可以的，可以了解下同步机制。

主机宕机之后，从机会自动上位吗？不会。这才有后面的哨兵模式，自动切换

主机宕机之后，重启之后，仍然是主机

主从复制的作用

1. 数据冗余：主从复制实现了数据的热备份，是持久化之外的一种数据冗余方式。
2. 故障恢复：当主节点出现问题时，可以由从节点提供服务，实现快速的故障恢复；实际上是一种服务的冗余。
3. 读写分离：提高服务器的负载能力，主节点提供写能力，从节点提供读能力
4. 高可用基石：除了上述作用以外，主从复制还是哨兵和集群能够实施的基础，因此说主从复制是Redis高可用的基础。

主从复制的缺点

• 复制延迟

• 主节点宕机，不会自动切换，造成写不可用

哨兵模式

Redis的主从复制模式下， 一旦主节点由于故障不能提供服务， 需要人工将从节点晋升为主节点， 同时还要通知应用方更新主节点地址， 对于很多应用场景这种故障处理的方式是无法接受的。 Redis从2.8开始正式提供了Redis Sentinel（哨兵） 架构来解决这个问题。

什么是哨兵模式

哨兵模式 是开辟一些独立的进程，用来监控redis服务器的运行状态,就像哨兵一样。其原理是哨兵通过发送命令，等待Redis服务器响应，从而监控运行的多个Redis实例。

哨兵模式作用

• 监控：通过发送命令，让Redis服务器返回监控其运行状态，包括主服务器和从服务器。
• 从变主：当哨兵监测到master宕机，会自动将slave切换成master，然后通过发布订阅模式通知其他的从服务器，修改配置文件，让它们切换主机。

然而一个哨兵进程对Redis服务器进行监控，可能会出现问题，为此，我们可以使用多个哨兵进行监控。各个哨兵之间还会进行监控，这样就形成了多哨兵模式。

哨兵模式故障切换过程

主观下线

客观下线

需要一定数量的sentinal，多个哨兵达成一致意见才能认为一个master客观上已经下线。

选出哨兵的leader

• 当节点被判断客观下线之后，各个哨兵会进行协商，先选举出一个领导者哨兵节点，并且由该节点进行faiover(故障迁移)

• 哨兵的leader选举算法（Raft算法）

1. 哨兵节点认为主节点是客观下线时，会向其他哨兵节点发送sentinel is-master-down-by-addr命令，要求将自己设置为leader
2. 收到命令的哨兵节点，如果没有同意过其他哨兵节点的sentinel is-master-down-by-addr命令(runid参数等于哨兵节点的runid)，就同意该请求，否则拒接
3. 发送命令的哨兵节点发现自己的票数已经大于等于quorum和哨兵节点数量/2+1，那么它将成为领导者
4. 上述过程没有没有选举出leader或者选举出多个，将重新进行一次选举

选出新的master,完成故障切换

有两个从节点，到底选哪个作为新的master呢？？？

1. 从节点中过滤掉"“不健康”(主观下线、断线)、5s内没有回复哨兵节点的ping命令、与主节点失联超过10*down-after-milliseconds；然后按照优先级 -> 复制偏移量最大(复制最完整) -> runid最小的逻辑(先按照优先级找，没找到，再按照复制偏移量找，找到了就选择这个从节点了，依次类推)来选择一个从节点
2. 对选出来的从节点，执行slaveof no one命令让其成为主节点
3. 向剩余的从节点发送slaveof ip port命令，让它们成为新主节点的从节点
4. 哨兵节点对旧主节点保持关注，当其恢复后发送slaveof ip port命令将其设置为从节点，并去同步数据

如果原来的主节点重启了，那么他也会是新主节点的从节点了

Redis-cluster集群

什么是Redis-cluster集群

在哨兵模式中，仍然只有一个Master节点。当并发写请求较大时，哨兵模式并不能缓解写压力。

只有主节点才具有写能力，那如果在一个集群中，能够配置多个主节点，是不是就可以缓解写压力了呢？

答：是的。这个就是redis-cluster集群模式。

（1）多个实例：由多个Redis服务器组成的分布式网络服务集群；

（2）多个主节点：集群之中有多个Master主节点，每一个主节点都可读可写；

（3）互通：节点之间会互相通信，两两相连；

（4）请求自动转发：Redis集群无中心节点，请求会随机发给任意主节点，再由算法转发到应到的节点。