高并发热点缓存数据可能出现问题及解决方案

本文主要是介绍高并发热点缓存数据可能出现问题及解决方案，希望对大家解决编程问题提供一定的参考价值，需要的开发者们随着小编来一起学习吧！

背景

电商场景促销活动的会场页由于经常集中在某个时间点进行“秒杀”促销，这些页面的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大小 > 单台缓存机器的网络流量限制，则也需要采取更多措施进行数据精简。