当前位置：首页 > news >正文

Redis缓存污染了怎么办?

news 来源：原创 2024/4/27 19:19:02

我们应用Redis缓存时，如果能缓存会被反复访问的数据，那就能加速业务应用的访问，但是，如果发生了缓存污染，那么，缓存对业务应用的加速作用就减少了。

在一些场景下，有些数据被访问的次数非常小，甚至只会被访问一次，当这些数据访问请求后，如果还继续留在缓存中的化，就只会白白占用缓存空间。这种情况，就是缓存污染。当缓存污染不严重时，只有少量数据占据缓存空间，此时，对缓存系统的影响不大，但是，缓存污染一旦变得严重后，就会有大量不再访问的数据滞留在缓存中。如果这时数据占满了缓存空间，我们再往缓存中写入新数据时，就需要先把这些数据逐步淘汰出缓存，这就引入额外的操作时间开销，进而会影响应用的性能。

如何积解决缓存问题污染问题

要解决缓存污染问题，我们可能很快就想到将不会再访问的数据筛选出来淘汰掉就好了，筛选出要淘汰的数据由淘汰算法来解决。常见的淘汰算法有8种：noeviction、volatile-random、volatile-ttl、volatile-lru、volatile-lfu、allkeys-lru、allkeys-random 和 allkeys-lfu 策略。noeviction策略是不会进行数据淘汰的，所以，它肯定不能用来解决缓存污染问题，其他7种策略，都会按照一定的规则来淘汰数据。

volatile-random 和 allkeys-random 这两种策略。它们都是采用随机挑选数据的方式，来筛选即将被淘汰的数据。那么 Redis 就不会根据数据的访问情况来筛选数据。如果被淘汰的数据又被访问了，就会发生缓存缺失。也就是说，应用需要到后端数据库中访问这些数据，降低了应用的请求响应速度。所以，volatile-random 和 allkeys-random 策略，在避免缓存污染这个问题上的效果非常有限。

volatile-ttl 针对的是设置了过期时间的数据，把这些数据中剩余存活时间最短的筛选出来并淘汰掉。虽然 volatile-ttl 策略不再是随机选择淘汰数据了，但是剩余存活时间并不能直接反映数据再次访问的情况。所以，按照 volatile-ttl 策略淘汰数据，和按随机方式淘汰数据类似，也可能出现数据被淘汰后，被再次访问导致的缓存缺失问题。

LRU缓存策略

LRU策略的核心思想：如果一个数据刚刚被访问，那么这个数据肯定是热数据，还会被再次访问。Redis中的LRU策略，会在每个数据对应的RedisObject结构体中设置一个LRU字段，用来记录数据的访问时间戳，在进行数据淘汰时，LRU策略会在候选数据集中淘汰LRU字段值最小的数据。

所以，在数据被频繁访问的业务场景中，LRU策略的确能有效留存访问时间最近的数据。而且，因为这些被查询的数据刚刚被访问过，所以lru字段值都很大。

正是因为只看数据的访问时间，使用 LRU 策略在处理扫描式单次查询操作时，无法解决缓存污染。所谓的扫描式单次查询操作，就是指应用对大量的数据进行一次全体读取，每个数据都会被读取，而且只会被读取一次。此时，因为这些被查询的数据刚刚被访问过，所以 lru 字段值都很大。

LFU 缓存策略的优化

LFU 缓存策略是在 LRU 策略基础上，为每个数据增加了一个计数器，来统计这个数据的访问次数。当使用 LFU 策略筛选淘汰数据时，首先会根据数据的访问次数进行筛选，把访问次数最低的数据淘汰出缓存。如果两个数据的访问次数相同，LFU 策略再比较这两个数据的访问时效性，把距离上一次访问时间更久的数据淘汰出缓存。

为了避免操作链表的开销，Redis 在实现 LRU 策略时使用了两个近似方法：

Redis 是用 RedisObject 结构来保存数据的，RedisObject 结构中设置了一个 lru 字段，用来记录数据的访问时间戳；
Redis 并没有为所有的数据维护一个全局的链表，而是通过随机采样方式，选取一定数量（例如 10 个）的数据放入候选集合，后续在候选集合中根据 lru 字段值的大小进行筛选。

学习来源：极客时间《Redis核心技术与实战》学习笔记 Day11

如何积解决缓存问题污染问题

LRU缓存策略

LFU 缓存策略的优化

相关文章：