简单聊聊怎么防止重复下单

一、问题背景

在分布式系统中，接口的幂等性问题是一个非常常见的挑战，尤其是在涉及数据库事务的场景中。以创建订单为例，通常需要往订单表和订单商品表中插入数据，这些操作需要在同一个事务中执行。假设订单服务调用了支付服务，但因为网络超时，订单服务启动了重试机制，导致支付服务接收了两个相同的支付请求。由于负载均衡的原因，这两个请求可能落在不同的业务节点上。如果没有处理好幂等性，同一个支付请求可能被处理两次，从而造成业务逻辑错误。因此，分布式系统中的接口必须保证幂等性。

二、如何避免重复下单

虽然可以通过前端页面防止用户重复提交表单，但网络异常可能导致请求重传。此外，很多 RPC 框架和网关都有自动重试机制，因此仅靠前端无法完全避免重复请求。最终，还是要通过服务端的接口设计来保证幂等性。

2.1 如何判断请求是重复的

• 避免重复下单的一个关键步骤是如何判断请求是否为重复请求。
• 在插入订单数据之前，可以先查询订单表，看看是否已经存在重复的订单。
• 但“重复订单”的定义并不简单。比如，两个订单的用户、商品和价格都一样，是否就可以认为是重复订单呢？
• 事实上，有些用户可能会连续下两单完全相同的订单，因此需要其他方式来判断。

为保证幂等性，需采取以下措施：

2.1.1 每个请求必须有唯一标识

以订单支付为例，支付请求应该包含订单 ID，一个订单 ID 只能成功支付一次。
通过唯一标识，可以准确识别每个请求是否已经处理。

2.1.2 每次处理请求后，记录标识已处理

可以在数据库中通过一个状态字段记录订单的处理情况，比如支付流水记录。在支付之前插入支付流水，标识该订单的支付状态。这样，后续的请求可以根据流水状态判断订单是否已经支付。

2.1.3 每次接收请求时，检查是否处理过

当收到一个支付请求时，先检查该订单是否已经有支付流水。如果发现该订单已经支付，数据库的唯一约束会使重复的插入操作失败，从而避免重复处理请求。

利用数据库主键的唯一性约束，可以实现幂等性。在插入数据时，使用订单 ID 作为主键，数据库会自动保证同一订单 ID 只能插入一次。因此，重复的支付请求由于主键冲突，会导致插入失败。为了进一步增强幂等性，可以在订单服务中增加一个订单号生成接口，前端在创建订单时先调用该接口，生成一个唯一订单号。这样，无论前端如何重试，每次请求都会携带相同的订单号，从而避免重复下单。

为了提高系统性能，可以结合 Redis 实现幂等性。使用订单 ID 作为 Redis 中的键，标识订单是否已经支付。在处理支付请求时，首先检查 Redis 中是否存在该订单 ID。如果订单已经支付，则不再进行后续处理。

在处理失败时，订单服务不应该将错误直接返回给前端。比如，如果由于重复订单导致插入订单表失败，正确的做法是直接返回“订单创建成功”，而不是告知用户失败，以避免用户的困惑。

三、解决 ABA 问题

3.1 什么是 ABA

ABA 问题是指在并发更新数据时，可能导致数据的错误回滚。例如，在订单支付后，卖家需要填写快递单号。假设卖家第一次输入单号 "666"，但发现填写错误后立刻修改为 "888"。此时，如果系统异常导致“666”请求成功但响应丢失，系统自动重试后，"666" 再次覆盖了 "888"。这种情况会导致订单数据不一致。

3.2 解决方案

为了解决 ABA 问题，可以在订单表中添加一个版本号字段。每次查询订单时，系统会将订单的版本号返回给前端页面。在更新订单时，页面需要将版本号一同提交。订单服务在更新数据时，先比较版本号是否匹配。如果版本号不一致，说明该订单已经被其他请求更新过，此时拒绝更新。若版本号一致，则允许更新，同时将版本号加 1。

例如，当卖家第一次提交快递单号 "666" 时，系统会更新订单表中的版本号。随后卖家再次提交 "888" 请求，此时请求带有的新版本号和数据库中的版本号一致，更新操作可以成功。而即使重试 "666" 请求，由于它携带的旧版本号已经过时，更新操作将会失败。

UPDATE orders set tracking_number = 666, version = version + 1 WHERE version = 8;

通过这种机制，数据库的数据和前端展示的数据将保持一致，避免了 ABA 问题。无论是多个并发更新请求，还是由于系统异常导致的重试请求，都会通过版本号的比对，确保数据的幂等性。

四、总结

在分布式系统中，保证接口的幂等性是避免重复处理和数据错误的关键。通过引入唯一标识、利用数据库的唯一约束、结合 Redis 实现状态保存，可以有效避免重复下单问题。对于并发更新的 ABA 问题，通过版本号控制可以确保更新操作的正确性。总之，设计合理的幂等性机制是确保系统稳定性和数据一致性的基础。