RocketMq（一）订单场景铺设

该系列参考狸猫技术窝的《》

该专栏以订单模块为驱动，对该模块面临的问题用RocketMQ来解决

一、业务背景

如下图所示，订单系统在用户下单后需要创建订单，且在订单支付成功回调后，会分别调用优惠卷、红包、积分、第三方物流系统、大数据系统等服务。

而在这个过程中就存在大量的问题.

如上图所示，一个简单的订单就需要经历上面的8个步骤（其实还不止。例如扣减库存、更新订单状态、更新积分、发优惠卷、发红包、发送Push推送、通知仓储系统发货等等一系列活），而这么多的步骤造成的之间影响就是响应时间太慢，在大流量的时间段可能会直接不可用。

我们不说其他步骤，就单步骤8，此时支付成功要去调用多个系统或服务，而且调用链是串行化的，此时整体的响应速度就被严重的拖慢了。试想一下，如果用户支付成功后会跳转为订单页面，此时由于订单响应太慢一直有个圈圈在转，那此时是非常影响用户体验的。

支付成功后我们订单系统的大概流程如下：

而且订单系统不仅仅要考虑订单支付成功后要干嘛，还要考虑支付失败后干嘛，用户退款后要干嘛？此时是不是得做之前支付成功得反操作，所以这个操作也是非常耗时。此时至少要做以下的几个步骤：

更甚者要考虑货物是否已经发货了，发货后又要做什么操作？
为了简单起见，我们这里是以没发货为例，所以我们退款的基本流程如下：

但退款不仅仅存在响应慢的问题，此时还要考虑如果订单状态更新了，积分回收了等等其他的工作完成了，此时第三方支付系统退款失败了，那此时怎么办？？

除退款后，我们还需注意放弃支付的情况（订单确定提交了，但就是不付款）（订单支付之前的问题）

那么此时已经锁定库存，那此时是不是得去在适当得时机去解锁这个库存，不然这个库存可能会被一直锁定无法使用。那么此时我们假设订单24小时未支付就把订单改为已关闭，然后释放掉商品库存。那此时就得专门设立一个线程去定时扫描哪些订单超过24小时没付款。具体流程如下：

此时问题就来了，如果有上百万订单甚至上千万未支付订单，此时是要一笔一笔地去扫描？这个效率不就非常低？

所以，订单地关闭、订单扫描是未支付前最大地问题。

 

说到这里，此时是否会发现，其实支付成功和退款的流程调用的服务或系统都是类似的，如果此时我们解决了支付的流程问题，是不是就相应的可以解决退款的流程。而对应未支付地问题我们还需要再想办法。

总结：
在订单系统中主要存在以下问题需要解决：（注意：这里只是列出简单的几个问题，其实订单系统还有更多的注意点和问题需要解决）

1、支付成功时：存在调用链长且串行调用带来的响应慢问题。

退款时的流程和支付成功时类似（基本解决了支付成功的问题就可以相应的解决退款时存在的问题），退款还需要考虑退款失败的问题。（其实响应慢的问题后续带来的问题还有很多，不仅仅是只有响应慢）

2、订单提交未支付：大量未支付订单的扫描问题。

二、对订单支付成功后问题进行分析

上面说了这个订单系统目前面临的问题，这里我们以订单支付成功为例，看看为什么会出现这些问题：
1、和第三方系统的对接耦合度太高

在订单支付成功的主流程中，我们以仓储系统为例，此时我们串行调用仓储系统，此时仓储系统会去调度仓库里的商品，在发货时还要去调用第三方物流公司的系统通知物流公司去仓库取货发货。那么接下来物流公司的系统会通知自己的快递员或运输队去仓库取货，然后派发货给购买商品的用户。那么我们整体的流程变成这样：

这个时候你想想，单单一个仓储系统就需要多出这么多步骤，且每个步骤都是有海量数据的筛选，和第三方系统的耦合度太高（性能差、不稳定）就是原因之一。

2、大数据团队需要大量的订单数据

此时大数据团队需要我们数据库的订单数据，那这个时候怎么给他们？
直接让他们去数据库select？？此时你要注意，大数据的sql基本都是几百行的大sql，如果直接去mysql中执行，在数据量大的时候是非常耗时的，此时也会造成数据库的压力。从而影响我们订单系统的性能。

此时其他系统的跨系统数据访问造成的数据库压力也是导致订单系统的问题之一。

3、高流量时段造成的订单系统压力

假如在流量高峰时，每秒有2000个请求到订单系统，此时包括下单接口、退款接口、查询接口等，那么此时每秒执行的sql数是巨大的。

一般你可以认为平均一个接口要执行2-3次数据库操作，那么此时2000请求大概对应6000的数据库请求。此时堆堆硬件可能就还暂时能抗住。但是随着业务发展、用户量增加，在下次的大促活动可能每秒就会提升到一两万的QPS，那么此时就不是简单的堆机器能解决的。

三、解决方法：消息中间件

对于订单存在的问题，此时可以使用消息中间件来解决。

了解消息中间件前，先了解下同步：

首先，通常而言在公司中可能存在多个业务系统，这些系统间的通信都是进行接口调用，例如A系统调用B系统，此时A系统要等B系统的调用结果返回回来才会进行下一步。这个步骤就是所谓的同步调用。

此时我们在看看怎么依托于消息中间件来实现异步调用。

我们在加入消息中间件后会是什么情况？

从图中我们可以看到，系统A不需要等系统B返回结果再向下执行了，此时往MQ中发送消息就可以自己做下面的事情了，然后直接返回结果即可。

这个时候就称为异步调用，异步调用就是A干自己的活，需要B干活了就通知它就行。

此时的MQ起到了异步化提升性能、降低系统耦合、流量削峰（用MQ积压部分消息慢慢消费的方式）等作用。

说到这里，你可去调研下现在市面上有什么主流的中间件，每个中间件的应用场景、各自的优缺点等，再去看看自己公司用的是什么mq，什么架构、怎么配置的。