由并发扣款如何保证数据一致性引起的幂等性问题的思考

上一篇文章：

由并发扣款如何保证数据一致性引起的ABA问题的思考

有遗漏场景，公众号 架构师之路 后续出了文章讨论了这个问题，这里附上。

1. 回顾

在上文并发扣款中的解决方案是采用CAS乐观锁，加入版本号控制。采用 select&set 方式进行余额写回：
update t_account set money=#{new_money} , version=#{new_version} where id=#{id} and version=#{old_version} ;

2. 问题

为什么不直接采用扣减方式：
update t_account set money=money - #{diff} where id=#{id};

上文中提到可能会把余额减成负数，但是在sql语句加一个判断就可以了，条件是只要余额大于扣款金额：
update t_account set money=money - #{diff} where id=#{id} and money>#{diff};

3. 思考

为什么不推荐直接扣减方式，答案是：不幂等

在开发过程种，接口幂等性的设计是非常重要的，幂等性要求同一接口，在参数不变的情况下，产生的结果不变；

常见幂等性实现方案：

1. 查询操作。只要数据不变，一次和多次查询的结果返回一致；
2. 删除操作。结果都是删除数据；
3. 唯一索引。保证数据唯一性，比如新增数据，在唯一索引条件下可以防止重复插入；
4. token机制。
5. 悲观锁 / 乐观锁。
6. 分布式锁。

上述场景中，采用直接扣减方式，如果有重试机制，比如超时或异常重试，那么重复执行将产生多次扣款，而select&set的操作就具有幂等性，无论执行多少次都只产生一次扣款。
当然具体到开发场景，是否需要重试，由业务决定。