Redis集群数据到底放哪了？存储位置那些事儿聊聊

很多人用Redis，尤其是用到集群的时候，心里都会有个疑问：我存进去的那个键值对，到底被放在哪台机器上了？感觉像变魔术一样，找不到了，但又能取出来，今天我们就来聊聊这个“数据到底放哪了”的事儿,把它弄明白。

咱们得知道Redis集群的一个核心思想：分片，你可以把它想象成一个大柜子有很多抽屉，如果所有东西都塞进一个抽屉，那这个抽屉会特别重，找东西也慢，聪明的方法是把东西分门别类，放到不同的抽屉里，Redis集群也是这个道理，它把海量的数据分成很多份（分片），每一份交给集群里的一个“主节点”（可以理解为一个负责写和读的Redis服务）来保管，这就是数据最根本的存放位置——分布在多个主节点上。

那下一个问题来了：Redis是怎么决定把我的某个数据，比如一个叫 user:1001:name 的键，放到哪个“抽屉”（也就是哪个主节点）里的呢？这里就要提到一个关键机制：CRC16哈希算法。（来源：Redis官方文档关于集群规范的说明）别被这个名字吓到，它其实就是一个非常高效的数学公式，你把这个键的名字（user:1001:name）作为一串字符喂给这个公式，公式会很快算出来一个数字，这个数字的范围是固定的，从0到16383，这个范围被分成了连续的16000多个“小格子”，每个小格子被称为一个 哈希槽，或者简称槽。

你可以把整个集群想象成一个有16384个槽的大转盘，集群在启动的时候，就会把这些槽比较平均地分配给所有的主节点，一个三主节点的集群，可能主节点A管理0-5460号槽，主节点B管理5461-10922号槽，主节点C管理10923-16383号槽，这样一来,每个主节点都知道自己负责哪一段槽位。

当你要存储 user:1001:name 这个键时，Redis集群客户端会先用CRC16算法算出这个键对应的哈希值，然后对这个哈希值取模，最终确定它属于哪个槽，比如是第5798号槽，客户端会查一下它之前从集群获取的“配置信息”，发现5798号槽是由主节点B管理的，客户端就直接把这个键值对发送给主节点B进行存储，取数据的时候，过程也是一样的，先算槽,再找对应的节点去要。

答案很明确了：你的数据，具体存放在负责管理该数据对应哈希槽的那个主节点上。

但这还没完，因为Redis集群还有个很重要的功能叫高可用，也就是怕某台机器坏掉，对于每一个主节点，Redis集群都建议你至少设置一个从节点。（来源：Redis官方文档关于复制和高可用的说明）这个从节点会几乎是实时地复制主节点上的所有数据，相当于一个完整的备份，当主节点因为断电、网络故障等原因挂掉的时候，集群会自动在它的从节点中选举出一个新的主节点来接替工作，这样你的服务就不会中断,数据也不会丢失。

数据在从节点那里也存了一份吗？是的！所以更全面的答案是：你的数据，主要存放在一个主节点上，同时还会有一个或多个从节点拥有完全相同的数据副本。 主节点负责写操作，从节点主要负责读操作和作为备份，平常你读写数据,主要是和主节点打交道。

还有一个地方可能存放着你的数据，那就是客户端缓存，一些高级的Redis客户端会实现本地缓存功能，你第一次查询 user:1001:name，客户端会去集群里找到正确的节点，拿到数据后，除了返回给你，它可能还会在自己本地内存里存一份，并设置一个很短的过期时间，下次你再查询同样的键时，它可能就直接从本地内存里给你了，速度更快，也减轻了集群的压力，但这只是客户端的一个优化行为，数据的“正本”还是在Redis集群的节点里。

Redis集群的数据，它的“家”主要在分配了对应哈希槽的主节点内存中，为了保证安全，它还有一个或多个“备用住所”，也就是从节点，为了提升速度，它可能还会在客户端的本地有一个临时的“休息站”，理解了这套分布和备份的机制,你就能更放心地使用Redis集群了。