Java开发过程中的幂等性问题

幂等性问题：

1. 有时我们在填写某些 form表单时，保存按钮不小心快速点了两次，表中竟然产生了两条重复的数据，只是id不一样。

2. 我们在项目中为了解决接口超时问题，通常会引入了重试机制。第一次请求接口超时了，请求方没能及时获取返回结果（此时有可能已经成功了），为了避免返回错误的结果（这种情况不可能直接返回失败吧？），于是会对该请求重试几次，这样也会产生重复的数据。

3. mq消费者在读取消息时，有时候会读取到重复消息，如果处理不好，也会产生重复的数据。接口幂等性 是指用户对于同一操作发起的一次请求或者多次请求的结果是一致的，不会因为多次点击而产生结果不一致的情况。

这类问题多发于接口的：insert 操作，这种情况下多次请求，可能会产生重复数据。update 操作，如果只是单纯的更新数据，比如： update user set status=1 where id=1 ，是没有问题的。如果还有计算，比如： update user set status=status+1 where id=1 ，这种情况下多次请求，可能会导致数据错误。

解决方案：

1. insert前先select

通常情况下，在保存数据的接口中，我们为了防止产生重复数据，一般会在 insert 前，先根据 name 或 code 字段 select 一下数据。如果该数据已存在，则执行 update 操作，如果不存在，才执行 insert 操作。

该方案可能是我们平时在防止产生重复数据时，使用最多的方案。但是该方案不适用于并发场景，在并发场景中，要配合其他方案一起使用，否则同样会产生重复数据。

2. 加悲观锁

1）支付场景在加减库存场景中，用户A的账号余额有150元，想转出100元，正常情况下用户A 的余额只剩50元。一般情况下，sql是这样的：

update user amount = amount-100 where id=123;

如果出现多次相同的请求，可能会导致用户A的余额变成负数。

update user amount = amount-100 where id=123;

为了解决这个问题，可以加悲观锁，将用户A的那行数据锁住，在同一时刻只允许一个请求获得锁，更新数据，其他的请求则等待。

通常情况下通过如下sql锁住单行数据：

select * from user id=123 for update;

具体流程如下：

具体步骤：

1. 多个请求同时根据id查询用户信息。

2. 判断余额是否不足100，如果余额不足，则直接返回余额不足。

3. 如果余额充足，则通过for update再次查询用户信息，并且尝试获取锁。

4. 只有第一个请求能获取到行锁，其余没有获取锁的请求，则等待下一次获取锁的机会。

5. 第一个请求获取到锁之后，判断余额是否不足100，如果余额足够，则进行update操作。

6. 如果余额不足，说明是重复请求，则直接返回成功。

需要特别注意的是：如果使用的是mysql数据库，存储引擎必须用innodb，因为它才支持事
务。此外，这里id字段一定要是主键或者唯一索引，不然会锁住整张表。
悲观锁需要在同一个事务操作过程中锁住一行数据，如果事务耗时比较长，会造成大量的请求等
待，影响接口性能。此外，每次请求接口很难保证都有相同的返回值，所以不适合幂等性设计场
景，但是在防重场景中是可以的使用的。

防重设计和幂等设计，其实是有区别的。防重设计主要为了避免产生重复数据，对接口返回没有太多要求。而幂等设计除了避免产生重复数据之外，还要求每次请求都返回一样的结果。

3. 加乐观锁

既然悲观锁有性能问题，为了提升接口性能，我们可以使用乐观锁。需要在表中增加一个 version 字段，在更新数据之前先查询一下数据：

如果数据存在，假设查到的 version 等于 1 ，再使用 id 和 version 字段作为查询条件更新数据：更新数据的同时 version+1 ，然后判断本次 update 操作的影响行数，如果大于0，则说明本次更新成功，如果等于0，则说明本次更新没有让数据变更。

由于第一次请求 version 等于 1 是可以成功的，操作成功后 version 变成 2 了。这时如果并发的请求过来，再执行相同的sql：

该 update 操作不会真正更新数据，最终sql的执行结果影响行数是 0 ，因为 version 已经变成 2 了， where 中的 version=1 肯定无法满足条件。但为了保证接口幂等性，接口可以直接返回成功，因为 version 值已经修改了，那么前面必定已经成功过一次，后面都是重复的请求。

具体流程如下：

具体步骤：

1. 先根据id查询用户信息，包含version字段

2. 根据id和version字段值作为where条件的参数，更新用户信息，同时version+1

3. 判断操作影响行数，如果影响1行，则说明是一次请求，可以做其他数据操作。

3. 如果影响0行，说明是重复请求，则直接返回成功。

4. 加唯一索引

绝大数情况下，为了防止重复数据的产生，我们都会在表中加唯一索引，加了唯一索引之后，第一次请求数据可以插入成功。但后面的相同请求，插入数据时会报唯一索引冲突的异常。

虽说抛异常对数据来说没有影响，不会造成错误数据。但是为了保证接口幂等性，我们需要对该异常进行捕获，然后返回成功。

具体步骤：

1. 用户通过浏览器发起请求，服务端收集数据。

2. 将该数据插入mysql

3. 判断是否执行成功，如果成功，则操作其他数据。

4. 如果执行失败，捕获唯一索引冲突异常，直接返回成功。

5. 建防重表 有时候表中并非所有的场景都不允许产生重复的数据，只有某些特定场景才不允许。这时候，直接在表中加唯一索引，显然是不太合适的。针对这种情况，我们可以通过建防重表来解决问题。该表可以只包含两个字段： id 和唯一索引，唯一索引可以是多个字段比如：name、code等组合起来的唯一标识，例如：pauipai_0001。

具体流程图如下：