文章目录：
- 前言
- 幂等性与重复提交比较
- SQL 语句幂等性
- SELECT
- UPDATE
- DELETE
- INSERT
- 实现方案
- 方案一
- 方案二
- 小结
- 推荐阅读
前言
什么是幂等性？一次和多次请求某一个资源，对资源本身所产生的的影响均与一次执行的影响相同。
幂等性是系统服务对外的一种承诺，承诺只要调用接口成功了，多次调用对系统的影响是一致的。
幂等性与重复提交比较
幂等性 更多使用的情况是第一次请求知道结果，但是由于网络抖动或连接超时等情况未进行正常返回，在这种情况下系统自动再次发起请求，其目的是确认第一次是否请求完成。
重复提交 更多使用的情况是第一次请求成功或请求结果暂未返回的情况下，人为的进行多次操作。
SQL 语句幂等性
SELECT
SELECT * FROM `user` WHERE id = 1
无论执行多少次都不会对资源造成影响，查询具有天然的幂等性。
UPDATE
UPDATE `user` SET status = 1 WHERE id = 1;
无论执行成功多少次状态都是一致的，这种场景是幂等操作。
UPDATE `user` SET score = score+1 WHERE id = 1;
每次执行的结果都会发生变化，这种场景不是幂等操作。
根据具体场景看能否写成这样的 SQL ：
UPDATE `user` SET score = score+1 WHERE id = 1 AND score = 59;
无论执行成功多少次分数都是一致的，这种场景是幂等操作。
DELETE
DELETE FROM `user` WHERE id = 1;
无论执行成功多少次数据都是一致的，这种场景是幂等操作。
INSERT
INSERT INTO `user` (`name`, `status`, `score`) VALUES ('tom', 1, 80);
每次执行的结果都会发生变化，这种场景不是幂等操作。
根据具体场景看能否为 name 创建一个唯一索引，或执行类型这样的 SQL ：
INSERT INTO ... values ... ON DUPLICATE KEY UPDATE ...
// 注意，要使用这条语句，前提条件是这个表必须有一个唯一索引或主键。
实现方案
方案一
下游系统提供相应查询接口。
上游系统在 timeout 后，首先去查询一下，如果查到了，就表明已经做了，成功了就不用做了，失败了就走失败流程。
方案二
将这个查询操作交给下游系统，上游系统只管重试，下游系统保证一次和多次的请求产生的影响是一样的。这时我们就说下游系统提供的接口支持幂等性。
小结
幂等性关注的是多次请求是否对资源产生了副作用，而不是关注的结果。SELECT 语句有可能每次查询的数据不一致，但是它是幂等性的。
关于 实现方案 -> 方案二 的具体实现方案，根据业务的实际情况考虑合适的解决方案，比如：通过 SQL 语句就可以实现幂等，就没必要引入 全局唯一ID 的解决方案。
