redis热点问题

热点Key如何产生？

• 双十一期间某些热门商品的降价促销，当这其中的某一件商品被数万次点击浏览或者购买时，会形成一个较大的需求量，这种情况下就会造成热点问题。热点新闻、热点评论等典型的读多写少的场景也会出现同样的问题。
• 请求分片集中，超过单 Server 的性能极限。在服务端读数据进行访问时，往往会对数据进行分片切分，此过程中会在某一主机 Server 上对相应的 Key 进行访问，当访问超过 Server 极限时，就会导致热点 Key 问题的产生。

热点Key的危害

• 当某一热点 Key 的请求在某一主机上超过该主机网卡上限时，由于流量的过度集中，会导致服务器中其它服务无法进行。
• 如果热点过于集中，热点 Key 的缓存过多，超过目前的缓存容量时，就会导致缓存分片服务被打垮现象的产生。
• 当缓存服务崩溃后，此时再有请求产生，会缓存到后台 DB 上，由于DB 本身性能较弱，在面临大请求时很容易发生请求穿透现象，会进一步导致雪崩现象，严重影响设备的性能。

问题和解决方案

缓存雪崩

需要避免失效那一刻大量请求同时去重新构建缓存。因为重新构建缓存，需要到数据库DB中获取数据，那一个时刻的所有请求到DB上面。

解决方案

• 把请求进入队列中，依次处理队列中的请求，避免同一时间多个请求同时操作。
• 利用分布式锁，只允许一个请求线程去访问DB，其他请求阻塞，这样就避免了很多请求打到DB上。
• 让缓存永不过期，热点商品上线前需要预热，提前把商品信息进行缓存，避免跟缓存失效的情况一样。 更新商品信息机制，如何在商品信息更新后，及时更新缓存中的商品信息。在更新商品事件中，增加个更新消息，由缓存服务进行消费，更新缓存信息。

redis达到了负载极限

热点商品的访问量太大，导致单台redis扛不住。

redis cluster经典的三主三从集群方案，客户端进行set和get时，都是走的主redis，从redis只是个备份，主要作用是用来做高可用的，主redis挂了，从redis顶上。

从redis是不负责set和get请求的，即使请求打到从redis节点，从redis也会转发给主redis。而其他的主redis，是用来做数据扩容的。商品A的信息，只会存在一个主redis中，其他主redis是没有此商品A的信息的，这就是redis集群哈希槽的特点。

因为热点数据只会在一个主redis中。会存在单台redis负载不足，达到网卡、网络上限。

解决方案

• 读写分离，从redis不负责读和写请求的，但redis官方提供了一个方法，在操作读请求时，可以先加上readonly命令，这样从redis就可以提供读请求服务了，不需要转发到主redis。可以对客户端工具进行改造，读请求方法时，加上readonly这个命令，从而实现读写分离，提高了从redis的利用率。
• 本地缓存，改造web应用服务，在获取到redis缓存后，在web服务本地把热点的数据进行缓存，因为热点的商品不会很多，所以保存在本地缓存中，是没有问题的。请求数据时，如果web本地有缓存数据，就直接返回了。

热点发现

• 人为预测，提前预估热点数据，单靠经验判断，准确性有时会较低。
• 系统推测，根据数据访问量进行推算。

系统推测方法

添加一个代理层，客户端通过代理访问数据。代理层采集请求信息，并计算在一个周期中发生的请求。当请求数达到阈值时，将热点存储在LRU列表中。

利用redis4.x自身特性，LFU机制发现热点数据。把redis内存淘汰机制设置为allkeys-lfu或者volatile-lfu方式，再执行./redis-cli --hotkeys。

本地缓存更新

修改热点key数据的时候，通过mq广播模式通知