阅读 565

redis缓存设计

缓存的利于弊及应用场景

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

缓存的优点

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

缓存带来的问题

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

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

应用场景

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

缓存更新策略

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

应用

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

缓存穿透

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

缓存穿透的发现:

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

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

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

缓存穿透的解决方案

  • 缓存空对象
    • 占用内存: 原因是为了防止大量空对象(被攻击) 方案是可以设置比较短的过期时间,让其自动剔除
    • 数据不一致: 原因是存储层添加了数据,但是缓存空对象还没过期, 方案是可以使用消息队列,
  • bloomfilter拦截
    • 这种方法适用于数据命中不高、 数据相对固定、 实时性低(通常是数据集较大) 的应用场景, 代码维护较为复杂,但是缓存空间占用少。

无底洞优化

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

常见的IO优化思路:

  • 命令本身的优化,例如优化SQL语句等
  • 减少网络通信次数
    • pipeline
    • mget
  • 降低介入成本,例如客户端使用长连/连接池、NIO等

集群客户端优化方案

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

雪崩优化

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

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

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

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

热点key重建优化

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

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

热点key重建

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