幂等性检查

重复执行，结果不变

幂等性是一个数学词汇，但它的核心思想很简单：无论你做多少次，结果都是一样的。

在计算机系统中，这意味着一个操作可以安全地重复执行，不会产生意外的副作用。

转账 100 元，执行一次是转 100，执行十次还是转 100。删除一个文件，删除一次是删除，删除十次还是那个状态。

这听起来理所当然，但现实的系统充满了不确定性。网络会超时，服务会重启，请求会重发。如果没有幂等性保障，重复就会带来灾难。

不确定性是常态

分布式系统的本质是不确定性。

消息可能丢失，可能延迟，也可能重复。你发出一个请求，等了 5 秒没有响应。你不知道是服务器没收到，还是收到了但正在处理，还是已经处理完了但响应丢失了。

在这种不确定性面前，重试是最常见的策略。超时了就重试，失败了就重试。但重试带来一个问题：如果服务器其实已经处理过了，重试会不会造成重复执行？

这就是为什么需要幂等性。它不是为了理想情况设计的，而是为了应对混乱。

在一个完美的世界里，每个请求只会被处理一次，消息不会丢失，网络不会中断。但现实不是这样。幂等性是对现实的妥协，也是对不确定性的应对。

两种策略

实现幂等性有两种基本思路。

第一种是唯一标识。 每个请求带一个唯一的 ID，服务器记录下所有处理过的 ID。收到请求时先检查这个 ID 是否已经处理过。如果处理过，直接返回之前的结果；如果没有，执行操作并记录 ID。

这个策略简单直接，但需要存储。你要保存所有处理过的请求 ID，这在高频操作下会成为负担。你还要决定保存多久——永久保存不现实，但保存时间太短可能遇到延迟很久的重复请求。

第二种是操作本身的幂等性。 有些操作天然就是幂等的。查询操作不改变状态，执行多少次都一样。删除操作也是幂等的，删除一个不存在的东西不会出错。设置操作通常也是幂等的，把一个值设为 X，设一次和设十次结果相同。

问题在于，不是所有操作都能设计成天然幂等的。累加、扣减、追加，这些操作本质上不幂等。执行一次和执行十次的结果完全不同。

对这类操作，你需要转换思路。不要设计成"账户余额减 100"，而是设计成"将订单 X 的支付状态设为已支付，相应调整余额"。前者不幂等，后者可以通过状态判断实现幂等。

边界与成本

幂等性不是免费的。

存储请求 ID 需要空间。检查 ID 是否存在需要查询。这些都是成本。

更复杂的是时间边界。你要保存请求 ID 多久？一小时？一天？一周？

保存时间太短，延迟很久的重复请求会被当作新请求处理。保存时间太长，存储成本和查询性能都会成为问题。

这里没有完美答案。你需要根据系统特点做权衡。

如果你的系统网络稳定，超时重试间隔短，那么保存时间可以短一些。如果你的系统会有人工重试，或者消息队列可能延迟很久，那么保存时间需要长一些。

幂等性的边界，反映了你对系统混乱程度的预期。

不只是技术问题

幂等性检查背后，是一种思维方式的体现。

它承认失败是必然的。网络会断，服务会挂，请求会重复。系统设计不应该假设一切正常，而应该假设一切都可能出错。

它拥抱防御性编程。不要期待客户端表现完美，不要期待网络永远可靠，不要期待用户只点一次按钮。做好准备，让重复变得安全。

它追求的是稳定性，而不是效率。幂等性检查增加了复杂度，可能降低性能，但它换来了确定性。在混乱的环境中，确定性比效率更重要。

更广的视角

幂等性的思想不局限于技术系统。

生活中也有类似的场景。你发了一封重要邮件，不确定对方收到没有，你会不会再发一次？如果再发，你希望对方不会因为收到两封而困惑或产生误解。

这就是人际交往中的"幂等性"。重复的沟通不应该产生负面影响。"我再说一次"不应该被理解为"我认为你没听懂"，而应该被理解为"我想确保信息传达准确"。

组织协作也是如此。一个决策被重复确认，不应该导致重复执行。"确认一下我们是不是要做 X"不应该触发 X 的重复启动。

系统需要有机制来识别：这是新的指令，还是对旧指令的确认？

稳定性的代价

追求幂等性是有成本的。

你需要额外的存储，额外的检查，额外的逻辑。你的代码会变得更复杂，你的系统会增加延迟。

但这个成本是值得的。

因为不幂等的代价更高。用户重复点击按钮导致重复扣款，消息队列的重复投递导致数据错乱，分布式事务的失败重试导致状态不一致。

这些不是理论上的风险，而是真实发生的事故。

幂等性是一种保险。 你为稳定性付出一些代价，来避免混乱带来的灾难。

在一个充满不确定性的世界里，能够安全地重复，本身就是一种确定性。

---

---

博客内链

• 队列、可靠性与系统边界 - 队列系统中的幂等性需求
• 指数退避超时 - 重试场景下的幂等性保证
• 错误隔离 - 幂等性与错误隔离的协同作用