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

前言

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

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

幂等性与反复提交比拟

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

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

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. 分布式之配置核心