分布式之接口幂等性

前言

什么是幂等性?一次和多次请求某一个资源,对资源本身所产生的的影响均与一次执行的影响相同。

幂等性是系统服务对外的一种承诺,承诺只要调用接口成功了,多次调用对系统的影响是一致的。

幂等性与重复提交比较

幂等性 更多使用的情况是第一次请求知道结果,但是由于网络抖动或连接超时等情况未进行正常返回,在这种情况下系统自动再次发起请求,其目的是确认第一次是否请求完成。

重复提交 更多使用的情况是第一次请求成功或请求结果暂未返回的情况下,人为的进行多次操作。

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 的解决方案。

推荐阅读

  1. 分布式事务之理解篇
  2. 分布式事务之最终一致性实现方案
  3. 分布式之异步通讯组件选择
  4. 分布式之配置中心

你可能感兴趣的:(后端分布式微服务)