第一次把 Kafka 的源码仓库拉下来,大部分人的阅读轨迹都很相似:从KafkaProducer的send()进去,跟到doSend()里的waitOnMetadata()就卡住,因为再往下就是网络层的NetworkClient,而网络层手里拿着的东西你还没见过。我当时也一样,笔记记了一堆类名,回头问自己“一条消息从调用 send 到落盘到底经过了哪几步”,还是答不上来。卡住的原因不是代码难,是顺序错了——从最顶层的 API 往下硬啃,等于同时面对缓冲区、网络、存储、副本四条独立的线,信息量直接过载。
所以这篇东西不打算带你“从头读一遍”,而是以 Kafka 3.0 这个版本为切入口,讲清楚三件事:为什么 3.0 特别适合作为源码阅读的锚点版本、仓库里各个模块的边界到底在哪、以及几条主干链路(生产者、存储、副本、KRaft 元数据)应该按什么顺序拆。适合已经会用 Kafka、想搞清楚内部机制的中高级开发者,也适合准备面试但不想背八股的人。文中涉及的操作和调试手法都是我自己跑过一遍的,参数取值直接给结论,你可以照抄。
1. 为什么把 Kafka 3.0 当作源码阅读的锚点版本
1.1 3.0 是一次“结构性断代”,不是一个普通小版本
选源码版本这件事,很多人图省事,直接拉最新 tag。这在 Kafka 上是个坑,因为 4.x 之后 Scala 代码被大规模改写,core模块被拆成server、metadata、group-coordinator好几个模块,你从网上找的大部分老文章对不上号。反过来,2.4 以前的版本又太旧,KRaft 还完全不存在,读完了对现在的生产环境帮助有限。
3.0 恰好卡在一个很舒服的位置上。它一方面保留了经典的 ZooKeeper 模式完整实现,KafkaController、ZooKeeperClient、各类监听器都在,老架构你能完整看到;另一方面 KRaft 模式第一次达到“可以真跑起来”的预览状态,raft模块和metadata模块已经成形,QuorumController也有了。等于说,一个版本里能同时读到新旧两套元数据管理方案,这在 Kafka 的版本史上不多见。
我自己的判断标准很简单:读源码是为了建立“心智模型”,而心智模型最怕的就是架构在脚下换地板。3.0 是最后一个“老架构完整、新架构可见”的版本,读完它你再往 4.x 迁,能清楚知道哪些东西被删掉了、为什么删,而不是面对一堆陌生模块发呆。
1.2 几处默认值变化,直接改变了主链路的代码分支
3.0 在客户端做了一次很关键的收紧,生产者侧的三个默认值被调整成“强投递保证”组合:enable.idempotence默认变为true,acks默认变为all,retries保持极大值。
很多人觉得这只是配置默认值的事,跟读源码没关系。恰恰相反,它影响巨大。因为幂等性一旦默认打开,TransactionManager这条线就不再是“只有用事务的人才走”的旁路,而是每个生产者实例都会进入的主干。你在doSend()里会看到transactionManager大量参与:申请 PID、给ProducerBatch赋baseSequence、在响应回来后推进 sequence、处理OUT_OF_ORDER_SEQUENCE_NUMBER这类错误。如果你读的是 2.x 的代码,这段逻辑你大概率会直接跳过,因为它默认不生效。
| 配置项 | 2.x 默认 | 3.0 默认 | 对源码阅读的影响 |
|---|---|---|---|
enable.idempotence | false | true | TransactionManager进入主路径,必须读懂 |
acks | 1 | all | Partition侧延时生产(DelayProduce)必然触发 |
retries | 极大值 | 极大值 | 重试与幂等序列的交互成为常态 |
| 消息格式 v0/v1 | 支持 | 标记弃用 | MemoryRecords的兼容分支可跳过 |
acks=all这一条尤其值得注意。它意味着 leader 收到消息后不能立刻回响应,得等 ISR 里的副本都同步完。这条“等待”在代码里的落点就是Partition里的延时操作队列,以及DelayedProduce这个类。你不理解它,就看不懂ReplicaManager.appendRecords为什么返回的是“可能还没完成”的结果。
1.3 版本锁定和构建环境,别在这里浪费时间
实操层面有几个细节,提前说清楚能省半天。3.0 的主语言仍是 Scala 2.13 加 Java 混编,core、raft、metadata里有大量 Scala 代码,IDEA 必须装好 Scala 插件并正确指定 SDK,否则索引会大面积标红——这不是代码有问题,是 IDE 没认出object和trait。
构建用 Gradle,./gradlew jar会编译全部模块,第一次跑要下载依赖,耐心点。如果你只想看某个模块,./gradlew :clients:compileJava这种带模块前缀的命令能快很多。还有一个我踩过的坑:3.0 已经不再支持 JDK 8 的完整构建路径(标记为弃用),用 JDK 11 或 17 更稳,我实测 11 最省心,17 上偶尔会遇到测试框架的兼容提示。
提示:不要一上手就
./gradlew test。整套测试跑完按小时计,而且对内存要求很高。读源码阶段只需要编译通过、能打断点即可。
2. 把仓库拆开看:模块边界决定了阅读顺序
2.1 五个核心模块各自的势力范围
Kafka 3.0 的仓库里,真正跟“消息怎么走”相关的就五个模块,其余(connect、streams、tools)可以先放一边。这五个模块的职责划分非常清晰,而且这个划分本身就是理解架构的第一把钥匙,因为模块之间的依赖方向,恰好就是数据流动的方向。
| 模块 | 主要语言 | 核心职责 | 阅读优先级 |
|---|---|---|---|
clients | Java | 生产者、消费者、Admin 客户端,以及通用协议与序列化 | 最高 |
server-common | Java/Scala | broker 与 controller 共享的基础设施,配置解析、日志抽象 | 中 |
storage | Java | 日志段、索引、MemoryRecords的读写 | 高 |
raft | Java | KRaft 一致性协议的实现 | 中高 |
metadata | Java | 元数据镜像(MetadataImage)、增量(MetadataDelta)、记录序列化 | 中 |
core | Scala | broker 主体、副本管理、控制器、网络层、协调器 | 最高 |
这里有个容易混淆的点:core模块在 3.0 里是个“大杂烩”,broker 的入口、副本管理、组协调器、旧版控制器、KRaft 控制器全在里面。你搜KafkaApis、ReplicaManager、GroupCoordinator、QuorumController这些类,全部落在core/src/main/scala/kafka/下面。等到了 4.x,这些东西被拆散了,所以你如果看的是新版本的目录结构,反而会对不上 3.0 的类路径。
依赖关系大致是:clients几乎不依赖别人,是自洽的;storage依赖clients里的记录格式;raft和metadata互相配合;core站在最上层,把所有人粘起来。这个方向很重要——它意味着你读core的时候遇到的所有类型,都应该已经在前面几个模块里见过。
2.2 三条阅读路线,选一条走到底
我不建议“按模块顺序读”,因为人和人的目标不一样。根据自己的目的选路线,效率差别很大。
第一条是生产消费链路优先。从KafkaProducer出发,一路跟到Sender、NetworkClient,再跳到服务端KafkaApis.handleProduceRequest,接着是ReplicaManager.appendRecords,最后到Log.appendAsLeader。这条线的好处是连贯,一条消息走完全程,你对“消息怎么落盘、什么时候算成功”会有非常具体的印象。适合大多数业务开发。
第二条是存储与副本优先。从Log、LogSegment、OffsetIndex入手,搞清楚磁盘上到底有哪些文件、索引怎么建、LEO和HW谁先动。然后往上看Partition和ReplicaManager,理解 ISR 收缩扩张的触发条件。适合做运维、调优、或者需要排查数据一致性问题的场景。
第三条是元数据优先。直接从raft模块的KafkaRaftClient和core里的QuorumController切进去,理解 KRaft 怎么把元数据变更变成一条条日志记录。这条路最陡,但如果你关心集群规模、controller 故障恢复时间,这是绕不开的。
我自己的做法是先走第一条,走通之后回头补第二条,第三条留着当“第二遍阅读”的任务。原因很实际:第一条路线上的每一个断点都能打出你认识的日志,反馈快;第三条路线调试起来麻烦,容易挫败。
2.3 定位入口类的笨办法,但真的有效
面对几万个类,怎么快速找到入口?我的办法是“从脚本反推”。bin/kafka-server-start.sh最终调用的是kafka.Kafka这个对象,它是 broker 的main;bin/kafka-console-producer.sh调用的是kafka.tools.ConsoleProducer,再往下就是KafkaProducer。顺着启动脚本找到main,再从main里看它 new 了哪些东西,三五步之内就能摸到主干。
另一个办法是从接口协议反推。clients模块里有org.apache.kafka.common.requests包,ProduceRequest、FetchRequest、JoinGroupRequest都在里面。你想知道服务端怎么处理生产请求,直接在core里搜handleProduceRequest就行,不用一层层点。这个包还有个额外好处:请求和响应的字段定义都在这儿,读代码时对着它看,比看文档准。
3. 生产者这条链路:从 send() 到网络发出的完整沉降过程
3.1 RecordAccumulator 才是生产者真正的心脏
KafkaProducer.send()表面上只是个入口,它做的事其实很少:序列化 key 和 value、算分区、然后调doSend()。真正的重量级工作在RecordAccumulator里。这个类的核心数据结构是一个ConcurrentMap<TopicPartition, Deque<ProducerBatch>>,每个分区对应一个双端队列,队列里是一个个已经打包好的批次。
这里的设计意图值得说透。为什么要按分区攒批?因为 Kafka 的协议是按分区组织数据的,一个请求里同一个分区的消息必须连续。为什么要用双端队列?因为Sender线程从队头取已经装满或超时的批次发出去,而业务线程从队尾追加新批次,一头进一头出,天然适配。
批次的容量受三个参数共同约束:batch.size默认 16384 字节,决定单个批次最大能装多少;linger.ms默认 0,决定批次最多等多久;buffer.memory默认 33554432 字节,是整个累加器的总内存上限。这三个参数的关系很多人搞混,我用一句话总结:buffer.memory是池子总量,batch.size是单个容器大小,linger.ms是“容器没装满也发货”的倒计时。
内存不是每次都新申请,BufferPool做了复用。它维护一个ByteBuffer的空闲队列,大小按batch.size切块。申请时先看有没有空闲块,没有就判断总占用是否超过buffer.memory,超了就让业务线程阻塞等待,最多等max.block.ms(默认 60000 毫秒),超时抛异常。这个阻塞点在生产环境里表现为“send 变慢甚至卡住”,根因往往是下游 broker 处理不过来导致批次释放不及时。读懂BufferPool.allocate的这一段,排这类问题会快很多。
3.2 Sender 线程与 NetworkClient 的一次完整轮询
Sender是一个独立线程,它实现Runnable,循环体就是run()里的while (running)。每一轮做四件事:从累加器里挑出“可以发”的分区、把批次按目标 broker 归组、组装成ProduceRequest塞给NetworkClient、然后poll一次网络。
“可以发”的判定在RecordAccumulator.ready()里,逻辑总结成三条:队列里第一个批次已经满了、或者等待时间超过linger.ms、或者累加器内存吃紧需要强制刷出。这三条任意满足即可。注意它检查的是队列的第一个批次,不是所有批次——这也是为什么队列必须是 FIFO 的,乱序发送会破坏分区内的顺序语义。
NetworkClient这一层的关键是InFlightRequests,它记录每个 broker 上还有多少个请求没收到响应,默认上限max.in.flight.requests.per.connection是 5。3.0 因为幂等默认打开,这个值虽然还是 5,但幂等保证要求同一分区的批次不能乱序,所以Sender在挑批次时会跳过“该分区已有在途请求”的情况。这段逻辑藏在accumulator.drain()和canSendRequest的判断里,第一遍读很容易漏掉,漏掉之后你就理解不了“为什么明明有数据却发不出去”。
响应回来的处理在Sender.handleProduceResponse里。成功就completeBatch释放内存、回调用户的Callback;失败就按错误类型分流,可重试的(如NOT_LEADER_OR_FOLLOWER)重新入队,不可重试的直接失败。这里的重试不是无限次,delivery.timeout.ms(默认 120000 毫秒)会兜底,超过这个时间无论什么错误都直接判失败。
3.3 幂等默认打开之后,多出来的那几条关键路径
前面说过,3.0 把enable.idempotence默认设为true,这意味着每个生产者都必须先向 broker 申请一个ProducerId,并且每个批次都要带baseSequence。这条逻辑全在TransactionManager里,虽然名字叫事务,但它同时管幂等。
流程大致是:第一批消息发送前,TransactionManager会先发一个InitProducerIdRequest,拿到 PID 和 epoch;拿到之后,每个ProducerBatch在reenqueue时被赋予从 0 开始的序列号,同一分区的序列号连续递增;broker 端ReplicaManager收到后校验序列号是否连续,不连续就回OUT_OF_ORDER_SEQUENCE_NUMBER,生产者收到后要么重置 PID 重来,要么按UNKNOWN_PRODUCER_ID处理。
这里有个实操经验:如果你在读代码时看到TransactionManager里有一大堆状态判断,别急着全部啃下来。先只关注isTransactional()返回 false 的那条分支,也就是“只用幂等、不用事务”的路径,这条路径覆盖了绝大多数生产场景。事务那条分支等你有需要再回头补,否则会陷在AddPartitionsToTxn、EndTxn这些请求里出不来。
注意:3.0 里
TransactionManager这个类的职责是幂等加事务混合的,别被名字误导。如果你只想看幂等,搜索ProducerIdAndEpoch和nextSequence这两个东西就够定位了。
4. 存储层:Log、LogSegment 与稀疏索引的真实工作方式
4.1 日志追加的写入路径与几个关键的“截止线”
Log.appendAsLeader是数据落盘的起点。它做的事看起来简单:判断当前活跃的LogSegment要不要滚动,不要就把记录追加进去,要就先roll出一个新段。但“要不要滚动”这个判断里藏着好几个条件,LogSegment.shouldRoll里同时检查:当前段大小是否超过segment.bytes(默认 1073741824,也就是 1GB)、索引是否已满、时间差是否超过segment.ms、以及偏移量差值是否超过segment.index.bytes推算出的上限。
为什么非要分段?因为 Kafka 的删除和查找都以段为单位。清理时整个段文件一起删,比在单个大文件里删中间一段高效得多;查找时先按段定位,段内再靠索引,层层收敛。这个设计和数据库的段页式存储思路是相通的。
写入本身调用的是FileRecords.append,底层就是FileChannel.write,追加模式,不需要 seek。这也是 Kafka 写入吞吐高的原因之一:纯顺序追加,没有随机写。不过要注意,写入的只是页缓存,不是真的到了磁盘——Kafka 不主动调fsync,而是依赖操作系统的刷盘策略和副本机制来保证可靠性。这一点在读代码时容易被忽略:看到append返回成功,不代表数据已经持久化到盘片。
4.2 索引为什么是稀疏的,以及稀疏到什么程度
LogSegment同目录下会有两个索引文件:.index是偏移量索引,.timeindex是时间戳索引。它们的共同点是稀疏——不是每条消息都记一笔,而是每隔index.interval.bytes(默认 4096 字节)才记一条。
为什么要稀疏?因为索引的目的是“二分查找后得到一个接近的位置,然后顺序扫描几 KB”,而不是精确定位。如果每条消息都建索引,索引文件会和数据文件一样大,得不偿失。按默认的 4096 字节间隔,一篇 1GB 的段大概有 26 万条索引项,找任意偏移量最多扫 4KB 数据,这个取舍非常划算。
| 索引文件 | 每条记录大小 | 记录内容 | 默认稀疏间隔 |
|---|---|---|---|
.index | 8 字节 | 相对偏移量 + 物理位置 | index.interval.bytes= 4096 |
.timeindex | 12 字节 | 时间戳 + 相对偏移量 | 同上 |
查找过程值得跟一遍:OffsetIndex.lookup先对索引项做二分,找到一个“不大于目标偏移量”的最大项,拿到它的物理位置,然后从那个位置开始顺序扫,直到命中目标偏移或者越过。这个“二分加顺序扫”的组合,是很多存储系统的通用套路,理解了它你就理解了为什么 Kafka 的随机读延迟虽然不如专业数据库,但依然可用。
调试这块有个小技巧:索引文件是二进制的,直接用文本编辑器看是乱码。想验证索引内容,可以写个几十行的小程序读OffsetIndex的entries方法;更省事的办法是把index.interval.bytes调小(比如调成 100),生产几条消息,索引文件会变得很密集,用十六进制工具看规律更明显。
4.3 LEO 与 HW 的推进时机,这是最容易读错的地方
LEO(Log End Offset)是本地日志的末尾位置,谁写谁涨,实现上就是当前活跃段的大小加上前面所有段的大小之和。HW(High Watermark)是“已提交”的位置,消费者只能读到HW之前的数据。
很多人以为 leader 写完就推进HW,这是错的。HW的推进依赖副本同步:ReplicaManager在每次处理 follower 的FetchRequest时,会记录该 follower 的LEO,然后取 ISR 列表中所有副本LEO的最小值作为新的HW。也就是说,最慢的那个 ISR 副本决定了HW能走多快。
这条规则直接解释了一个常见现象:为什么 ISR 里加进来一个慢副本之后,消费延迟会突然上升?因为HW被它拖住了,消费者读不到新数据。也解释了为什么acks=all的写入延迟会高于acks=1,因为要等着最慢的那个副本确认。
读代码时重点看Partition.updateFollowerFetchState和maybeIncrementLeaderHW这两个方法,前者更新 follower 状态,后者尝试推进HW,里面还有个细节:如果 ISR 发生了变化或者有副本正在追赶,HW的推进会被延迟到下一次检查,避免在副本状态不稳定时误推进。这个延迟判断不看注释很容易漏。
5. KRaft:3.0 里最值得花时间的预览特性
5.1 raft 模块与 metadata 模块的分工边界
KRaft 的本质是把元数据变更变成一条条追加到内部日志里的记录,然后用一致性协议保证这条日志在所有控制节点上一致。3.0 里这个机制被拆成两个模块,分界线很清楚。
raft模块管“日志怎么达成一致”:RaftClient定义接口,KafkaRaftClient是具体实现,负责选举、复制、提交。它对上层暴露的能力就是“追加一条记录”“读已提交的记录”“成为 leader 或 follower”这几件事,完全不知道记录的内容是什么。
metadata模块管“记录代表什么”:MetadataRecord定义记录类型(比如注册 broker、创建 topic、变更分区),RecordSerde负责序列化反序列化,MetadataImage是某个时刻的完整元数据快照,MetadataDelta是相对上一次的增量。
这种分工的好处是解耦。你想加一种新的元数据类型,只需要在metadata里加记录定义和处理逻辑,raft模块一行都不用改。读源码时也要顺着这个边界看:先搞清楚raft怎么保证顺序和一致性,再看metadata怎么把一条条记录重放成内存里的镜像,两件事不要混在一起想。
5.2 QuorumController 与老 KafkaController 的差异
老模式下的KafkaController是个复杂的东西:它监听 ZooKeeper 的节点变化,在回调里改内存状态,然后再把结果写回 ZooKeeper。这种“事件驱动加共享状态”的写法,问题是并发控制很难做对,加锁的地方多,历史遗留的竞态条件也不少。
QuorumController在 3.0 里走的完全是另一条路:单线程事件队列。所有操作被包装成事件放进一个队列,由一个专门的线程按顺序取出执行,执行过程中读写MetadataImage。因为是单线程,天然没有并发问题,状态变更也就天然线性化。
读QuorumController时重点关注两点。第一是MetadataDelta的应用方式:事件执行时不是直接改MetadataImage,而是先构造一个增量,应用成功后再替换镜像,失败就丢弃。这保证了“要么全成功要么全不影响”。第二是appendWriteEvent这种异步写日志加回调的模式,写事件时先把记录追加到 raft 日志,等提交后再回调更新镜像,中间那段时间状态是“待定”的。理解了这个异步特性,你才能明白为什么 controller 的某些操作不是立刻可见的。
5.3 预览状态下真跑起来会遇到什么
3.0 的 KRaft 是预览,能跑但不建议上生产,这句话不是免责声明,是真会踩坑。我在测试环境搭过一个三节点的 KRaft 集群,几个实打实的体会。
配置上需要指定process.roles(是broker、controller还是两者兼有)、node.id、controller.quorum.voters。这个 voters 列表要写成id@host:port的形式,三个节点必须写得完全一致,写错一个端口就会起不来,而且报错信息比较含糊,经常只提示“无法建立 quorum”。格式化存储目录要用带--standalone或者集群模式的格式化命令,这一步忘了做,启动时会直接报找不到元数据日志目录。
功能上也有限制。3.0 的 KRaft 模式下,ACL、动态配置、分区重分配这些能力还不完整,你如果在测试里依赖它们,会得到“不支持”的错误。另外QuorumController的某些路径还没做性能优化,元数据操作频繁的场景下,延迟比 ZooKeeper 模式高一些。这些都是“预览”二字的真实含义,读源码时看到TODO和UnsupportedOperationException,不用怀疑自己看错了,那就是没做完。
提示:如果你只是想验证理解,不想折腾集群,可以直接跑
raft模块里的单元测试,里面用模拟时钟和内存日志构造了各种选举、复制的边界场景,比搭集群快得多。
6. 调试与验证:让源码“跑起来”的几个手法
6.1 单节点环境加日志埋点,比空读强十倍
读源码最容易陷入的误区是“看懂了”,其实只是看明白了语法。要验证理解,只有一个办法:让它跑起来,在关键位置留下你自己的痕迹。
最省事的做法是本地起一个单节点 broker,然后把源码里的日志级别调高。Kafka 用的是自己的日志封装org.apache.kafka.common.utils.LogContext,每个类构造时都会传一个logIdent前缀(比如[Producer clientId=producer-1]),所以日志读起来很有层次。你可以直接改log4j.properties把kafka.log.Log、kafka.cluster.Partition这些包的级别调到DEBUG,生产一条消息,观察追加、滚动、HW推进的完整时序。
更主动一点的做法是自己在源码里加System.out或者临时日志。我习惯在LogSegment.append的入口加一行,打印当前段的基偏移和追加后的位置;在maybeIncrementLeaderHW里加一行,打印新旧HW和当时 ISR 的LEO列表。这两处一加,一条消息从写入到可被消费的全过程就变成时间线上的一串打印,比任何图都直观。
6.2 断点打在哪里,直接决定你能看到什么
断点位置选得好,一次调试抵得上读半天代码。我常用的几个位置列在下面,基本都是“一次命中就能看清全貌”的节点。
| 目标链路 | 断点位置 | 观察什么 |
|---|---|---|
| 消息如何攒批 | RecordAccumulator.append | 队列长度、当前批次大小、内存占用 |
| 何时真正发出 | Sender.sendProducerData | 哪些分区被ready()选中 |
| 请求如何组包 | NetworkClient.send | 目标节点、请求体大小 |
| 服务端如何落盘 | Log.appendAsLeader | 是否需要 roll、写入偏移量 |
HW何时推进 | Partition.maybeIncrementLeaderHW | 旧HW、新HW、ISR 各副本LEO |
有个细节要注意:Sender是独立线程,你在业务线程打的断点到了Sender里会变成另一个线程的调用栈。IDEA 里记得把“挂起模式”从 All 改成 Thread,不然一断就把整个生产者卡死,你连后续的响应都等不到。
6.3 拿测试用例当“带答案的源码导读”
这个方法我强烈推荐。Kafka 的测试写得相当细,尤其是core和clients模块,很多边界条件在测试里被显式构造出来了。你读Log的滚动逻辑觉得模糊,直接去翻LogTest里关于 roll 的用例,它会明确告诉你“当段大小超过阈值时会新建一段”。
更妙的是单元测试可以单独跑,反馈快。./gradlew :core:test --tests "*LogTest*"这种命令能只跑一个测试类,几十秒出结果。你可以先看测试怎么构造场景,再回源码看对应方法,来回两三次,理解会牢固得多。
对于 KRaft 这种不好搭集群的部分,测试更是唯一可行的验证途径。raft模块里有大量用模拟时钟、内存日志、mock 网络构造的选举和复制场景,读一遍相当于把协议的各种边界情况过了一遍,比自己搭三个节点折腾配置快太多。
6.4 一个我自己的阅读节奏,供参考
最后说说节奏安排。我现在的习惯是每读一个链路,固定做三件事:先用文字写下“这个链路的输入输出是什么”,再画一张只有五六个方框的草图(手画,不用工具),最后在代码里找到那张图上每根线对应的具体方法。
三件事里最有价值的是第三件。因为画图的时候人容易自我欺骗,觉得“这里应该是这样”,但去找具体方法时会发现根本不是。我读ProduceRequest的处理链路时,一开始以为服务端收到就写盘了,去找对应方法才发现中间还隔着DelayedProduce和一层Purgatory的调度,如果你不落实到方法名,这个误解会一直留着。
单条链路的源码量其实不大,难的是同时记住多条链路之间的交互点。我的经验是先把一条走通走透,再进入下一条,不要在生产者看到一半时跳去看副本,那样两条线都会变成半成品。等你能连续讲清楚“一条消息从 send 到被消费”的完整路径,再回头看存储细节和元数据管理,会发现它们都是挂在这条主线上的枝节,位置很清楚。
