Redis缓存系列：你所不知道的Redis热点问题以及如何发现热点

超、凢脫俗 2023-03-04 10:30 1阅读 0赞

## **前言** ##

“这个商品不错，大家来看啊“，每个平台都有会有些大卖的商品，**简称为爆品**。这些商品会有个特点，就是**访问量特别大**。我们专业上面可以**称之为热点数据**，在处理这些热点商品时，系统需要**做一些特殊的处理**。

## **缓存化** ##

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

![format_png][]

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

## **分布式锁** ##

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

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

## **永不过期** ##

这个方案就是利用**redis本身的特性**，导致的问题是因为缓存失效了，那我们可以让**缓存永不过期**就行了。这个方案中需要考虑两个情况：

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

## **遗留问题** ##

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

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

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

![format_png 1][]

上图是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官方推荐没有必要使用读写分离。**

## **本地缓存** ##

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

![format_png 2][]

**改造web应用服务，在获取到redis缓存后，在web服务本地把热点的数据进行缓存**，因为热点的商品不会很多，所以保存在本地缓存中，是没有问题的。**这样请求数据时，如果web本地有缓存数据，就直接返回了。**

> 这样前端3个web应用就**分担了redis缓存的压力**，如访问过大就可以**增加web应用服务**，本来web应用服务就需要集群化

## **热点发现** ##

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

### **人为预测** ###

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

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

### 系统推算 ###

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

./redis-cli --hotkeys

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

![format_png 3][]

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

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

## **总结** ##

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

> 如果小伙伴们部署到阿里云上面，阿里云上面也有类似方案

谢谢大家阅读！！！  
**END**

[https://www.jianshu.com/p/b08a8f7c79bf][https_www.jianshu.com_p_b08a8f7c79bf]

[format_png]: /images/20230208/296f4fa993d044ea98618df5f7b1b372.png
[format_png 1]: /images/20230208/5c2cb0b8ad50401d9a33f173610cde82.png
[format_png 2]: /images/20230208/bbea4e1416fb4a7db431701a0570de67.png
[format_png 3]: /images/20230208/7a09c819e8774e01a22e1a0b19320430.png
[https_www.jianshu.com_p_b08a8f7c79bf]: https://www.jianshu.com/p/b08a8f7c79bf