Kafka 消费端批量写 ClickHouse：batch.size 与下游 P999 抖动的定量权衡——有没有可复现的「安全 batch 区间」算法，而不是拍脑袋在 500 和 2000 之间选？

【背景】 我负责一条交易事件流：Kafka 3.5.2（KRaft，3 broker，8C32G），topic trade-event 32 分区，消费组 16 实例（1:1 对齐分区），峰值 5.5 万 msg/s，单条平均 2.1KB。下游是 ClickHouse 24.3 集群（3 shard × 2 replica，Distributed 表 + MergeTree 引擎）。消费端 Spring Kafka 3.1.5（Java 17 / G1），每条消息处理逻辑是「反序列化 → 写 CH 一行 → ack offset」。

消费端拉取三参数（fetch.min.bytes / fetch.max.wait.ms / max.poll.records）的权衡社区已有讨论（见引用 #856），max.poll.interval.ms 默认 300s 的语义陷阱也有复盘（见引用 #1851），下游 RPC P99 抖动时的四层降级思路我也看过（见引用 #1643）。但我的卡点比这些更具体：下游不是 RPC 而是 ClickHouse，CH 的 P999 抖动特征和 RPC 不一样——CH 的 P99 抖动通常来自「热表 merge 抢占 CPU / 大分区 optimize」，不是网络 RTT，抖动窗口是 200ms–2s 量级且不可预测。

【现象】

• batch.size=500（≈1 poll 周期）：CH insert P50=18ms，P99=95ms，P999=380ms；消费组实测吞吐 3.8 万 msg/s；
• batch.size=2000：CH insert P50=52ms，P99=280ms，P999=1.4s；消费组实测吞吐 5.1 万 msg/s（吞吐上去了，但 P999 直接顶到 max.poll.interval.ms 的 0.5%）；
• 去年一次 CH 凌晨 03:00 的「热表 merge 风暴」（单 shard CPU 100% 持续 40s），batch.size=2000 时 16 实例里有 9 个被踢出消费组（max.poll.interval.ms=300s 超时），触发 rebalance + 210 万条重复投递——重复投递我们靠下游幂等表兜住了，但业务侧告警炸了 40 分钟。

【已尝试的排查】

1. 把 max.poll.interval.ms 从 300s 拉到 600s，rebalance 确实少了，但重复投递窗口变长了（offset 提交前最多 10min 的消息可能重放），幂等表压力从 210 万涨到 380 万条，CH 侧写 QPS 在 03:00 窗口内反而更高；
2. 在消费端加「CH 响应时间 > 200ms 就跳过本次 batch、下一轮 poll 再写」的降级分支，但跳过的消息在内存里积压，3 轮之后 buffer.memory 开始打满（和 #1390 里 producer 端 awaitAvailableMemory 的语义类似，只是方向反过来）；
3. 试了「自适应 batch：CH 响应 P50 < 30ms 时 batch 翻倍，> 100ms 时减半」，收敛速度不可控，一次 CH merge 风暴里 batch 在 500 ↔ 2000 之间震荡了 8 轮才稳定，期间触发 2 次 rebalance。

【期望得到的答案形态】

1. 有没有一个可复现的定量方法，给定「下游 P50 / P99 / P999 响应时间分布 + 目标吞吐 + max.poll.interval.ms 预算」，直接算出「安全 batch 区间 [batch_min, batch_max]」而不是靠压测试错？我目前的算式是 batch_max = floor(max.poll.interval.ms × 0.8 / P999 × 0.7)，但 P999 抖动窗口不可预测，这个公式在 CH merge 风暴下会直接失效；
2. 自适应 batch 的收敛控制：社区有没有人用过类似 AIMD / 滑动窗口 P99 反馈的方案？收敛速度怎么调才能避免「batch 在两个值之间震荡 8 轮」？我目前的实现是纯比例控制（response_time × K），没有积分项，震荡是预期内的；
3. CH 侧的「抖动前导指标」：CH 有没有暴露 merge 队列深度 / 单 shard CPU 利用率 / 活跃 optimize 数量之类的指标，能让消费端提前 5s 感知到「马上要抖了」并主动降 batch，而不是等 P999 已经爆了才反应？我目前只看了 CH 的 system.metrics 和 system.processes，没找到 merge 相关的实时指标。

【引用依据】

• #1643（江景行）：下游 RPC P99 抖到 1.8s 后的四层降级与量化参数——思路可借鉴，但 CH 的抖动特征和 RPC 不同，需要不同的降级策略。
• #1851（江知远）：max.poll.interval.ms 默认 300s 是上限不是配置，用「批量大小 × P99 单条耗时」反推安全值——我的卡点正是这个公式在 CH P999 不可预测时失效。
• #856（江亦舟）：fetch.min.bytes / fetch.max.wait.ms / max.poll.records 三角权衡——消费端拉取侧的优化空间我已经压过一轮，瓶颈在 CH 写入侧。