Redis 性能调优——缓存设计优化

最新推荐文章于 2024-06-06 16:07:02 发布

一叶知秋V

最新推荐文章于 2024-06-06 16:07:02 发布

阅读量1.7k

点赞数 4

分类专栏： Redis 文章标签： Redis

本文链接：https://blog.csdn.net/smartbetter/article/details/97953883

版权

Redis 专栏收录该内容

11 篇文章 2 订阅

订阅专栏

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

1. 缓存的受益与成本

-	说明
缓存的受益	1、加速读写，通过缓存加速读写速度，例如 CPU L1/L2/L3 Cache、Linux page Cache 加速硬盘读写、浏览器缓存、Ehcache 缓存数据库结果； 2、降低后端负载，后端服务器通过前端缓存降低负载，业务端使用 Redis 降低后端 MySQL 负载等。
缓存的成本	1、数据不一致，缓存和数据层有时间窗口不一致，和更新策略有关； 2、代码维护成本增加，多了一层缓存逻辑； 3、运维成本增加。

缓存的使用场景：

降低后端负载，对高消耗的 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.缓存更新策略

策略	说明	一致性	维护成本
LRU/LFU/FIFO 算法剔除	例如 maxmemory-policy	最差	低
超时剔除	例如 expire	较差	低
主动更新	开发控制生命周期	强	高

两条建议：

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

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.缓存穿透优化

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

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

业务代码自身问题；
恶意攻击、爬虫等等。

如何发现问题？

业务的响应时间；
业务本身问题；
相关监控指标：总调用数、缓存层命中数、存储层命中数；

缓存穿透问题解决方案：

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

public String getPassThrough(String key) {
    String cacheValue = cache.get(key);
    if (StringUtils.isBlank(cacheValue)) {
        String storageValue = storage.get(key);
        cache.set(key, storageValue);
        // 如果存储数据为空, 需要设置过期时间
        if (StringUtils.isBlank(storageValue)) {
            cache.expire(key, 300); // 300秒
        }
        return storageValue;
    } else {
        return cacheValue;
    }
}

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

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 的调用次数：

public static final AtomicLongMap<String> ATOMIC_LONG_MAP = AtomicLongMap.create();
String get(String key) {
	counterKey(key);
	...
}
String set(String key, String value) {
	counterKey(key);
	...
}

方法二：代理端

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

方法三：服务端

使用 monitor 解析，输出统计。

方法四：机器收集

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

四种方式对比：

方案	优点	缺点
客户端	1、实现简单；	1、内存泄露隐患，如果 key 量太大不建议使用； 2、维护成本高； 3、只能统计单个客户端；
代理端	1、代理是客户端和服务端的桥梁，实现最方便最系统；	1、增加代理端的开发部署成本；
服务端	1、实现简单；	1、monitor 本身的使用成本和危害，只能短时间使用； 2、只能统计单个 Redis 节点；
机器收集	1、对于客户端和服务端无侵入和影响；	1、需要专业的运维团队开发，并且增加了机器的部署成本；

优化方案：

避免 bigkey；
热键不要用 hash_tag，因为 hash_tag 会落到一个节点上；
如果真有热点 key 而且业务对一致性要求不高时，可以用本地缓存 + MQ 解决。

8.热点key重建优化

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

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

三个优化目标：

减少重建缓存的次数；
数据尽可能一致；
减少潜在风险。

两个优化方案：

互斥锁（mutex key），查询数据源 -> 重建缓存这个过程加互斥锁；
永不过期，缓存层面不设置过期时间（没有用 expire），功能层面为每个 value 添加逻辑过期时间，但发现超过逻辑过期时间后，会使用单独的线程去构建缓存。

两个优化方案的对比：

策略	优点	缺点
互斥锁	思路简单，保证一致性	代码复杂度增加，存在死锁的风险
永不过期	基本杜绝热点 key 重建问题	不保证一致性，逻辑过期时间增加维护成本和内存成本