分布式之接口幂等性

文章目录：

• 前言
• 幂等性与重复提交比较
• 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 的解决方案。