共计 2244 个字符，预计需要花费 6 分钟才能阅读完成。
幂等性在咱们的工作中无处不在，无论是领取场景还是下订单等外围场景都会波及，也是分布式系统最常遇到的问题，除此之外，也是大厂面试的重灾区。
晓得了幂等性的重要性，上面我就具体介绍幂等性以及具体的解决方案，心愿对大家有所帮忙 @mikechen
什么是幂等性
幂等是一个数学与计算机学概念，在数学中某一元运算为幂等时，其作用在任一元素两次后会和其作用一次的后果雷同。
所谓接口幂等性，就是一次和屡次申请某一个资源对于资源自身应该具备同样的后果。
也就是说，在接口反复调用的状况下，对系统产生的影响是一样的，这就是幂等性。
为什么须要幂等性
业务开发中，常常会遇到反复提交的状况，无论是因为网络问题无奈收到申请后果而从新发动申请，或是前端的操作抖动而造成反复提交状况。
在交易系统，领取零碎这种反复提交造成的问题有尤其显著，比方：用户在 APP 上间断点击了屡次提交订单，后盾应该只产生一个订单。
再比方：向支付宝发动领取申请，因为网络问题或零碎 BUG 重试，支付宝应该只扣一次钱，而不是多次重试，造成屡次扣钱。
再比方：当初是微服务的时代，服务化接口在内部调用者会存在屡次调用的状况(思考网络中断重试等)，为了避免内部屡次调用对系统数据状态的产生屡次扭转，将服务设计成幂等，就是为了避免多次重试，造成零碎不统一的问题。
通过以上典型的领取场景就晓得幂等性的重要性了，那问题来了，如何实现幂等性，有哪些解决方案? 上面咱们接着聊。
幂等性的解决方案
数据库惟一主键
数据库惟一主键的实现次要是利用数据库中主键惟一束缚的个性，一般来说惟一主键比拟实用于“插入”时的幂等性，其能保障一张表中只能存在一条带该惟一主键的记录。
惟一索引 应用惟一索引能够防止脏数据的增加，当插入反复数据时数据库会抛异样，保障了数据的唯一性。
惟一索引表的创立示例如下：
CREATE TABLE `table_name` (
`id` int NOT NULL AUTO_INCREMENT,
`orderid` varchar(32) NOT NULL DEFAULT ''COMMENT' 惟一 id',
PRIMARY KEY (`id`),
UNIQUE KEY `uq_orderid` (`orderid`) COMMENT '惟一束缚'
) ENGINE=InnoDB;应用数据库惟一主键实现幂等性时须要留神的是，该主键一般来说并不是应用数据库中自增主键，而是应用分布式 全局 ID 充当主键，这样能力能保障在分布式环境下 ID 的全局唯一性。
实用操作：
- 插入操作
- 删除操作
数据库乐观锁
数据库乐观锁计划个别只能实用于执行“更新操作”的过程，咱们能够提前在对应的数据表中多增加一个字段，充当以后数据的版本标识。
这样每次对该数据库该表的这条数据执行更新时，都会将该版本标识作为一个条件，值为上次待更新数据中的版本标识的值。
select version from tablename where xxx更新数据时首先和版本号作比照，如果不相等阐明曾经有其余的申请去更新数据了，提醒更新失败。
update tablename set count=count+1,version=version+1 where version=#{version}实用操作：
- 更新操作
PRG 模式
Post/Redirect/Get 是一种 web 开发设计模式，用于避免表单的反复提交。
默认状况，提交 Post 申请到服务器后，如果间接刷新浏览器，会从新在提交一次 Post 申请。
在拜访电商网站时，提交订单采纳的是 Post 申请，如果间接刷新浏览器就容易导致反复订单的提交，这个不是用户心愿产生的行为。
PRG 办法就是用户避免这种景象的产生，上面例图形容了用 PRG 办法来防止 Post 申请的反复提交。当服务器解决完 Post 申请后，会发响应给用户浏览器，批示用户浏览器用 Get 形式立即拜访另一条 URL。用户浏览器拿到 Get 申请的数据，整个流程才算完结。
此时用户刷新以后页面，也不会引起 Post 申请的反复提交了。
防重 Token 令牌
针对客户端间断点击或者调用方的超时重试等状况，例如提交订单，此种操作就能够用 Token 的机制实现避免反复提交。
简略的说就是调用方在调用接口的时候先向后端申请一个全局 ID（Token），申请的时候携带这个全局 ID 一起申请（Token 最好将其放到 Headers 中），后端须要对这个 Token 作为 Key，用户信息作为 Value 到 Redis 中进行键值内容校验，如果 Key 存在且 Value 匹配就执行删除命令，而后失常执行前面的业务逻辑。
如果不存在对应的 Key 或 Value 不匹配就返回反复执行的错误信息，这样来保障幂等操作。
下面我只是列举了解决幂等性的解决方案与思路，其实还有很多相似解决方案，比方订单流程还能够联合前段拦挡，以及更多的后端计划来保障唯一性。
这些还须要联合你的理论业务场景，来最终来抉择更适宜你的解决方案，然而万变不离其中，都是为了保障一次操作，保障惟一束缚，这才是幂等性的实质。
作者简介
mikechen,10 年 + 大厂架构教训，《BAT 架构技术 500 期》系列文章作者，曾就任于阿里、淘宝、百度等一线互联网大厂。
浏览 mikechen 的互联网架构更多技术文章合集
Java 并发 |JVM|MySQL|Spring|Redis| 分布式 | 高并发 | 架构师
关注「mikechen 的互联网架构」公众号，回复 【架构】 支付我原创的《300 期 + BAT 架构技术系列与 1000 + 大厂面试题答案》
