问题
在第三方支付业务中，确保每笔支付订单只能被成功支付一次是非常关键的。这不仅关系到用户体验，也直接影响到商家的财务安全。通常情况下，人们会想到使用分布式锁来实现这一目标：当一个订单发起支付请求时，首先尝试获取该订单号对应的分布式锁；如果成功获取，则检查数据库中的订单状态是否为未支付；如果是未支付状态，则调用支付渠道执行扣款操作。
然而，在实际生产环境中单纯依赖分布式锁可能并不足够，因为没有任何技术手段可以做到100%可靠。因此，我们需要考虑更多层次的安全措施来保障业务连续性和数据一致性。
方案
数据库唯一索引兜底
在微服务架构中，面对不可靠的第三方服务时，我们需要采取多层次的安全措施来确保关键业务逻辑的正确执行。使用分布式锁虽然可以有效减少并发写操作的压力，但它并不能作为唯一的保障手段。因此，利用关系型数据库的特性，如唯一索引，是一个非常有效的兜底方案。
- 唯一索引：通过为订单号字段设置唯一索引，可以直接在数据库层面防止重复数据的插入。当尝试插入已经存在的订单号时，数据库将抛出异常或返回错误信息，从而阻止重复支付的发生。这种方式简单直接，且不依赖于任何外部服务，是保证数据一致性的基础方法之一。
状态机+版本号实现乐观锁机制
为了进一步提高系统的健壮性和支持失败重试场景，结合状态机和版本号的乐观锁机制是一种常见做法。这种机制不仅能够有效地防止订单被重复处理，还可以很好地支持事务的重试。
- 状态机模型：定义清晰的状态转换规则，比如从“未支付”到“支付中”，再到“已支付”或者“支付失败”。每个状态都有明确的意义，并且状态之间的转换需要满足特定条件。
- 版本号控制：引入版本号（
lock_version）字段，用于记录每次更新前的数据版本。在进行更新操作时，必须指定当前的版本号。如果在此期间有其他事务修改了该记录，则会导致版本号不匹配，更新操作将会失败。这样就避免了并发情况下出现的竞态条件问题。
关键SQL语句示例
UPDATE orders
SET lock_version = lock_version + 1, status='PROCESS'
WHERE status='FAIL' AND lock_version = @currentVersion;
在这个例子中：
@currentVersion是客户端读取到的当前版本号。- 更新操作只有在
status为FAIL并且lock_version与客户端持有的版本号相等时才会成功执行。 - 如果更新成功，表示没有其他并发事务更改过这条记录，可以继续执行后续的业务逻辑。
- 若更新失败（通常是因为受影响行数为0），则表明在这次更新之前已有其他事务改变了记录的状态或版本号，此时应该回滚事务并根据具体情况进行重试或其他处理。
综合应用与注意事项
- 在实际部署中，应当同时采用上述两种策略——即数据库唯一索引加状态机+版本号的组合，以构建一个更加安全可靠的系统。
- 需要特别注意的是，在设计状态转换逻辑时，要充分考虑到各种可能的异常情况及恢复流程，确保即使在部分组件故障的情况下也能保持系统的整体稳定。
- 此外，还需定期审查和测试这些机制的有效性，及时调整优化，以应对不断变化的需求和技术环境。
