后端怎样防止重复提交订单？
悲观锁需要在同一个事务操作过程中锁住一行数据，如果事务耗时比较长，会造成大量的请求等待，影响接口性能。此外，每次请求接口很难保证都有相同的返回值，所以不适合幂等性设计场景，但是在防重场景中是可以的使用的。在这里顺便说一下，防重设计 和 幂等设计，其实是有区别的。防重设计主要为了避免产生重复数据，对接口返回没有太多要求。而幂等设计除了避免产生重复数据之外，还要求每次请求都返回一样的结果。
3. 加乐观锁
既然悲观锁有性能问题，为了提升接口性能，我们可以使用乐观锁。需要在表中增加一个timestamp或者version字段，这里以version字段为例。
在更新数据之前先查询一下数据：
select id,amount,version from user id=123;
如果数据存在，假设查到的version等于1，再使用id和version字段作为查询条件更新数据：
update user set amount=amount+100,version=version+1
where id=123 and version=1;
更新数据的同时version+1，然后判断本次update操作的影响行数，如果大于0，则说明本次更新成功，如果等于0，则说明本次更新没有让数据变更。
由于第一次请求version等于1是可以成功的，操作成功后version变成2了。这时如果并发的请求过来，再执行相同的sql：
update user set amount=amount+100,version=version+1
where id=123 and version=1;
该update操作不会真正更新数据，最终sql的执行结果影响行数是0，因为version已经变成2了，where中的version=1肯定无法满足条件。但为了保证接口幂等性，接口可以直接返回成功，因为version值已经修改了，那么前面必定已经成功过一次，后面都是重复的请求。
具体流程如下：
具体步骤：
- 先根据id查询用户信息，包含version字段
- 根据id和version字段值作为where条件的参数，更新用户信息，同时version+1
- 判断操作影响行数，如果影响1行，则说明是一次请求，可以做其他数据操作。
- 如果影响0行，说明是重复请求，则直接返回成功。
4. 加唯一索引
绝大数情况下，为了防止重复数据的产生，我们都会在表中加唯一索引，这是一个非常简单，并且有效的方案。
alter table `order` add UNIQUE KEY `un_code` (`code`);
加了唯一索引之后，第一次请求数据可以插入成功。但后面的相同请求，插入数据时会报Duplicate entry ‘002’ for key 'order.un_code异常，表示唯一索引有冲突。
虽说抛异常对数据来说没有影响，不会造成错误数据。但是为了保证接口幂等性，我们需要对该异常进行捕获，然后返回成功。
如果是java程序需要捕获：DuplicateKeyException异常，如果使用了spring框架还需要捕获：MySQLIntegrityConstraintViolationException异常。
具体流程图如下：
具体步骤：
- 用户通过浏览器发起请求，服务端收集数据。
- 将该数据插入mysql
- 判断是否执行成功，如果成功，则操作其他数据（可能还有其他的业务逻辑）。
- 如果执行失败，捕获唯一索引冲突异常，直接返回成功。
5. 建防重表
有时候表中并非所有的场景都不允许产生重复的数据，只有某些特定场景才不允许。这时候，直接在表中加唯一索引，显然是不太合适的。
针对这种情况，我们可以通过建防重表来解决问题。
该表可以只包含两个字段：id 和 唯一索引，唯一索引可以是多个字段比如：name、code等组合起来的唯一标识，例如：susan_0001。
具体流程图如下：
具体步骤：
- 用户通过浏览器发起请求，服务端收集数据。
- 将该数据插入mysql防重表
- 判断是否执行成功，如果成功，则做mysql其他的数据操作（可能还有其他的业务逻辑）。
- 如果执行失败，捕获唯一索引冲突异常，直接返回成功。
6. 根据状态机
很多时候业务表是有状态的，比如订单表中有：1-下单、2-已支付、3-完成、4-撤销等状态。如果这些状态的值是有规律的，按照业务节点正好是从小到大，我们就能通过它来保证接口的幂等性。
假如id=123的订单状态是已支付，现在要变成完成状态。
update `order` set status=3 where id=123 and status=2;
第一次请求时，该订单的状态是已支付，值是2，所以该update语句可以正常更新数据，sql执行结果的影响行数是1，订单状态变成了3。
后面有相同的请求过来，再执行相同的sql时，由于订单状态变成了3，再用status=2作为条件，无法查询出需要更新的数据，所以最终sql执行结果的影响行数是0，即不会真正的更新数据。但为了保证接口幂等性，影响行数是0时，接口也可以直接返回成功。
具体流程图如下：
具体步骤：
- 用户通过浏览器发起请求，服务端收集数据。
- 根据id和当前状态作为条件，更新成下一个状态
- 判断操作影响行数，如果影响了1行，说明当前操作成功，可以进行其他数据操作。
- 如果影响了0行，说明是重复请求，直接返回成功。
7. 加分布式锁
其实前面介绍过的加唯一索引或者加防重表，本质是使用了数据库的分布式锁，也属于分布式锁的一种。但由于数据库分布式锁的性能不太好，我们可以改用：redis或zookeeper。
鉴于现在很多公司分布式配置中心改用apollo或nacos，已经很少用zookeeper了，我们以redis为例介绍分布式锁。
目前主要有三种方式实现redis的分布式锁：
- setNx命令
- set命令
- Redission框架
每种方案各有利弊，具体实现细节我就不说了，有兴趣的朋友可以加我微信找我私聊。
具体流程图如下：
具体步骤：
- 用户通过浏览器发起请求，服务端会收集数据，并且生成订单号code作为唯一业务字段。
- 使用redis的set命令，将该订单code设置到redis中，同时设置超时时间。
- 判断是否设置成功，如果设置成功，说明是第一次请求，则进行数据操作。
- 如果设置失败，说明是重复请求，则直接返回成功。
最近无意间获得一份BAT大厂大佬写的刷题笔记，一下子打通了我的任督二脉，越来越觉得算法没有想象中那么难了。
BAT大佬写的刷题笔记，让我offer拿到手软
8. 获取token
除了上述方案之外，还有最后一种使用token的方案。该方案跟之前的所有方案都有点不一样，需要两次请求才能完成一次业务操作。
- 第一次请求获取token
- 第二次请求带着这个token，完成业务操作。
具体流程图如下：
第一步，先获取token。
第二步，做具体业务操作。
具体步骤：
- 用户访问页面时，浏览器自动发起获取token请求。
- 服务端生成token，保存到redis中，然后返回给浏览器。
- 用户通过浏览器发起请求时，携带该token。
- 在redis中查询该token是否存在，如果不存在，说明是第一次请求，做则后续的数据操作。
- 如果存在，说明是重复请求，则直接返回成功。
- 在redis中token会在过期时间之后，被自动删除。
以上方案是针对幂等设计的。
如果是防重设计，流程图要改改：
写在最后
如果这篇【文章】有帮助到你，希望可以给【JavaGPT】点个赞👍，创作不易，如果有对【后端技术】、【前端领域】感兴趣的小可爱，也欢迎关注❤️❤️❤️ 【JavaGPT】❤️❤️❤️，我将会给你带来巨大的【收获与惊喜】💝💝💝！
