redis缓存设计

缓存的利于弊及应用场景

这里我们主要讨论以Redis为代表的基于内存的缓存方案。

缓存的优点

提升访问速度，减少后端如数据库存储的时间消耗
减轻后端如数据库的压力

缓存带来的问题

任何系统每增加一个组件，在带来新的特性的同时也必然会带来额外的复杂度，可以说系统的设计过程就是一个折中的过程。缓存的引入也带来了一些需要考虑的问题:

• 数据不一致: 缓存层和存储层的数据存在着一定的时间窗口的不一致性，时间窗口跟缓存更新策略有关
• 代码维护成本： 需要同时处理缓存和存储层的逻辑
• 运维成本: 为了保证redis的可用性和并发性，会引入redis sentinel或redis cluster等架构，这又增加了系统复杂性和运维难度。

应用场景

• 开销大的复杂运算
• 加速请求响应

缓存更新策略

• LRU/LFU/FIFO算法
• 超时剔除
• 主动更新

应用

• 低一致性业务建议：最大内存+淘汰策略
• 高一致性：超时剔除和主动更新

缓存穿透

缓存穿透: 是指查询一个根本不存在的数据， 缓存层和存储层都不会命中。这会造成存储层压力变大。

缓存穿透的发现:

通常可以在程序中分别统计

• 总调用数
• 缓存层命中数
• 存储层命中数

如果发现大量存储层空命中， 可能就是出现了缓存穿透问题。

缓存穿透的解决方案

• 缓存空对象

。占用内存： 原因是为了防止大量空对象(被攻击) 方案是可以设置比较短的过期时间，让其自动剔除 数据不一致:
。原因是存储层添加了数据，但是缓存空对象还没过期， 方案是可以使用消息队列，

• bloomfilter拦截

。 这种方法适用于数据命中不高、 数据相对固定、 实时性低（通常是数据集较大） 的应用场景， 代码维护较为复杂，但是缓存空间占用少。

无底洞优化

由于缓存集群通常会将key进行hash，然后映射到相应的节点上，造成key的分布与业务无关，批量操作通常需要从不同节点上获取，相比于单机批量操作只涉及一次网络操作，分布式批量操作会涉及多次网络时间。
常见的IO优化思路：

• 命令本身的优化，例如优化SQL语句等
• 减少网络通信次数

。pipeline
。mget

• 降低介入成本，例如客户端使用长连/连接池、NIO等

集群客户端优化方案

• 串行IO，把key的请求按照节点分组，然后依次处理
• 并行IO，把key的请求按照节点分组，然后并行处理
• hash_tag实现， 可以将多个key强制分配到一个节点上，它的操作时间=1此网络时间+n次命令时间，性能最高，但是数据维护成本高，数据易倾斜

雪崩优化

雪崩定义：由于缓存层承载着大量请求，有效地保存了存储层，但是如果缓存层由于某些原因不能提供服务，于是所有的请求都会到达存储层，存储层的调用会暴增。

说到底就是缓存扛不住了，把压力冲击到了存储层。

预防和缓解缓存雪崩问题的三个方面

• 保证缓存层服务高可用性，redis提供了Redis Sentinel和Redis Cluster
• 依赖隔离组件为后端限流并降级，降级机制，如Hystrix
• 提前演练，项目上线前，演练缓存层宕掉后，应用及后端的负载情况以及可能出现的问题。

热点key重建优化

缓存+过期时间的策略既可以加速数据读写，又保证数据的定期更新，这种模式基本能够满足绝大部分需求。但有两个问题：

• 热点key，并发量非常大
• 重建缓存不能在短时间完成（长时生成缓存）

热点key重建

互斥锁
永远不过期，但是重建期间会有不一致问题