{"name":"集群","id":"中间件-数据库-redis-集群","content":"# Redis Cluster\n\n## 一、问题定义层（Why）——Redis Cluster 试图解决什么？\n\n### 1. Redis 单机模型的物理极限\n\nRedis 本质是：\n\n> **单进程、内存型、事件驱动的 Key-Value 引擎**\n\n这一模型带来极高性能的同时，也内生了不可突破的上限：\n\n* **内存上限**：单机内存容量有限\n* **CPU 上限**：单线程模型难以纵向扩展\n* **IO 上限**：网络与事件循环竞争\n\n当数据规模与并发持续增长时，单机 + 主从复制只能解决**可用性**，而无法解决**容量与吞吐扩展**。\n\n### 2. Redis Cluster 的核心目标\n\nRedis Cluster 的目标可以高度抽象为一句话：\n\n> **在保持 Redis 简单模型的前提下，实现容量与吞吐的水平扩展（Scale Out）**\n\n因此，它的设计优先级是：\n\n1. 可线性扩展\n2. 去中心化\n3. 自动化故障恢复\n\n而不是：\n\n* 跨节点强一致事务\n* 复杂查询\n* 完整数据库语义\n\n> **这是一个“缓存系统”的架构选择，而不是“数据库”的选择。**\n\n---\n\n## 二、核心架构思想（What）——Redis Cluster 的三大不变原则\n\n### 原则一：数据必须分片（Sharding is Mandatory）\n\n要突破单机极限，唯一出路是：\n\n> **将 Key 空间切分，分布到多个节点上**\n\n这意味着：\n\n* 一个 Key 只能归属于一个节点\n* 多 Key 操作天然会跨节点\n\n从这一刻起，**分布式事务被放弃是必然结果，而非实现缺陷**。\n\n---\n\n### 原则二：拓扑变化必须对客户端最小侵入\n\n集群意味着：\n\n* 节点会增加\n* 节点会下线\n* 主从会切换\n\n如果客户端需要理解全部拓扑变化，系统将极度复杂。\n\n因此 Redis Cluster 引入了一个**稳定的中间抽象层**：\n\n> **Hash Slot（虚拟槽）**\n\n---\n\n### 原则三：系统必须去中心化\n\nRedis Cluster 明确拒绝：\n\n* 中心元数据节点\n* 强一致协调服务\n\n选择的是：\n\n> **所有节点平权 + 最终一致的集群视图**\n\n这是一个典型的分布式系统工程取舍。\n\n---\n\n## 三、机制层（How）——关键设计如何落地\n\n## 3.1 Slot：稳定抽象边界（Stable Abstraction Boundary）\n\n### Slot 的本质\n\nRedis Cluster 固定定义：\n\n* **16384 个 Hash Slot**\n* Key → CRC16(key) % 16384 → Slot\n\nSlot 的设计目标不是均匀，而是：\n\n> **稳定**\n\nSlot 作为中间层，完成了三重解耦：\n\n```\nKey  ──▶ Slot ──▶ Node ──▶ Memory\n```\n\n* 解耦 Key 与 Node\n* 解耦客户端与节点变化\n* 解耦扩缩容与数据语义\n\n> **Slot 是人为引入的“稳定边界”，不是数学最优解。**\n\n---\n\n## 3.2 路由模型：客户端参与的去中心化路由\n\n### MOVED：稳定态路由\n\n当客户端访问错误节点时：\n\n* 节点返回 `MOVED slot ip:port`\n* 客户端更新本地 slot → node 缓存\n\n这是一种：\n\n> **将路由状态下推给客户端的设计**\n\n优点：\n\n* 节点无路由压力\n* 集群无中心瓶颈\n\n代价：\n\n* 客户端必须具备集群感知能力\n\n---\n\n### ASK：过渡态路由\n\nASK 出现于：\n\n> **Slot 正在迁移过程中**\n\n它的语义是：\n\n* 这是一次“临时指路”\n* 客户端**不应更新**本地路由表\n\n这体现了 Redis Cluster 的一个重要哲学：\n\n> **承认系统处于不稳定中间态，而不是强行隐藏它**\n\n---\n\n## 3.3 成员管理：Gossip 作为控制平面\n\n### 去中心化控制平面\n\nRedis Cluster 没有：\n\n* Master Controller\n* Meta Server\n\n而是通过 Gossip 协议：\n\n* 每个节点维护一份集群视图\n* 通过 Ping/Pong 不断交换状态\n\n这意味着：\n\n* 集群视图是**最终一致**的\n* 状态传播存在延迟\n\n> **这是用确定性换取可扩展性的经典模式**\n\n---\n\n## 四、高可用模型（Failover）——可用性优先的选择\n\n### 4.1 故障判定\n\n* 主观下线：单节点判断\n* 客观下线：多数节点确认\n\n这是一个：\n\n> **弱共识 + 多数派确认** 的模型\n\n---\n\n### 4.2 主节点替换\n\n当持有 Slot 的主节点失败：\n\n* 其从节点参与竞选\n* 获胜者接管 Slot\n\n注意：\n\n> **Failover 的对象是 Slot，而不是节点本身**\n\n---\n\n## 五、伸缩机制（Scaling）——在线系统的代价\n\n### 5.1 扩容的本质\n\n扩容不是“加机器”，而是：\n\n> **重新分配 Slot 责任**\n\n过程包括：\n\n1. 标记迁移状态\n2. 同步迁移 Key\n3. 更新 Slot 映射\n\n迁移是：\n\n* 同步读写\n* 会阻塞源节点\n\n这是在线系统为一致性付出的现实代价。\n\n---\n\n## 六、代价层（Trade-off）——必须接受的限制\n\n这些限制不是\"缺陷\"，而是设计结果。\n\n| 限制          | 架构根因   |\n| ----------- | ------ |\n| 多 Key 操作受限  | 数据分片   |\n| 单 DB        | 简化元数据  |\n| Pub/Sub 成本高 | 全节点广播  |\n| 热点 Key      | 分片粒度固定 |\n\n---\n\n## 七、运维视角：从现象到模式\n\n### 模式一：去中心化的通信放大\n\n* Gossip 带来 O(N²) 消息趋势\n* 节点越多，控制流量越大\n\n### 模式二：稳定抽象的迁移成本\n\n* Slot 稳定\n* 数据迁移昂贵\n\n### 模式三：逻辑均匀 ≠ 物理均匀\n\n* Slot 均匀\n* Key 热度不均\n\n---\n\n## 八、架构定位总结\n\nRedis Cluster 是：\n\n* 一个 **去中心化的分布式缓存系统**\n* 一个 **为扩展性牺牲强一致性的工程方案**\n\n它非常适合：\n\n* 大规模缓存\n* 会话数据\n* 高吞吐 KV 场景\n\n但不适合：\n\n* 强事务系统\n* 复杂查询\n* 数据库替代方案\n\n## 关联内容（自动生成）\n\n- [/中间件/数据库/redis/Redis.md](/中间件/数据库/redis/Redis.md) Redis的核心概念、数据结构和基本操作，与集群架构形成基础与扩展的关系\n- [/中间件/数据库/redis/复制.md](/中间件/数据库/redis/复制.md) Redis复制机制是集群实现高可用的基础，了解复制原理有助于理解集群的主从切换机制\n- [/中间件/数据库/redis/哨兵.md](/中间件/数据库/redis/哨兵.md) Redis Sentinel提供了高可用性解决方案，与Redis Cluster在故障转移机制上有不同的设计理念\n- [/中间件/数据库/redis/数据结构.md](/中间件/数据库/redis/数据结构.md) Redis的数据结构是集群节点存储的基础，理解数据结构有助于优化集群的数据分布\n- [/中间件/数据库/redis/持久化.md](/中间件/数据库/redis/持久化.md) Redis持久化机制在集群环境中同样重要，关系到数据的安全性和恢复能力\n- [/软件工程/架构/系统设计/分布式/分布式系统.md](/软件工程/架构/系统设计/分布式/分布式系统.md) 分布式系统的基本概念和原理，为理解Redis Cluster的设计思想提供理论基础\n- [/软件工程/架构/系统设计/分布式/分布式理论.md](/软件工程/架构/系统设计/分布式/分布式理论.md) 分布式理论（如CAP定理、一致性模型）是理解Redis Cluster架构权衡的关键\n- [/软件工程/架构/系统设计/缓存.md](/软件工程/架构/系统设计/缓存.md) 缓存系统的设计原则和模式，Redis Cluster作为分布式缓存系统的应用场景和设计考量\n- [/软件工程/架构/系统设计/可用性.md](/软件工程/架构/系统设计/可用性.md) 系统可用性的设计原则，Redis Cluster的故障检测和恢复机制是实现高可用的重要手段\n- [/软件工程/架构/系统设计/扩展性.md](/软件工程/架构/系统设计/扩展性.md) 系统扩展性的设计方法，Redis Cluster通过数据分片实现水平扩展的具体实践\n- [/软件工程/架构/系统设计/分布式/分布式数据.md](/软件工程/架构/系统设计/分布式/分布式数据.md) 分布式环境下的数据管理策略，与Redis Cluster的数据分片和迁移机制密切相关\n- [/中间件/数据库/分布式数据库.md](/中间件/数据库/分布式数据库.md) 分布式数据库的设计理念和技术，与Redis Cluster在数据分布和一致性方面形成对比\n- [/软件工程/架构/系统设计/分布式/分布式一致性与协调机制.md](/软件工程/架构/系统设计/分布式/分布式一致性与协调机制.md) 分布式一致性协议和协调机制，Redis Cluster采用最终一致性模型的设计考量\n- [/软件工程/架构/系统设计/架构设计.md](/软件工程/架构/系统设计/架构设计.md) 系统架构设计的原则和方法，Redis Cluster体现了去中心化、可扩展的架构思想\n- [/算法与数据结构/散列表.md](/算法与数据结构/散列表.md) Redis内部使用散列表作为核心数据结构之一，理解散列表有助于理解Redis的数据存储机制\n","metadata":"tags: ['数据库', '分布式系统', '架构设计', '可扩展性']","hasMoreCommit":false,"totalCommits":9,"commitList":[{"date":"2026-02-12T14:07:03+08:00","author":"MY","message":"doc: 整理标签","hash":"290b3e8ad18f48832ac282290238d020fc030a88"},{"date":"2026-01-09T11:50:48+08:00","author":"MY","message":"feat(redis): 重构Redis集群文档增加架构设计深度","hash":"57b419136353d9f0c3a394cd3cc771737c9a3d48"},{"date":"2024-11-21T15:39:18+08:00","author":"MY","message":"📦扩展性","hash":"9ef3316bfb402eb1995ebd52f90bec6971ac1aca"},{"date":"2023-12-13T19:40:21+08:00","author":"MY","message":"✏Redis","hash":"642b342a819421f389fef3a4e72f0ad641fe9c84"},{"date":"2023-12-13T10:37:44+08:00","author":"MY","message":"✏Redis","hash":"8a2d69ac6b84f17f1b9083b0b452e0c482eb0bc7"},{"date":"2023-12-12T20:05:39+08:00","author":"MY","message":"✏Redis","hash":"9383a0a26f89f8ea309108f5f38002cb0919b7ac"},{"date":"2023-12-06T19:59:46+08:00","author":"MY","message":"✏Redis","hash":"e0d5cfa5358133bd93587d26f55ff78955214b42"},{"date":"2023-11-16T18:57:34+08:00","author":"MY","message":"✏Redis","hash":"7955ae3a5874322931281a113be629782a29c57a"},{"date":"2020-11-05T16:53:44+08:00","author":"MY","message":"📦重构 Redis","hash":"436d256214f45aea37f8659d4758b82fe1709560"}],"createTime":"2020-11-05T16:53:44+08:00"}