用软件做的网站权限,浙江网商银行,乐陵属于山东哪个市,企业网站推广方案的策划背景
目前工作所负责的工作主要是投放业务#xff0c;属于读高并发场景#xff0c;记录一下之前碰到的redis相关的问题。
热点大值Key缓存击穿问题
问题表现
在某次流量峰值过程中#xff0c;redis的CPU突然飙升#xff0c;从监控看起来就是CPU飙升到一定程度属于读高并发场景记录一下之前碰到的redis相关的问题。
热点大值Key缓存击穿问题
问题表现
在某次流量峰值过程中redis的CPU突然飙升从监控看起来就是CPU飙升到一定程度内存突然掉0然后命中率掉0实际上是主节点被打挂了触发了主备切换。流量和系统调用链路逻辑跟之前并无区别。
原因分析
先看一下计划发布流程和投放端读取计划配置的逻辑 具体逻辑
配置端会生成一个全局的索引index_key来存放坑位和所关联投放计划的关系(注意这里是一个大值key);配置端每次更新完全局索引后会在redis刷新一个全局的时间戳time_key记录索引的最后更新时间;投放端请求进来后获取redis时间戳缓存(这里是一个热点key)会判断本地索引时间戳缓存是否和redis的时间戳一致若时间戳不一致会刷新本地全局index缓存刷新成功后会刷新本地时间戳缓存;
好处
只要时间戳更新投放端就会获取最新的索引版本能保证索引发布后所有对于所有机器来说就马上生效
弊端
时间戳redis值本来就是个热点key投放端每次请求都会打到redis全局索引会是大值key当QPS很高的时候每次发布新的索引之后所有机器会同时触发刷新若集群的机器数量很多的时候瞬间会打到同一个redis分片
上面所说的问题就是由于在流量峰值期间有运营发布了新计划导致全局索引刷新瞬间1000qps打到同一个redis分片获取全局索引导致分片被打崩。
解决办法
最简单的解决办法就是把全局索引复制多个备份key值加入后缀使value分布到redis集群的每个分片中。比如复制20个备份index_key_{random}投放端机器随机访问0-20后缀的全局索引分片解决热点问题 弊端需要保持多个备份的一致性可能会存在一致性问题把全局索引根据业务划分为更小的颗粒度。比如在这个场景可以把全局索引改为资源位-计划的索引减少value的值大小而且根据资源位进行索引后value的分布也自然就打散了使用压缩工具减少value的值。因为存放的value为json格式json格式其实是有很大的压缩空间使用压缩工具能够大大减少value的值增加时间戳本地缓存过期时间使更新本地索引的请求不会同时触发通过减少并发量解决问题。 弊端会导致计划发布之后投放端会有延迟更新因为本地缓存时间的存在所以并不会马上去校验索引是否更新。
总结
总结一下解决热点大值key基本就几个思路
通过预热的方式把热点key打散把压力分散到整个集群通过减小value的size压缩、修改缓存颗粒度引入缓存过期时间对峰值尖刺进行削峰减少并发量
