共计 1062 个字符，预计需要花费 3 分钟才能阅读完成。
背景
平台有局部 API 须要保障接口幂等性，避免业务频繁刷 API 造成资源节约，或者不小心重发消息影响业务。
名词解释
接口的 幂等，指的是一个操作反复执行 N 次失去的后果（副作用）与执行一次是相等的。比方在 HTTP 协定中，GET 申请，会失去同样的数据。然而对于 POST 和 PATCH 的接口，每次申请动作失去后果都是不同，这里是不幂等的，而有的是时候对接口有幂等的要求。
比方银行的转账，因为各种起因可能同一个申请会被屡次发送，然而后果只会胜利转账一次，其余转账不会失效。
解决方案
目前业界有绝对成熟的解决方案，包含 乐观锁，乐观锁，防重表和应用 Token。上面别离介绍以上 4 种解决方案。
乐观锁
流程：
- 申请过去的时候开启事务，对查问事件（比方订单）加锁
- 判断事件是否合乎执行条件
- 在全副执行完后，提交或回滚
毛病：执行工夫长，乐观锁容易锁住整表，导致服务不可用问题。
乐观锁
实现：通过版本号的形式，在更新事件的时候锁表（大部分工夫不会锁表），比方：
UPDATE table set usage=usage+1, version=version+1 where uuid = XXX and version = XXX 即便多个申请过去，因为进来的 version 是雷同的，然而 DB 中的版本号曾经被更新, 批改条件不成立，也就是说不会被屡次更新。
毛病 ：应用 主键 或 惟一索引 来更新，应用 行锁 而不是 表锁。
防重表
流程：
- 建设一张防重表，应用事件 ID (比方订单号) 作为惟一索引
- 在发动申请时依据事件 ID 在 防重表 中新增一条记录
因为是 惟一索引，重发的申请增加记录不会胜利，第一个进入的事件能够被执行（事件实现后，能够删除防重表的记录）
毛病：多保护一张数据表，减少业务逻辑复杂度。
应用 Token
流程：
- 业务方在调用 API 的时候，在 Header 里传递一个
X-Request-Id参数（随机 id, 相似 token） -
平台接管到这次申请，判断在 缓存 里是否存在对应
X-Request-Id对应的记录：- 如果记录存在，表明这条音讯曾经被发送过，接口返回 HTTP 412 Code
- 如果记录不存在，将该记录刷到缓存里，发送音讯
- Response 的 Header 也返回
X-Request-Id
毛病：流程比防重表更简单。
幂等性优缺点
长处：
- 实现接口的幂等性
- 不须要关怀随机 id 的业务逻辑
毛病：
- 减少了实现的复杂度
- 减少运维老本
总结
基于咱们以后的业务现状，应用 X-Request-Id + 缓存来反对音讯 API 的幂等操作。尽管计划依赖 Redis, 然而平台自身就有应用缓存，运维老本这个毛病可忽略不计，逻辑实现绝对简略。综上能够设施。
参考
- 在 API 中实现幂等性
正文完
