Redis 是一个开源的高性能的 Key-Value 服务器。本篇主要介绍一下缓存的设计与优化。

1. 缓存的受益与成本

缓存的使用场景：

降低后端负载，对高消耗的 SQL，例如 join 结果集/分组统计结果缓存；

加速请求响应，利用 Redis/Memcache 优化 IO 响应时间；

大量写合并为批量写，例如计数器先 Redis 累加再批量写 DB。

2.单线程架构

Redis 在一个同一时间点只会执行一条命令。

大多情况下，单线程是非常慢的。Redis 单线程架构为什么这么快？

主要原因：纯内存；

非阻塞 IO，Redis 使用 Event Loop 这样的模型作为 IO 多路复用的实现，并且 Redis 自身实现了一个事件处理，将 Event Loop 连接、读写、关闭转换为自身的一个事件，不再往 IO 上浪费过多时间；

避免线程切换和竞态消耗；

单线程架构要注意什么？

一次只运行一条命令；

拒绝长（慢）命令，例如 keys、flushall、flushdb、slow lua scrip、mutil/exec、operate big value（collection）；

2.缓存更新策略

两条建议：

低一致性：推荐最大内存和淘汰策略；

高一致性：推荐超时剔除和主动更新结合，超时剔除是给主动更新做了一个兜底，还需要最大内存和淘汰策略二次兜底。

3.缓存粒度控制

从 MySQL 获取用户信息：select * from user where id = {id}

设置用户信息缓存：set user:{id} ‘select * from user where id = {id}’

缓存粒度：

全部属性：set user:{id} ‘select * from user where id = {id}’

部分重要属性：set user:{id} ‘select importantColumn1, …importantColumnK from user where id = {id}’

缓存粒度控制的三个角度：

通用性：全部属性更好；

占用空间：部分重要属性更好；

代码维护：表面上全部属性更好，增删字段不需要维护代码。

4.缓存穿透优化

缓存穿透问题，大量请求不命中？

发生缓存穿透的常见原因：

业务代码自身问题；

恶意攻击、爬虫等等。

如何发现问题？

业务的响应时间；

业务本身问题；

相关监控指标：总调用数、缓存层命中数、存储层命中数；

缓存穿透问题解决方案：

方案一：缓存空对象。示例代码：

方案二：布隆过滤器拦截。通过很小的内存来实现对数据的过滤。

5.缓存雪崩优化

缓存雪崩：由于 cache 服务承载大量请求，当 cache 服务异常/脱机后，流量直接压向后端组件（例如 DB），造成级联故障。

缓存雪崩优化方案：

保证缓存高可用性，例如 Redis Cluster、Redis Sentinel、VIP；

依赖隔离组件为后端限流；

提前演练，例如压力测试。

6.无底洞问题优化

无底洞问题：增加机器性能没能提升，反而下降。问题关键点就是批量操作的链化，例如 mget 操作，时间复杂度为 O(node)，随着机器的增加，mget 批量操作的时间会越长，更多的机器不代表更多的性能。

但是随着数据增长，水平扩展是必须的。

优化 IO 的几种方法：

命令本身优化，例如慢查询 keys、hgetall bigkey；

减少网络通信次数；

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

7.热点key优化

发现热点key：

方法一：客户端，可以使用 Guava 的 AtomicLongMap，记录 key 的调用次数：

方法二：代理端

    客户端和 Redis 中间加一个代理进行收集统计。

方法三：服务端

    使用 monitor 解析，输出统计。

方法四：机器收集

抓取分析 Redis 所在机器的 TPC 数据。

四种方式对比：

优化方案：

    1、避免 bigkey；

    2、热键不要用 hash_tag，因为 hash_tag 会落到一个节点上；

    3、如果真有热点 key 而且业务对一致性要求不高时，可以用本地缓存 + MQ 解决。

8.热点key重建优化

问题：热点 key + 较长的重建时间。

获取缓存 -> 查询数据源 -> 重建缓存 -> 输出，这个步骤在高并发的情况下，由于查询数据源需要时间，所以会有很多请求会进入到 查询数据源 -> 重建缓存 这个过程。对数据源会造成很大压力，响应时间也会变慢。

三个优化目标：

    1、减少重建缓存的次数；

    2、数据尽可能一致；

    3、减少潜在风险。

两个优化方案：

    1、互斥锁（mutex key），查询数据源 -> 重建缓存 这个过程加互斥锁；

    2、永不过期，缓存层面不设置过期时间（没有用 expire），功能层面为每个 value 添加逻辑过期时间，但发现超过逻辑过期时间后，会使用单独的线程去构建缓存。

两个优化方案的对比：

9.总结

缓存收益：加速读写、降低后端存储负载；

缓存成本：缓存和存储数据不一致性、代码维护成本、运维成本；

推荐结合剔除、超时、主动更新三种方案共同完成；

穿透问题：使用缓存空对象和布隆过滤器来解决，注意它们各自的使用场景和局限性；

无底洞问题：分布式缓存中，有更多的机器不保证有更高的性能。有四种批量操作方式：串行命令、串行 IO、并行 IO、hash_tag；

雪崩问题：缓存层高可用、客户端降级、提前演练是解决雪崩问题的重要方法；

热点 key 重建问题：互斥锁、永不过期能够在一定程度上解决热点 key 问题，开发人员在使用时要了解它们各自的使用成本。

原文转载自：https://blog.csdn.net/smartbetter/article/details/97953883