【Redis 故障排查】「连接失败问题排查和解决」带你深入分析一下 Redis 阻塞原因以及问题排查方案指南
Redis 阻塞原因以及问题排查
尽管我们在日常工作中经常使用 Redis 作为数据库的缓存，以大大减轻数据库压力并提升用户体验，但 Redis 也可能出现阻塞情况，导致整个系统变慢，进而影响用户体验。
因此，在面对 Redis 阻塞的情况下，我们可以从以下七个方面进行全面的分析，以确定造成 Redis 阻塞的具体原因。
慢查询
因为 Redis 是单线程的，所以如果出现大量的慢查询，可能会导致 redis-server 阻塞，可以通过 slowlog get n 获取慢日志查看详细情况，如下所示。
查看慢查询配置
在 Redis 中，慢查询日志是用来记录执行时间超过阈值的命令的。可以通过配置慢查询相关的参数来控制记录的条件和日志的保存位置。
可以使用CONFIG GET slowlog-*命令来查看现有的 Redis 配置。这个命令用于获取 Redis 慢查询日志的相关配置。
使用CONFIG GET slowlog-*命令可以获取与慢查询日志有关的配置项及其对应的值。该命令会返回一个列表，列表中包含了以slowlog-*开头的配置项的名称和对应的值。
参数介绍分析
slowlog-log-slower-than是 Redis 的一个配置项，用于设置慢查询日志的阈值。它表示执行时间超过该阈值的命令会被记录到慢查询日志中。在您提供的示例中，slowlog-log-slower-than被配置为 10000，单位是微秒（μs），即 10 毫秒。
这意味着当一个命令的执行时间超过 10 毫秒时，它将被 Redis 记录到慢查询日志中。
slowlog-max-len是 Redis 的另一个配置项，表示慢查询日志的最大长度。它决定了慢查询日志中可以保存的记录数量。在您提供的示例中，slowlog-max-len被配置为 128，即最多保存 128 条慢查询日志记录。
当慢查询日志中的记录达到最大长度后，新的慢查询会替换掉最旧的记录。
通过配置这些参数，您可以根据实际需求，灵活地设置 Redis 的慢查询日志的阈值和最大长度。这样可以帮助您及时发现影响性能的慢查询操作，并对其进行优化。
注意，执行
CONFIG GET slowlog-*命令需要具备访问 Redis 配置的权限。如果您没有对应的权限，将无法执行该命令。
bigkey 大对象
大对象（bigkey）可能导致以下问题：
内存空间不均衡：在 Redis Cluster 中，大对象会导致节点的内存使用不均衡。一些节点可能会存储更多的大对象，而另一些节点可能只保存较小的键值对，从而导致内存分配不平衡。
超时阻塞：由于 Redis 是单线程的，处理大对象会占用更多的处理时间，可能导致其他操作的阻塞。如果一个大对象的存取操作耗时较长，那么有可能会造成其他请求的延迟或阻塞。
网络阻塞：获取大对象时会产生大量网络流量，尤其在分布式环境中。如果每次获取大对象的操作都会涉及传输大量数据，可能会导致网络拥塞或延迟。
性能问题影响
如果一个大对象几乎不会被访问到，那么对性能的影响相对较小，主要存在内存空间不均衡的问题。但是，如果一个大对象是一个热点 key（频繁访问），它将对系统的性能产生重大的影响。
拆分键值
需要根据实际情况来评估和管理大对象，如果一个大对象经常被访问，可能需要将其分解成多个小的键值对，或者使用其他数据结构来存储和处理该对象，以减轻 Redis 的负担。
集群分片
同样，可以考虑使用 Redis 的分片、集群等功能来均衡内存使用，并增加系统的扩展性和容错性。
可以通过redis-cli -h {ip} -p {port} bigkeys发现大对象。
swap 热交换
前提介绍
首先，Redis 在版本 3.0 之后，从内部代码中删除了对交换空间（swap space）的支持和依赖。因此，Redis 3.0 及更高版本不再使用交换空间进行内存交换。
在早期版本的 Redis 中，如果 Redis 实例的内存超过可用最大内存限制，操作系统会使用交换空间进行内存交换。然而，这种行为被发现会导致严重的性能下降，并且将 Redis 带入不稳定的状态，因此在 Redis 3.0 中已经放弃了对交换空间的依赖。
识别 Redis 进程号
根据进程号查询内存交换信息
如果交换量都是 0kb 或者个别的 4kb 都是正常现象
官方建议
Redis 官方建议用户合理配置最大可用内存，并确保 Redis 实例具有足够的可用内存来容纳数据和处理操作，以避免内存交换问题。这样做可以提高 Redis 的性能和稳定性，确保良好的的用户体验。
我们可以使用指标"used_memory"来了解 Redis 当前使用的内存情况。通过监测 used_memory 的值，可以确定 Redis 是否接近或超过了最大可用内存的阈值，从而及时做出相应的调整。
为了避免内存交换问题，需要合理配置 Redis 的内存限制，并确保 Redis 实例有足够的可用内存来容纳数据和处理操作。这可以通过监控内存使用情况、调整 Redis 的缓存策略、设置合理的最大内存限制等手段来实现。
分布式 Redis 集群
为了提高性能和避免内存交换问题，建议单独部署 Redis 实例或使用分布式 Redis 集群，并且配置足够的内存，以便满足实际需求和预防潜在的性能问题。
Fork 子进程
当 Redis 执行持久化操作（RDB 生成或 AOF 重写）时，会使用 fork 系统调用创建一个子进程来完成工作。在执行 fork 操作时，子进程会复制父进程的内存空间，包括所有数据集的内存表，这会导致 fork 操作的耗时与内存量（数据集）相关。
根据经验，每 GB 内存的 fork 操作耗时大约在 20 毫秒左右。因此，为了避免长时间的阻塞，需要严格控制每个 Redis 实例可使用的最大内存在 10GB 以内，以减少 fork 操作的执行时间。
查看对应 INFO STATS 命令分析
可以通过使用 Redis 的 INFO STATS 命令来获取 lastest_fork_usec 指标，它表示 Redis 最近一次 fork 操作的耗时。通过监控这个指标，可以了解每次 fork 操作的耗时情况，并根据需要采取适当的措施，如降低 fork 操作的频率或调整内存配置，以减少阻塞情况的发生。
总之，了解 fork 操作对性能的影响以及控制内存使用是重要的，以确保 Redis 实例的稳定性和良好的性能。
AOF 刷盘阻塞
当 Redis 开启 AOF（Append-Only File）持久化的同时，文件刷盘操作通常每秒执行一次。但是，当硬盘压力过大时，执行fsync操作需要等待写入完成，这可能会导致延迟。
INFO PERSISTENCE
要查看 Redis 日志或使用INFO PERSISTENCE命令可以获取到aof_delayed_fsync指标，它表示延迟执行的fsync操作的次数。
Redis 的输入/输出缓冲区也可能导致阻塞
当 Redis 无法及时处理写入数据或无法将数据及时发送到磁盘，输入/输出缓冲区可能会增长，并导致阻塞。为了避免这种情况，可以根据实际情况调整 Redis 的相关配置参数，如client-output-buffer-limit和aof-rewrite-incremental-fsync等，以控制输入/输出缓冲区的大小和行为。
综上所述，理解和监控aof_delayed_fsync指标以及适时调整 Redis 的相关配置参数，可以帮助应对可能导致阻塞的硬盘压力和输入/输出缓冲区的问题。
输入缓冲区
要查看输入缓冲区的总容量(qbuf)和剩余容量(qbuf-free)，你可以使用 Redis 的INFO MEMORY命令。
在 Redis 客户端中，执行以下步骤：
使用
INFO MEMORY命令获取内存使用情况的相关信息。
在命令输出中，你会看到关于内存使用的详细信息，包括输入缓冲区的总容量和剩余容量。
参数介绍
used_memory字段表示 Redis 使用的总内存。used_memory_human字段表示 Redis 使用的总内存的人类可读形式。used_memory_rss字段表示 Redis 的物理内存占用。used_memory_rss_human字段表示 Redis 的物理内存占用的人类可读形式。used_memory_peak字段表示 Redis 使用的内存峰值。used_memory_peak_human字段表示 Redis 使用的内存峰值的人类可读形式。注意：
qbuf和qbuf-free字段在这个输出中可能不显式地列出，但是你可以根据上面提到的字段来推断 Redis 的输入缓冲区容量。如果used_memory_peak字段和used_memory_peak_human字段的值为 0，那么说明没有分配查询缓冲区，每次只能处理一个命令。
redis 为每个客户端分配了输入缓冲区，会将客户端发送命令临时保存，然后取出来执行。
qbuf 表示总容量（0 表示没有分配查询缓冲区）
qbuf-free 表示剩余容量（0 表示没有剩余空间）；
大小不能超过 1G，当大小超过 1G 时会将客户端自动关闭，输入缓冲区不受 maxmemory 限制。
Blocked_Clients
当大量的 key 进入输入缓冲区且无法被消费时，即可造成 redis 阻塞；通过 client list 命令可定位发生阻塞的客户端；通过 info clients 命令的 blocked_clients 参数可以查看到当前阻塞的命令。
输出缓冲区
redis-server 端实现的一个读取缓冲区，redis-server 在接收到客户端的请求后，把获取结果写入到 client buffer 中，而不是直接发送给客户端。从而可以继续处理客户端的其他请求，这样异步处理方式使 redis-server 不会因为网络原因阻塞其他请求的处理。
网络问题
连接拒绝
当出现网络闪断或 Redis 连接拒绝时，你可以使用以下方法来解决问题：
网络闪断：
检查网络连接是否正常。确保网络连接稳定，没有断开或中断。
检查网络带宽是否耗尽。如果网络带宽达到极限，可能会导致闪断。你可以联系网络管理员或提供商以解决带宽问题。
Redis 连接拒绝：
确认 maxclients 设置。在 Redis 配置文件(redis.conf)中，找到
maxclients设置项，确保其值足够大以容纳你的并发连接数。你可以通过修改配置文件来增加 maxclients 的值。检查已建立的连接数。使用 Redis 的
INFO STATS命令可以获取有关连接的统计信息。关注rejected_connections字段的值，如果该值增加，说明已经达到了 maxclients 的限制。你可以通过增加 maxclients 或优化现有连接以减少连接数来解决此问题。
连接溢出
进程限制
进程可打开的最大文件数控制(ulimit -n)是限制系统中同时存在的文件描述符数量的设置。对于 Redis 来说，高并发情况下需要处理大量的连接，因此需要增大该值。
增大 Redis 连接
建议增大ulimit -n的值来满足 Redis 的连接需求。你可以通过修改系统的配置文件来设置该值。例如，在 Linux 系统中，可以编辑/etc/security/limits.conf文件或/etc/sysctl.conf文件，并添加如下配置来增大该值：
然后重启系统或使用sysctl -p命令加载配置。这样可以增大系统对打开文件数量的限制，为 Redis 提供足够的文件描述符。
backlog 队列溢出
backlog 队列溢出是指由于系统对于特定端口的 TCP 连接使用的 backlog 队列溢出，导致连接无法进入队列，造成连接丢失。
你可以通过定时执行netstat -s | grep overflowed命令来统计 backlog 队列溢出情况。如果溢出的数量较多，可以考虑增加 backlog 队列的大小。
参数来增大 backlog 队列
在 Redis 中，默认 backlog 队列大小为 511，而系统默认的 backlog 队列大小为 128。你可以通过修改 Redis 的配置文件(redis.conf)中的tcp-backlog参数来增大 backlog 队列的大小。例如，将其设置为 1024：
网络延迟
网络延迟是指数据在网络中的传输所需要的时间。若要优化网络延迟，你可以考虑以下几个方面：
确保网络连接的稳定性。检查网络设备和链路，确保没有断开、抖动或故障。可以联系网络管理员或服务提供商来解决网络问题。
优化 Redis 的网络配置。可以调整 Redis 的
timeout参数，增加客户端与 Redis 服务器之间的超时时间，以适应网络延迟的情况。默认超时时间为 0，即永不超时。你可以根据实际情况适度增加这个时间。使用合适的网络协议及相关优化技术。选择较低的网络协议延迟、使用 TCP/IP 的 Nagle 算法或开启 TCP_NODELAY 选项来减少延迟等方式，都可以帮助优化网络延迟。
开启 TCP_NODELAY
TCP_NODELAY是一个 TCP 套接字选项，用于控制是否启用 Nagle 算法。Nagle 算法通过将数据缓存一小段时间，合并多个小数据包一起发送，以减少网络传输中的报文数量，提升网络吞吐量和效率。但是这种优化策略会增加网络传输的延迟，特别是对于需要实时响应的应用来说，Nagle 算法可能会导致延迟较高的现象。
当启用TCP_NODELAY选项时，套接字禁用了 Nagle 算法，数据会立即发送，并且不会缓冲等待合并。这可以降低延迟，但会增加网络传输的负载。
在 Redis 中，默认情况下TCP_NODELAY是被禁用的，这意味着 Nagle 算法是启用的，适用于大部分情况。然而，如果你的应用对实时性要求较高，可以考虑启用TCP_NODELAY来减少延迟。
可以通过 Redis 的配置文件(redis.conf)中的tcp-keepalive参数来启用TCP_NODELAY。将其设置为 1 以启用该选项：
需要注意的是，启用TCP_NODELAY可能会增加网络带宽的负载，特别是在高并发环境中使用时，可能会影响性能。因此，在启用该选项之前，应该仔细评估你的应用的实际需求，并进行相应的性能测试。
彩蛋介绍
在这里，我向大家推荐一本关于 JVM 优化和调优的实战系列书籍，《深入浅出 Java 虚拟机 — JVM 原理与实战》。这本书是最新出版的，内容涵盖了与我们当前工作和开发实例密切相关的技术和实战案例。通过学习这本书，我们可以深入了解 Java 虚拟机的原理，并通过实践掌握优化和调优的技巧。我诚挚地推荐这本书给大家，相信它将为我们的工作和技术发展带来巨大的收益。希望大家能够抽出时间多多学习一下这本宝贵的资料。
🏆 InfoQ写作平台-签约作者 🏆 2020-03-25 加入
【个人简介】酷爱计算机科学、醉心编程技术、喜爱健身运动、热衷悬疑推理的“极客达人” 【技术格言】任何足够先进的技术都与魔法无异 【技术范畴】Java领域、Spring生态、MySQL专项、微服务/分布式体系和算法设计等
评论