redis缓存设计及经常使用问题

redis缓存设计及经常使用问题

缓存的收益与成本分析 缓存更新策略的选择以及使用场景 缓存粒度控制法 穿透问题优化 无底洞问题优化 雪崩问题优化 热点key重建优化 收益与成本

收益

1. 加速读写

2. 下降后端负载 成本

3. 数据不一致性

4. 代码维护成本

5. 运维成本 缓存更新策略

6. lru，ttl，random，allkey-lru，allkey-random，no-enviction（内存达到最大值时的缓存策略） 2.超时删除 （设定过时时间） 3.主动更新（用于数据一致性较高） 缓存粒度

7. 所有数据缓存以及部分数据缓存的选择

8. 思考缓存粒度从几个维度考虑： 数据通用性，空间占用比，代码维护性 一般缓存所有数据 通用性好，代码维护简单，可是空间占用大，而缓存部分数据则相反 穿透问题

缘由：cache miss 后直接请求后端服务，常发生在业务代码异常，或者大量恶意攻击致使的

解决方法：

1. 空对象缓存，可是须要注意缓存空间的使用状况，对空对象缓存时间尽可能要小
2. 布隆过滤器缓存 miss cache 直接返回 不请求后端服务，可是必须有定时程序往缓存中写数据，适用于数据缓存命中不高的场景 布隆过滤器

用途：快速查询一个元素是否在一个集合中

入参：失败率，集合个数

原理：用k个hash函数将结果存在一个位数组中，检查的时候对比每个位上是不是1 若是全是的话 则说明命中

说明：结果在，有可能不在 结果不在，则必定不在 无底洞问题

表现：集群增长节点依然性能不佳。耗时有可能还有增长

缘由：客户端使用mget之类批量获取key的命令时候，会致使更多的io请求。在redis cluster中 key是分布在各个slot中，批量操做的话会增长更多的网络io

解决方式：

1. 相同节点key 合并。总时间 = node + n次命令时间

2. redis 强制将这些key 写入同一个slot中

性能比较

1. 编程复杂，须要考虑多线程开发的问题
2. 性能最高，维护成本很高，可是容易发生数据倾斜的问题 雪崩问题

表现：在缓存层中服务不可以使用，致使后端服务负载太高，出现宕机的状况

解决办法：

1. 缓存高可用架构 （master/slaver，哨兵，cluster）
2. 后端限流降级 （限流3个手段 计数器，漏斗，令牌桶）
3. 提早对业务进行故障演练，正确估计缓存性能，负载状况 热点key重建

表现：一般 缓存key+过时时间，能保证绝大部分需求，可是有2种状况下，这样的作法会引发性能问题

1. 热点key 过时重建
2. 重建的逻辑计算至关复杂

缘由。热点key中 会有大量的线程尝试重建缓存，致使后端负载过大，甚至引发宕机 解决方式：

1. 引入分布式锁 保证同一时间只有一个请求来进行key 重建
2. 设定key 永不过时 直到他变成不是热点key