前任开发在代码里下毒了，支付下单居然没加幂等

故事
阳光明媚的一天，小猫戴着耳机，享受着音乐的旋律，悠闲地编写着代码，这样无需参加会议的日子真是惬意无比。

然而，好景不长，组长急匆匆地赶来找到了小猫。“赶紧检查一下，A公司的用户反映他们的积分被多扣了。”

小猫回忆了一下，“奇怪，那个接口我没动过啊。前几天，对外平台的老六找我要支付接口，我就给了他以前的代码，那些我都没动过的……”

带着疑惑，小猫翻看着以前的代码，脸色逐渐凝重……

小猫负责的是一个标准的积分兑换商城系统。以往和客户合作时，客户都直接使用他们单位定制的H5页面。但这次合作的A公司有些特别，他们希望定制个性化的H5页面，并且自身具备开发能力。因此，双方商定以接口形式对接，A公司完成H5开发后进行对接。

经过一番排查，原因逐渐浮出水面。之前业务一直平稳运行，是因为商城的H5页面自带了防重复提交机制。由于之前对接的都是纯 H5，且业务量小，所以没有问题。但这次直接开放了接口，且接口没有实现幂等性……

小猫无辜“躺枪”，不仅要进行数据修正，还要撰写事故报告。

真是“前人栽树后人乘凉”，但有时候也会变成“前人挖坑后人遭殃”。

幂等接口
接口幂等性解析
这个案例就是一个典型的接口幂等问题。接下来，我们就来深入剖析一下接口幂等性。

何为接口幂等性？
专业术语解释：任意多次执行所产生的影响与第一次执行的影响相同。

通俗易懂的说法：无论调用多少次，接口的最终结果都是一样的。

那么，为什么需要幂等性呢？
用户提交时，由于网络波动等原因导致后端响应不及时，用户可能会连续点击，从而造成重复提交。

在分布式系统间调用（如RPC）时，为了防止请求因网络波动或超时失败，通常会添加重试机制，这也可能导致请求被多次提交。

分布式系统常用消息中间件，若因网络原因未收到ack，消息会重复投递，进而造成重复提交。

此外，恶意攻击也不容忽视。一些业务接口设计粗糙，黑 客找到漏洞后会发起重复提交攻击。

哪些接口需要幂等性？
并非所有接口都需要幂等性，因为幂等的实现会消耗系统性能。是否需要幂等性应结合业务逻辑来判断。但一般来说，涉及多表更新的接口最好加上幂等性。

幂等性实战策略
前端防抖
前端防抖主要有技术层面和产品层面两种方案：

技术层面：如限制100ms内同一用户最多提交一次订单。

产品层面：用户点击提交后，按钮置灰。

数据库唯一索引
利用数据库唯一索引来实现幂等性。以小猫遇到的案例为例，可以建立一张去重表，将订单提交流水单号作为唯一索引。客户端携带流水信息到后端，若编号重复则插入失败，报错并给出友好提示。

数据库乐观锁
乐观锁假设多用户并发处理时不会互相影响，只在更新时判断数据是否被修改。如提交订单扣款时，可在update语句中加入版本号来判断数据是否被修改。

数据库悲观锁
悲观锁具有强烈的独占和排他特性。可使用select ... for update语法进行行锁，并结合业务状态进行校验。但需注意，悲观锁只能解决同一时刻大并发的幂等问题。

后端生成Token
引入令牌桶机制，前端调用后端接口获取Token。Token由后端生成并放入Redis中，设置失效时间。后端接收到请求时先判断Token是否存在，第一次请求时Token存在并正常返回结果，第二次携带相同Token时则拒绝请求。

分布式锁+状态机
在分布式系统中，可使用分布式锁和状态机结合来实现幂等性。分布式锁保证同一时间只有一个请求能访问同一资源，状态机则用于校验订单状态防止重复支付。

总结
在日常开发中，对待重要接口需谨慎。即使是前任开发的接口且未做改动，在有人咨询时也应深入了解其实现方式和技术细节。这是每个程序员的基本素养。

特别是在资金相关接口上，幂等性尤为重要。大家还有其他解决方案或思考吗？欢迎留言交流。

（顺便提一句，技术大厂年前正在招聘，前后端测试岗位都有，感兴趣的朋友不妨一试→https://jsj.top/f/o38ijj）