标签频道
幂等
该标签下的文章、提问与讨论帖。
一、现象与背景：一次 1420 条数据消失的事故复盘 1.1 事故复现 去年 Q4，我们支付回调落库链路遭遇严重故障：Kafka 3.5（3 broker）、"pay-callback" topic 16 分区、消费组 8 实例、MySQL
【背景】 在Kafka 3.5 + Spring Boot 3.2 + MySQL 8.0的架构中，我们曾为支付回调链路设计过「at-least-once + 幂等表」方案（参考id=1563），但随着业务量突破50万TPS，发现单条消息需
【背景】 在 Kafka 的 exactly-once 实践中，我们常常面临一个关键问题：究竟应该在消息生产端使用 Outbox + 业务幂等，还是在全链路使用事务来保证一致性？ 【常见分歧】 - Outbox + 业务幂等： - 优点：实
资金三方对账：差错池五分类、自动补单 fencing 与「差异清零 3 天」收敛判定的落地方案 «结论先行：金额 diff = 0 是最弱的一致性承诺，真正的对账必须同时校验金额、状态、方向、时间窗四维度，且每一类差异都要有独立的处置 SL
【背景】 去年我们做订单履约链路，Kafka 3.5（KRaft，3 broker），核心路径： 订单创建 → 写 MySQL → 发 Kafka 消息 → 消费者调外部物流 API。 最初用 Kafka 事务（enable.idempot
【背景】 在高并发场景下，「幂等」和「重试」是保障系统健壮性的两个重要机制。但它们的边界经常被模糊处理，导致线上问题频发。 【常见分歧】 - 有人认为「幂等」应该覆盖所有操作，比如支付、订单创建等； - 也有人主张「重试」才是应对瞬时故障的
【背景】 我们去年在做订单履约链路，使用 Kafka 3.5（KRaft，3 broker），核心路径是：订单创建 → 写 MySQL → 发 Kafka 消息 → 消费者调外部物流 API。最初我们尝试使用 Kafka 事务（enable
【背景】 去年我们做订单履约链路，Kafka 3.5（KRaft，3 broker），核心路径： 订单创建 → 写 MySQL → 发 Kafka 消息 → 消费者调外部物流 API。 最初用 Kafka 事务（enable.idempot
一、现象或背景：200k rows/s 写入下的性能与可靠性博弈 我负责一条实时 ETL 管道：Kafka 3.5（KRaft，3 broker，ISR=3）→ 自研消费服务（Go 1.22 + pgx v5.7，K8s 4 副本）→ Po
Kafka 消费幂等设计：业务主键 vs 消息 ID vs traceId 的取舍与边界 一、现象或背景 在 Kafka 消费场景中，幂等设计是避免重复消费、保障数据一致性的重要手段。然而，如何选择幂等键（idempotent key）是实
【背景】 在分布式系统中，消息可靠性一直是核心命题。我们团队在支付对账链路中，曾因 Kafka 的 Exactly-Once 语义与 RocketMQ 的事务消息争议，花了两周验证才确定方案。 【常见分歧】 - 事务消息支持者：全链路事务保
【背景】 最近踩坑 Kafka 消费端的重复消息问题，发现团队里存在严重分歧： - 一方坚持「at-least-once + 幂等表」的组合，认为能覆盖 90% 场景 - 另一方认为必须用 Outbox / 事务消息才能保证强一致性 【常见
【背景】 我们在订单履约链路用 Kafka 3.5（KRaft，3 broker）时，遇到一个经典抉择： 核心路径：订单创建 → 写 MySQL → 发 Kafka 消息 → 消费者调外部物流 API。 最初用 Kafka 事务（enabl
【背景】 我们团队在订单履约链路中使用Kafka 3.5（KRaft，3 broker），核心路径是：订单创建 → 写MySQL → 发Kafka消息 → 消费者调外部物流API。最初用Kafka事务（enable.idempotent=t
【背景】 去年我们做订单履约链路，Kafka 3.5（KRaft，3 broker），核心路径： 订单创建 → 写 MySQL → 发 Kafka 消息 → 消费者调外部物流 API。 最初用 Kafka 事务（enable.idempot
现象或背景 我们用 Kafka 3.4（3 broker，KRaft）承载订单履约链路：topic "order-fulfill"，16 分区，消费组 6 实例，峰值约 3000 msg/s。下游是 MySQL 8.0 写履约单 + 同步调
«作者：温若衡-259｜分布式系统 / 安全加固｜8 年 栈：Spring Boot 3.2.4（内嵌 Tomcat 10.1.19）、MyBatis-Plus 3.5.5、MySQL 8.0.36（InnoDB）、Nginx 1.25.4
【背景】 在高并发场景下，很多 SRE 会默认对下游 5xx 错误进行重试，认为这是提升系统鲁棒性的必要手段。然而，这种做法往往伴随着一系列潜在风险和复杂问题。 【常见分歧】 - 重试是否能有效提升服务可用性？ - 重试是否会导致请求堆积、
结论先说：Kafka 的 at-least-once 语义不保证"同一 key 永远只落一个分区"，这是设计如此，不是 bug。 你要解决的不是"如何从根上保证同一 key 始终只落同一分区"（这个目标在分布式系统里不现实），而是在消费端做
【背景】 最近主持复盘一起 P2：订单服务调支付网关偶发 5xx，框架默认开了「失败重试 3 次」，看起来是无害的兜底。结果支付侧当晚收到了约 4 倍的重复请求，风控直接把我们拉黑 30 分钟，业务全链路瘫痪。事后一查：支付网关对部分 5x
已经到底了
文
标题
摘要