⁴³

《Redis 武功秘籍：40 条实战绝学，纵横江湖无敌手👋》

程序员贺同学

2023-08-22 19:55

阅读3726

程序员贺同学

2023-08-22 19:55

阅读 3726

大家好，今天七夕，祝大家七夕快乐！🎋

有对象的好好陪对象，没对象的赶紧 new 一个对象，hh

趁在过节之前，肝出这篇 Redis 武功秘籍，祝星球小伙伴们，纵横江湖无敌手！😜

导言

你的项目或许已经使用 Redis 很长时间了，但在使用过程中，你可能还会或多或少地遇到以下问题：

我的 Redis 内存为什么增长这么快？
为什么我的 Redis 操作延迟变大了？
如何降低 Redis 故障发生的频率？
日常运维 Redis 需要注意什么？
部署 Redis 时，如何做好资源规划？
Redis 监控重点要关注哪些指标？

尤其是当你的项目越来越依赖 Redis 时，这些问题就变得尤为重要。

此时，你迫切需要一份「最佳实践指南」。

这篇文章，我将从以下五个维度，带你「全面」分析 Redis 的最佳实践优化：

内存
性能
高可靠
缓存
日常运维

在文章的最后，我还会给你一个完整的最佳实践清单，不管你是业务开发人员，还是 DBA 运维人员，这个清单将会帮助你更加「优雅」地用好 Redis。

【1】如何使用 Redis 更节省内存？

首先，我们来看一下 Redis 内存方面的优化。

众所周知，Redis 的性能之所以如此之高，原因就在于它的数据都存储在「内存」中，所以访问 Redis 中的数据速度极快。

但从资源利用率层面来说，机器的内存资源相比于磁盘，还是比较昂贵的。

当你的业务应用在 Redis 中存储数据很少时，你可能并不太关心内存资源的使用情况。但随着业务的发展，你的业务存储在 Redis 中的数据就会越来越多。

如果没有提前制定好内存优化策略，那么等业务开始增长时，Redis 占用的内存也会开始膨胀。

所以，提前制定合理的内存优化策略，对于资源利用率的提升是很有必要的。

那在使用 Redis 时，怎样做才能更节省内存呢？这里我给你总结了 6 点建议，我们依次来看：

键值设计 - Key 名设计

最简单直接的内存优化，就是控制 key 的长度。

在开发业务时，你需要提前预估整个 Redis 中写入 key 的数量，如果 key 数量达到了百万级别，那么，过长的 key 名也会占用过多的内存空间。

所以，你需要保证 key 在简单、清晰的前提下，尽可能把 key 定义得短一些。

这样一来，你的 Redis 就可以节省大量的内存，这个方案对内存的优化非常直接和高效。

【建议】可读性和可管理性

以业务名为前缀(防止key冲突)，用冒号分隔，比如业务名:模型名:{id}ugc:video:1
如果是业务独立的 Redis ，可以忽略业务名前缀(redis实例名就包含了业务)，直接以场景名或模型名为前缀
避免一个 Redis 中的不同场景的 key 都使用同样的一级前缀，会导致热 key 前缀分析工具无法区分具体场景。

【建议】简洁性

保证语义的前提下，控制 key 的长度，当key的总量很大时，内存占用也不容忽视，例如
user:{uid}:messages:{mid} 简化为 u:{uid}:m:{mid}:mid}

【强制】不要包含特殊字符

反例：包含空格、换行、单双引号以及其他转义字符

Value 设计

【强制】拒绝 bigkey(防止网卡流量过大、慢查询)

string 类型控制在 10KB 以内，hash、list、set、zset元素个数控制 1w 以下。
反例:一个包含200万个元素的list
非字符串的 bigkey，不要使用 del 删除。使用 hscan、sscan、zscan方式渐进式删除
同时要注意防止 bigkey 过期时间自动删除问题(例如一个200万的的zset设置1小时过期,会触发del操作,造成阻塞，而且该操作不会出现在慢查询中)

【推荐】选择适合的数据类型

String、Set 在存储 int 数据时，会采用整数编码存储。Hash、ZSet 在元素数量比较少时（可配置），会采用压缩列表（ziplist）存储，在存储比较多的数据时，才会转换为哈希表和跳表。

作者这么设计的原因，就是为了进一步节约内存资源。

那么你在存储数据时，就可以利用这些特性来优化 Redis 的内存。这里我给你的建议如下：

String、Set：尽可能存储 int 类型数据
Hash、ZSet：存储的元素数量控制在转换阈值之下，以压缩列表存储，节约内存

反例:

set user:1:name tom

set user:1:age 19

3 set user:1:favor football

正例:

1 hmset user:1 name tom age 19 favor football

TTL 过期时间

【推荐】控制 Key 的生命周期，Redis 不是垃圾桶，什么数据都一直往里面扔。
建议使用 expire 设置过期时间（条件允许可以打散设置过期时间，防止集中过期），不过期的数据重点关注闲置时间。

命令使用

【推荐】 O(N)命令关注N的数量

例如 hgetall、Irange、smembers、zrange、sinter 等并非不能使用，但是需要明确N的值，有遍历的需求可以使用 hscan、sscan、zscan 代替( Redis 支持，但 proxy 不支持)

【推荐】禁用命令

禁止线上使用 keys、flushall、flushdb等，使用 scan 的方式渐进式处理(Redis 支持，但 proxy 不支持

【推荐】不要使用 select

看下公司 Redis 集群是否支持多个数据库
Redis 的多数据库较弱，使用数字进行区分，很多客户端支持转较差，同时多业务用多数据库实际还是单线程处理，会有干扰

【推荐】使用批量操作提高效率

可以使用 pipeline 提高效率。有 mget/mset场景尽量改用 pipeline( mget 对 proxy 的消耗比较大)
但要注意控制一次批量操作的元素个数(例如500以内，实际也和元素字节数有关)

【建议】Redis 事务功能较弱，不建议过多使用

有的公司 Redis proxy 不支持 Redis 事务
Redis 的事务功能较弱(不支持回滚)，如果一定要使用只能能直连

【建议】必要情况下使用 monitor 命令时,要注意不要长时间使用

淘汰策略

【推荐】实例设置 maxmemory + 淘汰策略

虽然你的 Redis key 都设置了过期时间，但如果你的业务应用写入量很大，并且过期时间设置得比较久，那么短期间内 Redis 的内存依旧会快速增长。

如果不控制 Redis 的内存上限，也会导致使用过多的内存资源。

对于这种场景，你需要提前预估业务数据量，然后给这个实例设置 maxmemory 控制实例的内存上限，这样可以避免 Redis 的内存持续膨胀。

配置了 maxmemory，此时你还要设置数据淘汰策略，而淘汰策略如何选择，你需要结合你的业务特点来决定：

volatile-lru / allkeys-lru：优先保留最近访问过的数据
volatile-lfu / allkeys-lfu：优先保留访问次数最频繁的数据（4.0+版本支持）
volatile-ttl ：优先淘汰即将过期的数据
volatile-random / allkeys-random：随机淘汰数据

数据压缩后写入 Redis

以上方案基本涵盖了 Redis 内存优化的各个方面。

如果你还想进一步优化 Redis 内存，你还可以在业务应用中先将数据压缩，再写入到 Redis 中（例如采用 snappy、gzip 等压缩算法）。

当然，压缩存储的数据，客户端在读取时还需要解压缩，在这期间会消耗更多 CPU 资源，你需要根据实际情况进行权衡。

以上就是「节省内存资源」方面的实践优化，是不是都比较简单？

【2】如何发挥 Redis 的高性能？

一个单机版 Redis 就可以达到 10W QPS，这么高的性能，也意味着如果在使用过程中发生延迟情况，就会与我们的预期不符。

所以，在使用 Redis 时，如何持续发挥它的高性能，避免操作延迟的情况发生，也是我们的关注焦点。

在这方面，我给你总结了 13 条建议：

【强制】避免存储 bigkey

存储 bigkey 除了前面讲到的使用过多内存之外，对 Redis 性能也会有很大影响。

由于 Redis 处理请求是单线程的，当你的应用在写入一个 bigkey 时，更多时间将消耗在「内存分配」上，这时操作延迟就会增加。同样地，删除一个 bigkey 在「释放内存」时，也会发生耗时。

而且，当你在读取这个 bigkey 时，也会在「网络数据传输」上花费更多时间，此时后面待执行的请求就会发生排队，Redis 性能下降。

如果你确实有存储 bigkey 的需求，你可以把 bigkey 拆分为多个小 key 存储。

【可选】开启 lazy-free 机制

如果你无法避免存储 bigkey，那么我建议你开启 Redis 的 lazy-free 机制。（4.0+版本支持）

当开启这个机制后，Redis 在删除一个 bigkey 时，释放内存的耗时操作，将会放到后台线程中去执行，这样可以在最大程度上，避免对主线程的影响。

【推荐】不使用复杂度过高的命令

Redis 是单线程模型处理请求，除了操作 bigkey 会导致后面请求发生排队之外，在执行复杂度过高的命令时，也会发生这种情况。

因为执行复杂度过高的命令，会消耗更多的 CPU 资源，主线程中的其它请求只能等待，这时也会发生排队延迟。

所以，你需要避免执行例如 SORT、SINTER、SINTERSTORE、ZUNIONSTORE、ZINTERSTORE 等聚合类命令。

对于这种聚合类操作，我建议你把它放到客户端来执行，不要让 Redis 承担太多的计算工作。

【推荐】执行 O(N) 命令时，关注 N 的大小

规避使用复杂度过高的命令，就可以高枕无忧了么？

答案是否定的。

当你在执行 O(N) 命令时，同样需要注意 N 的大小。

如果一次性查询过多的数据，也会在网络传输过程中耗时过长，操作延迟变大。

所以，对于容器类型（List/Hash/Set/ZSet），在元素数量未知的情况下，一定不要无脑执行 LRANGE key 0 -1 / HGETALL / SMEMBERS / ZRANGE key 0 -1。

在查询数据时，你要遵循以下原则：

先查询数据元素的数量（LLEN/HLEN/SCARD/ZCARD）
元素数量较少，可一次性查询全量数据
元素数量非常多，分批查询数据（LRANGE/HASCAN/SSCAN/ZSCAN）
ZRANGE / ZRANGEBYSCORE 建议用 limit offset

【推荐】关注 DEL 时间复杂度

你没看错，在删除一个 key 时，如果姿势不对，也有可能影响到 Redis 性能。

删除一个 key，我们通常使用的是 DEL 命令，回想一下，你觉得 DEL 的时间复杂度是多少？

O(1) ？其实不一定。

当你删除的是一个 String 类型 key 时，时间复杂度确实是 O(1)。

但当你要删除的 key 是 List/Hash/Set/ZSet 类型，它的复杂度其实为 O(N)，N 代表元素个数。

也就是说，删除一个 key，其元素数量越多，执行 DEL 也就越慢！

原因在于，删除大量元素时，需要依次回收每个元素的内存，元素越多，花费的时间也就越久！

而且，这个过程默认是在主线程中执行的，这势必会阻塞主线程，产生性能问题。

那删除这种元素比较多的 key，如何处理呢？

建议是，分批删除：

List类型：执行多次 LPOP/RPOP，直到所有元素都删除完成
Hash/Set/ZSet类型：先执行 HSCAN/SSCAN/SCAN 查询元素，再执行 HDEL/SREM/ZREM 依次删除每个元素

没想到吧？一个小小的删除操作，稍微不小心，也有可能引发性能问题，你在操作时需要格外注意。

【推荐】批量命令代替单个命令

当你需要一次性操作多个 key 时，你应该使用批量命令来处理。

批量操作相比于多次单个操作的优势在于，可以显著减少客户端、服务端的来回网络 IO 次数。

所以我给你的建议是：

String / Hash 使用 MGET/MSET 替代 GET/SET，HMGET/HMSET 替代 HGET/HSET
其它数据类型使用 Pipeline，打包一次性发送多个命令到服务端执行

【推荐】避免集中过期 key

Redis 清理过期 key 是采用定时 + 懒惰的方式来做的，而且这个过程都是在主线程中执行。

如果你的业务存在大量 key 集中过期的情况，那么 Redis 在清理过期 key 时，也会有阻塞主线程的风险。

想要避免这种情况发生，你可以在设置过期时间时，增加一个随机时间，把这些 key 的过期时间打散，从而降低集中过期对主线程的影响。

【推荐】使用长连接操作 Redis，合理配置连接池

你的业务应该使用长连接操作 Redis，避免短连接。

当使用短连接操作 Redis 时，每次都需要经过 TCP 三次握手、四次挥手，这个过程也会增加操作耗时。

同时，你的客户端应该使用连接池的方式访问 Redis，并设置合理的参数，长时间不操作 Redis 时，需及时释放连接资源。

【推荐】使用读写分离 + 分片集群

如果你的业务读请求量很大，那么可以采用部署多个从库的方式，实现读写分离，让 Redis 的从库分担读压力，进而提升性能。

如果你的业务写请求量很大，单个 Redis 实例已无法支撑这么大的写流量，那么此时你需要使用分片集群，分担写压力。

【推荐】不开启 AOF 或 AOF 配置为每秒刷盘

如果对于丢失数据不敏感的业务，我建议你不开启 AOF，避免 AOF 写磁盘拖慢 Redis 的性能。

如果确实需要开启 AOF，那么我建议你配置为 appendfsync everysec，把数据持久化的刷盘操作，放到后台线程中去执行，尽量降低 Redis 写磁盘对性能的影响。

【推荐】使用物理机部署 Redis

Redis 在做数据持久化时，采用创建子进程的方式进行。

而创建子进程会调用操作系统的 fork 系统调用，这个系统调用的执行耗时，与系统环境有关。

虚拟机环境执行 fork 的耗时，要比物理机慢得多，所以你的 Redis 应该尽可能部署在物理机上。

【推荐】关闭操作系统内存大页机制

Linux 操作系统提供了内存大页机制，其特点在于，每次应用程序向操作系统申请内存时，申请单位由之前的 4KB 变为了 2MB。

这会导致什么问题呢？

当 Redis 在做数据持久化时，会先 fork 一个子进程，此时主进程和子进程共享相同的内存地址空间。

当主进程需要修改现有数据时，会采用写时复制（Copy On Write）的方式进行操作，在这个过程中，需要重新申请内存。

如果申请内存单位变为了 2MB，那么势必会增加内存申请的耗时，如果此时主进程有大量写操作，需要修改原有的数据，那么在此期间，操作延迟就会变大。

【3】如何保证 Redis 的可靠性？

这里我想提醒你的是，保证 Redis 可靠性其实并不难，但难的是如何做到「持续稳定」。

下面我会从「资源隔离」、「多副本」、「故障恢复」这三大维度，带你分析保障 Redis 可靠性的最佳实践。

【推荐】按业务线部署实例

提升可靠性的第一步，就是「资源隔离」。

你最好按不同的业务线来部署 Redis 实例，这样当其中一个实例发生故障时，不会影响到其它业务。

这种资源隔离的方案，实施成本是最低的，但成效却是非常大的。

【推荐】部署主从集群

如果你只使用单机版 Redis，那么就会存在机器宕机服务不可用的风险。

所以，你需要部署「多副本」实例，即主从集群，这样当主库宕机后，依旧有从库可以使用，避免了数据丢失的风险，也降低了服务不可用的时间。

在部署主从集群时，你还需要注意，主从库需要分布在不同机器上，避免交叉部署。

这么做的原因在于，通常情况下，Redis 的主库会承担所有的读写流量，所以我们一定要优先保证主库的稳定性，即使从库机器异常，也不要对主库造成影响。

而且，有时我们需要对 Redis 做日常维护，例如数据定时备份等操作，这时你就可以只在从库上进行，这只会消耗从库机器的资源，也避免了对主库的影响。

【推荐】合理配置主从复制参数

在部署主从集群时，如果参数配置不合理，也有可能导致主从复制发生问题：

主从复制中断
从库发起全量复制，主库性能受到影响

在这方面我给你的建议有以下 2 点：

设置合理的 repl-backlog 参数：过小的 repl-backlog 在写流量比较大的场景下，主从复制中断会引发全量复制数据的风险
设置合理的 slave client-output-buffer-limit：当从库复制发生问题时，过小的 buffer 会导致从库缓冲区溢出，从而导致复制中断

【推荐】部署哨兵集群，实现故障自动切换

只部署了主从节点，但故障发生时是无法自动切换的，所以，你还需要部署哨兵集群，实现故障的「自动切换」。

而且，多个哨兵节点需要分布在不同机器上，实例为奇数个，防止哨兵选举失败，影响切换时间。

以上这些就是保障 Redis「高可靠」实践优化，你应该也发现了，这些都是部署和运维层的优化。

除此之外，你可能还会对 Redis 做一些「日常运维」工作，这时你要注意哪些问题呢？

【5】数据更新时，如何保证 Redis 缓存的一致性？

常见的数据更新方式有几种：

【1】先更新数据库，再更新缓存

在并发更新情况下会有问题，假设两个并发线程同时修改一个数据，时序上更新数据库的操作和更新缓存的先后顺序不一致，会导致缓存了脏数据
在读>>写，写操作不易冲突的场景，这个方案是可行的，实现成本最低

【2】先更新数据库，再删除缓存，下次读请求穿透+更新缓存

可以降低缓存脏数据的可能性，但极端情况下还是可能导致缓存过期数据
数据库主从不同步，会导致读请求穿透后拿到的还是旧数据
更新数据库之前如果另一个线程先cache miss并读取了旧值，更新删除缓存后还是可能会有旧数据被写入缓存（概率较小，理论可能，如cache miss的线程读完旧值后、写入缓存前正好遇到GC，可能会导致这种情况）
在主从同步延迟较小的场景，这个方案是可行的，实现成本较低
穿透时需要注意并发问题，具体参考“缓存穿透”小节