前言

文章中的图片和在摘录不是来自一篇文章，所以细节不是完全对应。可借鉴的是开发的思路：

从整体的功能模块的使用；
到核心流程；
到系统实现的架构；
再到代码流程（可以采用序列图）。

前两点是业务需求，后两点是功能实现。

支付系统的作用

https://www.cnblogs.com/veblen/p/10992167.html

核心流程

http://www.woshipm.com/pd/1392102.html

订单支付：

用户支付完订单后，需要获取订单的支付信息，包括支付流水号、支付时间等。支付完订单接着就是等商家发货，但在发货过程中，根据平台业务模式的不同，可能会涉及到订单的拆分。

架构图

https://blog.csdn.net/egworkspace/article/details/78900438?depth_1-utm_source=distribute.pc_relevant.none-task&utm_source=distribute.pc_relevant.none-task

跟着标注的序号，可以跟踪到一个支付请求是如何发起的（Sequence Diagram就免了），流程描述如下：

Submit a pay task，当客户端需要发起支付的时候，起始是向支付任务队列里面加入了一个新的支付任务，这个过程是异步实现的。先根据客户端提交的参数，构造好一个新的支付任务；
Offer a task，开启一个异步任务，做的事情就是向MQ中添加一个新的支付任务，等待被消费；
Pay task description，一旦异步任务被成功创建，将会把第一步构造好的支付任务信息直接return给客户端；
Poll a task，与此同时，支付任务的消费者将新的支付任务poll下来进行执行；
Send a pay request，这一步需要根据实际情况而定。并不是所有的支付请求都要先经过第三方支付平台，比如支付宝；而对于微信，则还需要凭支付参数申请一个prepay_id，再经由客户端发起支付；
Response，没什么好说的，第三方渠道返回的支付必要参数；
Cache result，至此，一个支付任务可以算是完成了，可以将任务的执行结果（无论成功与否）缓存在Redis中，随时等待客户端的回访；
Query result，客户端在提交支付任务后，间隔一定时间后（建议2~3s），发起一个结果查询的请求；
Query，直接进Redis查找结果；
Synchronize，这是一个异步的操作，将支付任务的执行结果“顺便”同步到MongoDB中，并删除Redis中缓存的任务执行结果。持久化到MongoDB主要是为后续的容错，重试，数据分析等提供落地的数据源；
Return，由Redis返回给应用服务器；
Return payment，应用服务器再将最终的支付对象返回给客户端。

让我们更深入一点，我们来看三张Class Diagram：

① 先说说支付任务(PayTask)部分。PayTask和Payment两个都是MongoDB中的Document对象，但在任务执行期间，PayTask是用Redis进行缓存的，方便客户端随时发起Query，任务执行成功后，会生成Payment对象，最终PayTask和Payment都会持久化到MongoDB中。在PayService中，有对支付任务的一些基本操作，包括任务提交，取消，重试，构建等等。

② 再说说任务的执行(runner)。这部分和RabbitMQ紧密相关，一旦一个支付任务形成了，就会放入任务执行队列中，由消费者取出执行。在TaskRunner中，有两个基本的接口方法：run(task)、retry(task)，分别是执行任务和重试任务。在AbstractPayTaskRunner中已经封装好了这两个方法，继承AbstractPayTaskRunner需要实现doTask方法，从返回值可以看出，这个过程是异步化的。关于Retry机制，用户可以设置重试与否，一旦设置了TaskInfo.needRetry=true（不出意外，默认就是允许重试），就启用了Retry机制。还可以设置重试的次数(TaskInfo.retryTimes)，默认三次，分别间隔1s，2s，3s，间隔时间以公差为1的等差数列组成。当然不会让用户无限重试，系统内置有一个最大重试次数，最大重试次数内置为5次。

为什么是5次？

你感受一下，1s，2s，3s，4s，5s，整个请求链条就被拉长到了15s，这对客户端简直就是灾难了！！