### 解决支付掉单问题的两种技术方案
支付过程中出现的掉单问题一直是困扰很多电商平台和技术团队的一个难题。用户支付完成后，系统未能正确反馈支付结果，导致订单状态异常，不仅影响用户体验，还可能引发一系列后续服务问题。本文将详细介绍两种解决支付掉单问题的技术方案：定时轮询补偿方案和延迟消息补偿方案，并对这两种方案进行深入剖析。
#### 一、定时轮询补偿方案
**1.1 整体流程**
定时轮询补偿方案的核心是通过设定周期性的任务来检测并处理支付异常情况。其主要流程包括：
- **支付请求**：用户发起支付请求后，系统将该请求传递给支付通道。
- **支付响应**：支付通道接收到请求后返回响应。如果支付通道返回的是支付受理成功或支付处理中的状态，则需要进一步处理；如果直接返回支付成功，则按正常流程返回即可。
- **记录掉单**：对于支付受理成功或处理中的状态，需记录到掉单表中。
- **定时查询**：设定一个定时任务，定期查询掉单表中的记录。
- **发起查询**：对于掉单表中的每一笔记录，使用线程池并发发起支付结果查询。
- **支付结果查询**：调用支付通道提供的支付结果查询接口。
- **结果处理**：
- 如果支付结果为扣款成功或明确失败，则删除掉单记录；
- 如果支付结果仍处于处理中，则经过一定延时后重复查询流程，直到成功或达到最大查询次数为止。
**1.2 相关问题**
- **为何需要掉单表?**
- 主要是考虑到数据库查询效率问题。支付订单表随着业务的发展会逐渐增长，直接查询该表会导致查询效率低下。而单独设立的掉单表只记录支付未成功的订单，因此数据量较小，查询效率更高。
- **掉单表的管理**
- 掉单表中的记录是临时性的，当支付结果查询成功或失败，或查询次数达到上限时，就会被删除。这有助于保持掉单表的高效运行。
**1.3 方案优缺点**
- **优点**：架构简单易实施。
- **缺点**：
- 轮询效率较低，可能存在重复计算的问题。
- 实时性较差，如果每小时轮询一次，则最坏情况下会有1小时的时间延迟。
- 增加轮询频率可能会加剧查询效率和重复计算的问题。
#### 二、延迟消息补偿方案
**2.1 整体流程**
与定时轮询补偿方案相比，延迟消息补偿方案采用了一种“推”式的机制，通过延迟消息队列来处理支付异常。其主要流程包括：
- **支付请求与响应**：流程与定时轮询方案相似。
- **记录掉单**：不同之处在于，此时不是将记录直接插入掉单表，而是发送一条掉单消息至延迟队列。
- **消息处理**：延迟队列按照预设的延迟时间发送掉单消息给补单程序。
- **发起查询**：补单程序接收到消息后，发起支付结果查询。
- **结果处理**：
- 如果支付结果为扣款成功或明确失败，则标记消息为已消费，延迟队列删除该消息。
- 如果支付结果仍处于处理中，则延迟队列会在一定时间后重新发送消息。
**2.2 延迟队列实现**
延迟队列的实现方式多种多样，常见的有基于RedisSortedSet的实现和基于时间轮算法(TimingWheel)的实现等。这些方法各有特点，可根据实际情况选择最适合的一种。
- **基于RedisSortedSet实现**：适用于轻量级且灵活的场景。
- **基于时间轮算法实现**：适合于对实时性和准确度要求较高的场景。
**2.3 方案优缺点**
- **优点**：提高了实时性和减少了不必要的查询。
- **缺点**：
- 实现难度相对较高，尤其是自定义延迟队列的开发。
- 需要额外考虑延迟队列的可靠性和稳定性问题。
### 结论
两种方案各有千秋，选择哪种方案取决于具体的业务需求和技术背景。定时轮询补偿方案虽然简单易行，但在实时性和效率方面有所欠缺；而延迟消息补偿方案虽然在实现上较为复杂，但能够提供更好的用户体验和更高的处理效率。在实际应用中，还需根据自身情况权衡利弊，选择最适合的技术方案。
VIP享7折，此内容立减5.97元 
