【转】如何避免下重复订单

傷城~ 2022-05-30 02:11 159阅读 0赞

转载一篇大宽宽的文章，出处：https://www.jianshu.com/p/e618cc818432

**如何避免下重复订单**

[![96][]][96 1]  [SpeedFirst][96 1]   字数 2407

电子交易的一个很基本的问题，就是避免用户下重复订单。用户明明想买一次，结果一看下了两个单。如果没有及时发现，就会带来额外的物流成本和扯皮。对商家的信誉也不好看。

从技术上看，这是一个分布式一致性问题；但实际上，技术无法100%解决这类问题，得结合多种手段综合处理。这里就来说道说道。

# 为啥会下重了呢？ #

*  原因1：客户端bug

比如下单的按键在点按之后，在没有收到服务器请求之前，按键的状态没有设为已禁用状态，还可以被按。又或者，在触摸屏下，用户手指的点按可能被手机操作系统识别为多次点击。

嗯，谁能保证客户端不偶尔出个什么bug 呢。

*  原因2: 超时

用户的设备与服务器之间可能是不稳定的网路。这样一个下单请求过去，返回不一定回得来。超时最大的问题是: 从用户的角度，他无法确定下单的请求是还没到服务器，还是已经到了服务器但是返回丢失了。——用户无法区分到底这个单下了还是没下。

这样在等待一个超时后，UI可能会提示用户下单超时，请重复再试。

![700][]

下单超时

*  原因3: 用户的App闪退/人工强退，之后重新打开重新下单

也许可以使用一些技术手段避免用户下重单，但是心急的用户可能会重启流程/重启App/重启手机。在这种强制的手段下，任何技术手段都会失效——用户压根就不让你的技术执行，你怎么玩？

在这些条件下，如何避免用户多下了一笔订单呢？

# 用幂等防止重复订单 #

在技术方面，这是一个分布式一致性的问题，即客户端和服务器端对某个订单是否成功/失败达成一致。防止重单的关键是使用一个由客户端生成的，可用于避免重复的key，俗称dedup key（deduplicate key之意）。这个key可以用任意可以保证全局唯一性的方式生成，比如uuid。客户端和服务器需要使用这个dedup key作为串联条件，一起解决去重问题。

# 客户端的流程 #

客户端需要实现这样一个下单界面。用户点击【确认下单】时，应该产生一个独一无二的dedup key，连定订单数据发送给服务器端。在服务器返回之前，该界面应该一直等待，直到服务器响应成功/失败或者超时发生（比如15秒后，收不到服务器响应）。如果超时发生，应该向用户提示是否重试下单或者退出该界面。当用户点击【重试】时，应该用刚刚生成的dedup key来再次发送下单请求——如果用户一直不退出这个流程，每次用户点击重试，都应该用这个dedup key来重试下单，直到服务器正常返回，或者用户放弃返回。

![700 1][]

下单的客户端流程

# 后端数据表设计 #

后端在订单数据表中，需要增加`dedup_key`这列，并设置唯一约束。

create table order( # ... dedup_key varchar(60) not null comment 'key to pretend order duplication', # ... unique uniq_dedup_key(dedup_key) );

# 下单的实现 #

在实现下单逻辑时，基于该`dedup_key`实现一个"create-or-get"语义的下单接口——简单说就是

如果带有指定dedup_key的订单已经存在，则直接返回；否则，用该dedup_key下单。

用伪代码表示大概是：

@Transactional Order createOrder(Integer userId, String prodCode, Decimal amount, String dedupKey) { try { String orderId = createOrder(userId, prodCode, amount, deupKey); // insert a new order Order order = getOrderById(orderId); // read order from db order.setDuplicated(false); return order; } catch(UniqueKeyViolationException e) { // if duplicated order has existed Order order = getOrderByDedupKey(dedupKey); order.setDuplicated(true); return order; } catch (Exception e) { // hanlde other errors and rollback transaction ... } }

这时，这段下单代码总是能返回一个订单（除非发生一些DB挂了之类的错误），要么是新创建的，要么就是一个已经存在的单。注意，最好在订单里增加一个属性（比如例子中用“duplicated”）来表示这个订单是这次新生成的，还是因为幂等而直接返回的。这样前端可以有针对性的对这两种情况提示不同的文案。

# 技术搞定幂等就足够了吗？ #

上面的流程没有考虑一种情况，就是用户中途强制退出客户端，或者直接点击【返回】回到产品页，重新走下单流程。这个时候客户端就无法判断用户到底是想重新下单，还是想第二次下单。此时，可以从产品设计上考虑一下。

比如，在客户端缓存一个表，记录所有没有确认结果的订单。

<table style="border-spacing:0px;background-color:transparent;width:620px;margin-bottom:20px;border-top:1px solid rgb(221,221,221);border-right:1px solid rgb(221,221,221);border-bottom:1px solid rgb(221,221,221);border-left:none;"> 
 <thead> 
  <tr> 
   <th style="text-align:inherit;line-height:20px;vertical-align:middle;">&nbsp;</th> 
   <th style="text-align:inherit;line-height:20px;vertical-align:middle;">产品代码</th> 
   <th style="text-align:right;line-height:20px;vertical-align:middle;">产品数量</th> 
   <th style="text-align:right;line-height:20px;vertical-align:middle;">金额</th> 
   <th style="text-align:inherit;line-height:20px;vertical-align:middle;">dedup key</th> 
  </tr> 
 </thead> 
 <tbody> 
  <tr> 
   <td style="line-height:20px;vertical-align:middle;">未确认订单1</td> 
   <td style="line-height:20px;vertical-align:middle;">AAA</td> 
   <td style="line-height:20px;vertical-align:middle;text-align:right;">1</td> 
   <td style="line-height:20px;vertical-align:middle;text-align:right;">1000</td> 
   <td style="line-height:20px;vertical-align:middle;">xxx-yyy-zzz</td> 
  </tr> 
  <tr style="background-color:rgba(181,181,181,.098);"> 
   <td style="line-height:20px;vertical-align:middle;">未确认订单2</td> 
   <td style="line-height:20px;vertical-align:middle;">BBB</td> 
   <td style="line-height:20px;vertical-align:middle;text-align:right;">2</td> 
   <td style="line-height:20px;vertical-align:middle;text-align:right;">500.00</td> 
   <td style="line-height:20px;vertical-align:middle;">Aaa-bbb-ccc</td> 
  </tr> 
  <tr> 
   <td style="line-height:20px;vertical-align:middle;">...</td> 
   <td style="line-height:20px;vertical-align:middle;">&nbsp;</td> 
   <td style="line-height:20px;vertical-align:middle;text-align:right;">&nbsp;</td> 
   <td style="line-height:20px;vertical-align:middle;text-align:right;">&nbsp;</td> 
   <td style="line-height:20px;vertical-align:middle;">&nbsp;</td> 
  </tr> 
 </tbody> 
</table>

通过这个表，我们可以猜一下用户的意图。比如，如果用户重新提交了一笔订单，其产品代码、金额与表中记录的某条完全一致，就可以提示一下用户:

![676][]

提示一下用户是不是下重了

如果用户想重试，可以继续用表中对应记录的dedup key重新发起下单。

这样不是绝对准确的，仅仅是尽量的减少用户误操作的可能性。当然，在产品设计上可以能出于用户交互简化，不一定真的会这样做。这就需要其他机制来配合，比如“通知”。

# 通知 #

一旦服务器下单成功，可以通过某种通知机制（如APNS、Websocket）主动将订单推送至客户端，强行让客户端重新拉取最新的订单信息，并配合“未确认订单”表，以通知Badge/弹框等方式提示用户刚刚一笔状态未知的订单成功/失败了。

另外一种手段就是，服务器端实时扫描用户的下单数据，一旦发现可能的重单，就立刻通知客服主动联系用户，及时处理问题。

# 如果还拦不住…… #

经过层层阻拦，可能还是会有用户误操作，直到收到两份商品才发现下重了。此时就得依靠运营/客服的支持了。提供用户申诉的手段，让用户提出哪些订单是重复的，并且由销售系统店家、商品提供者和买家三方共同根据用户操作的记录来协商如何处理。我们需要让技术帮助让这种人工处理的几率尽量小。因为每次处理都会耗费较大的人工成本，和一些运营费用（比如赔款、小礼品等等）。

# 这么麻烦，有必要吗？ #

这要分业务场景，对于很多电商来讲可能不是必要的。因为从用户下单到订单被审核处理进入到发货阶段需要一定的时间（可能是半小时～1小时），并且一定是支付成功后才会开始进行下一步流程。在这个时间段，用户大概率能从网络错误中恢复过来，自行区分是否下重了。配合客服主动提示，会极大的降低出问题的概率。

但是对于理财服务来说，这种去重就非常必要了。因为

*  “下单+支付”。用户购买理财往往是“下单+支付”一起执行，不可以单独下单/单独支付
 *  用户的入金可能很大。例如数万，数十万
 *  准确性丢失。如果一旦下重了，有可能影响用户的投资资金配置的准确性。
 *  撤销难。部分理财产品存在下单不可撤销的问题；或者即便撤销，资金也无法立刻回款。等到回款，可能这个购入机会就错过去了。例如对于基金交易，错过1个交易日，价格就会发生变动。

基于这些特性，在理财产品中，就要竭尽全力的去重。

# 结论 #

以上所讲是处理重复订单问题的一般方法。你可以注意到，无论多么好的技术，也不可能100%的拦截所有的可能性，必须依靠技术+产品设计+运营支持的综合手段才能解决这类问题。

另外，本文还没涉及到关于订单支付（支付也可能重复哦）带来的进一步的复杂性，也没有讨论在高并发情况下的性能优化，仅仅讨论下单本身的问题。所以可以想象一下现实中的交易业务比这里的说的要复杂得多。

本文介绍的原理也不仅仅适用于防止下重复订单，而是可以应用到任何需要“创建一个不应该重复资源”的场景，比如“向用户发一条通知”，“触发一次不能重复的批处理任务“……

希望今天你有get到：）。

[96]: /images/20220530/e24b0d4a5206484daf02d733d1462ea6.png
[96 1]: https://www.jianshu.com/u/5f4fd06b24dd
[700]: /images/20220530/085402de609e444ea18a76c5e049a8f1.png
[700 1]: /images/20220530/2518731501004395a696224374619e3b.png
[676]: /images/20220530/d5f18d98218d4c79ad912c7ae677d01b.png