你所不知道的Redis热点问题以及如何发现热点

享学课堂特邀做者：老顾

前言

“这个商品不错，你们来看啊“，每一个平台都有会有些大卖的商品，简称为爆品。这些商品会有个特色，就是访问量特别大。咱们专业上面能够称之为热点数据，在处理这些热点商品时，系统须要作一些特殊的处理。

缓存化

针对热点商品这些类型的数据，要考虑到访问量比较大，你们首先想到的是缓存，上redis缓存，这点确定没有错。系统框架以下： 

上图中，先从缓存中获取，没有再到DB获取，并保存到缓存中。但有个问题会产生，热点数据的访问会比较大，若是缓存一旦失效，全部请求同一时刻，会打到DB上面，DB确定会崩溃。那怎么办呢？

分布式锁

缓存一旦失效，如何从新构建缓存？首先须要避免失效那一刻大量请求同时去从新构建缓存。由于从新构建缓存，须要到数据库DB中获取数据，那一个时刻的全部请求到DB上面。方案有两种，第一个方案是把请求进入队列中（这个老顾之后会介绍，关于库存一致性的问题中，有涉及到这个知识点）。还有一个方案就比较简单，利用分布式锁，只容许一个请求线程去访问DB，其余请求阻塞，这样就避免了不少请求打到DB上。

具体怎么实现能够看老顾以前的文章【如何利用锁，防止缓存击穿？重构思想的重要性】

永不过时

这个方案就是利用redis自己的特性，致使的问题是由于缓存失效了，那咱们可让缓存永不过时就好了。这个方案中须要考虑两个状况：

一、热点商品上线前须要预热，也就是在商品正式发布到前端时，须要提早把商品信息进行缓存，避免跟缓存失效的状况同样。 二、更新商品信息机制，如何在商品信息更新后，及时更新缓存中的商品信息。这个也比较简单在更新商品事件中，增长个更新消息，由缓存服务进行消费，更新缓存信息。

遗留问题

上面两个方案是网上常常提到的方案，其实这两个方案会存在一个问题，也就是redis达到了负载极限怎么办？也就是热点商品的访问量，咱们的单台redis扛不住了。

小伙伴们会有疑问，redis能够上集群啊，不就解决了吗？

咱们先了解一下，redis cluster集群部署方案

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

备注：老顾这里介绍的是redis集群部署方案，若是是以前的redis主从方案，另外讨论

从redis是不负责set和get请求的，即便请求打到从redis节点，从redis也会转发给主redis。而其余的主redis，是用来作数据扩容的。

即就是商品A的信息，只会存在一个主redis中，其余主redis是没有此商品A的信息的，这就是redis集群哈希槽的特色。

也就是小伙伴刚才想到的作redis集群这个方案是不行的，由于热点数据只会在一个主redis中。会存在单台redis负载不足（达到网卡、网络上限。达到这个瓶颈流量表明很是大了）。那怎么办呢？

读写分离

上面咱们提到从redis只不负责读和写请求的，但redis官方提供了一个方法，在操做读请求时，能够先加上readonly命令，这样从redis就能够提供读请求服务了，不须要转发到主redis。

根据这个特性，咱们能够对客户端工具进行改造，读请求方法时，加上readonly这个命令，从而实现读写分离，提升了从redis的利用率。

即达到了多台从redis去扛大量请求了，减小了主redis压力。这个方案须要对客户端进行改造，并且redis官方推荐没有必要使用读写分离。

本地缓存

这个方案就是多级缓存的方案，把缓存前置，架构图以下：

改造web应用服务，在获取到redis缓存后，在web服务本地把热点的数据进行缓存，由于热点的商品不会不少，因此保存在本地缓存中，是没有问题的。这样请求数据时，若是web本地有缓存数据，就直接返回了。

这样前端3个web应用就分担了redis缓存的压力，如访问过大就能够增长web应用服务，原本web应用服务就须要集群化

热点发现

本地缓存的方案中，有一个问题须要解决，那就是怎么知道哪些数据是热点数据？由于本地缓存资源有限，不可能把全部的商品数据进行缓存，它只会缓存热点的数据。那怎么知道数据是热点数据呢？

人为预测

就是人工标记，预测这个商品会成为热点，打个标记。web应用根据这个标记把此商品保存到本地缓存中

这个方案，是根据运营人员的经验进行预测，太不靠谱了。

系统推算

这个方案是根据实实在在的数据访问量进行推算造成，网上也介绍了用访问日志的什么算法，推算哪些是热点数据。 老顾这里分享一个比较简单的方式，就是利用redis4.x自身特性，LFU机制发现热点数据。实现很简单，只要把redis内存淘汰机制设置为allkeys-lfu或者volatile-lfu方式，再执行

./redis-cli --hotkeys复制代码

会返回访问频率高的key，并从高到底的排序

那就是咱们的热点数据的key了。

备注：在设置key时，须要把商品id带上，这样就是知道是哪些商品了

总结

到此为止，老顾就把热点数据的问题、解决方案以及热点发现介绍完了，但愿可以帮助小伙伴。固然整个解决方案的搭建，还须要小伙伴结合自身业务去实现。

若是小伙伴们部署到阿里云上面，阿里云上面也有相似方案

谢谢你们阅读！！！

END

欢迎长按下图关注公众号：享学课堂online！

公众号后台回复【java】，获取精选准备的架构学习资料（视频+文档+架构笔记）

学习分享：shimo.im/docs/vrfAWT…