5.Redis 集群 主从复制 哨兵

1. Redis 集群

1.1 什么是 Redis 集群？

Redis 集群是 Redis 提供的一种分布式解决方案，旨在将数据分布在多个节点上，从而解决单机内存、并发和流量等瓶颈问题。通过集群架构，可以实现负载均衡，提高数据的存储和访问效率。

生活场景

想象一下，一个大型电商平台在促销活动期间，用户访问量激增。如果只有一个数据库处理所有请求，可能会导致服务器崩溃。通过使用 Redis 集群，数据被分散到多个节点上，用户请求被均匀分配到不同的节点，从而提高响应速度和系统稳定性。

1.2 Redis 集群的优势

• 水平扩展：通过增加节点来扩展系统的存储和处理能力，用户可以根据实际需求随时增加或减少节点。
• 高可用性：即使部分节点出现故障，集群仍然能够继续提供服务，确保业务的连续性。
• 分区管理：将数据分散到多个节点上，避免单个节点的负载过重，提高系统的整体性能。

1.3 数据分布理论

在分布式数据库中，数据需要按照特定的规则分布到多个节点上。常见的分区规则包括：

1.3.1 节点取余分区

使用特定的数据（如 Redis 的键或用户 ID），根据节点数量 N 使用公式 hash(key) % N 计算出哈希值，用来决定数据映射到哪一个节点上。这种方案的优点是简单，但在节点数量变化时需要重新计算数据映射关系，可能导致数据迁移。

1.3.2 一致性哈希分区

一致性哈希分区为系统中每个节点分配一个 token，这些 token 构成一个哈希环。数据读写时先根据 key 计算哈希值，然后顺时针找到第一个大于等于该哈希值的 token 节点。这种方式相比节点取余的好处在于加入和删除节点只影响哈希环中相邻的节点，对其他节点无影响。

1.3.3 虚拟槽分区

Redis 集群采用虚拟槽分区，将数据映射到 0 到 16383 的槽中。总共有 16384 个槽，每个节点负责一定数量的槽。这种方式简化了节点的扩容和收缩，也提高了数据的访问效率。

• 槽的概念：槽是 Redis 集群用来管理数据分布的基本单位。每个键通过哈希算法被映射到一个槽，进而决定数据存储在哪个节点上。
• 槽的分配：当你创建集群时，Redis 会将这些槽分配给集群中的各个节点。每个节点负责处理自己所拥有的槽中的数据。
• 动态扩展：当需要增加新节点时，Redis 可以重新分配槽，从而将部分槽的数据迁移到新节点上，实现动态扩展。

1.4 集群的搭建

1.4.1 节点配置

以三主三从的集群为例，配置文件示例如下。每个节点都需要独立的配置文件：

主节点（redis-6900.conf）：

plaintext

port 6900
cluster-enabled yes
cluster-config-file nodes-6900.conf
daemonize yes

从节点（redis-6901.conf 和 redis-6902.conf）：

plaintext

port 6901
cluster-enabled yes
cluster-config-file nodes-6901.conf
daemonize yes
slaveof 127.0.0.1 6900  # 指定主节点

1.4.2 创建集群

使用以下命令创建集群：

bash

./redis-cli --cluster create 127.0.0.1:6900 127.0.0.1:6901 127.0.0.1:6902 --cluster-replicas 1

这条命令会创建一个包含三个主节点和三个从节点的集群，--cluster-replicas 1 表示每个主节点有一个从节点。

1.5 集群管理

使用以下命令检查集群状态：

./redis-cli --cluster check 127.0.0.1:6900

可以查看集群的槽分配情况、节点状态等信息。它会返回每个节点的状态、槽的分配情况以及是否存在故障节点。

2. Redis Sentinel 哨兵机制

2.1 什么是 Redis Sentinel？

Redis Sentinel 是 Redis 提供的高可用解决方案，能够自动监控主节点和从节点的状态，并在主节点故障时自动进行故障转移。这一机制确保了 Redis 的高可用性，避免了人工干预的需求。

生活场景

想象一下，一个在线支付系统需要确保交易数据的安全性和可用性。如果主数据库出现故障，系统必须能够迅速切换到备用数据库，确保用户能够继续完成付款。Redis Sentinel 就是为了满足这种高可用性需求而设计的。

2.2 Sentinel 的工作原理

2.2.1 定时监控任务

Redis Sentinel 使用定时任务监控 Redis 节点的状态，主要有以下三种任务：

1. 每隔10秒：向主节点和从节点发送 info 命令获取最新状态。
2. 每隔2秒：通过 __sentinel__:hello 频道与其他 Sentinel 节点交换状态信息。
3. 每隔1秒：发送心跳检测命令，确认节点的可达性。

2.2.2 主观下线与客观下线

• 主观下线：当 Sentinel 认为某个节点不可达时，标记为主观下线。这是一个单独的判断，可能存在误判。
• 客观下线：当大多数 Sentinel 节点一致认为某个节点不可达时，标记为客观下线，这时会进行故障转移。

2.3 故障转移

当主节点被标记为客观下线时，Sentinel 会选举一个新的主节点。故障转移的步骤包括：

1. 从从节点列表中选出一个健康的从节点作为新的主节点。
2. 执行 slaveof no one 命令，将其提升为主节点。
3. 更新其他从节点，让它们复制新的主节点。
4. 通知客户端新的主节点地址，以便客户端进行后续的读写操作。

2.4 Sentinel 的搭建

2.4.1 启动 Sentinel 节点

使用以下命令启动 Sentinel 节点，确保使用正确的配置文件路径：

redis-sentinel /path/to/sentinel.conf

配置文件示例（sentinel.conf）：

plaintext

port 26379
sentinel monitor mymaster 127.0.0.1 6900 2  # 监视主节点
sentinel down-after-milliseconds mymaster 5000  # 5秒后认为主节点下线
sentinel failover-timeout mymaster 60000  # 故障转移超时时间

2.4.2 确认 Sentinel 状态

可以通过以下命令查看 Sentinel 状态：

redis-cli -p 26379 sentinel masters

该命令会返回当前监控的主节点信息以及其状态。

3. 主从复制

3.1 什么是主从复制？

主从复制是 Redis 提供的一种数据复制机制，允许一个主节点将数据复制到一个或多个从节点。在主从复制中，主节点负责处理写操作，而从节点则负责处理读操作，从而实现读写分离和负载均衡。

生活场景

在社交媒体应用中，用户的动态信息需要被多个用户访问。如果所有用户的请求都指向主数据库，可能会导致主数据库过载。通过设置多个从节点，用户可以从从节点读取动态信息，从而减轻主节点的压力。

3.2 主从复制的工作原理

1. 配置主从关系：通过命令 SLAVEOF 将从节点配置为主节点的副本。例如：

   SLAVEOF 127.0.0.1 6900

2. 数据同步：从节点在启动时会向主节点发送 SYNC 命令，主节点会将当前的数据快照发送给从节点。初次同步时，从节点会接收主节点的全部数据。
3. 增量复制：在初始同步完成后，主节点会将后续的写操作以增量的方式发送给从节点，确保从节点的数据保持最新。主节点会通过 PSYNC 命令与从节点保持连接，处理后续的写操作。

3.3 主从复制的优点

• 提高读性能：通过将读请求分散到多个从节点，可以有效提高系统的读性能。
• 数据备份：从节点作为主节点的备份，确保在主节点故障时能够快速切换，减少数据丢失的风险。

4. 读写分离与高可用

4.1 从节点的作用

从节点可以用于扩展主节点的读能力，尤其在读多写少的场景下非常适用。通过 Redis Sentinel，可以实现从节点的高可用，确保在主节点故障时，系统仍然能够正常工作。

4.2 Redis Sentinel 读写分离设计思路

为了实现从节点的高可用，客户端需要实时掌握所有从节点的状态。通过监控 Sentinel 节点的事件消息，客户端可以动态调整可用的从节点列表，实现高效的读写分离。通常，客户端会优先选择从节点进行读操作，而将写操作发送到主节点。

应用案例

在一个在线购物网站中，用户在浏览商品时，系统会从从节点读取商品信息，而在用户下单时，写操作会发送到主节点。这样可以有效分散读写压力，提高系统的响应速度和用户体验。

5. 底层原理

5.1 Redis 数据存储原理

Redis 将数据存储在内存中，使用数据结构（如字符串、哈希、列表、集合等）来高效管理数据。每种数据结构都有其独特的底层实现，以优化特定类型的操作。

5.2 网络通信原理

Redis 使用 TCP 协议进行客户端与服务器之间的通信。所有命令都是以简单的文本协议发送，Redis 的性能优势部分来源于其高效的网络 I/O 操作。

5.3 复制与持久化机制

• 复制：通过主从复制机制，Redis 能够将数据实时复制到从节点，确保数据的一致性和高可用性。
• 持久化：Redis 提供 RDB（快照）和 AOF（追加文件）两种持久化机制，确保数据在服务器重启后仍然可用。