Redis 是如何做到高可用的呢？
它主要通过支持主从模式、哨兵模式、集群模式这三种模式，来满足不同业务特点和可用等级的需求。 其中，主从模式部署最简单，用得也最多，集群模式比较复杂，但可用性最高。
Redis 集群模式有三种：
- 主从模式
- 哨兵模式
Cluster集群模式
1 主从模式
为了 Redis 服务避免单点故障，通常的做法是将 Redis 数据复制多个副本以部署在不同的服务器上。这样即使有一台服务器出现故障，其他服务器依然可以继续提供服务。为此，Redis 提供了复制（ replication ）功能，可以实现当一台数据库中的数据更新后，自动将更新的数据同步到其他数据库上。
Redis 服务器分为两类：一类是主数据库（Master），另一类是从数据库（Slave）。
主数据库可以进行读写操作，当写操作导致数据变化时会自动将数据同步给从数据库。
从数据库一般是只读的，并接受主数据库同步过来的数据。一个主数据库可以拥有多个从数据库，而一个从数据库只能拥有一个主数据库。
如图所示：
优点：
- 一个主，可以有多个从，并以非阻塞的方式完成数据同步；
- 从服务器提供读服务，分散主服务的压力，实现读写分离；
- 从服务器之前可以彼此连接和同步请求，减少主服务同步压力；
缺点：
- 不具备容错和恢复功能，主服务存在单点风险；
Redis的主从复制采用全量复制，需要服务器有足够的空余内存；- 主从模式较难支持在线扩容；
主从模式比较简单，可部署多个节点，其中一个作为 Master 节点，剩下的作为 Slave 节点。它的示意图如下：
在主从模式里，客户端同时连接 Master 节点和 Slave 节点，写操作通过 Master 节点执行，并将结果同步给 Slave 节点，读操作通过 Slave 节点执行。假如 Master 节点挂了，不影响读操作，我们可以通过手动修改配置将某个 Slave 节点提升为 Master 节点，重新提供写能力。
主从模式最大的优点是部署简单，最少两个节点便可以构成主从模式，并且可以通过读写分离避免读和写同时不可用。不过，一旦 Master 节点出现故障，主从节点就无法自动切换，直接导致 SLA 下降。所以，主从模式一般适合业务发展初期，并发量低，运维成本低的情况。
后来，为了避免主从无法自动切换的问题，又出现了一种新模式——哨兵模式，它是主从模式的升级。
2 哨兵模式
Redis 提供的 sentinel（哨兵）机制，通过 sentinel 模式启动 redis 后，自动监控 Master/Slave 的运行状态，基本原理是：心跳机制 + 投票裁决。
简单来说，哨兵的作用就是监控 Redis 系统的运行状况。它的功能包括以下两个：
- 监控主数据库和从数据库是否正常运行；
- 主数据库出现故障时自动将从数据库转换为主数据库；
哨兵模式主要有下面几个内容：
- 监控（
Monitoring）：Sentinel会定期检查主从服务器是否处于正常工作状态。 - 提醒（
Notification）：当被监控的某个Redis服务器出现异常时，Sentinel可以通过API向管理员或者其他应用程序发送通知。 - 自动故障迁移（
Automatic failover）：当一个主服务器不能正常工作时，Sentinel会开始一次自动故障迁移操作，它会将失效主服务器的其中一个从服务器升级为新的主服务器，并让失效主服务器的其他从服务器改为复制新的主服务器；当客户端试图连接失效的主服务器时，集群也会向客户端返回新主服务器的地址， 使得集群可以使用新主服务器代替失效服务器。
Redis Sentinel 是一个分布式系统，你可以在一个架构中运行多个 Sentinel 进程（ progress ）。
如图：
优点：
- 哨兵模式主从可以切换，具备基本的故障转移能力；
- 哨兵模式具备主从模式的所有优点；
缺点：
- 哨兵模式也很难支持在线扩容操作；
- 集群的配置信息管理比较复杂；
哨兵模式是部署图
相比主从模式，哨兵模式新增了独立部署的节点——哨兵节点（Sentinel）。
这些节点虽然不参与数据处理，但它们会像哨兵一样负责监控 Master 和 Slave 的状态及拓扑关系，并把主从关系信息提供给客户端。客户端在连接 Redis 的时候，会先连接哨兵节点，获取 Master 和 Slave 信息，然后再连接 Master 和 Slave。
在三种模式当中，哨兵模式是 Redis 官方推荐的高可用模式，那它是如何做到高可用的呢？
- 首先，哨兵集群会通过
Ping和Info请求监控所有Redis节点的状态，并且哨兵集群内会选举出Leader节点。 - 当
Master节点挂了后，哨兵集群内部会进行投票，如果超过半数节点确认Master节点挂了，则会由哨兵集群的Leader节点选择一个Slave节点进行主从切换。 - 最后，哨兵集群会将新的主从信息通知给客户端，让客户端连接到新的
Master和Slave节点上。
哨兵模式适合读请求远多于写请求的业务场景，比如在秒杀系统中用来缓存活动信息。 如果写请求较多，当集群 Slave 节点数量多了后，Master 节点同步数据的压力会非常大。怎么办呢？为了解决写请求较多的业务场景， Redis 又提供了集群模式。
3 Cluster 集群模式
Redis Cluster 是一种服务器 Sharding 技术，3.0 版本开始正式提供。采用无中心结构，每个节点保存数据和整个集群状态,每个节点都和其他所有节点连接。如图所示：
Cluster 集群结构特点：
Redis Cluster所有的物理节点都映射到 [ 0-16383 ]slot上（不一定均匀分布），Cluster负责维护节点、桶、值之间的关系；- 在
Redis集群中放置一个key-value时，根据 CRC16(key) mod 16384 的值，从之前划分的 16384 个桶中选择一个； - 所有的
Redis节点彼此互联（PING-PONG机制），内部使用二进制协议优化传输效率； - 超过半数的节点检测到某个节点失效时则判定该节点失效；
- 使用端与
Redis节点链接,不需要中间proxy层，直接可以操作，使用端不需要连接集群所有节点，连接集群中任何一个可用节点即可。
优点
- 无中心架构，节点间数据共享，可动态调整数据分布；
- 节点可动态添加删除，扩展性比较灵活；
- 部分节点异常，不影响整体集群的可用性。
缺点
- 集群实现比较复杂；
- 批量操作指令（
mget、mset等）支持有限； - 事务操作支持有限。
集群模式具体是怎么部署的呢？请看下图：
为了避免单一节点负载过高导致不稳定，集群模式采用一致性哈希算法将 Key分布到各个节点上。其中，每个 Master 节点后跟若干个 Slave节点，用于出现故障时做主备切换。
在这种模式下，Master 节点可以同时处理读和写请求。具体来说，客户端可以连接任意 Master 节点，集群内部会按照不同 key 将请求转发到不同的 Master 节点。当然，为了减少 Master 内部转发请求的压力，也可以选择在客户端连接所有 Master 节点，直接在客户端将请求哈希到对应的 Master 节点。
集群模式是如何实现高可用的呢？集群内部节点之间会互相定时探测对方是否存活，如果多数节点判断某个节点挂了，则会将其踢出集群，然后从 Slave 节点中选举出一个节点替补挂掉的 Master 节点。
虽然集群模式避免了 Master 单节点的问题，但集群内同步数据时会占用一定的带宽。所以，只有在写操作比较多的情况下人们才使用集群模式，其他大多数情况，使用哨兵模式都能满足需求。
备注：部分来源于网络，若侵权请联系删除
原文链接：https://blog.csdn.net/wohu1104/article/details/103466168
原创文章，作者：优速盾-小U，如若转载，请注明出处：https://www.cdnb.net/bbs/archives/16886
