如果你写过一段时间 Redis不管是用来做缓存还是扛高并发大概率只是会调GET/SET顶多再了解点expire和集群分片。但一旦线上出现“命令延迟突然从微秒级涨到毫秒级”Redis 自己又没报错很多人就懵了。这时候绕不开的一件事就是Redis 服务端到底是怎么接收、解析、校验和执行一条命令的。只有把这条链路抠明白你才能真正看懂那些延迟波动、慢查询和连接异常从哪来。这篇文章我会从 Redis 源码的角度把一条命令从客户端发出到服务端响应回包的完整路径拆开讲。源码版本我会以目前主流使用的 6.x/7.x 为参考核心流程在这些版本中基本一致。适合已经把 Redis 文档刷过一遍、想往底层再走一步的读者也适合准备系统性排查线上问题的同学当作源码阅读路线图。1. 一条命令的完整旅程从 socket 读入到塞进执行队列1.1 事件驱动框架命令是怎么“被看见”的Redis 并不是像很多人想象的“每个客户端连接起一个线程去处理”——它的设计核心是单线程事件循环所有命令在同一个线程里串行执行这也是为什么它能把“原子性”做得这么自然。入口在ae.c里的事件循环aeMain()它会反复执行aeProcessEvents()负责监听所有客户端连接上的可读/可写事件。当有请求到达时事件分发给networking.c里的回调函数处理。最核心的两个/* file event → read handler */ readQueryFromClient /* file event → writable handler */ handleClientsWithPendingWrites前者负责把 socket 里的字节读进客户端对象的缓冲区后者负责把待返回的数据写回 socket。这一读一写就是命令生命周期的开始和结束。1.2 输入缓冲区字节先是住进了一个临时旅馆很多新手会把“客户端发送了一条命令”想象成一个完整数据包服务端直接收到就能解析。实际上 Redis 虽然协议简单但网络是不可靠的一个SET foo bar\r\n可能分三次到达而且 Redis 不会在每次 read 到一半就去执行它先把读到的所有内容统一塞进每个连接自己的缓冲区client* c; c-querybuf sdsempty();这块就是协议解析的输入源。你要注意一个容易被忽略的点Redis 并不是每收到一块数据就立刻执行一块而是等processInputBuffer()里能完整解析出至少一条命令后才进入执行流程。所以当一条命令的字节没到齐时它只是安静地躺在querybuf里等待。我读源码的时候第一次在这里栽了跟头我原以为querybuf只是“临时转存”一条命令执行完缓冲区就空了。实际上它是一次性累积的。如果客户端发了多条命令Redis 会在一次处理中循环解析、批量执行这也是 Redis pipeline 在服务端层面的真实工作方式。1.3 从字符流到 C 结构体RESP 协议的拆解现场缓冲区里躺着的还是裸字节Redis 需要把它变成可执行的命令结构。这个工作在networking.c里对应函数是processInputBuffer对于普通客户端走的是 RESP 协议解析。以精确解析为例服务端从*3\r\n$3\r\nSET\r\n$3\r\nfoo\r\n$3\r\nbar\r\n中先读出参数个数3然后循环读出三个参数的长度和内容最终填充c-argc 3; c-argv zmalloc(sizeof(robj*) * 3); c-argv[0] createRawStringObject(SET, 3); c-argv[1] createRawStringObject(foo, 3); c-argv[2] createRawStringObject(bar, 3);每个参数都用一个robjRedis Object包装起来这样后面找命令、算 key、做类型检查都能统一处理。值得多说一句的是除 RESP 外 Redis 还支持一种 telnet 风格的行协议就是直接发SET foo bar\r\n。这就是processInlineBuffer的由来。源码里这两套解析逻辑是分开的但最终产物一样都是把内容填进c-argv。我把这一段当“文本变成结构体”的过程来看之后任何一步出问题先判断是在解析阶段还是执行阶段排查思路会清晰很多。2. commandTable命令查找背后的数据结构取舍2.1 命令表是怎么来的执行命令的第一步是“查命令”。Redis 所有可用命令都存在一张命令表中表项类型是struct redisCommand字段包括了命令名、命令处理函数指针、参数数量约束、命令属性 flags 等。服务启动时通过populateCommandTable()将这些项注册进server.commands字典key 是命令名的 sds 字符串value 是命令结构体指针。这里有一个在 7.0 以后非常明显的变化6.x 及以前命令定义大多是“流水账”每个命令在commands.c里通过一个宏初始化参数校验和 ACL 相关逻辑集中在执行时。7.0 开始Redis 引入了更结构化的命令注册方式每个命令不仅标了参数范围还带了文档、ACL 分类等信息让命令表本身就自带“元数据”。我当时从 6.2 直接跨到 7.2 看代码第一反应是命令表从“功能列表”变成了“词典”。2.2 查找命令为什么可以不做哈希这里有个反直觉的设计。server.commands字典明明已经存在命令查找走lookupCommand()时本可以直接哈希。实际上代码里确实也这样做了struct redisCommand *lookupCommand(sds name) { return dictFetchValue(server.commands, name); }但如果你看老版本的lookupCommand会发现它先做了一个线性扫描。为什么 Redis 不从一开始就全部哈希化原因很朴素命令总数通常只有两百左右数据量小到哈希和线性扫描的差距根本构不成性能瓶颈。加上命令名是固定短字符串线性比较的 cache 命中率高反而可能更快。这给我们的启发很实际不要一听到“查找”就条件反射去上哈希。数据规模小、生命周期固定、无并发写时线性结构配合好缓存往往是最简单可靠的方案。2.3 命令 flags命令的“性格标签”命令表里最值得研究的是 flags 字段。它不仅影响命令能否执行还决定了好几个关键分支Flag含义典型命令CMD_WRITE写操作影响持久化与复制SET, DELCMD_READONLY只读操作集群模式可以走从节点GETCMD_DENYOOM内存超限时拒绝执行SET, LPUSHCMD_ADMIN管理命令需特殊权限CONFIG, SHUTDOWNCMD_NOSCRIPT不允许在 Lua 脚本中执行RANDOMKEY读代码时我发现多数“线上诡异行为”都能从 flags 找到解释。例如内存已满时DEL依然执行而SET直接返回 OOM就是 CMD_DENYOOM 在做拦截你想在集群环境用KEYS但被拒绝也和 flag/权限有关系。所以排查命令问题前先翻一下这条命令的 flags 定义是效率最高的捷径。3. processCommand命令执行前的那道严防死守3.1 执行前的裁判团校验顺序里的门道命令解析完成后并不会立刻执行而是先进processCommand()。这个名字看起来像“处理命令”实际它更像一个“前置检查集中营”顺序依次是命令是否存在lookupCommand参数数量是否合法arity校验是否经过身份验证ACL 或 requirepass是否已经超过最大内存maxmemory检查集群模式下 key 是否在本节点是否只读从节点的写命令拦截是否处于 loading 状态该命令是否需要延迟执行阻塞队列场景我第一次完整读这个函数时印象最深的是它的检查顺序不是随意排的而是按“代价从低到高”排布的。命令名查字典几乎零成本所以最先做ACL 校验涉及权限匹配虽然也不贵但要有前置条件内存检查要读取当前已用内存状态成本偏高所以放后面。源码里的每一个顺序决策都隐藏着对性能的考量。3.2 内存超限OOM 检查和 lazy free 的边界maxmemory检查是这块的重头戏。如果配置了maxmemory在真正执行写命令前 Redis 会先看当前内存是否超标一旦超标如果配置了maxmemory-policy且可逐出先尝试淘汰老键如果还不能释放足够空间且命令本身带CMD_DENYOOM标志直接返回 OOM 错误如果命令不带CMD_DENYOOM比如DEL、EXPIRE仍然放行——因为它们能腾出内存而不是增加内存。这就是为什么线上明明内存已满DEL却能删掉 key。我之前排查过一个“Redis 不报错但 set 全部失败”的案例最后就是在processCommand的 OOM 分支上发现的maxmemory设置得太低且没有淘汰策略所有SET都被拦在门前。3.3 集群重定向MOVED 错误背后的选择集群模式下命令执行前多了一道“key 属于哪个槽”的判断。Redis 通过keyHashSlot()算出 key 对应的 slot再看当前节点是不是该 slot 的 owner。不是则返回MOVED或ASK把客户端引导到正确节点上。判断逻辑在processCommand中独立成块并在重定向之前把纯只读命令与写命令做了区分这也是为什么GET可以打从节点而SET必须转发主节点的根因。我在理解这部分时习惯把它想成“酒店前台查房卡”客人拿错房卡key 在别的槽前台不会帮他开门而是告诉他“该去哪个分店”。3.4 过期键清理执行命令时顺手处理的“临期键”Redis 的过期键清理策略是惰性删除为主定时删除为辅。这意味着执行命令时获取某个 key 之前会先检查它是否已过期。这个逻辑散落在键空间操作函数中但入口都能追溯到lookupKeyRead和expireIfNeeded。初读源码很容易忽略这个环节但它对读多写少的业务非常重要。举个例子你用GET key查一个已经过期的 key返回nil其实经历了三层先看 key 是否存在发现存在但已过期则删除该键并返回空。如果过期键数量很大每条读命令都要多付出一次删除代价这也能解释某些时候 Redis 明明很空闲读延迟却偶尔抖动一下。4. call 执行器命令真正落地的瞬间4.1 统一通道call 函数里的那些隐藏计数你现在拿着一个通过校验的client* c接下来进入的是call()。整个 Redis 中所有正常命令最终都走进这同一个执行器它在调用命令处理函数c-cmd-proc(c)的前后做了大量“统一但又容易被忽略”的工作执行前增加server.stat_numcommands计数执行前设置server.monitor需要的数据执行前如果开启 AOF提前准备好 propagate 所需的数据调用真正的命令处理函数执行后统计 dirty 计数被修改的 key 数量执行后差量更新server.stat_expiredkeys等信息call函数的精妙之处在于它把命令执行前后的通用逻辑全部收拢避免了每个命令实现里重复造轮子。比如你写一个自定义模块命令只要注册好 proc就能免费获得监控、统计、持久化这些能力。4.2 慢查询、监控、AOF都在这一瞬打点很多人用SLOWLOG GET查慢查询却不知道慢查询记录生成的地方其实就在call()里。命令执行完后Redis 会拿当前时间减去执行前记录的时间一旦超过slowlog-log-slower-than阈值就往 slowlog 链表中“头插”一条记录if (duration server.slowlog_log_slower_than) slowlogPushEntryIfNeeded(c, argv, argc, duration);与此同时如果开启了 monitor所有命令文本都会在这里同步给监视客户端。AOF 也是类似的原理如果配置了appendonly yes命令执行后会被记录进 AOF 缓冲等待后续落盘。这带出一个非常实用的调优点一条命令真正花在“执行 proc”上的时间可能很短但如果你去测整体 RT会发现慢在协议解析、命令校验、AOF 写入这几个额外环节上。不要一慢就怀疑命令本身低效先看 slowlog 的耗时分布。4.3 dirty 计数与主从同步的源头call里还有一个细节执行完命令后会server.dirty dirty。这个 dirty 看起来只是一个数字实际上它和server.stat_dirty一起成为节流刷盘、持久化和主从增量同步的基石。主从复制时从库不是直接同步命令文本的而是主库通过 propagate 机制把命令推到 replication backlog从库再从 backlog 拉取并应用。理解 dirty 的作用对排查“明明写了数据从库却查不到”这类问题非常有帮助如果主库的repl_backlog太小积压数据超过限制从库只能做全量重同步脏数据相关的时间线会错乱。你从源码层面看到 dirty 的累积和 backlog 的关系后就很少会再犯把repl-backlog-size设成 1MB 这种错误了。5. 输出缓冲与写回万人请求下最容易被忽略的瓶颈5.1 返回数据先住哪buf 和 reply 链表的双通道命令处理完的结果并不会直接write()回客户端而是先封装到输出缓冲区里。每个client都有两块输出区域固定缓冲区c-buf大小默认为 16KB适合小的返回结果动态链表c-reply用于放不下的大响应或者多个命令攒下来的返回数据。写入的入口是各类addReply*函数例如addReplyStatus、addReplyBulk、addReplyError等。它们内部全部走同一套逻辑先尝试把内容拷贝到c-buf如果空间不够就追加到c-reply链表上。我接触过一个面试题常客“MGET一次取一万个 key为什么要小心输出缓冲区”答案其实就是这里。一万个 value 拼成的响应远超 16KB全部落到c-reply动态链表中如果客户端消费不及时链表会一直膨胀最终触发输出缓冲限制导致连接被强制断开。5.2 输出缓冲限制背压与强制断连的博弈Redis 对输出缓冲区有硬性限制配置项是client-output-buffer-limit normal 0 0 0 client-output-buffer-limit replica 256mb 64mb 60 client-output-buffer-limit pubsub 32mb 8mb 60格式是hard-limit soft-limit soft-seconds。在networking.c的checkClientOutputBufferLimits里Redis 会周期性检查每个客户端超出 hard limit立刻断开连接超出 soft limit 且持续超过 soft-seconds也断开连接。我曾经在生产环境里遇到过“大 key 导出导致主库连接被自己断开”的诡异现象根源就是这个。客户端用KEYS *一次性拉全量返回的结果集巨大主库一边写 socket 一边发现缓冲区超限出于保护机制直接掐断连接。所以读源码后你会明白设置client-output-buffer-limit不只是防 OOM更是防“慢客户端拖垮服务端”。5.3 多线程 IO 的真相只优化了写回和读入没改变执行Redis 6.0 引入了 IO 多线程这个功能常被误解为“Redis 终于支持多线程执行命令了”。实际上源码里的initThreadedIO和handleClientsWithPendingWritesUsingThreads都只做一件事把“从 socket 读取数据”和“向 socket 写回数据”这两个 IO 密集操作分摊到多个线程而命令的实际执行仍然集中在主线程。也就是说命令的协议解析和真正的proc调用依然在主线程串行完成多线程优化的只是搬运工。这对于压测结果有直接影响如果业务本身是纯内存操作且响应很短开多线程收益极小但如果客户端数量多、返回体量又大开io-threads 4能有效降低写回阻塞。理解了线程边界以后再看到类似“开 IO 线程后性能没提升”的疑问就能自己判断了。6. 源码阅读路线图版本选择、断点调试与常见误区6.1 该从哪个版本入手如果你也想亲自读一遍 Redis 命令处理链路我的建议是直接从 6.2 或者 7.0 之后的稳定分支开始。6.2 的代码相对精简命令表、processCommand、call 这些核心逻辑的“骨架感”很强适合第一遍理解。7.x 虽然引入了更复杂的命令元数据结构和 IO 线程但也带来不少干扰项容易在细节里迷路。入口文件优先级建议这样排src/networking.c—— 读入、解析、写回全在这里是命令处理最核心的文件src/server.c—— processCommand 和 call 的所在地命令执行主链路src/db.c—— 键空间操作的具体实现查看 key 时怎么走 expireIfNeededsrc/commands.c—— 命令表定义查 flags 和 arity 很方便6.2 用调试器“看到”命令流转纯读代码容易走神一个高效的办法是本地编译一个 Redis然后用 gdb 或 lldb 加断点跟踪实际请求。我在调试时放的几个关键断点readQueryFromClient确认数据是否进入服务端processInputBuffer观察请求是否完成了协议解析processCommand观察校验链路call确认命令真正执行时刻addReply观察响应如何进入输出缓冲区实际操作中你甚至可以做一个简单实验开两个终端一个跑 gdb 停在processCommand另一个用redis-cli发一条SET k v单步执行时看c-argv[0]里的字符串是什么、c-cmd指向哪个命令整个抽象瞬间就落地了。还有一个贴心技巧在断点处打印c-argv[i]-ptr内容时要注意robj的类型可能是OBJ_STRING。直接强转成sds可能会遇到编码格式问题稳妥做法是先确认o-encoding是OBJ_ENCODING_RAW还是OBJ_ENCODING_EMBSTR想省事可以直接printf(%s, (char*)o-ptr)。这种细节在源码调试里很常见遇到了别慌。6.3 几个容易踩的阅读误区第一别把c-argc和命令参数个数混淆。argc包含命令名本身SET k v的 argc 是 3不是 2。如果写模块或改源码时按“参数个数”来校验常常会出现 off-by-one 错误。第二不要以为querybuf在每条命令执行后都会被清空。它只在每次事件循环处理的末尾做不定长清理所以调试时如果发现 buffer 里残留了之前的数据不要紧张那是正在堆积的后续命令内容。第三看命令执行时间时别只盯着 proc 本身。call()函数前置的 AOF 传播、后置的 slowlog 判断加上processCommand里的 ACL、内存淘汰检查叠加起来可能比 proc 还耗时。想优化命令性能一定要打点统计整段链路而不是只看单个函数。我自己的感受是读 Redis 源码一开始最难的并不是某个算法看不懂而是始终在“一直跳来跳去”的状态里找不到主线。但如果以readQueryFromClient → processInputBuffer → processCommand → call → addReply为骨架从这条链路上把每个节点的边界和责任看清Redis 在你眼里就不再是一个黑盒。后面不管是调参、写模块还是排查线上诡异延迟你都会自动多一层“大概哪段代码出问题了”的判断力。
如果你写过一段时间 Redis不管是用来做缓存还是扛高并发大概率只是会调GET/SET顶多再了解点expire和集群分片。但一旦线上出现“命令延迟突然从微秒级涨到毫秒级”Redis 自己又没报错很多人就懵了。这时候绕不开的一件事就是Redis 服务端到底是怎么接收、解析、校验和执行一条命令的。只有把这条链路抠明白你才能真正看懂那些延迟波动、慢查询和连接异常从哪来。这篇文章我会从 Redis 源码的角度把一条命令从客户端发出到服务端响应回包的完整路径拆开讲。源码版本我会以目前主流使用的 6.x/7.x 为参考核心流程在这些版本中基本一致。适合已经把 Redis 文档刷过一遍、想往底层再走一步的读者也适合准备系统性排查线上问题的同学当作源码阅读路线图。1. 一条命令的完整旅程从 socket 读入到塞进执行队列1.1 事件驱动框架命令是怎么“被看见”的Redis 并不是像很多人想象的“每个客户端连接起一个线程去处理”——它的设计核心是单线程事件循环所有命令在同一个线程里串行执行这也是为什么它能把“原子性”做得这么自然。入口在ae.c里的事件循环aeMain()它会反复执行aeProcessEvents()负责监听所有客户端连接上的可读/可写事件。当有请求到达时事件分发给networking.c里的回调函数处理。最核心的两个/* file event → read handler */ readQueryFromClient /* file event → writable handler */ handleClientsWithPendingWrites前者负责把 socket 里的字节读进客户端对象的缓冲区后者负责把待返回的数据写回 socket。这一读一写就是命令生命周期的开始和结束。1.2 输入缓冲区字节先是住进了一个临时旅馆很多新手会把“客户端发送了一条命令”想象成一个完整数据包服务端直接收到就能解析。实际上 Redis 虽然协议简单但网络是不可靠的一个SET foo bar\r\n可能分三次到达而且 Redis 不会在每次 read 到一半就去执行它先把读到的所有内容统一塞进每个连接自己的缓冲区client* c; c-querybuf sdsempty();这块就是协议解析的输入源。你要注意一个容易被忽略的点Redis 并不是每收到一块数据就立刻执行一块而是等processInputBuffer()里能完整解析出至少一条命令后才进入执行流程。所以当一条命令的字节没到齐时它只是安静地躺在querybuf里等待。我读源码的时候第一次在这里栽了跟头我原以为querybuf只是“临时转存”一条命令执行完缓冲区就空了。实际上它是一次性累积的。如果客户端发了多条命令Redis 会在一次处理中循环解析、批量执行这也是 Redis pipeline 在服务端层面的真实工作方式。1.3 从字符流到 C 结构体RESP 协议的拆解现场缓冲区里躺着的还是裸字节Redis 需要把它变成可执行的命令结构。这个工作在networking.c里对应函数是processInputBuffer对于普通客户端走的是 RESP 协议解析。以精确解析为例服务端从*3\r\n$3\r\nSET\r\n$3\r\nfoo\r\n$3\r\nbar\r\n中先读出参数个数3然后循环读出三个参数的长度和内容最终填充c-argc 3; c-argv zmalloc(sizeof(robj*) * 3); c-argv[0] createRawStringObject(SET, 3); c-argv[1] createRawStringObject(foo, 3); c-argv[2] createRawStringObject(bar, 3);每个参数都用一个robjRedis Object包装起来这样后面找命令、算 key、做类型检查都能统一处理。值得多说一句的是除 RESP 外 Redis 还支持一种 telnet 风格的行协议就是直接发SET foo bar\r\n。这就是processInlineBuffer的由来。源码里这两套解析逻辑是分开的但最终产物一样都是把内容填进c-argv。我把这一段当“文本变成结构体”的过程来看之后任何一步出问题先判断是在解析阶段还是执行阶段排查思路会清晰很多。2. commandTable命令查找背后的数据结构取舍2.1 命令表是怎么来的执行命令的第一步是“查命令”。Redis 所有可用命令都存在一张命令表中表项类型是struct redisCommand字段包括了命令名、命令处理函数指针、参数数量约束、命令属性 flags 等。服务启动时通过populateCommandTable()将这些项注册进server.commands字典key 是命令名的 sds 字符串value 是命令结构体指针。这里有一个在 7.0 以后非常明显的变化6.x 及以前命令定义大多是“流水账”每个命令在commands.c里通过一个宏初始化参数校验和 ACL 相关逻辑集中在执行时。7.0 开始Redis 引入了更结构化的命令注册方式每个命令不仅标了参数范围还带了文档、ACL 分类等信息让命令表本身就自带“元数据”。我当时从 6.2 直接跨到 7.2 看代码第一反应是命令表从“功能列表”变成了“词典”。2.2 查找命令为什么可以不做哈希这里有个反直觉的设计。server.commands字典明明已经存在命令查找走lookupCommand()时本可以直接哈希。实际上代码里确实也这样做了struct redisCommand *lookupCommand(sds name) { return dictFetchValue(server.commands, name); }但如果你看老版本的lookupCommand会发现它先做了一个线性扫描。为什么 Redis 不从一开始就全部哈希化原因很朴素命令总数通常只有两百左右数据量小到哈希和线性扫描的差距根本构不成性能瓶颈。加上命令名是固定短字符串线性比较的 cache 命中率高反而可能更快。这给我们的启发很实际不要一听到“查找”就条件反射去上哈希。数据规模小、生命周期固定、无并发写时线性结构配合好缓存往往是最简单可靠的方案。2.3 命令 flags命令的“性格标签”命令表里最值得研究的是 flags 字段。它不仅影响命令能否执行还决定了好几个关键分支Flag含义典型命令CMD_WRITE写操作影响持久化与复制SET, DELCMD_READONLY只读操作集群模式可以走从节点GETCMD_DENYOOM内存超限时拒绝执行SET, LPUSHCMD_ADMIN管理命令需特殊权限CONFIG, SHUTDOWNCMD_NOSCRIPT不允许在 Lua 脚本中执行RANDOMKEY读代码时我发现多数“线上诡异行为”都能从 flags 找到解释。例如内存已满时DEL依然执行而SET直接返回 OOM就是 CMD_DENYOOM 在做拦截你想在集群环境用KEYS但被拒绝也和 flag/权限有关系。所以排查命令问题前先翻一下这条命令的 flags 定义是效率最高的捷径。3. processCommand命令执行前的那道严防死守3.1 执行前的裁判团校验顺序里的门道命令解析完成后并不会立刻执行而是先进processCommand()。这个名字看起来像“处理命令”实际它更像一个“前置检查集中营”顺序依次是命令是否存在lookupCommand参数数量是否合法arity校验是否经过身份验证ACL 或 requirepass是否已经超过最大内存maxmemory检查集群模式下 key 是否在本节点是否只读从节点的写命令拦截是否处于 loading 状态该命令是否需要延迟执行阻塞队列场景我第一次完整读这个函数时印象最深的是它的检查顺序不是随意排的而是按“代价从低到高”排布的。命令名查字典几乎零成本所以最先做ACL 校验涉及权限匹配虽然也不贵但要有前置条件内存检查要读取当前已用内存状态成本偏高所以放后面。源码里的每一个顺序决策都隐藏着对性能的考量。3.2 内存超限OOM 检查和 lazy free 的边界maxmemory检查是这块的重头戏。如果配置了maxmemory在真正执行写命令前 Redis 会先看当前内存是否超标一旦超标如果配置了maxmemory-policy且可逐出先尝试淘汰老键如果还不能释放足够空间且命令本身带CMD_DENYOOM标志直接返回 OOM 错误如果命令不带CMD_DENYOOM比如DEL、EXPIRE仍然放行——因为它们能腾出内存而不是增加内存。这就是为什么线上明明内存已满DEL却能删掉 key。我之前排查过一个“Redis 不报错但 set 全部失败”的案例最后就是在processCommand的 OOM 分支上发现的maxmemory设置得太低且没有淘汰策略所有SET都被拦在门前。3.3 集群重定向MOVED 错误背后的选择集群模式下命令执行前多了一道“key 属于哪个槽”的判断。Redis 通过keyHashSlot()算出 key 对应的 slot再看当前节点是不是该 slot 的 owner。不是则返回MOVED或ASK把客户端引导到正确节点上。判断逻辑在processCommand中独立成块并在重定向之前把纯只读命令与写命令做了区分这也是为什么GET可以打从节点而SET必须转发主节点的根因。我在理解这部分时习惯把它想成“酒店前台查房卡”客人拿错房卡key 在别的槽前台不会帮他开门而是告诉他“该去哪个分店”。3.4 过期键清理执行命令时顺手处理的“临期键”Redis 的过期键清理策略是惰性删除为主定时删除为辅。这意味着执行命令时获取某个 key 之前会先检查它是否已过期。这个逻辑散落在键空间操作函数中但入口都能追溯到lookupKeyRead和expireIfNeeded。初读源码很容易忽略这个环节但它对读多写少的业务非常重要。举个例子你用GET key查一个已经过期的 key返回nil其实经历了三层先看 key 是否存在发现存在但已过期则删除该键并返回空。如果过期键数量很大每条读命令都要多付出一次删除代价这也能解释某些时候 Redis 明明很空闲读延迟却偶尔抖动一下。4. call 执行器命令真正落地的瞬间4.1 统一通道call 函数里的那些隐藏计数你现在拿着一个通过校验的client* c接下来进入的是call()。整个 Redis 中所有正常命令最终都走进这同一个执行器它在调用命令处理函数c-cmd-proc(c)的前后做了大量“统一但又容易被忽略”的工作执行前增加server.stat_numcommands计数执行前设置server.monitor需要的数据执行前如果开启 AOF提前准备好 propagate 所需的数据调用真正的命令处理函数执行后统计 dirty 计数被修改的 key 数量执行后差量更新server.stat_expiredkeys等信息call函数的精妙之处在于它把命令执行前后的通用逻辑全部收拢避免了每个命令实现里重复造轮子。比如你写一个自定义模块命令只要注册好 proc就能免费获得监控、统计、持久化这些能力。4.2 慢查询、监控、AOF都在这一瞬打点很多人用SLOWLOG GET查慢查询却不知道慢查询记录生成的地方其实就在call()里。命令执行完后Redis 会拿当前时间减去执行前记录的时间一旦超过slowlog-log-slower-than阈值就往 slowlog 链表中“头插”一条记录if (duration server.slowlog_log_slower_than) slowlogPushEntryIfNeeded(c, argv, argc, duration);与此同时如果开启了 monitor所有命令文本都会在这里同步给监视客户端。AOF 也是类似的原理如果配置了appendonly yes命令执行后会被记录进 AOF 缓冲等待后续落盘。这带出一个非常实用的调优点一条命令真正花在“执行 proc”上的时间可能很短但如果你去测整体 RT会发现慢在协议解析、命令校验、AOF 写入这几个额外环节上。不要一慢就怀疑命令本身低效先看 slowlog 的耗时分布。4.3 dirty 计数与主从同步的源头call里还有一个细节执行完命令后会server.dirty dirty。这个 dirty 看起来只是一个数字实际上它和server.stat_dirty一起成为节流刷盘、持久化和主从增量同步的基石。主从复制时从库不是直接同步命令文本的而是主库通过 propagate 机制把命令推到 replication backlog从库再从 backlog 拉取并应用。理解 dirty 的作用对排查“明明写了数据从库却查不到”这类问题非常有帮助如果主库的repl_backlog太小积压数据超过限制从库只能做全量重同步脏数据相关的时间线会错乱。你从源码层面看到 dirty 的累积和 backlog 的关系后就很少会再犯把repl-backlog-size设成 1MB 这种错误了。5. 输出缓冲与写回万人请求下最容易被忽略的瓶颈5.1 返回数据先住哪buf 和 reply 链表的双通道命令处理完的结果并不会直接write()回客户端而是先封装到输出缓冲区里。每个client都有两块输出区域固定缓冲区c-buf大小默认为 16KB适合小的返回结果动态链表c-reply用于放不下的大响应或者多个命令攒下来的返回数据。写入的入口是各类addReply*函数例如addReplyStatus、addReplyBulk、addReplyError等。它们内部全部走同一套逻辑先尝试把内容拷贝到c-buf如果空间不够就追加到c-reply链表上。我接触过一个面试题常客“MGET一次取一万个 key为什么要小心输出缓冲区”答案其实就是这里。一万个 value 拼成的响应远超 16KB全部落到c-reply动态链表中如果客户端消费不及时链表会一直膨胀最终触发输出缓冲限制导致连接被强制断开。5.2 输出缓冲限制背压与强制断连的博弈Redis 对输出缓冲区有硬性限制配置项是client-output-buffer-limit normal 0 0 0 client-output-buffer-limit replica 256mb 64mb 60 client-output-buffer-limit pubsub 32mb 8mb 60格式是hard-limit soft-limit soft-seconds。在networking.c的checkClientOutputBufferLimits里Redis 会周期性检查每个客户端超出 hard limit立刻断开连接超出 soft limit 且持续超过 soft-seconds也断开连接。我曾经在生产环境里遇到过“大 key 导出导致主库连接被自己断开”的诡异现象根源就是这个。客户端用KEYS *一次性拉全量返回的结果集巨大主库一边写 socket 一边发现缓冲区超限出于保护机制直接掐断连接。所以读源码后你会明白设置client-output-buffer-limit不只是防 OOM更是防“慢客户端拖垮服务端”。5.3 多线程 IO 的真相只优化了写回和读入没改变执行Redis 6.0 引入了 IO 多线程这个功能常被误解为“Redis 终于支持多线程执行命令了”。实际上源码里的initThreadedIO和handleClientsWithPendingWritesUsingThreads都只做一件事把“从 socket 读取数据”和“向 socket 写回数据”这两个 IO 密集操作分摊到多个线程而命令的实际执行仍然集中在主线程。也就是说命令的协议解析和真正的proc调用依然在主线程串行完成多线程优化的只是搬运工。这对于压测结果有直接影响如果业务本身是纯内存操作且响应很短开多线程收益极小但如果客户端数量多、返回体量又大开io-threads 4能有效降低写回阻塞。理解了线程边界以后再看到类似“开 IO 线程后性能没提升”的疑问就能自己判断了。6. 源码阅读路线图版本选择、断点调试与常见误区6.1 该从哪个版本入手如果你也想亲自读一遍 Redis 命令处理链路我的建议是直接从 6.2 或者 7.0 之后的稳定分支开始。6.2 的代码相对精简命令表、processCommand、call 这些核心逻辑的“骨架感”很强适合第一遍理解。7.x 虽然引入了更复杂的命令元数据结构和 IO 线程但也带来不少干扰项容易在细节里迷路。入口文件优先级建议这样排src/networking.c—— 读入、解析、写回全在这里是命令处理最核心的文件src/server.c—— processCommand 和 call 的所在地命令执行主链路src/db.c—— 键空间操作的具体实现查看 key 时怎么走 expireIfNeededsrc/commands.c—— 命令表定义查 flags 和 arity 很方便6.2 用调试器“看到”命令流转纯读代码容易走神一个高效的办法是本地编译一个 Redis然后用 gdb 或 lldb 加断点跟踪实际请求。我在调试时放的几个关键断点readQueryFromClient确认数据是否进入服务端processInputBuffer观察请求是否完成了协议解析processCommand观察校验链路call确认命令真正执行时刻addReply观察响应如何进入输出缓冲区实际操作中你甚至可以做一个简单实验开两个终端一个跑 gdb 停在processCommand另一个用redis-cli发一条SET k v单步执行时看c-argv[0]里的字符串是什么、c-cmd指向哪个命令整个抽象瞬间就落地了。还有一个贴心技巧在断点处打印c-argv[i]-ptr内容时要注意robj的类型可能是OBJ_STRING。直接强转成sds可能会遇到编码格式问题稳妥做法是先确认o-encoding是OBJ_ENCODING_RAW还是OBJ_ENCODING_EMBSTR想省事可以直接printf(%s, (char*)o-ptr)。这种细节在源码调试里很常见遇到了别慌。6.3 几个容易踩的阅读误区第一别把c-argc和命令参数个数混淆。argc包含命令名本身SET k v的 argc 是 3不是 2。如果写模块或改源码时按“参数个数”来校验常常会出现 off-by-one 错误。第二不要以为querybuf在每条命令执行后都会被清空。它只在每次事件循环处理的末尾做不定长清理所以调试时如果发现 buffer 里残留了之前的数据不要紧张那是正在堆积的后续命令内容。第三看命令执行时间时别只盯着 proc 本身。call()函数前置的 AOF 传播、后置的 slowlog 判断加上processCommand里的 ACL、内存淘汰检查叠加起来可能比 proc 还耗时。想优化命令性能一定要打点统计整段链路而不是只看单个函数。我自己的感受是读 Redis 源码一开始最难的并不是某个算法看不懂而是始终在“一直跳来跳去”的状态里找不到主线。但如果以readQueryFromClient → processInputBuffer → processCommand → call → addReply为骨架从这条链路上把每个节点的边界和责任看清Redis 在你眼里就不再是一个黑盒。后面不管是调参、写模块还是排查线上诡异延迟你都会自动多一层“大概哪段代码出问题了”的判断力。
平方复杂度无法被常规优化消除｜TaoToken 统一 Key 通道实测)
