今天，没有人能保证你构建的微服务不会遇到麻烦。当问题发生时，我们通常希望最简单的解决问题的方法是重试并再次调用 API。
重试可以是您的中间件/API 编排产品处理的一种简单机制。如果记录的性质可以通过主键之类的东西优雅地管理重复，那么这样做的挑战将始终在于 API 的业务逻辑。
例如：使用汽车注册号创建汽车记录，执行记录更新时您可能不会遇到问题。
如果解决方案必须始终在业务逻辑中实现，那么使微服务具有弹性可能是一场噩梦。然后需要审查每个业务逻辑，并确保该逻辑可以优雅地管理重复。
如果我告诉你有一种一致的方法可以在不触及业务逻辑的情况下检查重复怎么办？当您的 API 需要由您的 API 工作流重试时，您甚至无需费力地分析主键并管理重复项。
当我查看 API 幂等密钥key的实现时，我找到了答案，它非常简单明了。基本上，幂等密钥key是表示特定有效期内特定交易的唯一密钥key。API使用者在发出请求时需要发出一个称为幂等密钥的唯一密钥，而不是实现业务逻辑来检查数据重复。
- 当 API 消费者向微服务发送记录创建（例如汽车的销售记录）时，GUID 将在 HTTP 标头中设置为 Idempotency-Key。这将是表示此特定请求的唯一键。
- 当你的微服务收到请求时，微服务只需要维护一个使用幂等性密钥的列表（即密钥列表），并根据密钥列表检查新请求中的密钥，如果密钥重复则返回冲突状态。
- 密钥列表可能会在一段时间后慢慢建立。管理密钥列表的最佳方式是包含有效期或 TTL（生存时间）。因此，可以轻松地对列表进行管理，以避免由于记录过多而导致重复检查变慢。
（您可能不需要检查几个月前使用的密钥，因为几个月后您不太可能重试 API 请求）这可以通过缓存解决方案（例如启用 TTL 的 Redis）很好地管理。
根据 IETF 文档，您可以使用 HTTP 409 — 发生这种情况时的冲突状态代码。
详细点击标题