posts
这里是全站文章的归档入口，下面是按时间倒序排列的全部文章。若想按主题浏览，请从首页的专题分类进入。
Sender 是一个 while 循环：拉就绪分区、按节点抽批、发请求、poll 响应。本节读 4.3.0 的 runOnce、sendProducerData 与 NetworkClient.poll，并用三组对照实验把 max.in.flight 与重试的乱序关系做实：5 个在途出现 9 处乱序，1 个在途与开启幂等均为 0 处。
每个分区一条双端队列、每个批次占满 16 KB 缓冲、整块内存由 BufferPool 统一分配。本节读 4.3.0 的 append、ready 与 allocate，实测 32 KB 缓冲池被打满后 send() 阻塞 5 秒，并纠正一个常见说法：异常不是从 send() 抛出的，而是从 Future 里拿到的。
KafkaProducer 只有两个线程：调用 send() 的应用线程，和跑 Sender 循环的 kafka-producer-network-thread。本节逐行读 4.3.0 的 send() 与 doSend()，实测回调跑在哪个线程、close() 在回调里为什么被降级成零超时，并划出共享状态与线程安全的边界。
从 arch-lab 订单系统一次乱序推送把实例配置从 v87 拉回 v85 的事故切入，对比推送与轮询的延迟、一致性和故障面，给出以版本水位拒绝陈旧快照、区分重复与冲突、并用新版本重发旧内容实现回滚的 Go 实现与本机可复现的真实测试输出。
周会上两张报表差了三万多元：一张含退款，一张不含，双方都认为自己是对的。文章先定义 GMV、订单数、退款数和净 GMV 的口径，再说明业务库与财务库对不上时如何用容差和完全相等条件判断，并给出 Row、Totals、Aggregate、Check 的 Go 实现和真实测试输出。
group.protocol 一个取值就换掉整套消费组实现：classic 走客户端分配和 JoinGroup/SyncGroup，consumer 走服务端分配和 ConsumerGroupHeartbeat。本节用反射打印真实实现类，核实 4.3.0 源码里的分支，再从 __consumer_offsets 读出 KIP-848 新增的五种记录，并给出迁移时必须先改的配置。
两个消费者加进同一个组，分区怎么从 3-0 变成 2-1？本节用实测时间线拆开 JoinGroup、SyncGroup、Heartbeat 三个阶段，说明 leader 成员在哪一步算分配、eager 与 cooperative 各自撤销哪些分区，以及 stop-the-world 卡在 poll() 的哪一行；再让一个消费者停 poll 超时，看它如何被踢出。
位移不是消息的一部分，它被写进一个叫 __consumer_offsets 的内部 topic。本节从段文件里解出真实的 key/value，说明一个组的位移为什么全落在同一个分区，用实测输出区分「消费位置」与「已提交位移」，并把 --describe 的六列和 offsets.retention.minutes 的边界讲清楚。
客户端的 Metadata 不是一个定时器，而是由「过期」和「显式请求」两个条件驱动的缓存状态机。本篇按 4.3.0 源码逐段读 timeToNextUpdate、requestUpdate、update、failedUpdate 与 NetworkClient 的 maybeUpdate，并用 DEBUG 日志量出 2 秒和 60 秒两种 max.age 下的真实请求次数。
broker 重启后 brokerEpoch 会变，leader 变更会以一条记录进入 __cluster_metadata，再经 broker 的元数据缓存传到客户端。本篇实测分区扩容在 metadata.max.age.ms=5s 与 600s 下的可见时间差，并说明为什么 broker 掉线时客户端反而恢复得很快。
KRaft 把集群元数据本身写成一条 Raft 日志：topic 创建、broker 注册、leader 变更都是 __cluster_metadata 里的记录。本篇用 kafka-dump-log.sh 解出 4.3.0 单节点的真实记录序列，说明 controller quorum 如何选举、元数据如何提交，以及为什么 4.x 不再需要 ZooKeeper。
停掉 leader 之后，分区多久能用？答案取决于集群能不能「干净」地选出新 leader。本节实测三节点 KRaft：停 leader 后 1.8 秒新 leader 就位、数据零丢失；但停掉两个 broker 会让 controller quorum 失去多数派，整个集群连元数据都查不了——这是 KRaft 和 ZooKeeper 时代最容易被忽略的差别。
acks=all 不是「写完就成功」，它真正的含义是「等 ISR 里的副本都写完」。ISR 会收缩，收缩到低于 min.insync.replicas 时写入被拒。本节用三节点集群实测：杀掉一个 broker 仍能写，再杀一个就报 NOT_ENOUGH_REPLICAS，并解释这两个参数为什么要成对出现。
生产者明明返回了 offset 5 到 9，消费者却一条都读不到——这不是 bug，是 LEO 与高水位分离的正常状态。本节用 docker pause 冻结一个 follower，在同一秒里同时读出「leader 磁盘上有 19 条」和「消费者只能看到 16 条」，并给出 stop、pause、崩溃三种失效下 ISR 收缩的真实时序。
4.3.0 的默认分区逻辑不在 DefaultPartitioner 里，而在 BuiltInPartitioner：key 存在时用 murmur2 取模，key 为 null 时按字节粘性切换。本篇用 6 个分区的实测序列说明粘性批次、key 基数与热点 key 三种倾斜，并给出自定义 Partitioner 的完整写法和边界。
运营在后台重复点了两次“执行”，活动库存被扣了两次；审批流、状态机和幂等缺少任何一层都会出问题。文章说明草稿、待审、通过、驳回、已执行的迁移规则，终态为什么必须拒绝所有动作，以及调用方如何用幂等键和条件更新兜住重复请求，并给出 Op 与 Next 的 Go 实现和真实测试输出。
acks=0 的成功只代表写进 socket，acks=1 的成功只代表 leader 写进本地日志，acks=all 才等到 ISR 确认。本篇用单节点杀 broker 的实验量出三种取值的失败窗口，拆开 retries 与 delivery.timeout.ms 的关系，并用批次头里的 PID 与 sequence 说明幂等生产者能去掉哪一种重复。
batch.size 是批次上限，linger.ms 是等待上限，compression.type 作用在整批数据上。本篇用五组参数和磁盘日志大小把三者的相互作用拆开：为什么批次满了 linger 就不起作用、为什么压缩率取决于批次而不是单条消息，以及 CPU 与带宽如何交换。
日志不会因为被读过就删除，它的生死由 cleanup.policy 决定。本节实测 delete 策略按时间整段回收，以及 compact 策略如何把同 key 的多次写入压成最后一条、墓碑如何先删除旧值、又为什么墓碑自己还要再等一轮清理，并给出两种策略的选择边界。
能通过 JSON.parse 的配置照样能让活动打不开。本节把类型、范围、枚举、重复、引用与孤儿行变成带错误码的校验报告，跨表检查引用完整性，再用客户端构建号与配置版本矩阵决定谁能读哪一版；最后给出以整数基点计算的灰度判据，明确 hold、promote 与 rollback 的边界。