Redis，作为一款开源的、内存中的数据结构存储系统，以其出色的性能和丰富的数据结构在业界赢得了广泛的认可。然而，当我们面临大量数据和高并发请求时，单个 Redis 实例可能无法满足我们的需求。这时，我们就需要使用到 Redis 的主从模式、哨兵系统和集群模式。通过这些模式，我们可以提高数据的可用性和可靠性，提高系统的性能和扩展性。在接下来的文章中，我将详细介绍如何搭建和使用 Redis 主从模式、哨兵系统和集群模式，以及这些模式的工作原理，故障转移和扩容等操作。

---

---

1、Redis主从

详细链接：Redis主从复制集群的介绍及搭建

1.1、Redis主从概念

你的理解是正确的。Redis 的主从模式是一种常见的数据冗余和读写分离的策略。

在主从模式中，主库负责处理写操作，并将数据的变更同步到从库。从库主要用于处理读操作，这样可以分担主库的读取压力，提高系统的读取性能。

当主库出现故障时，可以通过故障转移的方式，将其中的一个从库提升为新的主库，以保证服务的可用性。这个过程可以通过 Sentinel 系统自动完成，也可以手动进行。

需要注意的是，虽然主从模式可以提高系统的读取性能和可用性，但是它并不能解决单点故障的问题。因为所有的写操作都需要通过主库进行，如果主库出现故障，那么整个系统的写操作就会被阻塞。因此，对于需要高可用性的场景，我们通常会使用 Redis 集群模式。

1.2、主从复制的步骤

以下是 Redis 主从复制的基本步骤：

1. 配置从服务器：你可以通过在从服务器上执行 SLAVEOF <master-ip> <master-port> 命令来配置从服务器。这将使从服务器开始监听主服务器，准备复制数据。

2. 数据同步：一旦从服务器接收到 SLAVEOF 命令，它将开始一个同步过程。在这个过程中，主服务器会创建一个当前数据的快照并将其发送给从服务器。

3. 命令复制：数据同步完成后，主服务器会继续在接收到写命令时将其发送给所有从服务器。这样，所有的从服务器都能实时地保持和主服务器一致的数据。

4. 读取数据：你可以配置应用程序从从服务器读取数据，以此来分担主服务器的读取负载。

5. 故障转移：如果主服务器出现故障，你可以手动或通过 Sentinel 系统自动将一个从服务器提升为新的主服务器。

注意：在 Redis 4.0 以后，SLAVEOF 命令已经被 REPLICAOF 命令替代，但是为了向后兼容，SLAVEOF 命令仍然可以使用。

1.3、Redis主从拓扑结构

Redis 的复制拓扑结构可以支持单层或多层复制关系，根据拓扑复杂性可以分为以下三种：一主一从、一主多从、树状主从结构。

• 一主一从结构：是最简单的复制拓扑结构，用于主节点出现宕机时从节点提供故障转移支持；
• 一主多从结构（又称为星形拓扑结构）：使得应用端可以利用多个从节点实现读写分离。对于读占比较大的场景，可以把读命令发送到从节点来分担主节点压力；
• 树状主从结构（又称为树状拓扑结构）：使得从节点不但可以复制主节点数据，同时可以作为其他从节点的主节点继续向下层复制。通过引入复制中间层，可以有效降低主节点负载和需要传送给从节点的数据量

1.4、主从复制的问题

主从复制虽好，但也存在一些问题：

1. 主从数据不一致：由于网络延迟或者其他原因，可能会导致主从节点的数据出现短暂的不一致。虽然 Redis 通过复制缓冲区和部分重同步机制尽量减少这种情况的发生，但是在某些极端情况下，还是可能出现数据不一致的问题。
2. 读取过期数据：如果主节点删除了一个已经过期的键，但是这个删除操作还没有来得及同步到从节点，那么在从节点上就可能读取到这个已经过期的键。
3. 一主多从，全量复制时主库压力问题：在一主多从的架构中，如果多个从节点同时进行全量复制，那么会给主节点带来很大的压力，可能会影响到主节点的性能。

---

2、Redis哨兵

详细链接：Redis哨兵集群的介绍及搭建

2.1、Redis哨兵模式概述

主从模式中，一旦主节点由于故障不能提供服务，需要人工将从节点晋升为主节点，同时还要通知应用方更新主节点地址。显然，多数业务场景都不能接受这种故障处理方式。Redis 从 2.8 开始正式提供了 Redis哨 兵机制来解决这个问题。

Redis Sentinel（哨兵）系统是为了解决 Redis 主从模式中主节点故障的问题而设计的。它可以自动监控 Redis 主从节点的运行状态，当主节点出现故障时，Sentinel 系统可以自动将从节点提升为新的主节点，并通知应用方更新主节点地址。

以下是 Redis 哨兵模式的主要特点：

1. 监控：哨兵会定期检查主服务器和从服务器是否正常运行，这包括检查是否能正常响应客户端的请求，以及主从服务器之间的数据复制是否正常。
2. 通知：当哨兵发现主服务器出现故障时，它可以通过 API 向管理员发送通知。
3. 自动故障转移：当主服务器出现故障时，哨兵会自动从从服务器中选举出一个新的主服务器，并让其他的从服务器开始复制新的主服务器。
4. 配置提供者：客户端可以向哨兵询问哪个服务器是当前的主服务器。这样，即使发生了故障转移，客户端也能找到正确的主服务器。

2.2、哨兵的工作模式

Redis 哨兵（Sentinel）的工作模式主要包括以下几个步骤：

1. 周期性检测：每个哨兵会以每秒一次的频率向它所知道的主库、从库以及其他哨兵实例发送 PING 命令。
2. 主观下线判断：如果一个实例在一定时间内（由 down-after-milliseconds 配置项指定）没有回应 PING 命令，那么哨兵会将这个实例标记为主观下线。
3. 客观下线判断：如果主库被标记为主观下线，那么所有监视这个主库的哨兵会以每秒一次的频率确认主库是否真的下线。只有当足够多的哨兵（数量由配置文件指定）确认主库下线，主库才会被标记为客观下线。
4. 选主模式：当主库被标记为客观下线后，哨兵会进入选主模式，选出一个新的主库。
5. 主观下线状态移除：如果没有足够多的哨兵确认主库下线，或者主库重新回应了 PING 命令，那么主库的主观下线状态就会被移除。

通过这种方式，哨兵系统可以自动监控 Redis 主从节点的运行状态，当主节点出现故障时，自动进行故障转移，无需人工干预。

2.3、哨兵确定主库下线

Redis 哨兵（Sentinel）判断主库是否下线主要通过主观下线和客观下线两个概念来实现：

1. 主观下线：哨兵进程会定期向主库发送 PING 命令，如果主库在一定时间内（由 down-after-milliseconds 参数指定）没有回应 PING 命令，那么哨兵会将主库标记为主观下线。
2. 客观下线：如果主库被标记为主观下线，那么所有监视这个主库的哨兵会以每秒一次的频率确认主库是否真的下线。只有当多数哨兵（数量由 Redis 管理员设定）确认主库下线，主库才会被标记为客观下线。

这种判断机制可以避免对主库的误判，减少不必要的主从切换，从而降低系统的开销。只有当多数哨兵确认主库下线，才会进行主从切换，这样可以确保主从切换的决策是基于多数哨兵的共识，从而提高了决策的可靠性。

2.4、哨兵的选主过程

Redis 哨兵（Sentinel）在选主过程中，主要包括过滤和打分两个步骤：

1. 过滤：哨兵会首先过滤掉那些不适合作为主库的从库。例如，已经下线的从库，或者网络状态不佳、经常超时的从库。这个过滤过程主要是通过检查 down-after-milliseconds 参数来实现的，这个参数表示我们认定主从库断连的最大连接超时时间。
2. 打分：过滤掉不适合的从库后，哨兵会给剩下的从库打分。打分主要根据以下三个规则：
   • 从库优先级：优先级高的从库得分高。优先级可以通过 slave-priority 配置。
   • 从库复制进度：与旧的主库复制进度最快的从库得分高。
   • 从库 ID 号：ID 号小的从库得分高。

最后，得分最高的从库会被选为新的主库。这种选主策略既考虑了从库的状态和性能，也考虑了从库的优先级和 ID，从而尽可能地选择出最适合作为主库的从库。

---

3、Redis集群

详细链接：Redis Cluster 集群的介绍

3.1、Redis集群模式概述

Redis Cluster（集群）是为了解决单个 Redis 实例存储容量有限和在线扩容困难的问题而设计的。它通过数据分片的方式，将数据分散到多个 Redis 实例中，从而实现了 Redis 的分布式存储。

在 Redis Cluster 中，每个节点都存储一部分数据，这样可以大大提高系统的存储容量。同时，由于数据是分散存储的，所以当需要增加存储容量时，只需要增加节点即可，实现了在线扩容。

此外，Redis Cluster 还提供了复制和故障转移的功能，当某个节点出现故障时，可以自动将其上的数据转移到其他节点，从而保证了系统的高可用性。

例如，如果你需要存储 15G 的数据，你可以选择使用单个 Redis 实例，但这可能会导致响应速度变慢。而如果你选择使用 3 台 Redis 实例组成的集群，那么每个实例只需要存储 5G 的数据，这样可以大大提高系统的响应速度和存储效率。

Redis 集群没有使用一致性哈希，而是引入了哈希槽的概念。Redis 集群有 16384个 哈希槽，当需要在 Redis 集群中放置一个键值对时，Redis 首先会对键进行 CRC16计 算，然后对 16384 取余数，得到的结果就是这个键应该被放置的哈希槽的编号。

每个 Redis 节点负责一部分哈希槽，例如在一个有3个节点的 Redis 集群中，可能节点 A 负责 0-5500 号哈希槽，节点 B 负责 5501-11000 号哈希槽，节点 C 负责 11001-16383 号哈希槽。

这样，当一个键需要被访问（读取、写入）时，Redis 集群会根据键名计算出哈希槽号，然后找到负责这个哈希槽的节点。

Redis 集群支持主从复制模式，每个节点都会有 0 个或多个从节点，数据会从主节点复制到从节点。当主节点宕机时，从节点可以提升为主节点，继续提供服务。

Redis 集群提供了高可用和分布式能力，但是客户端在使用时需要有一定的复杂性，例如在处理跨节点的事务和 Lua 脚本时，以及在添加、删除节点时重新分配哈希槽等。

3.2、Redis集群的虚拟槽分区

分布式的存储中，要把数据集按照分区规则映射到多个节点，常见的数据分区规则三种：节点取余分区、一致性哈希分区、虚拟槽分区。

节点取余分区（Modulo Partitioning）：这种方式是通过取余数的方式将数据映射到不同的节点上。例如，我们可以将用户 ID 对节点数量取余，然后将数据存储在对应的节点上。这种方式的优点是实现简单，数据分布相对均匀。但是，当节点数量变化时，大部分数据都需要重新分配，这会导致大量的数据迁移；

一致性哈希分区（Consistent Hashing Partitioning)：这种方式是通过一致性哈希算法将数据映射到不同的节点上。一致性哈希算法的优点是，当节点数量变化时，只需要迁移哈希环上的一小部分数据，大大减少了数据迁移的开销。同时，一致性哈希算法也能保证数据分布的相对均匀。

比如说下面 这张图里面，Key1 和 Key2 会落入到 Node1 中，Key3、Key4 会落入到 Node2 中，Key5 落入到 Node3 中，Key6 落入到 Node4 中。

但它还是存在问题：缓存节点在圆环上分布不平均，会造成部分缓存节点的压力较大；当某个节点故障时，这个节点所要承担的所有访问都会被顺移到另一个节点上，会对后面这个节点造成力。

虚拟槽分区（Virtual Slot Partitioning）：这种方式是将数据空间分割成多个虚拟槽，然后将这些虚拟槽映射到不同的节点上。Redis Cluster 就是使用的虚拟槽分区方式，它将所有的键空间分割成 16384 个虚拟槽。这种方式的优点是，当节点数量变化时，只需要重新分配虚拟槽而不是数据，减少了数据迁移的开销。同时，虚拟槽分区也能保证数据分布的相对均匀。