预防“缓存被击穿”总结

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

更多思考

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

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


全部评论: 0

    我有话说: