Redis哈希槽，对于哈希槽的理解，以及高并发情况下哈希槽不够的情况讲解，热点缓存的解决思路

目录

Redis哈希槽

并发量与哈希槽

Redis如何通过哈希槽实现数据共享

热点缓存的问题

案例背景

缓存问题分析与解决过程

预防“缓存被击穿”总结

更多思考

---

Redis哈希槽

一个 redis 集群包含 16384 个哈希槽（hash slot），数据库中的每个数据都属于这16384个哈希槽中的一个。集群使用公式 CRC16(key) % 16384 来计算键 key 属于哪个槽。集群中的每一个节点负责处理一部分哈希槽。

slot返回有关哪个集群插槽映射到哪个redis实例的详细信息。该命令适用于redis集群客户端库实现，以便检索（或在收到重定向时更新）将集群散列槽与实际节点网络坐标（由ip地址和tcp端口组成）关联的映射，以便在接收到命令时，可以将其发送到命令中指定的键的正确实例。

 

并发量与哈希槽

也就是说哈希槽是用来决定这个key存在哪个节点，通过哈希计算，得到槽值为1，那么这个数据将存到节点1的Redis上，但是对于并发性的问题，大家可能会有一个误解，如同时有大于16384个请求，我们是否等待16383个槽处理完之后再处理16384之后的请求呢？答案是不需要，槽值一旦被计算出来，就只作为一个值来用，这个值决定了访问哪个节点的Redis，而计算这个值的速度，或者并发量（同一时刻允许多少次计算），并不取决与槽有多少，而是取决与这台服务器的计算能力

如图，该Redis集群拥有三个节点，哈希槽平均分配

 

 

Redis如何通过哈希槽实现数据共享

Redis集群没有使用一致的散列，而是一种不同的分片形式，其中每个 key 在概念上都是我们称之为散列槽的部分。

Redis集群中有16384个散列槽，为了计算给定 key 的散列槽，我们简单地取16384模的CRC16。

Redis集群中的每个节点负责哈希槽的一个子集，例如，您可能有一个具有3个节点的集群，其中：

• 1、节点A包含从0到5500的散列槽。
• 2、节点B包含从5501到11000的散列槽。
• 3、节点C包含从11001到16383的散列槽。

这允许轻松地添加和删除集群中的节点。例如，如果我想添加一个新节点D，我需要将节点A，B，C中的一些散列槽移动到D。同样，如果我想从集群中删除节点A，我可以只移动由A使用的散列槽到B和C，当节点A将为空时，我可以将它从群集中彻底删除。

因为将散列槽从一个节点移动到另一个节点不需要停机操作，添加和移除节点或更改节点占用的散列槽的百分比也不需要任何停机时间。

只要涉及单个命令执行（或整个事务或Lua脚本执行）的所有 key 都属于同一散列插槽，Redis群集就支持多个 key 操作。用户可以使用称为散列标签的概念强制多个 key 成为同一个散列槽的一部分。

Hash标记记录在Redis集群规范文档中，但要点是如果在关键字{}括号内有一个子字符串，那么只有该花括号“{}”内部的内容被散列，例如 this{foo}key 和 another{foo}key 保证在同一散列槽中，并且可以在具有多个 key 作为参数的命令中一起使用。

 

热点缓存的问题

redis cluster采用数据分片的哈希槽来进行数据存储和数据的读取。redis cluster一共有2^14（16384）个槽，所有的master节点都会有一个槽区比如0～1000，槽数是可以迁移的。master节点的slave节点不分配槽，只拥有读权限。但是注意在代码中redis cluster执行读写操作的都是master节点，并不是你想 的读是从节点，写是主节点。第一次新建redis cluster时，16384个槽是被master节点均匀分布的。

 

 

和一致性哈希相比

1. 它并不是闭合的，key的定位规则是根据CRC-16(key)%16384的值来判断属于哪个槽区，从而判断该key属于哪个节点，而一致性哈希是根据hash(key)的值来顺时针找第一个hash(ip)的节点，从而确定key存储在哪个节点。
2. 一致性哈希是创建虚拟节点来实现节点宕机后的数据转移并保证数据的安全性和集群的可用性的。redis cluster是采用master节点有多个slave节点机制来保证数据的完整性的,master节点写入数据，slave节点同步数据。当master节点挂机后，slave节点会通过选举机制选举出一个节点变成master节点，实现高可用。但是这里有一点需要考虑，如果master节点存在热点缓存，某一个时刻某个key的访问急剧增高，这时该mater节点可能操劳过度而死，随后从节点选举为主节点后，同样宕机，一次类推，造成缓存雪崩，看下面这个案例

 

案例背景

电商场景促销活动的会场页由于经常集中在某个时间点进行“秒杀”促销，这些页面的QPS（服务器每秒可以处理的请求量）往往特别高，数据库通常无法直接支撑如此高QPS的请求，常见的解决方案是让大部分相同信息的请求都尽可能地压在缓存（cache）上来缓解数据库（DB）的压力，从而尽可能地去满足高并发访问的诉求（如图2-1所示）。

 

 

 

在一次业务促销过程中，运营给一大批用户集中推送了一条消息：10点钟准时抢购一批远低于市场价而且数量有限的促销活动商品。由于确实物美价廉，用户收到消息之后10点钟准时进入手机客户端的会场页进行疯抢。几分钟内很多用户进入会场页，最终导致页面异常，服务器疯狂报警。报警信息显示很多关于缓存的异常，由于缓存拿不到数据转而会转向数据库去查询数据，这样数据库更加难以支撑，整个业务集群处于雪崩状态（如图所示）。

 

 

 

此时缓存到底发生了什么问题？关注哪些方面可以有效地预防缓存被击穿导致雪崩的发生呢？

缓存问题分析与解决过程

1. 首先查看缓存详细日志，发现有很多带有“CacheOverflow”字样的日志，初步怀疑是触发了缓存限流。但是计算了缓存的整体能力和当前访问量情况：缓存的机器数×单机能够承受的QPS > 当前用户访问的最大QPS值，此时用户访问QPS并没有超过缓存之前的预算，怎么也会触发限流呢？
2. 进一步分析日志，发现所有服务器上限流日志中缓存机器IP貌似都是同一台，说明大流量并没有按预想平均分散在不同的缓存机器上。回想前面提到的案例实际现象，发现确实有部分数据用户的访问请求都会触发对缓存中同一个key（热点key）进行访问，用户访问QPS有多大，则这个key的并发数就会有多大，而其他缓存机器完全没有分担任何请求压力。
3. 然后紧急梳理出存在“热点请求”的key，并快速接入“热点本地缓存”方案，然后迅速在下一场秒杀活动中进一步进行验证，此时发现之前异常大幅度减少。不过还是有少量“CacheOverflow”字样异常日志。热点key的请求都被“本地缓存”拦截掉了，此时发现远程QPS限流异常已经基本没有了，这又是什么原因呢？ 

 

仔细查看缓存单台机器的网络流量监控，发现偶尔有网络流量过大超过单台缓存机器的情况。 

 

说明缓存中有某些key对应的value数据过大，导致尽管QPS不是很高，但是网络流量（QPS×单个value的大小）还是过大，触发了缓存单台机器的网络流量限流。

1. 紧急梳理出存在“大value”的key，发现这些“大value”部分是可以精简，部分是可以直接放入内存不用每次都远程获取的，经过一番梳理和优化之后，下次“秒杀”场景终于风平浪静了。至此问题初步得到解决。

预防“缓存被击穿”总结

1. 评估缓存是否满足具体业务场景的请求流量，不是简单地对预估访问流量除以单台缓存的最大服务能力。
2. 如果使用的缓存机制是按key的hash值散列到同一台机器，则必须梳理出当前业务场景中被高并发访问的那些key，看看这些key的并发访问量是否会超过单台机器的服务能力，如果超过则必须采取更多措施进行规避。
3. 除了关注key的并发访问量外，还要关注key对应value的大小，如果key的并发访问量×value大小 > 单台缓存机器的网络流量限制，则也需要采取更多措施进行数据精简。

更多思考

1. 单个key的请求量不超过单台缓存机器的服务能力，但是如果多个key正好散列到同一台机器，而且这几个key的流量之和超过单台机器的服务能力，我们该如何处理呢？
2. 单个key的并发访问量×对应value大小 < 单台缓存机器的网络流量限制，但是如果多个key的并发访问量×各自对应value大小 >单台缓存机器的网络流量限制，又该如何处理呢？

针对上述两个问题，首先要做的是做好缓存中元素key的访问监控，一旦发现缓存有QPS限流或者网络大小限流时，能够迅速定位哪些key并发访问量过大，或者哪些key返回的value大小较大，再结合缓存的散列算法，通过一定规则动态修改key值来自动将这些可疑的key平均散列到各台缓存机器上去，这样就可以充分地利用所有缓存机器来分摊压力，保证缓存集群的最大可用能力，从而减少缓存被击穿的风险。提示：Redis集群提供了移动哈希槽的命令，我们可以从这一点入手