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重建

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