作者：叁滴水 \
博客：https://blog.csdn.net/qq_3028…
前言
在订单的状态产生扭转后，支付宝会通过异步形式同志商家服务器。商家服务器须要返回 success 这 7 个字符，如果不是，则会一直反复发送。
微信也是如此，必须须要商家服务器的正确反馈。既然这样，在回调接口就须要进行幂等解决。
一、什么是幂等？
幂等操作的特点是其任意屡次执行所产生的影响均与一次执行的影响雷同。
细想一下回调接口个别会这样解决：
- 查看订单是否存在。
- 批改订单状态。
- 如果是领取胜利状态，则进行发货。
这种逻辑自身是没有什么问题的，然而它不是一个幂等接口，如果收到好几次订单 1001 领取胜利的申请，则会对订单 1001 的商品屡次发货，这就导致了一个订单屡次发货的景象，这种在电商开发时是灾难性的 bug。
因而，咱们须要对此接口做一个解决，使得即便有很多申请都通知商户服务器订单 1001 领取胜利的申请，商户也只发货一次。
二、如何进行幂等解决
对于这种接口的幂等解决，我也是思量许久，最终决定再生应用批改状态的形式。
具体实现形式如下：
- 订单表
t_order存在订单号1001的订单是未领取状态。 - 支付宝转账胜利，通知商家服务器订单
1001的订单转账胜利。 - 商家服务器验签。
- 查看订单是否存在，根本信息是否统一。
- 批改此订单状态。通过
update t_order set 状态 = 已领取 where order_id=1001 and 状态 = 未领取 - 通过如上 sql 乐观锁的思维对发货进行管制，只有 sql 执行的时候有批改胜利，则进行发货，批改失败则不发货。
通过乐观锁能够无效的管制发货次数。不论几次回调告诉，只有以后订单是未领取状态并且胜利批改成已领取状态之后才进行发货。
如下图，两个 sql 一起执行批改订单状态，然而必定只会有一个 sql 批改胜利。
批改胜利的线程进行发货即可。
如果思路有什么毛病，或者您还有更好的实现形式，请留言点评。
最初，关注公众号 Java 技术栈，在后盾回复：面试，能够获取我整顿的 Java 系列面试题和答案，十分齐全。
本文来自作者「叁滴水」投稿，谢谢分享，也欢送喜好技术分享的各位技术敌人向「Java 技术栈」投稿，让更多人看到，投稿形式：关注公众号「Java 技术栈」在后盾回复：投稿。
近期热文举荐：
1.600+ 道 Java 面试题及答案整顿(2021 最新版)
2. 终于靠开源我的项目弄到 IntelliJ IDEA 激活码了，真香！
3. 阿里 Mock 工具正式开源，干掉市面上所有 Mock 工具！
4.Spring Cloud 2020.0.0 正式公布，全新颠覆性版本！
5.《Java 开发手册（嵩山版）》最新公布，速速下载！
感觉不错，别忘了顺手点赞 + 转发哦！