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