Redis集群概念（切片）

为何要切片集群？

无论是主从集群还是哨兵集群（基于主从集群），每个实例都保存着所有的数据。对于fork子进程做数据持久化时，会拷贝整个实例的数据，数据量大时候，就会出现Redis的卡顿。而切片集群就解决了这个问题。按照一定规则，把收到的数据划分成多分，每一份用一个实例来保存，就能减少fork子进程时产生的阻塞时间。

数据切片和实例的对应关系？

在Redis3.0之前，官方并没有针对切片集群提供具体的方案。从3.0开始，官方提供了一个名为Redis Cluster的方案，用于实现切片集群。Redis Cluster的方案中就规定了数据和实例的对应规则。

Redis Cluster的方案？

Redis Cluster方案采用哈希槽（hash slot），来处理数据和实例之间的映射关系。规定一个切片集群共有16384个哈希槽，每个键值对都会根据它的key，被映射到一个哈希槽中。类似于hashMap的结构，只不过规定了数组长度。具体映射过程分为两大步：

1. 根据键值对的key，按照CRC16算法计算一个16bit的值，然后再用这个16bit的值对16384取模，得到0-16384范围内的模数，再映射到相应实例上。
2. 在使用cluster create命令创建集群时，Redis会自动把这16384个槽平均分布在集群实例上。也可以使用cluster meet命令手动建立实例间连接，形成集群，再使用cluster addslots命令，指定每个实例上的哈希槽个数。可以根据不同实例的资源配置情况，使用手动分配哈希槽。（需要将16384个槽分配完，否则Redis集群无法正常工作）

客户端如何定位数据？

在定位键值对数据时，它所处的哈希槽是可以通过计算得到的，这个计算在客户端发送请求时来执行。但是，要进一步定位到哪个实例上，还需要知道哈希槽分布在哪个实例上。在建立集群时，每个实例只知道自己分配了那些哈希槽，但Redis实例会把自己的哈希槽信息发给和它相连接的其他实例，来完成哈希槽分配信息的扩散。当实例之间相互连接后，每个实例就有所有哈希槽的映射关系了。客户端和集群建立连接后，实例就会把哈希槽的分配信息发给客户端。客户端收到哈希槽信息后会先缓存在本地，当客户端请求键值对时，会先计算键所对应的哈希槽，然后给相应的实例发送请求。

实例和哈希槽对应关系变化？

1. 在集群时，实例有新增或者删除，Redis需要重新分配哈希槽
2. 为了负载均衡，Redis需要把哈希槽在所有实例上重新分布一遍（这里的负载均衡是人为重新分布哈希槽还是Redis主动重新分布）

哈希槽和实例关系变化之后，实例之间还可以通过相互传递消息，获得最新的哈希槽分配信息。但是，客户端是无法主动感知这些变化的。这就会导致，它缓存的分配信息和最新的分配信息就不一致了，那该怎么办呢？

Redis Cluster 重定向机制？

当客户端把一个键值对的操作请求发给一个实例时，如果这个实例上并没有这个键值对映射的哈希槽，那么，这个实例就会给客户端返回下面的 MOVED或者ASK 命令响应结果，这个结果中就包含了新实例的访问地址。

GET name
(error) MOVED 5798 172.18.0.1:6392

客户端接收到MOVED 命令，表示客户端请求的键值对所在的哈希槽 5798，实际是在 172.18.0.1:6392 这个实例上。通过返回的 MOVED 命令，就相当于把哈希槽所在的新实例的信息告诉给客户端了。这样一来，客户端就可以直接和 172.18.0.1:6392 连接，并发送操作请求了。同时还会更新本地缓存，把哈希槽与实例的对应关系更新过来。

GET name
(error) ASK 5798 172.18.0.1:6392

客户端接收到ASK命令，表示客户端请求的键值对所在的哈希槽5798，实际是在 172.18.0.1:6392 这个实例上。通过返回的 ASK命令，就相当于把哈希槽所在的新实例的信息告诉给客户端了。这样一来，客户端就会发送ASKING和 172.18.0.1:6392 连接，并发送操作请求了。但是客户端并不会更新本地缓存，所以客户端的下次请求还是会请求6394这个端口。

何时发送ASK或者MOVED？

客户端请求的键值对所在的哈希槽 5798，在 172.18.0.1:6392 这个实例上，但是这个哈希槽正在迁移。此时，客户端需要先给 172.18.0.1:6392 这个实例发送一个 ASKING 命令。这个命令的意思是，让这个实例允许执行客户端接下来发送的命令。然后，客户端再向这个实例发送 GET 命令，以读取数据。其余情况则使用 MOVED 命令。