集群搭建好之后，用户发送的命令请求可以被分配到不同的节点去处理。那Redis对命令请求分配的依据是什么？如果节点数量有变动，命令又是如何重新分配的，重分配的过程是否会阻塞对外提供的服务？接下来会从这两个问题入手，分析Redis3.0的源码实现。
1. 分配依据——槽
Redis将每个客户端的请求命令通过哈希的方式映射到槽上，映射方法就是对该客户端请求中的键值求CRC16校验值，求得的值再和16383（0x3FFF）进行与操作，得到的结果即为槽值；Redis集群默认设置了16384个slot槽，集群的节点接管了哪些槽就会存储相对应的数据库键值对，每个节点可以接管的槽数量为[0, 16384]。客户端的命令发送到Redis集群的任意节点都会先根据该命令所要操作的key来计算其对应的槽。如果该槽是由接收命令的节点接管，则该节点可直接处理该命令并返回客户端结果，如果槽是由其他节点接管则会返回给客户端MOVED错误，并准备转向正确的节点进行处理。这就是Redis集群分配命令的基本原理。（备注：如果客户端的请求中不带有key，则该命令不会对Redis存储的数据进行操作，只是获取服务状态的命令，无需分配到其他节点）
1.1 槽初始分配
对槽的初始分配是通过cluster addslots命令实现的
Cluster addslots <slot>