Redis缓存污染了怎么办?

我们应用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

你可能感兴趣的:(学习笔记,缓存,redis,java)