Kafka Producer 的 batch.size 和 linger.ms 怎么配？
面试怎么回答
Kafka Producer 按分区组织 Record Batch。batch.size 是单分区批次的字节上限，太小会让请求碎，太大可能增加缓冲占用；linger.ms 是等待更多记录的最长时间，能用少量延迟换更好的批量和压缩。达到 batch.size 可以提前发送。我会结合单分区流量、消息大小、延迟 SLA、compression.type、buffer.memory 和 delivery.timeout.ms 做压测，而不是孤立调整两个参数。
先把这段讲顺；面试官追问时，再展开下面的原理和细节。
详细讲解
把 batch.size 调大，不代表 Producer 一定会等到这个批次装满后才发送。
如果 linger.ms 到期，或者发送线程有其他触发条件，未满批次也可以被发送。
batch.size 控制单分区批次的目标上限，linger.ms 控制等待更多记录的最长时间，两者共同影响请求数量、吞吐、压缩率和延迟。
Producer 是按分区积累批次
同一个请求可以携带多个分区的 batch，但每个 batch 对应一个分区。某个 Topic 分区很多、单分区流量很低时，即使总 QPS 不低，每个 batch 也可能长期装不满。
因此批量效果不仅取决于参数，还取决于 key 分布、分区数、消息大小和流量稳定性。
batch.size 是上限，不是发送门槛
batch.size 设置单个分区批次的字节上限。太小会产生更多请求和协议开销；过大可能为活跃分区分配更多缓冲，并增加 buffer.memory 压力。
单条消息超过 batch.size 仍可能以独立批次发送，但还受 max.request.size 和 Broker 限制，不能把 batch.size 当成单条消息唯一上限。
linger.ms 用少量等待换更大批次
低到中等流量下，Producer 可以等待不超过 linger.ms，让更多记录进入同一批次；达到 batch.size 后则无需继续等待。
较新 Kafka 版本调整过 linger.ms 默认值，因此面试中最好解释机制和版本差异，不要只背某个默认数字。
压缩、内存和超时必须联调
压缩通常按 batch 生效，批次更大往往压缩率更好，但会增加 CPU。buffer.memory 决定等待发送记录可使用的缓冲总量，耗尽后 send 可能阻塞并受 max.block.ms 限制。
delivery.timeout.ms 还要覆盖等待批量、请求等待和重试时间。只调大 linger，却不检查端到端延迟目标，很容易让监控出现新的尾延迟。
一个典型场景
某 Producer 的总流量不低，但平均 batch 仍然很小。检查后发现消息被均匀发往大量分区，单分区到达率很低。
继续放大 batch.size 基本没有收益，适当调整 linger、检查分区设计和启用合适压缩后，请求数才下降。参数必须结合分区维度指标观察，而不是只看全局吞吐。
批量调优是流量形态问题，不是单个参数越大越好。