redis的缓存更新策略，缓存粒度控制

⼀、缓存的更新策略

缓存中的数据有⽣命周期，需要定期更新和删除以保证内存空间的合理使⽤以及缓存数据与数据库数据的⼀致性。缓存数据需要根据合理的数据更新策略更新缓存中的数据，有如下三种策略：

（1）LRU/LFU/FIFO算法剔除：Redis使⽤maxmemory-policy,即Redis中的数据占⽤的内存超过设定的最⼤内存时的操作策略

（2）超时剔除：对缓存的数据设置过期时间，超过过期时间⾃动删除缓存数据，然后再次进⾏缓存，保证与数据库中的数据⼀致

（3）主动更新：开发者控制key的更新周期，当key在后端数据库中发⽣更新时，向Redis主动发送消息，Redis接收到消息对key进⾏更新或删除

# 根据LRU算法删除过期的key

volatile-lru -> remove the key with an expire set using an LRU algorithm # 根据LRU算法删除⼀些key

allkeys-lru -> remove any key according to the LRU algorithm # 随机删除⼀些设置了过期时间的key

volatile-random -> remove a random key with an expire set# 从所有的key中随机删除⼀些key

allkeys-random -> remove a random key, any key # 删除⼀些快过期的key

volatile-ttl -> remove the key with the nearest expire time (minor TTL)

# 不删除任何key，在向Redis写⼊key时返回⼀个错误，这将会占⽤更多的内存noeviction -> don't expire at all, just return an error on write operations

需要注意的是：with any of the above policies, Redis will return an error on write operations, when there are no suitable keys for eviction。即在上⾯的六种策略中，如果没有key可以被删除时，向Redis中写⼊数据会返回⼀个error异常。缓存更新策略对⽐如下图所⽰：

⼆、缓存粒度控制

上图中，使⽤Redis来做缓存，底层使⽤MySQL来做数据存储源，这种架构下⼤部分请求由Redis处理，少部分请求到达MySQL。从MySQL中获取⼀个⽤户的所有信息，然后缓存到Redis的数据结构中。

此时需要⾯对⼀个问题：缓存这个⽤户的所有数据信息，还是缓存⽤户需要的⽤户信息字段。可以从三个⾓度来考虑：

（1）通⽤性：从通⽤性⾓度考虑，缓存全量属性更好。

因为当⽤户数据表字段发⽣改变时，不需要修改程序就可以直接同步修改之后的⽤户信息到Redis缓存中供⽤户使⽤，但是这样会占⽤更多的内存空间。

（2）占⽤空间：从占⽤空间的⾓度考虑，缓存部分属性更好。

因为当⽤户数据表字段发⽣改变时⽽⽤户需要这个字段信息时，就需要修改程序源代码来把修改之后的⽤户信息同步缓存到Redis中，这种情况下占⽤的内存空间⽐全量属性占⽤的内存空间要少。

（3）代码维护：从代码维护⾓度考虑，表⾯上缓存全量属性更好。

因为不管数据源中的数据表结构如何改变，都会把所有的数据同步到Redis缓存中，⽽不需要修改程序源代码，但是在⼤多数情况下，并不会使⽤到全量数据，只需要缓存需要的数据就可以了。因此从内存空间消耗及性能⽅⾯考虑，缓存部分属性更好。综合以上3点原因得出：在选择缓存属性时，需要综合考虑缓存全量属性还是部分属性。后续待写。。。参考博⽂：

（1）

（2） （redis系列⽂章）

（3） （Redis 缓存雪崩、击穿、穿透）