前言
什么是幂等性?一次和屡次申请某一个资源,对资源自身所产生的的影响均与一次执行的影响雷同。
幂等性是零碎服务对外的一种承诺,承诺只有调用接口胜利了,屡次调用对系统的影响是统一的。
幂等性与反复提交比拟
幂等性 更多应用的状况是第一次申请晓得后果,然而因为网络抖动或连贯超时等状况未进行失常返回,在这种状况下零碎主动再次发动申请,其目标是确认第一次是否申请实现。
反复提交 更多应用的状况是第一次申请胜利或申请后果暂未返回的状况下,人为的进行屡次操作。
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
的解决方案。
举荐浏览
- 分布式事务之了解篇
- 分布式事务之最终一致性实现计划
- 分布式之异步通信组件抉择
- 分布式之配置核心