Redis 集群问题

前言

什么是Redis集群？为什么要集群？Redis集群的优/缺点是什么？

Redis集群是指将多台Redis实例进行协同组合以统一对外提供服务的一种部署/工作方式，也是官方提供的具体数据分区实现。通过将数据/请求以各类算法分片/分流到不同节点中保存/访问，可以达到大幅降低单台Redis实例负载的效果以实现对现实大数据/高并发场景的支持…Redis集群的优/缺点具体如下：

去中心化：Redis并未设计专用组件来处理请求的引导/分流问题，而是直接将该功能内嵌到到了所有节点中以实现引导组件的同步集群，从避免单机成为高并发引导的性能瓶颈。此外Redis还允许客户端也具备一定程度的引导/分流能力，从而使得客户端可以直接访问目标节点，并以此避免代理转发的开销；
动态拓展能力强：Redis集群采用了哈希槽来替换倡议的一致性哈希方案来实现数据分区，从而增强了集群的动态扩展能力，即数据重分片更加高效；
内嵌主从同步/哨兵：Redis集群内嵌了主从同步/哨兵功能，从而可以在完全无人为干预的情况下建立建立合理的主从关系并进行自动的故障转移。
不支持跨节点操作：无论是多键指令还是事务，所有涉及跨节点的操作在集群中都是不支持的；
无法动态选择数据库：在开启集群的情况下只能选择0数据库；
维护相对复杂：集群的扩/缩容相对复杂，因为数据重分片需要人为的指定范围/数量。

什么是哈希槽？

哈希槽是Redis设计用于集群中实现数据分区的逻辑区间。为了增加集群的动态扩/缩容能力，Redis没有简单采用常规的一致性哈希（取模）方案实现数据分区，而是设计了16384个哈希槽用于挂靠数据。这些哈希槽会与集群中的节点建立尽可能均匀的映射关系，而当Redis/客户端通过公式CRC16(key) / 16384计算得到数据所挂靠的哈希槽时，数据便会被置于其映射的节点中保存。

哈希槽并无法在集群扩/缩容是避免数据重分片/迁移，除非新增的节点并没有实际发挥作用。哈希槽的核心作用是将数据重分片从一致性哈希的被动性转为了主动性，因为在一致性哈希方案中节点数量的变化就意味着模的变化，同理也意味着数据所在仓库的变化，从而被动导致全量数据被强制性的重分片。但哈希槽总数的不变性注定了其与数据的挂靠关系不会改变，因此只要哈希槽与节点的映射关系不变，数据重分片就永远不会发生。而由于这两者的映射关系是受开发者主观控制的，因此迁移那（几）个节点的数据，迁移多少数据都可以自由决定，从而为最佳迁移方案的指定/执行提供了实现基础。

哈希槽为什么被固定为16384个？

哈希槽总数16384是经验值。所谓经验值是指没有/缺少实际的理论依据，但在程序实际运行的各个方面都能取得良好效果的阈值。因此想要说出哈希槽总数被设计为16384的具体原因是难以做到的，我们只能从以下几个实际的好处来拥戴这一点：

计算效率高：计算机对于2的幂次方数字处理更快，并且该数字对于CRC16算法也有优化加成；
负载均衡强/迁移更灵活：对于实际开发场景中的主节点数量而言，16384个哈希槽不但可以做到对各主节点的大致均匀分配以实现负载均衡，还能保证单个主节点具备较高的哈希槽/数据颗粒度以实现迁移的灵活性，即能够选择的迁移范围更加多样化；
内存开销小/通讯影响少/增加集群体量：Redis集群的节点数量是很难超过1000个的，其“主要”原因是集群中的节点两两之间都会进行通讯，因此节点数量的增加就意味着“单个节点需要通讯的其它节点数量/通讯心跳包中包含的各节点数据（主要指各节点的运行状态，用于综合反应集群状态）”也同步增加，从而在节点数量接近1000时因为出现网络拥堵现象而难以继续扩容。而在这心跳包中除了各节点数据外还有一项非常重要的哈希槽数据，还数据的本质是当前节点被分配的哈希槽。由于以位图形式（具体如下图）保存且哈希槽总数为16384的原因，该哈希槽数据会固定占有较小的2（16384/8/1024）KB大小。但如果将哈希槽总数设计的更大，那么心跳包的大小自然也会水涨船高，从而就会导致网络拥堵现象出现的更早，并进一步导致可支持的节点数量也更少。

Redis除了集群外还有别的数据分片方案？

Redis可用的数据分片方案如下：

客户端分片：由客户端根据自身算法去决定数据具体落在哪台Redis实例上；
代理/中心化分片：客户端将读/写请求发送至专门用于引导/分流的代理服务器，并由代理服务器根据内部将读/写访问请求分发至相应Redis实例上。该数据分片方案的实现组件有Twemproxy；
去中心化分片（最推荐）：Redis集群所采用的数据分片方案，所有节点/客户端都具备引导/分流读/写请求至正确客户端的能力。