Redis集群模式之Redis Cluster（3）

        上篇文章我们讲解了Redis Cluster的状态监测与恢复过程，这篇文章我们来进行Redis Cluster内容的收尾，将其扩容和缩容的过程进行讲解，并分析RedisCluster的优缺点。

扩容和缩容

        当集群中出现容量限制或者其他一些原因需要扩容时，Reids Cluster提供了比较优雅的集群扩容方案：

        （1）首先将新节点加入到集群中，可以通过在集群中热河一个客户端执行Cluster meet新节点ip：端口，或者通过redis-trib add node添加，新添加的节点默认在集群中都是主节点。

        （2）数据的迁移。迁移数据的大致流程是，首先需要确定哪些槽需要被迁移到目标节点，然后获取槽中key，将槽中的key全部迁移到目标节点，然后向集群所有主节点广播槽（数据）全部迁移到了目标节点。

        缩容的大致过程与扩容一致，需要判断下线的节点是否是主节点，以及主节点上是否有槽。若主节点上有槽，需要将槽迁移到集群中的其他主节点，槽迁移完成之后，需要向其他节点广播该节点准备下线。最后需要将该下线主节点的从节点指向其他主节点（最好是先将从节点下线）。

为什么Redis Cluster的Hash Slot是16384？

        在Redis节点发送心跳包时需要把所有的槽放到这个心跳包里，以便让节点知道当前集群信息，16384 = 16K，在发送心跳包时使用char进行bitmap压缩后是2K，也就是说用2K的空间创建了16K的槽数。

        虽然说用CRC16算法最多可以分配65535个槽位，65535 = 65K，压缩后就是8K，也就是说需要8K的心跳包，作者认为这样不太值的；并且一般情况下一个Redis集群不会有超过1000个Master节点，所以16K的槽位是比较合适的选择。

为什么Redis Cluster中不建议使用发布订阅呢？

        在集群模式下，所有的publish命令都会向所有节点（包括从节点）进行广播，造成每条publish数据都会在集群内所有节点传播一次，加重了带宽负担，对于在有大量节点的集群中频繁使用pub，会严重消耗带宽，不建议使用。（虽然官网上说有时候可以使用布隆过滤器或其他算法进行优化）。

Redis Cluster的优缺点总结：

        优点：

        （1）无中心架构。

        （2）数据按照Slot存储分布在多个节点，节点间数据共享，可动态调整数据分布。

        （3）可扩展性。可以线性扩展到1000多个节点，节点可动态添加或删除。

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

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

        缺点：

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

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

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

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

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

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

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

        这篇文章我们对Redis Cluster的讲解进行了收尾和总结。大家有什么问题或勘误可以在评论区留言，笔者看到都会回复的。