别再只盯着单节点了！Redis 集群性能调优实战案例解析

别再只盯着单节点了！Redis 集群性能调优实战案例解析

大家好，我是你们的老朋友，码农老王。

相信咱们搞技术的，对 Redis 都再熟悉不过了。这玩意儿快啊！用起来是真爽！但 Redis 用得多了，各种性能问题也就来了。以前单机 Redis 玩得溜，现在上了集群，发现事情没那么简单了。很多时候，你辛辛苦苦优化了半天单个节点，结果集群整体性能还是上不去，你说气不气？

今天老王就来跟大家聊聊 Redis 集群的性能调优。咱们不讲那些虚头巴脑的理论，直接上案例，手把手教你分析问题、解决问题，让你的 Redis 集群跑得飞起！

案例背景：电商大促，Redis 集群扛不住了！

先说说咱们这次案例的背景。一家电商公司，平时 Redis 集群用得好好的，一到大促，流量暴增，Redis 集群就各种报警：响应时间变长、连接数飙升、CPU 打满……用户那边呢，页面加载慢、下单失败，投诉电话都快被打爆了！

技术负责人老李急得团团转，找到老王我：“老王啊，你快帮我看看，这 Redis 集群到底咋回事啊？再这么下去，今年的奖金都得泡汤了！”

问题分析：从单点到集群，全局视角看问题

老李遇到的问题，其实很多公司都会遇到。单机 Redis 性能调优，大家可能都比较熟悉了，无非就是看看慢查询、优化数据结构、调整配置参数等等。但是，到了集群环境，情况就复杂多了。单个节点的优化，可能对集群整体性能影响不大，甚至还会带来负面影响。

所以，面对 Redis 集群的性能问题，咱们首先要做的，就是转变思路，从单点到集群，站在全局视角看问题。

具体怎么做呢？老王总结了几个步骤：

1. 监控先行，摸清家底：没有监控，就等于盲人摸象。我们要对 Redis 集群进行全方位的监控，包括但不限于：

   • Redis 节点层面：CPU 使用率、内存使用率、连接数、QPS、OPS、网络流量、慢查询数量、内存碎片率、AOF/RDB 持久化状态等。
   • 客户端层面：连接池状态、请求延迟、超时次数等。
   • 操作系统层面：CPU、内存、磁盘 I/O、网络 I/O 等。
   • 集群层面：节点状态、主从复制延迟、集群分片状态等。

   常用的监控工具有 Redis 自带的 INFO 命令、redis-cli 工具、redis-stat 工具，以及一些开源的监控平台，如 Prometheus、Grafana 等。老李他们公司用的是 Prometheus + Grafana，监控数据一目了然。

2. 数据分析，定位瓶颈：有了监控数据，接下来就是分析数据，找出性能瓶颈。这一步很关键，需要我们对 Redis 的原理和常见问题有深入的了解。一般来说，Redis 集群的性能瓶颈主要有以下几种：

   • CPU 瓶颈：
     • 单线程模型：Redis 的单线程模型在处理大量短连接、小数据量的请求时非常高效，但如果遇到耗时较长的命令（如 KEYS *、SORT 等），或者需要进行大量计算的命令（如 Lua 脚本），就会阻塞其他请求，导致 CPU 利用率不高，但性能却上不去。
     • 持久化操作：AOF 和 RDB 持久化操作都需要 fork 子进程，如果内存使用量较大，fork 操作可能会非常耗时，导致 Redis 阻塞。
     • 集群操作：集群模式下，节点之间需要进行数据同步、故障转移等操作，这些操作也会消耗 CPU 资源。
   • 内存瓶颈：
     • 数据量过大：如果 Redis 存储的数据量超过了物理内存大小，就会触发 swap 操作，导致性能急剧下降。
     • 内存碎片：频繁的写入和删除操作会导致内存碎片，降低内存利用率，影响性能。
     • 过期 key 清理：Redis 会定期清理过期的 key，如果过期 key 数量过多，也会占用 CPU 资源。
   • 网络瓶颈：
     • 带宽不足：如果网络带宽不足，就会导致请求和响应的延迟增加，影响性能。
     • 连接数过多：如果客户端连接数过多，超过了 Redis 的最大连接数限制，就会导致新的连接无法建立。
   • 客户端瓶颈：
     • 连接池配置不合理：如果连接池配置过小，就会导致客户端频繁地创建和销毁连接，增加开销；如果连接池配置过大，又会占用过多的资源。
     • 请求超时设置不合理：如果请求超时时间设置过短，就会导致请求频繁超时；如果设置过长，又会导致客户端长时间等待，影响用户体验。
     • Pipeline 使用不当：Pipeline 可以批量发送请求，减少网络开销，但如果使用不当，也可能导致性能问题。

3. 对症下药，解决问题：找到瓶颈之后，就可以针对性地进行优化了。具体的优化方法，咱们在后面的案例中详细讲解。

实战演练：抽丝剥茧，逐个击破

回到老李的案例。我们通过 Prometheus + Grafana 监控平台，发现以下几个问题：

1. 慢查询激增：大促期间，慢查询数量比平时增加了几十倍，平均响应时间超过了 1 秒。
2. CPU 使用率飙升：Redis 节点的 CPU 使用率接近 100%，但 QPS 并没有明显提升。
3. 连接数异常：Redis 连接数接近上限，客户端出现大量连接超时。
4. 主从复制延迟：主从节点之间的数据同步延迟达到了几秒甚至几十秒。

针对以上问题，我们逐个分析，逐个击破。

1. 慢查询优化：揪出“害群之马”

慢查询是 Redis 性能的“杀手”之一。我们要做的，就是把这些“害群之马”揪出来，干掉它们！

Redis 提供了 slowlog 命令，可以查看最近的慢查询记录。通过 slowlog get 命令，我们可以获取慢查询的详细信息，包括执行时间、命令内容、客户端地址等。

# 获取最近 10 条慢查询记录
redis-cli slowlog get 10

通过分析慢查询日志，我们发现，大部分慢查询都是由于使用了 KEYS * 命令导致的。KEYS * 命令会遍历所有 key，在 key 数量较多的情况下，非常耗时，严重影响 Redis 性能。

解决方案：

• 禁用 KEYS 命令：在生产环境中，强烈建议禁用 KEYS 命令，或者使用 SCAN 命令代替。SCAN 命令可以分批次遍历 key，避免阻塞 Redis。
• 优化业务逻辑：从业务层面进行优化，避免使用 KEYS 命令。例如，可以使用 Redis 的集合（Set）或有序集合（Sorted Set）来存储特定类型的 key，然后使用 SMEMBERS 或 ZRANGE 命令来获取数据。

老李他们公司就是因为在商品搜索功能中使用了 KEYS * 来查找符合条件的商品 key，导致了大量的慢查询。我们建议他们使用 Redis 的搜索功能（RediSearch）或者将商品信息存储到 Elasticsearch 中，彻底解决了这个问题。

2. CPU 优化：合理配置，避免阻塞

CPU 使用率飙升，说明 Redis 忙不过来了。我们要做的，就是减轻 Redis 的负担，让它更高效地工作。

通过分析 CPU 使用情况，我们发现，CPU 主要消耗在以下几个方面：

• Lua 脚本执行：大促期间，为了实现一些复杂的业务逻辑，开发人员使用了大量的 Lua 脚本。这些 Lua 脚本中包含了一些耗时的操作，导致 CPU 使用率飙升。
• AOF 持久化：为了保证数据安全，Redis 开启了 AOF 持久化，并且配置了 appendfsync always 策略。这个策略下，每次写入操作都需要同步到磁盘，导致 CPU 负载较高。

解决方案：

• 优化 Lua 脚本：
  • 避免在 Lua 脚本中执行耗时操作：例如，避免在 Lua 脚本中使用循环、嵌套查询等。
  • 将 Lua 脚本拆分为多个小脚本：将复杂的 Lua 脚本拆分为多个小脚本，减少单个脚本的执行时间。
  • 使用 Lua 脚本的预编译功能：Redis 支持 Lua 脚本的预编译功能，可以将 Lua 脚本预先编译成字节码，减少执行时间。
• 调整 AOF 持久化策略：
  • 修改 appendfsync 策略：将 appendfsync always 修改为 appendfsync everysec 或者 appendfsync no。everysec 策略每秒同步一次数据，no 策略则由操作系统决定何时同步数据。这两种策略都可以降低 CPU 负载，但会牺牲一定的数据安全性。
  • 开启 AOF 重写：AOF 文件会随着写入操作的增加而不断增大，导致性能下降。Redis 提供了 AOF 重写功能，可以定期对 AOF 文件进行重写，减少文件大小，提高性能。

老李他们公司最终将 Lua 脚本进行了拆分和优化，并将 AOF 持久化策略修改为 appendfsync everysec，CPU 使用率明显下降。

3. 连接数优化：合理配置，避免拒绝

Redis 连接数接近上限，说明客户端连接太多了。我们要做的，就是优化客户端连接池配置，避免 Redis 拒绝新的连接。

解决方案：

• 调整 Redis 的 maxclients 参数：maxclients 参数用于设置 Redis 的最大连接数。我们可以根据实际情况，适当增大 maxclients 的值。但是，maxclients 的值不能设置过大，否则会占用过多的系统资源。
• 优化客户端连接池配置：
  • 增大连接池的最大连接数：如果连接池的最大连接数过小，就会导致客户端频繁地创建和销毁连接，增加开销。我们可以适当增大连接池的最大连接数。
  • 设置合理的连接超时时间：如果连接超时时间设置过短，就会导致客户端频繁超时；如果设置过长，又会导致客户端长时间等待，影响用户体验。我们需要根据实际情况，设置合理的连接超时时间。
  • 启用连接池的健康检查：连接池的健康检查可以定期检查连接的可用性，及时移除不可用的连接，保证连接池的健康。

老李他们公司最终调整了 Redis 的 maxclients 参数，并优化了客户端连接池配置，解决了连接数异常的问题。

4. 主从复制优化：保证数据同步，避免延迟

主从复制延迟过大，会导致数据不一致，影响业务。我们要做的，就是保证主从节点之间的数据同步，避免延迟。

解决方案：

• 优化网络环境：
  • 保证主从节点之间的网络带宽：如果网络带宽不足，就会导致数据同步延迟增加。我们需要保证主从节点之间的网络带宽充足。
  • 减少网络延迟：如果主从节点之间的网络延迟较大，也会导致数据同步延迟增加。我们可以将主从节点部署在同一个机房或者同一个可用区，减少网络延迟。
• 调整 Redis 的 repl-backlog-size 参数：repl-backlog-size 参数用于设置 Redis 复制积压缓冲区的大小。如果复制积压缓冲区过小，就会导致主从节点之间的数据同步中断，需要重新进行全量同步。我们可以适当增大 repl-backlog-size 的值。
• 开启 Redis 的 min-slaves-to-write 和 min-slaves-max-lag 参数：这两个参数可以用于设置 Redis 主节点在进行写操作时，至少需要同步数据的从节点数量和最大延迟时间。如果从节点的数量不足或者延迟时间过长，主节点就会拒绝写操作，保证数据的一致性。

老李他们公司最终优化了网络环境，并调整了 Redis 的相关参数，解决了主从复制延迟的问题。

总结：持续监控，持续优化

经过一系列的优化，老李他们公司的 Redis 集群终于恢复了正常，扛住了大促的流量高峰。老李也终于松了一口气，笑着对我说：“老王，多亏了你啊！这次真是学到了不少东西！”

其实，Redis 集群的性能调优是一个持续的过程，没有一劳永逸的解决方案。我们需要不断地监控 Redis 集群的运行状态，分析数据，找出瓶颈，进行优化。只有这样，才能保证 Redis 集群的稳定性和高性能。

希望今天的分享对大家有所帮助。如果你在 Redis 集群的性能调优方面有什么问题或者经验，欢迎在评论区留言，咱们一起交流学习！

记住，性能调优，永无止境！