posts
这里是全站文章的归档入口，下面是按时间倒序排列的全部文章。若想按主题浏览，请从首页的专题分类进入。
一个 broker 停机一段时间再上线，是接着拉落后的部分，还是把整段日志丢掉重来？本节实测两种情形：日志未截断时 100 MB 追赶约 5 秒；leader 的 log start 越过 follower 之后，follower 丢掉 311 MB 旧段、从 offset 349995 重建。另附 1 MiB/s 限流实测：稳定在 0.96–1.02 MiB/s。
从一次单测全绿、上线后却退款不退券的活动事故切入，说明券与活动的端到端验证必须覆盖库存、预算、防刷、退款回补四类不变量。给出用 httptest 真跑多步 HTTP 场景、失败后继续执行并捕获 panic 的 Go 实现与测试，复盘模块级 mock 掩盖的预算重复占用。
三节点逐个重启，先停 follower 还是先停 leader，差别有多大？本机实测：按 follower→leader 顺序，200 次写入零失败、最长 43ms；按 leader→新 leader 顺序，多了一次选举、一次写入卡了 2.6 秒。而 min.insync.replicas=2 时，再停一台，生产者 26 毫秒内收到 NotEnoughReplicasException。
三个 broker 配了两个机架，三副本的 topic 会怎么放？本节在三节点 KRaft 上实测：每个分区都是 2 个副本落在同一机架、1 个在另一机架，12 个分区无一例外——只要机架里只有一台 broker，机架感知就无法把 3 个副本分到 3 个故障域。文中还统计了跨机架复制链路的真实占比与 broker.rack 的配置边界。
容量规划的输入是业务事件率，不是 Kafka 参数。本节用 libraryd 六个事件主题的假设流量，把一个 Java 程序跑出磁盘、分区、内存、网络四笔账，并实测了 retention.bytes 与 retention.ms 同时设置时谁先触发，以及为什么磁盘占用会超出 retention.bytes 这个「上限」。
acks、batch.size 与 linger.ms、compression.type 三组参数同时拉扯吞吐、延迟与持久性，任何「三个都要」的方案都只是把成本挪到了别处。本节用四组配置各跑两轮压测，给出对照表，并指出这些数字只能看相对关系，以及单节点为什么测不出 acks 的真实代价。
kafka-producer-perf-test.sh 只输出九列，但每一列都可能被误读。本节逐个拆开 num-records、record-size、throughput 与已弃用的 producer-props，贴出三次同参数运行的完整原文，用 94k 与 203k 的差距说明单次数字为什么不能当基准，并划清客户端数字与 broker 真实能力之间的边界。
分区数不是免费的并行度。本节在 1、10、50、200 个分区的 topic 上实测：每个分区稳定占用 1 个文件描述符和 2 个 mmap 区域，controller 元数据日志约 105 字节/分区，启动加载 261 个空日志要 780 毫秒，并解释为什么上千分区会同时拖慢选举、再平衡与尾延迟。
follower 不是被动接收推送，而是主动向 leader 发 fetch。本节用两节点 RF=2 集群实测 acks=1 与 acks=all 的写入速率差，停掉一个 broker 后观察 min.insync.replicas=1 为何仍能写、吞吐为何反而变快，并解释 replica.fetch.* 四个参数各自管什么。
一条 Produce 请求进入 broker 后要经过 acceptor、processor、请求队列和 KafkaRequestHandler 四道关。本节用两节点集群实测线程清单与队列深度：3 个 acceptor、9 个网络线程、16 个处理线程，并解释 mute/unmute 为什么让同一条连接同一时刻只处理一个请求。
容量、文件描述符、IO 线程是三笔独立的账。本节用 JDK 25 跑出 libraryd 三档流量的容量估算表，并在容器内实测 fd：12 个新分区只增加 14 个句柄，删除主题后句柄要 60 秒才释放，而不少环境默认的软限制只有 1024，远不够 3000 分区的集群使用。
把 segment.bytes 调到 1 MB 后写入 4.5 MB 数据，观察段文件如何按 680 条一批滚出 5 个段；删除一个 .index 再模拟崩溃重启，抓住 Could not find offset index file 与 rebuilding index files 两行日志，验证索引确实是从 .log 重建的。
从一笔“已发货却查不到物流”的客诉切入，拆解下单、支付、履约、对账四个阶段各自的同步或异步边界与失败语义，说明为什么履约超时不能当成成功。给出用阶段秩、步骤名校验链路形状的 Go 实现与表驱动测试，并复盘把超时当成功导致的虚假发货与对账差额。
顺序写为什么快、零拷贝到底省掉哪两次拷贝、Kafka 为什么把缓存交给操作系统？本节把约 10 MB 数据写进单分区，用 kafka-dump-log.sh 验证 625 个批次的 position 首尾相接，再对照 /proc/meminfo 的 Dirty 值与内核脏页参数，解释刷盘抖动从哪里来。
metrics() 构造后有 77 项，跑起来变成 110 项，同一个名字在不同 group 下含义不同。本节把 producer-metrics 里与背压、批次、延迟相关的指标拆开口径：实测打满 1 MiB 缓冲时 buffer-available-bytes 归零、waiting-threads 变 1，并对比客户端 lag 为 0 而服务端 LAG 为 200 的同一条消费链路。
onSend 在调用线程、序列化之前执行，onAcknowledgement 在 Sender 线程、用户回调之前执行，这个位置差决定了埋点能不能测到真实耗时。本节实测 100 条消息的 send→ack 分布，验证链上拦截器抛异常后仍继续、ack 回调里的 headers 只读，以及 onSend 里 sleep 会等量拖慢 send()。
序列化发生在 send() 的调用线程里，而不是 Sender 线程，这决定了异常在哪抛、可变对象何时被读。本节用手写 TLV 格式在同一 topic 混写 v1/v2：严格老读者在第 4 条抛 RecordDeserializationException，宽容老读者能读完却丢掉新字段，复用字段编号则静默读错值。
自动提交不是后台定时器，它只在 poll() 里触发；提交的值是 position，而 position 在 poll 返回记录时就已推进。本节用源码和实测把这个时间差做成丢消息场景：处理 3 条，位移却已提交到 10，close() 时更进一步到 20。
4.3.0 的 Fetcher 只剩 9,378 字节，因为拉取逻辑被拆进了 AbstractFetch、FetchCollector、CompletedFetch 和 FetchBuffer。本节把 poll 的一次完整路径走一遍，说明请求按 leader 节点合并、分区不按 lag 排序，以及 max.poll.records 与两个字节上限的真实关系。
KafkaConsumer 在 4.3.0 里只是一个门面，真正的实现是 ClassicKafkaConsumer 或 AsyncKafkaConsumer，分支点在 ConsumerDelegateCreator 而不是 KafkaConsumer 本身。本节用源码和三次运行把默认值、判定逻辑、以及为什么 getClass() 永远测不出真实实现讲清楚。