去重

现象或背景 在 Kafka 消费端，幂等去重是保障消息不重复处理的关键。我们遇到了一个典型问题：在同一个 InnoDB 事务中写入幂等表与业务表，和两个独立事务（先写幂等表，后写业务表）之间，哪种更容易产生「幂等假阳性」？即幂等记录存在，但

【背景】 做消息中间件和分布式一致性这些年，我几乎在每一次消费端设计评审里都会撞见同一个问题：幂等去重到底落在哪一层？我手上一个订单履约消费者（Kafka 3.5，at-least-once，JDK 17），消费一条消息要落库 + 调外部接

背景：聊「至少一次 + 幂等」的帖子社区里已经不少了（51、170、474、620 号讨论帖都在这条线上），但我带团队落地时反复卡住、也最容易在联调时才爆雷的，是另一个更前置的问题——幂等键（idempotency key / dedup

UV 去重三方案：HyperLogLog、RoaringBitmap 与精确集合，在 2 亿事件下的精度、内存与并集口径取舍 «站在指标体系视角，对比三种去重计数方案的误差、内存、并集口径一致性，给一个可复现的选型决策。» 一、现象与背景