一、Redis集群分为3种  

redis的主从和哨兵两种集群方案，redis从3.0版本开始引入了redis-cluster(集群)。从主从-哨兵-集群可以看到redis的不断完善；

• 主从复制是最简单的节点同步方案无法主从自动故障转移。
• 哨兵可以同时管理多个主从同步方案同时也可以处理主从自动故障转移，通过配置多个哨兵节点可以解决单点网络故障问题，但是单个节点的性能压力问题无法解决。
• 集群解决了前面两个方案的所有问题。

二、Redis的分片机制

Redis 集群没有使用一致性hash, 而是引入了哈希槽的概念。

Redis Cluster 采用虚拟哈希槽分区，所有的键根据哈希函数映射到 0 ~ 16383 整数槽内，每个key通过CRC16校验后对16384取模来决定放置哪个槽(Slot)，每一个节点负责维护一部分槽以及槽所映射的键值数据。在Redis Cluster中，只有Master才拥有槽的所有权，如果是某个Master的slave，这个slave只负责槽的使用，但是没有所有权。

计算公式：slot = CRC16(key) % 16383。

(1）假设主节点的数量为3，将16384个槽位按照用户自己的规则手动去分配这3个节点，16384除以3，那么每个节点大约得到5460个槽。（用户自定义分配的原因在于有些机器的配置高，有些机器的配置低，配置高的可以分配多一点槽位，配置低的可以分配少一点槽位）

图中定义的规则是平均分配槽位：

• 节点1的槽位区间范围为0-5460
• 节点2的槽位区间范围为5461-10922
• 节点3的槽位区间范围为10923-16383

(2)存储数据时，对要存储的键进行crc16哈希运算,得到一个值，并取模16384，判断这个值在哪个节点的范围区间。假设crc16("test_key")%16384=3345，因为3345在区间0-5460之间，所以test_key数据写入到节点1里面

(3)查询数据时，对要查询的键进行crc16哈希运算,得到一个值，并取模16384，判断这个值在哪个节点的范围区间。假设crc16("test_key")%16384=3345，因为3345在区间0-5460之间，所test_key数据应该从节点1里面获取。 

这种结构很容易添加或者删除节点，并且无论是添加删除或者修改某一个节点，都不会造成集群不可用的状态。使用哈希槽的好处就在于可以方便的添加或移除节点。

1. 当需要增加节点时，只需要把其他节点的某些哈希槽挪到新节点就可以了；
2. 当需要移除节点时，只需要把移除节点上的哈希槽挪到其他节点就行了。

三、Redis虚拟槽分区的特点

• 解耦数据和节点之间的关系，简化了节点扩容和收缩难度。
• 节点自身维护槽的映射关系，不需要客户端或者代理服务维护槽分区元数据
• 支持节点、槽和键之间的映射查询，用于数据路由，在线集群伸缩等场景。

四、 Redis 集群伸缩的原理

Redis 集群提供了灵活的节点扩容和收缩方案。在不影响集群对外服务的情况下，可以为集群添加节点进行扩容也可以下线部分节点进行缩容。可以说，槽是 Redis 集群管理数据的基本单位，集群伸缩就是槽和数据在节点之间的移动。

1.集群扩容

当一个 Redis 新节点运行并加入现有集群后，我们需要为其迁移槽和数据。首先要为新节点指定槽的迁移计划，确保迁移后每个节点负责相似数量的槽，从而保证这些节点的数据均匀。

1. 首先启动一个 Redis 节点，记为 M4。
2. 使用 cluster meet 命令，让新 Redis 节点加入到集群中。新节点刚开始都是主节点状态，由于没有负责的>槽，所以不能接受任何读写操作，后续我们就给他迁移槽和填充数据。
3. 对 M4 节点发送 cluster setslot { slot } importing { sourceNodeId } 命令，让目标节点准备导入槽的数据。 >4) 对源节点，也就是 M1，M2，M3 节点发送 cluster setslot { slot } migrating { targetNodeId } 命令，让源节>点准备迁出槽的数据。
4. 源节点执行 cluster getkeysinslot { slot } { count } 命令，获取 count 个属于槽 { slot } 的键，然后执行步骤>六的操作进行迁移键值数据。
5. 在源节点上执行 migrate { targetNodeIp} " " 0 { timeout } keys { key... } 命令，把获取的键通过 pipeline 机制>批量迁移到目标节点，批量迁移版本的 migrate 命令在 Redis 3.0.6 以上版本提供。
6. 重复执行步骤 5 和步骤 6 直到槽下所有的键值数据迁移到目标节点。
7. 向集群内所有主节点发送 cluster setslot { slot } node { targetNodeId } 命令，通知槽分配给目标节点。为了>保证槽节点映射变更及时传播，需要遍历发送给所有主节点更新被迁移的槽执行新节点。

2.集群收缩

收缩节点就是将 Redis 节点下线，整个流程需要如下操作流程。

1. 首先需要确认下线节点是否有负责的槽，如果是，需要把槽迁移到其他节点，保证节点下线后整个集群槽节点映射的完整性。
2. 当下线节点不再负责槽或者本身是从节点时，就可以通知集群内其他节点忘记下线节点，当所有的节点忘记改节点后可以正常关闭。

下线节点需要将节点自己负责的槽迁移到其他节点，原理与之前节点扩容的迁移槽过程一致。

迁移完槽后，还需要通知集群内所有节点忘记下线的节点，也就是说让其他节点不再与要下线的节点进行 Gossip 消息交换。 

Redis 集群使用 cluster forget { downNodeId } 命令来讲指定的节点加入到禁用列表中，在禁用列表内的节点不再发送 Gossip 消息。

为什么RedisCluster会设计成16384个槽呢

理论上crc16算法可以得到2^16个数值，其数值范围在0-65535之间，取模运算key的时候，应该是crc16(key)%65535

1.如果槽位为65536，发送心跳信息的消息头达8k，发送的心跳包过于庞大。

如上所述，在消息头中，最占空间的是 myslots[CLUSTER_SLOTS/8]。 当槽位为65536时，这块的大小是: 65536÷8÷1024=8kb因为每秒钟，redis节点需要发送一定数量的ping消息作为心跳包，如果槽位为65536，这个ping消息的消息头太大了，浪费带宽。

2.redis的集群主节点数量基本不可能超过1000个。

如上所述，集群节点越多，心跳包的消息体内携带的数据越多。如果节点过1000个，也会导致网络拥堵。因此redis作者，不建议redis cluster节点数量超过1000个。 那么，对于节点数在1000以内的redis cluster集群，16384个槽位够用了。没有必要拓展到65536个。

3.槽位越小，节点少的情况下，压缩率高

Redis主节点的配置信息中，它所负责的哈希槽是通过一张bitmap的形式来保存的，在传输过程中，会对bitmap进行压缩，但是如果bitmap的填充率slots / N很高的话(N表示节点数)，bitmap的压缩率就很低。 如果节点数很少，而哈希槽数量很多的话，bitmap的压缩率就很低。16384÷8=2kb，怎么样，神奇不！综上所述，作者决定取16384个槽，不多不少，刚刚好！

 一个redis实例的组成

redis中默认有编号0-15总共16个db，默认使用db0，每个数据库都有属于自己的空间。在redis集群时，不可以使用select命令选择db，因为redis集群仅支持db0。redis一个实例能存多少个key? 官方说单例能处理key：2.5亿个。

Redis Cluster优缺点

优点：

• 无中心架构；

• 数据按照slot存储分布在多个节点，节点间数据共享，可动态调整数据分布；

• 可扩展性：可线性扩展到1000多个节点，节点可动态添加或删除；

• 高可用性：部分节点不可用时，集群仍可用。通过增加Slave做standby数据副本，能够实现故障自动failover，节点之间通过gossip协议交换状态信息，用投票机制完成Slave到Master的角色提升；

• 降低运维成本，提高系统的扩展性和可用性。

缺点：

• Client实现复杂，驱动要求实现Smart Client，缓存slots mapping信息并及时更新，提高了开发难度，客户端的不成熟影响业务的稳定性。目前仅JedisCluster相对成熟，异常处理部分还不完善，比如常见的“max redirect exception”。

• 节点会因为某些原因发生阻塞（阻塞时间大于clutser-node-timeout），被判断下线，这种failover是没有必要的。

• 数据通过异步复制，不保证数据的强一致性。

• 多个业务使用同一套集群时，无法根据统计区分冷热数据，资源隔离性较差，容易出现相互影响的情况。

• Slave在集群中充当“冷备”，不能缓解读压力，当然可以通过SDK的合理设计来提高Slave资源的利用率。

• Key批量操作限制，如使用mset、mget目前只支持具有相同slot值的Key执行批量操作。对于映射为不同slot值的Key由于Keys不支持跨slot查询，所以执行mset、mget、sunion等操作支持不友好。

• Key事务操作支持有限，只支持多key在同一节点上的事务操作，当多个Key分布于不同的节点上时无法使用事务功能。

• Key作为数据分区的最小粒度，不能将一个很大的键值对象如hash、list等映射到不同的节点。

• 不支持多数据库空间，单机下的redis可以支持到16个数据库，集群模式下只能使用1个数据库空间，即db 0。

• 复制结构只支持一层，从节点只能复制主节点，不支持嵌套树状复制结构。

• 避免产生hot-key，导致主库节点成为系统的短板。

• 避免产生big-key，导致网卡撑爆、慢查询等。

• 重试时间应该大于cluster-node-time时间。

• Redis Cluster不建议使用pipeline和multi-keys操作，减少max redirect产生的场景。