订单系统设计方案之如何避免出现ABA？

举个例子：

商家发货，填写运单号，开始填了 123，后来发现填错了，然后又修改为 456。

此时，如果就为某种特殊场景埋下错误伏笔，具体我们来看下

过程：

• 开始「请求A」发货，调订单服务接口，更新运单号 123
• 但是响应有点慢，超时了
• 此时，商家发现运单号填错了，发起了「请求B」，更新运单号为 456 ，订单服务也响应成功了
• 这时，「请求A」触发了重试，再次调用订单服务，更新运单号 123，订单服务也响应成功了
• 订单服务最后保存的 运单号 是 123

是不是犯错了！！！！

那么有什么好的解决方案吗？

很多人可能会说，不重试不就可以了，要知道重试机制 是高可用服务的重要保障手段，很多重试是框架自动发起的。

理想的解决方案：

数据库表引入一个额外字段  version，每次更新时，判断表中的版本号与请求参数携带的版本号是否一致

update order
set logistics_num = #{logistics_num} , version = #{version} + 1
where order_id= 1111 and version = #{version}

• 一致：才触发更新
• 不一致：说明这期间执行过数据更新，可能会引发错误，拒绝执行。