Redis集群里到底是怎么找到对应节点的，寻址机制是啥原理啊？

Redis集群的寻址机制，其核心思想可以概括为“数据分片”和“客户端智能路由”，它不是靠一个中心化的总指挥来告诉你数据在哪，而是像一张大家都认可的“地图”，客户端和服务器都拿着这份地图，自己能快速定位，这套机制主要依赖的是“哈希槽”（Hash Slot）这个概念。

为什么需要分片？ 想象一下，如果你的Redis数据库里存了海量的键值对，比如上亿个，而一台机器的内存是有限的，根本存不下这么多数据，解决办法就是把数据分散到多台机器（节点）上，Redis集群的做法就是把所有可能存在的键（key）分配到一个固定大小的“篮子”里，这个篮子有16384个（0到16383号）小格子，每个小格子就是一个“哈希槽”，整个集群的所有数据,就是由这16384个哈希槽来分担的。

关键一步：键是如何被分配到槽里的？ 当你存一个数据，set user:1001 "张三"，集群需要决定把这个键 user:1001 放到哪个槽里，计算规则很简单：对键名使用一种叫CRC16的算法算出一个数值，然后把这个数值对16384取余数，公式是：HASH_SLOT = CRC16(key) % 16384，这样，任何一个键都能唯一地对应到0-16383之间的一个槽号，这个计算过程非常快，而且对于同一个键，无论计算多少次,结果都是一样的。

槽又是如何分配到节点上的？ 这16384个槽需要被分配给集群里的各个主节点（负责读写数据的节点），分配工作是在集群创建时由管理员手动完成的，或者通过工具自动平均分配，一个三主节点的集群，可能这样分配：节点A负责0-5460号槽，节点B负责5461-10922号槽，节点C负责10923-16383号槽，每个主节点都清楚地知道自己负责哪些槽，并且会把这份“槽分配信息”告诉集群里的其他所有节点，集群中的每个节点都拥有一份完整的、一致的“集群槽映射图”。

客户端是如何找到正确节点的？这才是寻址的核心。 这个过程体现了“智能客户端”的含义，一个支持集群模式的Redis客户端（比如Jedis、Lettuce等）在工作时,通常会经历以下步骤：

1. 初始化连接与获取地图：客户端启动时，你只需要配置它连接集群中的任意一个或多个节点地址（种子节点），客户端会随机连上一个节点，然后向这个节点发送命令，索要当前集群的“槽映射图”，这个节点会将自己维护的完整映射图（包含每个槽由哪个主节点负责、节点的IP和端口等信息）返回给客户端。

2. 客户端缓存地图：客户端在内存里缓存这份映射图,这样它就不用每次操作都去问节点了。

3. 计算并直接路由：当你要执行一个命令，get user:1001，客户端会先做我们上面提到的那一步：对键 user:1001 计算CRC16，再对16384取余，算出它属于哪个槽（假设是1200），客户端查一下自己缓存的映射图，发现1200号槽是由节点A（IP: 192.168.1.101:6379）负责的，客户端就不会再把命令发给自己最初连接的那个种子节点了，而是直接向节点A发起连接并发送 get user:1001 命令。

4. 处理异常情况：MOVED重定向：万一客户端的映射图过时了怎么办？集群刚刚做了扩容，槽1200已经从节点A迁移到了新加入的节点D，当客户端还按照旧地图把请求发给了节点A时，节点A一查，发现这个键对应的槽1200现在已经不属于自己管了，这时，节点A不会帮客户端去节点D拿数据，而是会给客户端返回一个MOVED错误，这个错误信息非常明确，类似于：MOVED 1200 192.168.1.104:6380（意思是：“这个键在1200槽，它现在归192.168.1.104:6380管了”）。

5. 客户端更新地图：智能客户端收到MOVED错误后，不会简单地给用户报错，它会做两件事：根据错误信息中的新地址，直接去连接正确的节点D，重新发送命令以完成本次请求；它会主动更新自己本地缓存的槽映射图，把1200槽标记为由节点D负责，这样，后续所有属于1200槽的请求都会直接发往节点D,效率就恢复了。

另一个重定向：ASK重定向 在数据迁移（比如槽1200正从节点A搬到节点D）的中间状态，还会出现一种ASK重定向，它和MOVED类似，但含义不同，ASK的意思是：“这个键大概率已经迁到节点D去了，我这儿没有了，你去节点D问问看，但仅限这次查询”，客户端收到ASK重定向后，也会临时转向节点D请求数据，但不会更新自己本地的槽映射图，因为迁移可能还没完全完成，槽1200的最终归属在集群看来还是节点A，只有等迁移彻底结束，集群会广播新的映射图,那时才会产生MOVED重定向。

总结一下 Redis集群的寻址机制是一个分布式协作的过程：

• 核心是哈希槽：将数据空间划分为固定数量的槽。
• 节点负责槽：集群管理槽到节点的分配关系,并保持所有节点信息一致。
• 客户端是智能的：客户端缓存全局槽映射图,并能通过计算键的哈希槽直接定位到目标节点。
• 通过重定向纠错：当客户端信息落后时，通过MOVED（永久迁移完成）和ASK（临时迁移中）两种重定向机制来纠正客户端的请求,并保证客户端能自我更新。

这种设计的好处是，数据查询的压力被分散到了各个客户端和节点上，避免了代理层或中心查询点的瓶颈，使得Redis集群具备了很好的扩展性和性能。 原理参考自《Redis设计与实现》以及Redis官方文档中关于Cluster Specification的说明）