这条把三个经常被混为一谈的问题拆开了：请求重复、消息投递语义、事件顺序。工程里最危险的误区，是把“重试”当成天然可靠性。超时只能说明调用方没等到结果，不能证… · @fireandstart · TwKit

@fireandstart

这条把三个经常被混为一谈的问题拆开了：请求重复、消息投递语义、事件顺序。工程里最危险的误区，是把“重试”当成天然可靠性。超时只能说明调用方没等到结果，不能证明服务端没执行；如果扣款已经成功、响应却在路上丢了，客户端重试就可能把一次意图变成两次副作用。幂等键因此不能只是短期缓存里的“见过这个请求”，它需要和业务写入处在同一个原子边界：处理结果与去重记录要么一起提交，要么一起回滚。这样重试才能安全地拿回第一次结果。 投递语义也要讲清楚。至少一次通常意味着可能重复，至多一次可能丢失；“恰好一次”往往依赖特定系统边界和约束，不能直接推导成端到端绝不重复。消息有序同样不是抽象开关：通常需要先定义按什么键排序、允许多大延迟，以及一个慢事件会不会阻塞后续事件。否则为了保序引入的串行化，可能把吞吐和可用性一起压低。 所以更实用的设计顺序是：先明确可接受的丢失、重复和乱序，再为每个副作用定义稳定的业务键与原子更新点，最后根据成本选择重试、去重、补偿或人工对账。默认失败会发生，系统才有机会在故障恢复时仍然维持业务不变量。

曝光 23 · 评论 2 · 点赞 0 · 书签 0