企业官网建设流程全解析

Redis用得好好的，突然某个查询延迟从1毫秒飙到几十秒，所有请求跟着一起堵死。做技术这几年，这类“灵异事件”没少见，追到最后绝大多数都指向同一个疑点：主线程被阻塞了。Redis是单线程模型，正常情况下主线程一直畅快地在事件循环里跑，一旦某个环节让它多等，所有客户端请求就得排队。哪怕每个请求本身只需要0.1毫秒，几百个请求等上几秒，延迟直接爆炸。

阻塞是一个结果，但引发阻塞的原因五花八门：一条大Key查询、一次RDB快照、一段fsync、甚至一个慢客户端，都可能在特定场景下把主线程卡住。这篇内容想做的，是把实际排查Redis阻塞问题的完整思路和方法理清楚——从命令层、持久化层、系统层到网络层，每一类都给出定位手段和规避方案，你在线上撞到这类问题时可以不抓瞎。内容偏实战，默认你已经有Redis的基本使用经验，但即使刚入门，跟着定位思路走一遍，也会对Redis底层模型有更深的理解。

1. 先建立阻塞的整体认知：单线程模型下到底谁在“卡脖子”

1.1 单线程模型决定了阻塞的放大效应

Redis内部最核心的执行模型，是一个基于事件循环的单线程处理器。所有客户端命令在同一个线程里被依次解析、执行、返回结果。这跟MySQL那种多线程并发模型完全不同，好处是省去了锁竞争和上下文切换的开销，单实例可以做到每秒十万级别的读写；坏处是，任何一步变慢都会直接影响全局。

打个比方，这就像高速收费站只有一个人工窗口。正常情况下每辆车通过只要1秒，排队车再多也能一秒一个消化掉。但如果有辆车付钱付了10分钟，后面的车全部卡住，哪怕每辆车本身只需要1秒。Redis也一样，一条命令阻塞10秒，这10秒里所有客户端的读写请求全部在原地等待。

很多第一次排查Redis问题的朋友会犯一个错误：看到延迟变高就去查客户端、查网络，折腾半天才发现是Redis主线程被某个后台操作卡住了。所以，建立“阻塞优先查主线程”的意识很重要。Redis延迟高的所有问题里，有相当大一部分最终都能追溯到主线程的某次停顿。

1.2 按阻塞来源给问题分层

排查阻塞问题不要凭感觉瞎猜，我的习惯是先给问题分层。因为每一层对应的指标、工具、修复方式完全不同，混在一起查效率极低。

我一般把Redis阻塞来源分成四层：

• 命令执行层：某条命令本身复杂度太高，或者命中了超大的数据结构，导致执行时间过长。
• 持久化层：RDB快照、AOF重写、AOF刷盘等后台任务，在fork或fsync时阻塞主线程。
• 系统资源层：内存被换出到磁盘、CPU被抢占、NUMA跨节点访问等，属于宿主机层面的拖累。
• 网络与客户端层：慢客户端不读取结果导致输出缓冲区积压，或主从复制同步时触发阻塞。

下面我逐个深入拆解，每一类都会给出具体场景、定位命令和解法。

2. 命令执行层的阻塞：大Key与“危险命令”是第一大坑

2.1 KEYS命令与全量遍历的惨痛教训

命令层面的阻塞，最常见的就是在生产环境执行了KEYS命令。这个命令会遍历整个键空间，匹配模式并返回所有符合条件的Key。表面上看很直观，但它的时间复杂度是O(N)，N是实例中所有Key的总数。一旦数据量上了百万级别，这条命令就会让Redis主线程陷入全程遍历，期间所有其他命令全部排队。

我印象很深刻的一次事故：某电商项目的缓存实例里有800多万个Key，一位同事为了查一个前缀的键，直接执行了KEYS user:*。这条命令跑了整整6秒，期间所有业务请求全部超时，商品详情接口的延迟从8毫秒飙升到15秒。事后看慢日志，那条命令的执行时间位列榜首，代价是整条业务链路跟着遭殃。

这个坑的解法非常简单，分两个层面：

• 搜索类需求：千万不要用KEYS，改用SCAN命令。SCAN通过游标分批迭代，每次返回少量Key，不会阻塞主线程。
• 预防机制：在Redis配置里直接禁止KEYS。有些团队通过改名的方式，把KEYS重命名成不可用的名字；更稳妥的办法是在代理层拦截，或者在云数据库的管控面配置命令禁用。生产环境建议把KEYS、FLUSHALL、FLUSHDB等危险命令一律禁掉。

SCAN的正确使用方式是这样的：

# 第一次调用传入游标0，返回下一轮游标 SCAN 0 MATCH user:* COUNT 1000 # 拿到返回的游标继续迭代，直到游标回到0 SCAN 15320 MATCH user:* COUNT 1000

注意：SCAN虽然不阻塞，但每次迭代返回的Key数量并不严格等于COUNT，它是一个提示值。所以循环里要处理游标回到0才算遍历完成，不要设置固定迭代次数。

2.2 大Key操作：隐藏的“性能黑洞”

比KEYS更隐蔽的，是大Key上的普通命令。这里说的“大Key”不是指单条数据量大，而是指一个Key内部聚合了大量元素。比如一个List里有几十万元素，一个Hash里有几万个字段，一个Set里有几百万个成员。对这些大Key执行LRANGE 0 -1、HGETALL、SMEMBERS这类全量操作，时间复杂度同样很高，而且还会一次性产生巨大的网络包。

举个例子，某个社交项目把用户关系存在一个Set里，一个头部用户的好友数达到500万。某次需要给这个用户做全量好友推送，有人直接执行了SMEMBERS user_friends_1024，结果命令执行了3秒多，返回的数据接近200MB。不仅主线程卡住，网络出口也被撑爆，关联的多个服务一起异常。

处理这类问题，核心思路是“拆分”和“分批”：

• 集合类数据操作：用SSCAN、HSCAN、ZSCAN代替全量获取，每次都只取一部分。
• 列表类数据：用LRANGE key 0 N-1限制范围，不要一次性取完。
• 业务设计：如果发现Key的元素规模可能持续增长，需要在上游就做容量规划，比如把好友关系按用户ID取模拆成多个Key。

另外推荐一个排查利器：Redis自带的redis-cli --bigkeys，它会用SCAN遍历整个实例，找出每种数据类型里最大的Key，并报告它的字节数和元素个数。这个工具有个特点，在遍历过程中每扫描一定数量会输出一次进度，不会把实例卡死，适合在低峰期跑。

2.3 慢查询与热Key：放大的“排队效应”

命令层的另一个典型问题，是普通命令本身不慢，但某个热点Key被大量并发访问，导致排队时间变长。Redis里所有命令都是单线程执行的，如果一个Key每秒钟被请求几万次，哪怕每条命令只需要0.1毫秒，这些请求也会在事件循环里排队。排在后面的请求延迟会迅速上升，表现就是该Key的访问延迟奇高，但Redis自身的CPU占用也到了高位。

还有一个容易忽略的情况：MGET虽然批量读，但如果其中一个Key是大Key，MGET会把这个大Key的全部数据一起返回，造成的阻塞和单条大Key命令是一样的。

定位这类问题，核心看慢日志。Redis的慢日志记录的是命令执行时间超过阈值的记录，默认阈值为10毫秒，可以通过参数调整：

# 查看当前慢日志阈值 CONFIG GET slowlog-log-slower-than # 调整为100毫秒（单位微秒） CONFIG SET slowlog-log-slower-than 100000 # 查看最近10条慢日志 SLOWLOG GET 10 # 查看慢日志数量 SLOWLOG LEN

慢日志里能看到每条慢命令的执行时间戳、耗时、命令参数和客户端IP。排查时我通常会重点看耗时最高的那几条，基本能锁定是哪个Key、哪条命令在搞事情。

热Key的排查方式，一是用redis-cli --hotkeys（需要开启maxmemory-policy为LFU策略），二是在低峰期用MONITOR命令短暂观察。MONITOR会输出所有实时命令，但注意它本身也有性能开销，生产环境不要长时间开着。

# 10秒内观察热点命令 timeout 10 redis-cli MONITOR | awk '{print $4}' | sort | uniq -c | sort -rn | head -20

顺带提一句，命令层阻塞的修复不一定要改代码。如果只是临时解决，可以先把大Key迁移到独立的Redis实例上隔离风险，再从容地做数据拆分和代码改造。

3. 持久化层的阻塞：fork、RDB快照与AOF刷盘

3.1 fork子进程耗时：内存越大，风险越高

Redis做RDB快照时采用了经典的操作系统机制——fork。主进程fork出一个子进程，子进程负责把内存数据写入磁盘，主进程继续处理请求。关键在这个fork本身：它要把当前进程的页表完整复制一份。如果Redis实例的内存达到几十GB，页表本身就很大，复制页表的时间会非常可观。

这个操作有多慢？某个项目实例内存12GB，做过一次统计，fork耗时约760毫秒。在这760毫秒里，主线程是完全暂停的，所有请求全部排队。更麻烦的是，fork之后主进程还在持续接收写请求，触发了Copy-On-Write机制，那些被修改的内存页需要额外分配和复制，内存占用会在短时间内猛增。

看fork耗时，直接看INFO stats里的指标：

INFO stats | grep latest_fork_usec # latest_fork_usec:760512

这个值单位是微秒，760512微秒就是760毫秒。在监控系统里我一般会加上一条告警：latest_fork_usec > 300000（即300毫秒）时触发警告，这个阈值可以根据自己实例的内存规模调整。

缓解fork阻塞的思路有这几条：

• 控制单实例内存：不要让单个Redis实例内存无节制增长。业界通常建议单实例内存不要超过20GB，超过之后fork成本直线上升。
• 错峰持久化：如果使用了主从架构，可以选择在从节点上做RDB持久化备份，主节点关闭自动RDB，这样主节点不触发fork。
• 调整RDB触发频率：默认的save 900 1 300 10 60 10000在写入频繁的场景会频繁触发bgsave，需要根据业务调整。比如交易系统写压力大，可以改成更保守的配置，减少fork次数。

3.2 AOF刷盘阻塞：everysec不是银弹

AOF持久化有三种刷盘策略：always、everysec、no。always每次写入都调用fsync，安全性最高但性能损耗大；no交给操作系统决定刷盘时机，性能好但丢失数据风险高；everysec是折中方案，每秒刷一次盘。

很多运维同学以为everysec只有一个阻塞点，就是每秒调用fsync的那一下。但实际上，AOF还有一个更隐蔽的阻塞点——AOF重写。当AOF文件增长到一定阈值，Redis会触发bgrewriteaof，这个操作同样需要fork子进程，而且父子进程同时写AOF，会产生大量内存拷贝。

在everysec模式下，还会出现一种被称为“AOF阻塞”的特殊情况。如果某一次fsync执行时间特别长（比如磁盘I/O阻塞），Redis会等待该次fsync完成后再继续处理下一批写命令。文档里通常说“每秒刷一次”，但极端情况下，一次刷盘卡住几秒，主线程也就会卡住几秒。

我之前排查过一个案例：某项目把Redis部署在一台共享云主机上，同一块磁盘还有其他数据库在疯狂写入，导致磁盘I/O饱和度极高。Redis的AOF fsync每次需要2到3秒才能完成，主线程频繁阻塞，业务侧看到的是每隔几秒就会出现一次秒级延迟尖刺。

排查这类问题，除了看INFO persistence里的aof_last_write_status，还要看系统层面的磁盘指标：

# 查看磁盘I/O等待 iostat -x 1 # 查看Redis所在进程的I/O等待 pidstat -d 1 | grep redis

如果确认是磁盘I/O导致，调整方向是给Redis用独立的磁盘或者性能更好的SSD，磁盘繁忙时不要跟其他重I/O组件共用。另外，如果业务对AOF的要求没那么高，可以考虑关闭AOF或者把appendfsync调成no。

3.3 透明大页：一个容易被忽视的“元凶”

透明大页（Transparent Huge Pages，THP）是Linux内核的一个特性，默认在多数发行版上是开启的。它对很多应用是透明的优化，但对Redis却是个不小的坑。

原因是THP与Copy-On-Write机制相互作用。Redis在fork之后，如果某个内存页被修改，需要触发COW流程。THP把连续的普通页合并成2MB的大页，COW时需要为整个2MB大页重新分配内存。这个分配在高并发写入场景下会变得非常慢，甚至出现“fork后写延迟暴增”的现象。

实际表现是：某一次bgsave之后，Redis的写入延迟突然从1毫秒跳到几百毫秒，持续数秒。不看THP的话，你可能会怀疑是fork本身的问题，但fork耗时明明正常。关闭THP之后，这个问题立刻消失。

关闭方法：

# 查看当前THP状态 cat /sys/kernel/mm/transparent_hugepage/enabled # 输出 [always] madvise never，表示当前是启用状态 # 关闭THP echo never > /sys/kernel/mm/transparent_hugepage/enabled # 将该设置写入开机启动 # 在 /etc/rc.local 里加入： # echo never > /sys/kernel/mm/transparent_hugepage/enabled

Redis官方文档也明确建议关闭THP。这算是我排查阻塞问题时的“固定检查项”，遇到莫名延迟尖刺，先看一眼THP状态，能省掉很多折腾时间。

4. 系统资源层的阻塞：内存换页与CPU的隐形拖累

4.1 内存被换出到磁盘：致命swap

这是最凶险、也最容易误判的一类问题。Redis本质上是内存数据库，所有数据都在内存里。如果操作系统把Redis的一部分内存页换出到swap分区，那么Redis下次访问这些页时，需要从磁盘读回内存，这个过程叫swap in。一次swap in的耗时通常在几十到几百毫秒，而正常情况下内存访问延迟是纳秒级别，差距巨大。

更麻烦的是，swap通常是整个进程的内存页被分散换出。也就是说，不是某一次访问慢，而是会有大量随机访问都变慢。对单线程的Redis来说，这意味着所有命令都会被拖慢，整体吞吐量断崖式下跌。

有个运维事故很典型：一台服务器上同时部署了Redis和多个Java应用，Java应用占了大量内存，操作系统在内存压力下把Redis的部分页换出。结果Redis的读写延迟从不到1毫秒变成平均20毫秒，最高到2秒。排查时top命令能看到RES值远小于内存占用，同时vmstat里的si、so列有持续的换入换出。

# 快速确认是否发生了swap redis-cli INFO memory | grep used_memory # 查看进程的swap占用 top -p <redis_pid> # VIRT和RES的差值如果非常大，说明swap很严重 # 查看系统换页情况 vmstat 1 5 # si 和 so 列持续非零，说明正在发生换页

避免swap的思路优先级从高到低：

• 物理内存要充足：Redis所在服务器的内存容量必须大于Redis的used_memory加上系统其他进程的内存需求，留足余量。
• 监控内存水位：对Redis的used_memory和系统可用内存都设置告警，可用内存低于阈值时提前扩容。
• 配置swap尽量小：有些环境为了容器支持，会启用swap，可以把swap配置成很小的值，比如1GB，让操作系统不至于无脑换出大量Redis页。
• 避免混部：不要在同一台机器上跑多个内存大户，特别是Java这种喜欢占满堆内存的应用。

4.2 CPU调度与NUMA跨节点访问

Redis对CPU调度也比较敏感。如果Redis进程在多个CPU核心之间频繁迁移，CPU缓存会反复失效，性能会下降。虽然这不算严格意义上的“阻塞”，但在高并发场景，缓存未命中带来的延迟损失会被放大，看起来就像Redis变慢了。

更系统性的问题出在NUMA架构。现在的服务器普遍是多路CPU，每个CPU有本地内存。Redis进程如果运行在CPU0，但内存被分配到CPU1的远端内存上，访问时就要跨QUICKPATH互联（QPI）链路，延迟会显著变高。

检查NUMA和CPU绑定的方法：

# 查看Redis进程当前运行在哪个CPU taskset -p <redis_pid> # 查看进程内存分配在哪个NUMA节点 numastat -p <redis_pid>

如果发现R Redis进程的内存分配跨了NUMA节点，可以用numactl调整：

# 启动Redis时绑定CPU和node numactl --cpunodebind=0 --membind=0 redis-server redis.conf # 或者把已有的Redis进程绑定CPU核心 taskset -pc 2,3 <redis_pid>

这里有个细节需要提醒：如果Redis使用了RDB持久化，绑核要慎重。fork出来的子进程如果跟主进程挤在同一个核上，可能会加剧CPU竞争。通常的做法是把主进程绑定核心，子进程让它自由调度，或者给子进程预留独立核心。

4.3 内存淘汰策略引发的连锁反应

当Redis内存达到maxmemory上限后，会根据maxmemory-policy执行淘汰策略。如果配置的是allkeys-lru或volatile-lru，淘汰过程需要随机采样并计算空闲时间，这个过程本身会消耗一定的CPU时间。如果内存长期处于高水位，淘汰操作频繁发生，主线程的负载会明显上升。

更极端的情况是，如果配置了noeviction策略，一旦内存打满，所有写命令都会返回错误。虽然这不阻塞Redis本身，但业务侧如果未做容错，可能造成大量重试，配合其他组件放大故障。

处理建议：

• 合理规划maxmemory：不要依赖淘汰策略来兜底，而是通过容量监控提前告警。
• 淘汰策略选型要认真：缓存场景用allkeys-lru；有明确过期时间的数据用volatile-ttl或volatile-lru。
• 大Key对淘汰的放大效应：如果一个超大Key被选中淘汰，释放内存的过程也会相对耗时。这也是要治理大Key的原因之一。

5. 网络与客户端层的阻塞：慢客户端与主从复制的坑

5.1 慢客户端：输出缓冲区堆积导致全站变慢

这个场景很多人没意识到，但实际生产中遇到不少。Redis的每个客户端连接都有自己的输出缓冲区。如果某个客户端发了一个请求，但一直不去读取返回结果（比如客户端代码卡住了，或者网络链路抖动），Redis往这个连接的缓冲区里写入的数据就无法被消费掉。缓冲区越积越多，最终打满。

当输出缓冲区达到限制之后，Redis为了自我保护，会主动断开这个慢客户端连接。但如果同时有很多慢客户端，Redis主线程需要花时间处理这些断开操作，也会影响正常命令处理。

还有一种情况更隐蔽：某些客户端命令读取了超大返回集，比如HGETALL返回了100MB数据。Redis把100MB数据塞进网络缓冲区需要时间，发送这些数据也会阻塞主线程的事件循环。

查看每个客户端的占用情况：

# 查看所有客户端连接及其输出缓冲区大小 redis-cli CLIENT LIST # 关注输出的中 COL 后面的 oob 字段，单位是字节

针对慢客户端问题，工程上的做法是在配置里限制输出缓冲区：

# 普通客户端的输出缓冲区限制为 256MB，硬限制 512MB，超过持续60秒断开 CONFIG SET client-output-buffer-limit normal 256mb 512mb 60 # 从库客户端的输出缓冲区限制 CONFIG SET client-output-buffer-limit replica 256mb 512mb 60

在业务侧，也要养成一个好习惯：批量获取数据的命令要控制返回量。与其一把梭到底，不如分页取、分批取，这既保护Redis，也保护网络传输。

5.2 主从复制的阻塞链条

主从架构里的阻塞问题比单机版更复杂，因为阻塞会沿着链路传导。先看主节点：当从节点发起全量同步时，主节点需要执行bgsave生成RDB快照，这个操作本身就会阻塞主线程（fork耗时）。再看从节点：从节点收到RDB快照后，需要把它加载到内存，这个过程会丢弃当前所有数据，而且加载期间从节点无法对外提供读服务。

这还只是同步过程。进入增量同步后，如果主节点处理写命令的速度远高于从节点应用命令的速度，从节点的复制积压缓冲区会持续增大。某些版本的Redis在主从网络差的情况下，会因为复制积压持续滞后而反复触发全量同步，进一步放大阻塞。

实际里我排查过一个案例：主从之间网络抖动，从节点断开重连后走了全量同步，主节点fork用了900毫秒，从节点加载RDB用了5秒，这两个时间段内，主节点全部请求超时，从节点读服务全部中断。业务侧看到的就是“Redis服务闪断”。

规避措施比较成熟：

• 合理设置repl-backlog大小：repl-backlog-size默认1MB，对于写量大、容易断连的场景建议调到64MB以上，减少断线重连后的全量同步概率。
• 从节点不参与阻塞传染：从节点可以做REPLICAOF no one快速中止同步，但要评估业务依赖。
• 网络保障：Redis主从间的网络带宽要留足，特别是在写量大、同步频繁的场景。
• 哨兵切换前的准备：如果发生主从切换，新主节点在切换前应该避免执行大Key操作，确保切换后能快速提供服务。

6. 阻塞排查的完整工具链与操作红线

6.1 从Latency监控到主动发现

排查阻塞问题不能全靠“出事之后救火”，更重要的是一套监控预警机制。Redis自带的LATENCY监控体系值得充分利用：

# 设置延迟监控阈值，超过100ms的命令事件会被记录 CONFIG SET latency-monitor-threshold 100 # 实时查看最近记录的延迟事件 LATENCY LATEST # 查看某类事件的详细历史 LATENCY HISTORY command LATENCY HISTORY fork # 查看监控事件种类的统计 LATENCY GRAPH

LATENCY LATEST的输出会告诉你最近有哪些类别的延迟事件，比如command、fork、aof-write、aof-fsync、expire-cycle。不同事件对应着不同的阻塞根因，可以直接把排查方向缩小到某一类。

配合外部监控，我一般会把这些指标纳入告警：

• Redis自身：INFO stats的latest_fork_usec、INFO persistence的rdb_last_bgsave_status和aof_last_wr状态。
• 系统层面：vmstat的si/so、iostat的%util、dmesg的OOM和内存错误日志。
• 业务层面：Redis响应延迟的P99、P999曲线，以及客户端连接数突增。

6.2 常用命令速查与现场处置

定位阶段，我习惯按下面这个顺序快速走一遍：

# 1. 看Redis的实时响应延迟（本机执行） redis-cli --latency # 2. 看当前连接到Redis的所有客户端 redis-cli CLIENT LIST # 3. 看慢日志，找耗时最高的命令 redis-cli SLOWLOG GET 20 # 4. 看fork和持久化状态 redis-cli INFO persistence redis-cli INFO stats | grep latest_fork_usec # 5. 看内存状态 redis-cli INFO memory # 6. 看系统层面是否存在swap和I/O问题 vmstat 1 iostat -x 1

如果问题是突发性的，已经导致线上服务不可用，第一时间不是分析，而是止损。止损手段按风险从低到高排列：

• 隔离大Key：把它迁移到独立的实例，降低对其他业务的影响。
• 临时调整持久化策略：关闭AOF或者改为no刷盘，降低磁盘I/O压力。
• 断开慢客户端：CLIENT KILL <ip:port>可以主动断开异常连接。
• 重启Redis：这是最后手段，会丢失未持久化的数据，需谨慎评估。

6.3 从事故中总结的操作红线

经历过几次Redis阻塞事故后，我把自己常犯的错和踩过的坑整理成一份“红线清单”，在这里分享出来，基本每条都是用真实事故换来的教训：

• 生产环境禁用KEYS命令：这是铁律，没有万一。需要遍历就用SCAN。
• 禁止对大Key执行全量操作：LRANGE 0 -1、HGETALL、SMEMBERS这类操作要经过评审，确有必要就分批。
• 大Key必须治理：新写入的Key要有大小预估机制，定期用--bigkeys扫描，发现就拆。
• 单实例内存不要超过建议值：超过后fork成本、内存碎片、COW开销都会指数上升。
• 关闭透明大页：echo never > /sys/kernel/mm/transparent_hugepage/enabled应该写进所有Redis服务器的初始化脚本。
• 物理内存必须冗余：Redis所在机器不要跑其他内存大户，且swap要控制在最小。
• 监控要提前布置：延迟P99、fork耗时、swap换页指标都要纳入告警，等事故发生后已经晚了。
• 持久化策略要分级：不是所有Redis都值得开AOF，也不是所有Redis都适合RDB。主从架构下可以只在从节点做持久化。

最后再分享一个经验：多数Redis阻塞问题，表面上看起来是“配置问题”或者“运维问题”，但往深里挖，大概率是“设计问题”。大Key是业务建模时没有考虑数据规模，KEYS是接口设计时没有约定查询方式，内存超卖是容量规划没有预期增长。所以排查阻塞问题时，我会把眼光放远一步，不是修完这个故障就结束，而是追到根因，推动业务侧改造数据结构、规范访问模式。故障修的是表面，堵塞的根源在设计里。

排查阻塞这事，工具和命令是死的，但思路可以活学活用。希望这篇文章能帮你建立一套清晰的排查框架，下次再遇到Redis延迟飙升的时候，能少走弯路，快速定位到真正的阻塞点。