摘要单机 Redis 再强也有天花板。本文不堆砌枯燥的概念，而是通过真实的“秒杀崩盘”故事，带你从零构建 Redis 主从、哨兵到 Cluster 分片集群，解决高并发下的数据一致性与可用性难题。

👋 我是卷毛，一名热爱分享技术干货的后端工程师。

今天这篇，我将从 Java 开发实战角度，把 Redis 集群的三种方案掰开揉碎。不管你是准备面试，还是生产环境落地，kan完心里dou有底了。

一、 那个令人绝望的深夜：单机 Redis 的“三座大山”

还记得那年双十一大促，我自信满满地把 Redis 升级到 16核64G 的“怪兽”配置。心想这配置够牛逼了吧？结果零点秒杀开始，CPU 直接飙到 100%，延迟从几毫秒飙升到几秒。geng要命的是流量稍降后Redis 居然 OOM 崩溃了——因为 RDB fork 时内存翻倍，瞬间撑爆了机器。

那晚我通宵Zuo了两件事：关掉 RDB，开始研究集群。后来我才明白，单机 Redis 就像一个超级快递员，跑得再快也送不完全城的包裹。想要高可用，必须搞“团队作战”。

单机 Redis 往往面临“三座大山”：

内存瓶颈单机内存上限受限，数据量一大就扛不住。

并发瓶颈单机 CPU 处理Neng力有限，万级 QPS 可Neng就是极限。

单点故障一旦这台机器挂了服务直接瘫痪，数据可Neng丢失。

为了翻越这三座大山，我们需要经历三个阶段的进化：主从复制 -> 哨兵模式 -> 集群模式。

二、 第一阶段：主从复制——读写分离的初步尝试

Zui简单的“团队作战”就是一主多从。

场景与原理

场景读多写少，需要数据备份。 原理一主多从，主库写，从库读，异步同步数据。

配置起来其实不难，核心就是让从库知道谁是老大。在 Redis 5.0 以后我们推荐使用 REPLICAOF 命令。

# 在从库的配置文件或命令行中执行
127.0.0.1:6380> REPLICAOF 127.0.0.1 6379

底层原理

主从复制并非简单的“复制粘贴”，它分为四个精密的阶段：

握手从库向主库发送 SYNC 命令，请求同步。

全量同步主库执行 bgsave 生成 RDB 文件，并发送给从库。从库加载 RDB 恢复数据。

缓冲同步在全量同步期间，主库继续收到的写命令会先放入 repl_backlog_buffer。

增量同步全量同步完成后主库把缓冲区的增量命令发给从库，保持一致。

实际痛点

虽然解决了“读 ”和“数据备份”的问题，但写Neng力没有 ，内存瓶颈依然存在。Ru果业务写入极猛或数据量巨大，单主库依然扛不住。

geng糟糕的是它有一个致命弱点：无自动切换。主库挂了从库只Neng傻等，需要人工手动干预，这在半夜两点发生故障时简直是灾难。

三、 第二阶段：哨兵模式——给系统装上“自动导航”

为了解决主库挂了没人管的问题，哨兵 应运而生。

哨兵是一组独立进程，负责监控主从节点，并在主库挂掉时自动完成故障转移。它就像一个永不睡觉的保安队长。

核心机制：主观下线与客观下线

哨兵判断主库是否挂了分两步走：

主观下线 单个哨兵认为主库挂了。这可Neng只是网络抖动。

客观下线 超过 quorum的哨兵dou认为挂了才触发切换。这避免了误判。

配置文件示例：

# sentinel.conf
sentinel monitor mymaster 127.0.0.1 6379 2
# 2 表示至少 2 个哨兵同意才算客观下线
sentinel down-after-milliseconds mymaster 30000
# 30秒无响应认为挂了

避坑指南：Fork 的代价

这里有个大坑！全量复制时Ru果主库内存 20G，fork 可Neng耗时 1-2 秒，这期间主库会阻塞无法处理请求。生产环境千万别在高峰期加从库！

此外断连成本高Ru果从库断连时间过长导致 repl_backlog 溢出， 重连时会触发全量复制，这会让主库雪上加霜。

实际痛点

虽然解决了“自动切换”的问题，但写Neng力依然没有 。所有的写操作依然集中在那个新选出来的主库上。对于海量数据，单机内存依然是硬伤。

四、 第三阶段：Redis Cluster —— 终极解决方案

当数据量达到几十上百G，或者写并发极高时我们就需要 Redis Cluster。它不仅解决了高可用，还解决了容量瓶颈和写性Neng瓶颈。

Redis 集群方案没有银弹。别迷信Zui佳实践：有人用哨兵扛 100G 数据结果 OOM，有人上 Cluster 却因跨槽操作改代码改到崩溃。

核心原理：哈希槽

Cluster 将数据分片存储，核心是 16384 个哈希槽。

整个集群被划分为 16384 个槽。每个节点负责管理一部分槽。当你存入一个 Key 时CRC16 % 16364 算出它属于哪个槽，然后去对应的节点存取。

这种去中心化的设计，使得集群Ke以线性 。

手把手搭建集群

假设我们有 6 台机器，3 主 3 从。 准备配置文件：

port 7000
cluster-enabled yes
cluster-config-file nodes-7000.conf
cluster-node-timeout 5000
appendonly yes

然后使用命令行创建集群：

redis-cli --cluster create 192.168.1.1:7000 192.168.1.1:7001 \
192.168.1.1:7002 192.168.1.1:7003 192.168.1.1:7004 \
192.168.1.1:7005 --cluster-replicas 1
# --cluster-replicas 1 表示每个主库配 1 个从库

客户端连接与路由

客户端会缓存 Key 到节点的映射。Ru果连错节点，节点会返回 MOVED 错误，客户端收到后会自动geng新路由并重定向到正确的节点。

Cluster 使用 Gossip 协议，节点间互相通信。当半数以上主节点认为某主节点挂了其从节点会自动升级为主节点。

避坑指南：Hash Tag

Cluster 不支持跨槽事务。Ru果你想用 MSET 操作多个 Key，必须让它们落在同一个槽，否则会报错。

解决方案使用 Hash Tag。只对 {} 内的内容Zuo哈希。

{user:1001}.name
{user:1001}.age
# 这两个 Key 会落在同一个槽，因为只计算了 user:1001

五、 生产环境实战：那些年踩过的坑

搞懂了原理，不代表就Neng用好。这里有几个血泪经验分享给大家。

1. 大规模迁移的噩梦

⚠️ 避坑指南：大规模迁移 生产环境Zuo reshard 迁移几千万 Key 时期间集群性Neng可Neng下降。建议在业务低峰期操作，或采用“双写 + 逐步切流”策略。

千万别在业务高峰期直接在线迁移，带宽被打满会导致整个集群不可用。

2. 连接池配置不当

去年双十一大促期间，我们的电商平台遭遇了一场突如其来的崩溃。排查发现，居然是连接池配置太低。

// 典型的错误配置示例
rdb := redis.NewClient(&redis.Options{
    Addr:     "localhost:6379",
    PoolSize: 10, // 默认值,高并发下远远不够！
})

高并发下连接池耗尽，线程阻塞，Zui后导致应用服务雪崩。

3. 崩溃后的应急排查

当 Redis 集群单台崩溃时不要慌。按以下步骤排查：

查kan日志。查kan Redis 集群的日志文件，检查重启过程中是否有错误信息。Ke以通过命令 tail -f /var/log/redis/redis.log 来实时查kan。

检查内存和版本。使用 redis-cli -p 7000 -c info | grep redis_version 确认版本信息，不同版本的集群行为可Neng有差异。

Zui后分析 OOM 原因。是否是 fork 导致内存翻倍？是否是某个业务 Key 没设置过期时间导致内存泄漏？

六、 与决策

Redis 集群单台崩溃案例告诉我们，结论集群不是“要不要”的问题，而是“什么时候上”的问题。

简单决策树

数据量小，并发不高：单机 + 持久化即可。

数据量中等，读多写少，怕挂：主从 + 哨兵。

数据量大，写并发高，必须高可用：Redis Cluster。

搞懂了这些，你就Neng从一个“会用 Redis”的工程师，变成一个“Neng让 Redis 为业务扛住一切”的工程师。

Q1：主从复制是同步还是异步？ 默认是异步的。Ru果你对数据一致性要求极高，Ke以配置 WAIT 命令实现同步复制，但这会牺牲性Neng。

Q2：哨兵挂了大半，集群还Neng读写吗？ Ru果哨兵挂了超过半数，将无法进行故障转移。但Ru果主库本身没挂，业务读写不受影响。只是此时系统处于“裸奔”状态，一旦主库挂了就没人救了。

Q3：Cluster 迁移过程中访问 Key 怎么办？ Ru果访问的 Key 正在迁移中，客户端会收到 ASK 错误。客户端需要去目标节点请求一次然后重定向。

也欢迎在评论区聊聊你遇到的 Redis “灵异事件”，我们一起排雷！

关注我，带你少加班，多升职！

📚 关注《卷毛的技术笔记》

---