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