交易明细从 Kafka 经托管 sink 写进三副本 ClickHouse，单日一千多万到三亿多行。现状是按结算日分区、至少一次写入、单分片三副本靠 Keeper；按键折叠、报表增量聚合加对账重算、整分区替换修数据在 lab 上验过，还没在现有集群上执行。

数据少了不报错，常常很久之后才被发现。排查从上游和 Kafka 开始，再看 connector 的错误处理：默认配置下一条坏记录让 task 停住；配了 DLQ，同批同分区的好记录跟着进 DLQ；只开容错不配 DLQ，整批静默消失。

Kafka 到 ClickHouse 的链路只能做到至少一次，三种重复都会落库。方案不开 sink 的 exactlyOnce，以 ReplacingMergeTree 按业务键折叠为主，入口调大去重窗口，报表靠对账重算兜底；lab 上验过，还没在现有集群上执行。

同一条 Kafka 到 ClickHouse 的链路上，重复行能从 producer 重试、sink 超时重投、task 重启重放和人工补发四处进来。lab 实测官方 sink 的 exactlyOnce 挡得住重放，挡不住超时重投，打开之后崩溃重启默认会停在状态冲突上。

按峰值每秒 6 万到 7 万条、每天约 2.4 TB 主分片数据推算日志集群：Kafka 缓冲、节点角色分离、写入调优和 data stream 滚动；热数据在 14 台本地 NVMe 节点上保留 7 天，快照在 S3 保留约 30 天。

H5 应用容器和奖池活动条由 Cloudflare Workers 上的容器页、overlay 和 EKS 里四个 Spring Boot 服务组成，结构由同源入口、一张凭证两处验签、钱只走交易平台、推送层不存状态和 overlay 固定入口发版五条决策定下。

同一个业务键在 ClickHouse 里出现两行完全一样的数据，写入时间相差 30 秒到两分钟。前一天吞吐掉到常态零头的十几个小时一行重复都没有，出重复的是第二天吞吐看着正常、Keeper 在途请求涨到几千的那三个小时。

一个 producer 八小时没写进消息，根因是有人给同一个 service account 加了一条 DENY。Confluent Cloud 上 API Key 只做认证，ACL 认的是账号，一次权限改动的作用面是账号名下所有 key。

同一个 JVM 里只有走 Confluent 序列化器的 topic 发不出去：它的配置类在静态初始化时按 TCCL 解析默认值的类名，而 fat jar 下那个 TCCL 看不见 BOOT-INF/lib；之后这个类不会再重新初始化，实例只能换掉。

结合官方文档、工程资料与技术文章，整理 Spring Boot 3.5 + Java 25 微服务中 Resilience4j 在 HTTP、Redis、Kafka、DB 外部调用上的使用边界与实践建议。