乐趣区

关于后端:分布式之接口幂等性

前言

什么是幂等性?一次和屡次申请某一个资源,对资源自身所产生的的影响均与一次执行的影响雷同。

幂等性是零碎服务对外的一种承诺,承诺只有调用接口胜利了,屡次调用对系统的影响是统一的。

幂等性与反复提交比拟

幂等性 更多应用的状况是第一次申请晓得后果,然而因为网络抖动或连贯超时等状况未进行失常返回,在这种状况下零碎主动再次发动申请,其目标是确认第一次是否申请实现。

反复提交 更多应用的状况是第一次申请胜利或申请后果暂未返回的状况下,人为的进行屡次操作。

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. 分布式之配置核心
退出移动版