Redis缓存使用技巧

缓存能够有效加速应用的访问速度，同时可以降低后端负载，在应用架构中起着至关重要的作用，本文主要介绍缓存使用的一些技巧。

缓存更新策略

LRU/LFU/FIFO算法剔除

场景：数据一致性要求较低

原理：缓存使用量超过了预设值，使用maxmemory-policy来选择何种剔除策略对现有数据进行删除

问题：数据清理由算法决定，开发人员只能选择使用哪种算法，数据一致性最差

超时剔除

场景：数据一致性要求低

原理：给缓存设置过期时间（expire），自动删除

问题：一段时间窗口内存在一致性问题

主动更新

场景：数据一致性要求较高

原理：真实数据更新后，立即更新缓存

问题：主动更新发生问题，这条数据很长时间不会发生更新

总结：

低一致性业务使用最大内存+淘汰策略
高一致性业务使用超时剔除+主动更新

缓存粒度控制

缓存的粒度在缓存应用时也有着很重要的影响，究竟缓存全部属性还是部分属性？可以从三个维度来进行权衡。

通用性

缓存全部数据比部分更加通用，但是较多情况下，应用只需要其中几个重要的属性

空间占用

缓存全部数据占用更多的空间，可能会造成内存的浪费，而且每次传输产生的网络流量较大，极端情况会阻塞网络

代码维护

部分数据一旦表结构变动，增加新字段则需要修改业务代码，并且需要重新刷新缓存

总结：

缓存粒度问题容易被忽视，但是使用不当，可能造成更多无用空间的浪费、网络带宽的浪费、代码通用型较差等情况，需要综合以上三点进行取舍

缓存穿透优化

缓存穿透指查询一个不存在的数据，导致不存在的数据每次请求都要到存储层查询，使后端存储层负载过大，极端情况可能导致宕掉。

缓存空对象

原理：缓存不命中，查询存储层，仍然不命中，则将空对象保存至缓存层中，然后再返回

场景：数据命中率不高，频繁变化实时性高

问题：1.空值占用更多的键，占用更多的内存空间，如果被攻击，可能导致内存快速增长，利用较短的过期时间来自动剔除；

2.缓存层和存储层一定时间窗口数据不一致，利用消息系统或者其它方式清楚缓存中空对象。

布隆过滤拦截器

原理：在缓存层和存储层之间，将存在的key用布隆过滤器提前保存，如果key存在，则不访问存储层，可以通过Bitmaps来实现。

场景：数据命中率不高、数据相对固定、实时性低（数据集较大）

问题：代码维护复杂

无底洞优化

业务增长导致需要增加缓存节点来提高性能，但是增加节点后性能不但没有反转反而下降。分布式场景下，一次批量操作需要访问多个Redis节点，需要多次网络访问时间。

串行命令

原理：n个key均匀分布在Redis Cluster各个节点上，逐次执行n个get命令

耗时：n次网络时间+n次命令时间

缺点：大量keys请求延迟

串行IO

原理： 使用JedisClusterCRC16计算出key的slot，然后找到对应的节点，将属于同一个节点的key进行归档，对每个节点执行mget操作

耗时：node次网络时间+n次命令时间

缺点：大量node延迟

并行IO

原理：对于串行IO中，得出每个节点的key列表，通过多线程来对每个节点进行mget操作

耗时：max_slow(node网络时间)+n次命令时间

缺点：变成复杂、多线程问题定位较难

hash_tag

原理：利用Redis Cluster功能，将多个key强制分配到一个节点

耗时：1次网络时间+n次命令时间

缺点：业务维护成本高、数据倾斜

雪崩优化

缓存层由于某些原因不可用，所有请求到达存储层，压力暴增，可能导致存储层也会级联宕机。

保证缓存层服务高可用：Redis Sentinel、Redis Cluster
依赖隔离组件为后端限流降级：Hystrix
提前演练：模拟缓存层宕掉，应用以及后端的负载情况和可能出现的问题

热点key重建优化

“缓存+过期时间”的策略绝大部分情况满足加速数据读写、保证数据定期更新的需求，但是也可能出现其它问题，假如某一个key是一个热点key，并发量很大，并且重建缓存遇到复杂SQL、多次IO等不可能短时间完成情况，当缓存失效的瞬间，大量线程重建，造成后端负载过大。

互斥锁（分布式锁）

原理：只允许一个线程重建缓存，其它线程等待，直接从缓存中获取数据

实现：使用Redis setnx或者其它方式来实现

问题：构建缓存过程出现问题或者时间过长，可能存在死锁和线程池阻塞的风险

永远不过期

原理：为每个value设置逻辑过期时间，当发现超过逻辑过期时间后，使用单独线程重新构建缓存

问题：不保证一致性问题，代码维护成本和内存成本（每次重建）增加

参考资料：《Redis开发与运维》