高并发“热点”缓存数据快速“退火”

背景

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

 

 

图2-1 常规数据缓存方案

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

 

 

图2-2 短时间内请求量过大缓存被击穿

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

缓存问题分析与解决过程

首先查看缓存详细日志，发现有很多带有“CacheOverflow”字样的日志，初步怀疑是触发了缓存限流。但是计算了缓存的整体能力和当前访问量情况：缓存的机器数×单机能够承受的QPS > 当前用户访问的最大QPS值，此时用户访问QPS并没有超过缓存之前的预算，怎么也会触发限流呢?

进一步分析日志，发现所有服务器上限流日志中缓存机器IP貌似都是同一台，说明大流量并没有按预想平均分散在不同的缓存机器上。回想前面提到的案例实际现象，发现确实有部分数据用户的访问请求都会触发对缓存中同一个key(热点key)进行访问，用户访问QPS有多大，则这个key的并发数就会有多大，而其他缓存机器完全没有分担任何请求压力，如图2-3所示。

然后紧急梳理出存在“热点请求”的key，并快速接入“热点本地缓存”方案，然后迅速在下一场秒杀活动中进一步进行验证，此时发现之前异常大幅度减少。不过还是有少量“CacheOverflow”字样异常日志。热点key的请求都被“本地缓存”拦截掉了，此时发现远程QPS限流异常已经基本没有了，这又是什么原因呢?

 

 

图2-3 热点key触发单点限流

仔细查看缓存单台机器的网络流量监控，发现偶尔有网络流量过大超过单台缓存机器的情况(如图2-4所示)。

 

 

图2-4 网络流量监控

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

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

预防“缓存被击穿”总结

评估缓存是否满足具体业务场景的请求流量，不是简单地对预估访问流量除以单台缓存的最大服务能力。

如果使用的缓存机制是按key的hash值散列到同一台机器，则必须梳理出当前业务场景中被高并发访问的那些key，看看这些key的并发访问量是否会超过单台机器的服务能力，如果超过则必须采取更多措施进行规避。

除了关注key的并发访问量外，还要关注key对应value的大小，如果key的并发访问量×value大小 > 单台缓存机器的网络流量限制，则也需要采取更多措施进行数据精简。

更多思考

单个key的请求量不超过单台缓存机器的服务能力，但是如果多个key正好散列到同一台机器，而且这几个key的流量之和超过单台机器的服务能力，我们该如何处理呢?

单个key的并发访问量×对应value大小 < 单台缓存机器的网络流量限制，但是如果多个key的并发访问量×各自对应value大小 >单台缓存机器的网络流量限制，又该如何处理呢?

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