幂等性、交付语义与去重详细指南
本文讲解幂等性使重试安全，覆盖交付语义、重复来源、幂等键、去重时限与“恰好一次”的真实边界。
中文处理结果
当服务发送请求向客户收费，但请求超时且没有响应时，会发生什么？关键问题是收费是否已完成，或者是否应该重试？
可能发生了两种不同情况：收费成功，但确认在返回途中丢失；或者请求从未到达支付服务。两种可能性产生相同的结果，这使得难以判断发生了什么以及下一步该怎么做。重试有重复收费的风险；而放弃重试则可能永远无法收费。
幂等性正是让重试变得安全的属性。当某个操作执行多次与执行一次产生相同状态时，该操作就是幂等的。例如，将账户余额设置为 500 是幂等的，因为即使执行第十次，结果也相同。相反，向余额增加 500 则不是幂等的，因为每次执行余额都会变化。业务系统中大多数重要操作都类似于后者。
在本文中，我们将详细探讨以下主题：
- 开发者可用的三种不同交付语义。
- 重复进入生产者、代理和消费者路径的三个环节，以及为何在一个环节修复对另外两个环节无效。
- 天然幂等的操作与设计成幂等行为的端点之间的区别。
- 幂等键需要什么才能工作，以及它如何失效？
- 为什么每种去重方案都有时间限制，以及一旦超过该限制，该保证的价值是什么？
- 在真实系统中“恰好一次”意味着什么，以及每种保证在哪里终止？
交付语义
阅读更多
原始正文摘录
A Detailed Guide to Idempotency, Delivery Semantics, and Deduplication
What happens when a service sends a request to charge a customer, but the request times out with no response? The burning question is whether the charge went through. Or should it be retried?
Two different things could have happened. The charge succeeded, and the confirmation was lost on the way back, or the request never reached the payment service at all. Both possibilities produce identical outputs, which makes it difficult to figure out what happened and the next action to be taken. Retrying risks charging the customer twice. On the other hand, declining to retry risks never charging them at all.
Idempotency is the property that makes the retry safe. An operation is idempotent when applying it more than once produces the same state as applying it once. For example, setting an account balance to 500 is idempotent, because even the tenth time to execute this operation, the outcome will be the same. In contrast, adding 500 to a balance is not idempotent, since every time it is executed, the balance amount changes. Most operations that matter in a business system resemble the second one.
In this article, we will look at the following topics in detail:
- The three different delivery semantics available for developers.
- The three points where duplicates enter a producer, broker, and consumer path, and why a fix at one point does nothing for the other two
- The difference between an operation that is idempotent by nature and an endpoint engineered to behave that way
- What does an idempotency key need to work, and how can it fail?
- Why every deduplication scheme has a time limit, and what the guarantee is worth once that limit passes
- What “exactly-once” means in real-world systems, and where each guarantee ends?
Delivery Semantics
Read more