红色的群集架构带来啥新变化，redis集群到底咋回事儿？

主要整合自 Redis 官方文档、多位技术社区专家如 Antirez（Redis 创始人）的博客解读、以及《Redis 设计与实现》等专业书籍中的普遍解释）

红色的群集架构带来啥新变化，redis集群到底咋回事儿？

在谈论“红色的群集”（通常指 Redis Cluster，即 Redis 官方提供的集群方案）之前，得先说说为啥需要它，早期的 Redis 虽然快，但有个明显的短板：它主要靠一个“大脑”（主节点）来处理所有读写请求和数据存储，如果这个大脑非常忙，或者干脆生病了（宕机），整个服务就可能卡住甚至瘫痪，为了解决这个问题，人们想出了“主从复制”的办法，就是给主节点配几个“跟班”（从节点），跟班会实时复制大脑里的数据，大脑挂了，可以手动选一个跟班顶上去，但这办法还是有点麻烦，需要人工干预，而且最关键的是，无论大脑多强，它存储的数据量是有上限的，一台机器的内存总是有限的。

这时候,Redis Cluster 就登场了，它带来了几个根本性的新变化：

第一个核心变化：数据分片，把大数据集“化整为零”。 这是 Redis Cluster 解决单机内存限制的法子，它不再把所有的数据都塞进一个节点里，而是把整个数据库分成 16384 个“小抽屉”（官方术语叫哈希槽），当你启动一个 Redis Cluster 时，你可以用多个节点（比如三台主节点）来共同承担这些抽屉，节点 A 管理 0 到 5500 号抽屉，节点 B 管理 5501 到 11000 号抽屉，节点 C 管理剩下的，当你存一个数据时，Cluster 会根据数据的键（Key）算出一个值，这个值决定了它该放进哪个抽屉，进而就知道该存到哪个节点上，这样，原本一台机器装不下的海量数据，现在可以由多台机器共同分担，实现了数据的横向扩展。

第二个核心变化：去中心化与自我管理，变得“聪明”了。 以前的“主从”模式通常需要一个额外的“裁判”（比如哨兵 Sentinel）来监控节点健康并决定主从切换，Redis Cluster 把这个管理功能做到了集群内部，形成了一个去中心化的结构，集群中的每个节点都保存着一份“全局地图”，上面记录着哪个节点负责管理哪些“小抽屉”，节点之间通过一种叫“Gossip”的协议互相聊天，不断地交换彼此的状态信息（比如谁还活着、谁负责的抽屉有没有变），这种设计的好处是，客户端可以连接集群中的任意一个节点，如果这个节点没有客户端想要的数据，它会根据自己手上的“地图”，告诉客户端：“这个数据不在我这儿，你去某某节点找吧”，并返回正确的地址给客户端，客户端之后就可以直接连接正确的节点进行操作了，整个过程不需要一个中心化的总指挥来调度。

第三个核心变化：高可用性内建，自动故障转移。 Redis Cluster 延续了主从复制的思想，并为每个“小抽屉”的管理者（主节点）配备了一个或多个备份（从节点），这些主从节点之间的数据是同步的，关键的区别在于，当某个主节点宕机时，整个集群不再需要外部工具来干预，集群中的其他主节点会通过“投票”的方式，共同检测到这个故障，然后自动将这个宕机主节点对应的某个从节点“提拔”为新的主节点，让它接管原来那些“小抽屉”的管理工作，这个过程是自动完成的，对应用程序的影响可以降到最低（虽然会有短暂的服务中断），大大提高了系统的可靠性。

Redis集群到底是怎么运作的呢？

可以把一个健康的 Redis Cluster 想象成一个分工明确的协作团队：

1. 准备阶段： 你需要准备好多台服务器，每台服务器上运行一个 Redis 集群模式的实例，在组建集群时，你需要明确指定哪些实例作为主节点（负责处理读写和存储部分数据），并为每个主节点指定它的从节点（负责热备份）。

2. 数据写入过程： 当你的应用程序要写入一个键值对时，它先随机连接上集群中的任意一个节点（比如节点 A），节点 A 收到命令后，会计算这个键属于哪个“小抽屉”（哈希槽），节点 A 会查一下自己的“内部地图”：

   • 如果这个抽屉正好归它自己管,它就直接执行写入操作。
   • 如果这个抽屉归节点 B 管，节点 A 不会自己去联系节点 B，而是会给客户端返回一个“重定向”指令，大意是：“MOVED [抽屉编号] [节点B的IP和端口]”，客户端收到这个指令后，会重新向节点 B 发起连接和写入请求，一个智能的 Redis 客户端库通常会帮你处理好这个重定向过程，让你感觉像是在操作一个整体的 Redis。

3. 容错过程： 假设主节点 B 突然宕机了，这时，一直与它保持“心跳”联系的其他主节点（比如节点 A 和节点 C）会很快发现节点 B“失联”了，经过短暂的确认和集体投票后，大家一致同意节点 B 已经失效，它们会共同决定，将节点 B 的从节点（B1）提升为新的主节点，B1 上位后，会广播通知集群中的所有节点更新“全局地图”，宣布从现在开始，原来由节点 B 负责的那些“小抽屉”改由它来管理，之后，所有针对这些抽屉的请求就会被引导到新的主节点 B1 上。

总结一下新变化： Redis Cluster 的核心价值在于，它通过数据分片突破了单机内存的瓶颈，通过去中心化的架构实现了系统的可扩展性和韧性，并通过内建的故障转移机制提供了高可用性，它让 Redis 从一个性能优异的“单兵作战”工具，进化成了一个能够应对大规模、高并发、高可用需求的“分布式系统”，它也不是万能的，比如它不支持同时操作多个键的事务（因为多个键可能分布在不同的节点上），架构和配置也比单机模式复杂，这些都是选择使用时需要权衡的。