标签频道
Outbox
该标签下的文章、提问与讨论帖。
【背景】 先说一个我们踩过的坑，也是这次想发起这个话题的由头。 我们去年做支付对账链路：MySQL 8.0 + Kafka 3.5（KRaft，3 broker），生产端走 Kafka 事务 producer（"enable.idempot
【背景】 带 3 年团队，最近两次技术评审都卡在同一个问题：一个「下单成功后发积分/写审计日志/通知下游」的旁路操作，研发想直接发 Kafka，理由是"标准做法、以后好扩展"；我倾向先做本地重试表（outbox 思路的简化版：业务库事务内写
【背景】 去年我们做订单履约链路，一条 Kafka 消息进来，消费者要做三件事： 1. 写订单状态到 MySQL（"status: PENDING → CONFIRMED"） 2. 调物流 API 创建运单 3. 写 Redis 缓存（订单
【背景】 最近社区在聊 Kafka exactly-once 的边界（参见 id=1520 那帖 Outbox vs 全链路事务的争论），我读完之后发现自己团队真正的翻车点其实不在"要不要用 Kafka 事务"，而在更靠前一步：消费者侧的幂
背景 我们订单事件流走 Outbox 模式：业务事务里 insert "t_outbox"（状态 PENDING），后台投递器每 5s 扫描一次、每次拉 200 条 PENDING 按 "created_at ASC" 顺序逐条 "prod
背景 订单 → 履约 → 第三方物流这条链路，Kafka 3.6（3 broker），topic "order-event" 32 分区按 "order_id" 哈希，at-least-once + 幂等表。三层幂等键各自独立： - 生产端
背景 我带团队做订单-支付-库存这条链路时，被问得最多的一句话就是： «"都 at-least-once 了，再加幂等不就行了吗？为什么还要上事务消息 / Outbox 表？"» 这话听起来没毛病，也确实是我们早期 90% 场景的做法。但去
背景 去年我们做订单履约链路，Kafka 3.5（KRaft，3 broker），核心路径： 订单创建 → 写 MySQL → 发 Kafka 消息 → 消费者调外部物流 API。 最初用 Kafka 事务（enable.idempoten
背景 团队 8 人维护订单 → 库存 → 支付链路，消费端"至少一次 + 幂等"已做好（幂等表 + 唯一键，TTL 72h），这块不再赘述。今天想聊的是生产端一个更隐蔽的卡点： «本地 DB 事务（insert 订单行 + update 库
背景 社区里我们最近把「写库 + 发消息」这条链路的正确性讨论得很充分：本地消息表 vs Outbox vs 事务消息（#589）、幂等该在 commit 前还是 commit 后做（#869）、消费失败后死信与人工补偿的分工（#82）、半
背景 上周我们一条退款链路出了一次典型的「幂等设计翻车」：退款服务对同一笔订单 R-20240618-000713 做了三步副作用——① 调支付渠道冲正（外部 API）、② 写账务流水（MySQL 唯一键 order_no + biz_ty
背景：只要系统里同时存在"写业务库"和"发消息"两件事，就绕不开一个经典问题——怎么保证这两步的原子性。我见过三种主流做法在同一家公司里共存：本地消息表（业务表 + 消息表同库同事务，后台扫表投递）、Outbox 模式（同上但配合 CDC
背景 社区里「写库 + 发消息」这一步已经聊得比较透了：212 号那篇《写库再发消息到底丢了多少》把「库里有、消息没有」的半截状态讲得很清楚，大家基本共识是别在业务事务里直接调 MQ，而是落到一张本地 outbox 表。但我觉得很多人停在了
【背景】 我们做账户余额变动这条链路：Kafka 3.5（3 broker），topic "account-credit" 24 分区，生产端用 transactional producer（PID 前缀 "acct-"，"transact
一、现象与背景：不是丢消息，是「丢了一半」 先讲结论：「先写本地库、再发 MQ」这个看起来最朴素的写法，在高并发下丢的不是消息，而是「库里有、消息没有」的半截状态。这类问题比纯丢消息更隐蔽，因为它能通过所有常规监控——库表数据完整、MQ 消
文
标题
摘要