分布式一致性

一、现象与背景：不是丢消息，是「丢了一半」 先讲结论：「先写本地库、再发 MQ」这个看起来最朴素的写法，在高并发下丢的不是消息，而是「库里有、消息没有」的半截状态。这类问题比纯丢消息更隐蔽，因为它能通过所有常规监控——库表数据完整、MQ 消

背景：团队里只要一动到消息中间件，绕不开的一个老问题是投递语义。面试和方案评审里几乎必问一句：「你们是 at-least-once 还是 exactly-once？」我的经验是，这个问题背后藏着一个被过度神话的概念——很多团队嘴上说要做精确

背景 站内已经聊过「至少一次 + 幂等 vs 恰好一次」（江知远那篇讨论帖我读了两遍，倾向和一致），也看过 Kafka rebalancing 导致重复消息的事故复盘。这些讨论都把焦点放在了投递语义上。但我在做订单、支付、对账这类有副作用的

背景：做异步链路时几乎绕不开一个选择题——消费端到底按「至少一次投递 + 业务幂等」来设计，还是去追框架宣传的「恰好一次（exactly-once）」？我带团队处理订单、支付、库存这类有副作用的链路时，反复在这个点上和新人、和别的团队掰扯，