深入剖析Redis Cluster集群，Redis持久化机制，Redis数据类型及其数据结构

一、Redis Cluster 高可用部署方案

---

1. 部署拓扑设计（推荐）

为了保证高可用 + 扩展性 + 性能，建议采用：

6 主 6 从结构（12 实例）
每个主节点管理 2,738 个 slot，总计 16,384 个 slot

节点分布：
┌─────────────┬──────────────┐
│ 主节点 M1   │ 从节点 S1（备份 M1）│
│ 主节点 M2   │ 从节点 S2（备份 M2）│
│ 主节点 M3   │ 从节点 S3（备份 M3）│
│ 主节点 M4   │ 从节点 S4（备份 M4）│
│ 主节点 M5   │ 从节点 S5（备份 M5）│
│ 主节点 M6   │ 从节点 S6（备份 M6）│
└─────────────┴──────────────┘

建议部署方式：

环境	部署建议
云环境（K8s）	每台机器部署一个 Pod，资源隔离
物理机或虚拟机	每台部署两个实例（一个主一个从，非互为主从）
容器环境	Docker + 网络固定映射（需注意端口）

---

2. 端口规划

每个 Redis 实例需要开放：

• 主端口（默认 6379）

• 集群总线端口（主端口 + 10000） → 16379

例如：

6379 / 6380 / 6381 ...   → 对应 Redis 实例
16379 / 16380 / 16381 ...→ 用于集群心跳、failover 等通信

---

3. 目录结构建议

/data/redis/
  └── 6379/
        ├── redis.conf
        ├── dump.rdb
        ├── appendonly.aof
        ├── logs/
        └── run/

每个端口一个独立目录。

---

4. 关键配置项（redis.conf）

最小配置示例（用于集群节点）：

port 6379
cluster-enabled yes
cluster-config-file nodes.conf
cluster-node-timeout 5000
appendonly yes
appendfilename "appendonly.aof"
dbfilename dump.rdb
dir /data/redis/6379
bind 0.0.0.0
protected-mode no
daemonize yes
logfile "/data/redis/6379/logs/redis.log"

✅ 注意：Redis Cluster 模式下必须开启 AOF 或 RDB，否则迁移和重启数据可能丢失。

---

5. 启动集群节点

假设你启动了以下 6 个主节点和 6 个从节点：

redis-server /data/redis/6379/redis.conf
redis-server /data/redis/6380/redis.conf
...

---

6. 构建 Redis Cluster

使用 redis-cli --cluster 一键创建集群：

redis-cli --cluster create \
  192.168.0.1:6379 192.168.0.2:6379 192.168.0.3:6379 \
  192.168.0.4:6379 192.168.0.5:6379 192.168.0.6:6379 \
  192.168.0.1:6380 192.168.0.2:6380 192.168.0.3:6380 \
  192.168.0.4:6380 192.168.0.5:6380 192.168.0.6:6380 \
  --cluster-replicas 1

自动将 6 个主节点分配 slot、剩余作为从节点。

---

7. 高可用保障机制

1. 节点宕机自动 failover

• Redis Cluster 采用内部 Gossip + 选举 协议

• 若主节点宕机，从节点会在 cluster-node-timeout 后自动接管

• 选举由剩余主节点投票完成（多数选举）

2. 客户端自动重定向（MOVED / ASK）

客户端支持 Redis Cluster 协议，自动更新路由映射表。

---

8. 安全与稳定性建议

项目	建议配置
密码认证	requirepass + masterauth
内存限制	maxmemory + allkeys-lru
延迟监控	latency-monitor-threshold 100
审计日志	配置 logfile 和 rotate
Redis Sentinel	Redis Cluster 本身已自动选主，不需要 sentinel

---

9. 监控指标建议

工具	说明
Prometheus + Redis Exporter	监控内存、连接数、命中率、slot 分布等
Grafana	可视化面板
自研监控	重点监控 cluster_state, connected_slaves, instantaneous_ops_per_sec

---

10. 调优建议

1. 提前规划 slot 分布

使用 --cluster-slots 指定 slot 范围，避免集中热点。

2. Key 设计防跨 slot

使用 Hash Tag，如：

sign:{123}:20250609
order:{uid123}:create

确保 {} 内的内容一致即可定位到同一 slot，支持多 key 操作（如 Lua 脚本）。

---

11. 常用命令

命令	说明
redis-cli -c -h host -p port	连接 cluster 节点
cluster nodes	查看节点状态
cluster slots	查看 slot 分布
cluster info	查看集群状态
redis-cli --cluster check	检查集群一致性
redis-cli --cluster fix	自动修复 slot 问题

---

12. 小结

模块	推荐方案
集群拓扑	6 主 6 从
数据结构	Hash Tag 防跨 slot
部署方式	容器化 / 多端口隔离
容灾机制	自动选主 + AOF
管理工具	redis-cli --cluster、Exporter
高并发	分区热点、避免集中访问

二、Redis-Cluster集群中数据的读写流程

在 Redis Cluster 中，写入数据的查找过程是通过一种称为 "分片（sharding）+槽位（hash slot）+节点路由" 的机制完成的。这种机制既保证了分布式扩展能力，又保证了较高的效率。

---

1. 核心概念

1.1 集群槽位（Hash Slot）

• Redis Cluster 将所有数据 key 映射到 0~16383（共 16384 个槽位）。

• 每个节点负责若干个槽位的写入、查询和删除。

• key 是通过 CRC16(key) mod 16384 算出来的。

1.2 节点

• Redis Cluster 中的每个节点负责一部分槽位（比如节点 A 负责 0~5000）。

• 集群中包含主节点（Master）和从节点（Slave），主节点负责写入操作，从节点用于备份与故障切换。

---

2. 写入流程详细剖析

假设我们写入一个 key：set user:123 "Tom"，以下是详细过程：

步骤 1：客户端计算 key 的槽位

slot = CRC16("user:123") % 16384

比如计算结果是 4567，Redis 客户端会尝试去访问负责 slot 4567 的节点。

⚠️ Redis 允许使用“哈希标签”来固定 key 到同一个 slot，例如：set user:{123}:name Tom 和 set user:{123}:age 20 会被 hash 到同一个槽位。

---

步骤 2：客户端从路由表中查找负责这个 slot 的节点

客户端（比如 JedisCluster、Lettuce、Redisson）在初始化连接时，会从任一节点获取整张路由表：

> CLUSTER SLOTS

返回内容示例：

1) 1) (integer) 0
   2) (integer) 5460
   3) 1) "192.168.1.101"
      2) (integer) 7000
2) 1) (integer) 5461
   2) (integer) 10922
   3) 1) "192.168.1.102"
      2) (integer) 7001

说明：

• 0 ~ 5460 的 slot 属于 192.168.1.101:7000

• 5461 ~ 10922 属于 192.168.1.102:7001

• ...其余依此类推

客户端将这个信息缓存起来，后续操作中直接路由到正确节点，减少中转。

---

步骤 3：客户端直接将命令发送到对应的节点

根据 slot 映射，客户端直接将命令 SET user:123 Tom 发送到对应节点（如 192.168.1.101:7000），该节点执行写入并返回结果。

---

步骤 4：数据写入节点内存 + AOF/RDB 机制（与单机一致）

在目标节点中，Redis 会：

• 将 key 写入内存（dict）

• 触发 AOF（Append Only File） 或 RDB（快照）机制持久化

• 主节点还会异步将写入同步给从节点

---

步骤 5：容灾同步（副本机制）

每个主节点都有对应的从节点。写操作默认只写主节点，再由主节点异步复制到从节点（类似 Master-Slave）。

如：

Master A（slot 0~5460） <-- async replicate -- Slave A'

---

3. 特殊情况：重定向（MOVED、ASK）

3.1 MOVED 重定向

当客户端访问了错误的节点，节点会返回：

-MOVED 4567 192.168.1.102:7001

客户端收到后更新本地路由表，下次访问就直接访问正确节点。

3.2 ASK 重定向（迁移槽位期间）

在 slot 迁移过程中，为了不丢请求，源节点会返回：

-ASK 4567 192.168.1.103:7003

客户端必须先向目标节点发送：

ASKING
SET user:123 Tom

---

4. 完整流程图（逻辑视图）

客户端 ——> 计算 CRC16(key) % 16384 ——> 查本地槽位路由表
         │
         ├─ 若命中：直接访问目标 Redis 节点
         │
         ├─ 若失败：收到 -MOVED，刷新路由重试
         │
         └─ 若 slot 迁移中：收到 -ASK，发送 ASKING 命令临时重定向

---

5. 示例：在 Java 中查看 slot 分配

import redis.clients.jedis.HostAndPort;
import redis.clients.jedis.JedisCluster;
import redis.clients.jedis.ClusterSlotRange;

Set nodes = new HashSet<>();
nodes.add(new HostAndPort("192.168.1.101", 7000));
JedisCluster cluster = new JedisCluster(nodes);

List