完整内容在此, 干话王_幂等性 Idempotence

幂等性(Idempotence) 是分散式系统和微服务架构中的一个关键概念, 尤其是在处理 retry 与 防止重复操作时非常重要. 简单来说, 幂等性意味着无论你发送相同的命令多少次, 结果都是一样的, 系统不会改变其状态, 甚至可能不会执行重复的操作. 对于网路异常或请求超时等情况下非常重要, 因为 client 可能会 retry, client 属于我们不可控的对象, 但我们服务方会希望避免同一操作被重复执行.

幂等性的关键概念

  • 幂等操作该操作是幂等的, 表示重复执行不会产生额外的影响或状态的改变. 例如, 使用相同的数据来更新资料的状态, 或调用建立纪录的端点, 这些都不会导致重复纪录的产生.

  • 幂等栏位(Idempotency Key)在许多系统的设计中, 请求或命令中都会包含一个唯一识别符(幂等栏位), 以确保如果请求被retry, 系统能够识别这是重复操作, 可以选择跳过执行. 幂等栏位通常是由client端产生.

    • Retry Attack（重试攻击） 是一种与网络安全相关的攻击方式，攻击者利用系统允许的重试机制，通过多次尝试重复提交请求，来实现以下目标：

    • 绕过安全检查：例如，发送多次支付请求，试图重复扣款或重复使用一次性 token。
    • 猜测敏感数据：例如，不断重试不同的凭证或密码，试图获取有效的凭据。
    • 利用系统异常：利用系统在某些情况下的异常行为（如高併发导致系统容量耗尽或错误处理），达成攻击目的。

    幂等栏位的设计原则

    • 唯一性：每个请求都应该有一个唯一的标识符，避免重复。
    • 可追踪性：幂等栏位应该能让服务端快速定位相关请求, (很类似 OpenTelemetry 中的 Trace Id)。
    • 安全性：避免使用敏感信息（如用户名、密码）作为幂等栏位。
    • 可控性：通常由client端生成，因为服务端无法完全控制请求的重发行为

    幂等栏位的组成

    幂等栏位通常是一个唯一识别符（UUID 或类似的值），但可以根据业务需求进行扩展设计。以下是常见的组成方式：

  • 使用 UUID（Universally Unique Identifier）或 GUID（Globally Unique Identifier）。idempotency_key: "4f9e8c3a-9a6b-4d7a-8c3e-123456789abc"优点：生成简单且不依赖具体业务逻辑。缺点：无法反映请求的业务语义，仅适合通用场景。

  • 基于业务的唯一标识符将业务相关的资讯组合起来，生成幂等栏位。例如：idempotency_key: "order_12345_user_67890"优点：幂等栏位与业务强相关，便于排查问题。缺点：栏位设计需要根据具体业务场景定制, 不容易有统一标準.

  • 基于 Hash 的唯一标识符将请求的核心参数内容（如用户 ID、订单 ID、请求时间等）拼接后产生 hash value 作为幂等栏位。idempotency_key: SHA256("user_67890_order_12345_20250124T095200")优点：减少幂等栏位的长度，并隐藏业务细节。缺点：需要额外的hash计算，增加了一些处理成本。

  • 基于 Timestamp 的唯一标识符在唯一标识符中加入时间戳，确保每次请求的幂等栏位不同。Snowflake Id 和 UUIDv7 就基于这种概念.idempotency_key: "4f9e8c3a-9a6b-4d7a-8c3e-123456789abc_20250124T095200"优点：适合需要频繁生成幂等栏位的场景。缺点：client 端如果是使用发出请求时的 timestamp 来产生唯一标识符, 会影响重试机制的有效性。

    • 数字或唯一标识符字串(UUID这类), 各有优缺点.数字的优点是好比较, payload size小; 缺点是极易被猜测出来范围.唯一值字串反过来, 但缺点大部分能用钞能力解决.

    完整内容在此, 干话王_幂等性 Idempotence