RocketMQ实战—1.订单系统面临的技术挑战-编程知识

RocketMQ实战—1.订单系统面临的技术挑战

news/2025/1/29 8:45:40/文章来源:https://www.cnblogs.com/mjunz/p/18692912

大纲

1.一个订单系统的整体架构、业务流程及负载情况

2.订单系统面临的技术问题一：下订单的同时还要发券、发红包、Push推送等导致性能太差

3.订单系统面临的技术问题二：订单退款时经常流程失败导致无法完成退款

4.订单系统面临的技术问题三：第三方客户系统的对接耦合性太高导致经常出现问题

5.订单系统面临的技术问题四：大数据团队需要订单数据应该怎么对接

6.订单系统面临的技术问题五：秒杀活动时数据库压力太大应该怎么缓解

7.梳理高并发订单系统面临的技术挑战

8.进行系统设计时放大100倍压力找出其技术挑战

1.一个订单系统的整体架构、业务流程及负载情况

(1)电商购物流程

(2)订单系统的核心业务流程

(3)订单系统的非核心业务流程

(4)订单系统的真实生产负载情况

(1)电商购物流程

(2)订单系统的核心业务流程

当用户对购物车中选中的一批商品提交订单时，会先出来一个确认订单的界面。用户得先确认这个订单中的商品、价格、运费是否无误，然后确认订单的快递方式、收件地址是否无误，接着判断是否需要开发票以及发票的抬头是什么。当然，在这个过程中用户可以选择是否需要使用优惠券等。当用户完成这些信息的确认后就可以提交订单了。

于是订单系统最核心的一个环节就出现了，就是根据APP传来的各种信息完成订单的创建。此时需要在数据库中创建对应的订单记录，整个过程如下图示：

当用户正式确认下单后，除了在数据库中创建这个订单外，还会跳转到支付界面，让用户选择支付方式并完成订单的支付。比如跳转到支付宝或微信，让用户在支付宝或微信中完成支付，如下图示：

当用户完成支付后，支付宝或微信之类的支付系统一般会回调订单系统的接口，通知订单系统本次支付已经成功。当订单系统收到支付成功的回调后，需要安排配送发货、需要给用户发放优惠券或者现金红包来鼓励用户继续购物、需要给用户发送推送来通知用户支付成功准备发货(这个推送一般会通过短信通知)。下图就包含了订单支付完成后要做的一些事情：

(3)订单系统的非核心业务流程

订单系统在运行的过程中还会和营销系统、购物车系统、商品系统、配送系统等进行复杂交互。下面就是订单系统在运行时的一些非核心业务流程(订单系统需要具备的基本功能模块)：

下单模块主要是用于创建订单，异步模块主要是在支付成功后发放优惠券、发送红包和推送通知，查询模块主要是提供订单查询的功能。

当订单系统完成核心的下单业务流程后，用户通常会查询自己的订单，那么订单系统就需要提供对应的订单查询功能。当用户查询到一个订单列表后，有时会因为各种原因想要退货，因此订单系统还需要退货模块提供退货功能。

此外，订单系统除了自己要提供的功能模块外，还需要跟第三方系统进行对接。比如想要查看订单的配送状态，那么就需要订单系统从第三方物流公司的系统中进行查询。比如运营团队需要根据订单数据进行业务分析，那么就需要订单系统提供订单数据给大数据团队进行报表生成。

最后在类似双11、秒杀等大促场景下，可能大量的用户会等待一些特价促销的商品开卖后进行抢购，此时可能会对订单系统产生一个流量洪峰，甚至影响正常的一些下单功能。因此订单系统往往需要提供一个专门用于抗双11、秒杀等活动的大促模块，专门用于处理特殊活动下的高并发下单请求。

(4)订单系统的真实生产负载情况

首先看订单系统的订单量。假设在一个垂直电商领域第一的APP中，几年时间累计注册的用户数量已有几千万。由于注册的用户不是每个都会天天来逛APP，大部分用户也就是每隔几天会来逛一逛APP。所以根据统计来看，每天活跃用户的数量是一两百万，每天新增订单的数量是几十万。随着该公司的发展，日常情况下的订单数量可能很快就会变成每日百万。当然在一些双11、618大促活动的情况下，目前的订单数量就已经能达到单日百万的级别了。如下图示：

接下来看订单系统的QPS。QPS就是系统每秒的查询数量，这个指标是指订单系统所有核心以及非核心功能模块加起来，每秒钟有多少请求量。对该公司来说，在平常每天的高峰期，大概最多会达到每秒2000的访问量，不算太大。但是如果要是有那种特价商品限时秒杀的活动，那可能就会达到每秒1万以上的访问量。如下图示：

以上就是该公司订单系统的整体压力。可以看到，压力主要在两方面：一方面是订单系统日益增长的数据量，一方面是在大促活动时每秒上万的访问量。

(5)总结

当前订单系统的整体架构是比较简单的，仅仅是让开发好的系统直接连接一台数据库服务器，所有数据都存储在里面。然后也是由这台数据库服务器去抗所有的访问压力，所以现在订单系统在一些大促活动时经常会出现不稳定的情况。

随着数据库中的订单数据越来越多，数据库的读写性能就会越来越差。尤其在大促活动高峰期时，数据库访问压力剧增，读写性能会进一步下降，经常出现请求过慢、请求超时等问题。所以需要在该订单系统的架构中引入更多的技术，进行大量的架构优化，让订单系统逐步趋向于稳定。

2.订单系统面临的技术问题一：下订单的同时还要发券、发红包、Push推送等导致性能太差

(1)订单系统的整体架构和流程

(2)订单系统的压力指的是什么及压力从哪里来

(3)根据线上统计数据推算出系统的负载

(4)为什么系统的压力会越来越大

(5)如果系统压力越来越大会怎么样

(1)订单系统的整体架构和流程

首先，订单系统必须得有一个下单模块负责让用户进行下订单。

其次，当订单创建好之后，必须要跳转到第三方支付的界面上去，让用户尽快支付。如果用户支付成功了，第三方支付系统就会回调订单系统的接口。

接着，订单系统会去做一些事情，比如扣减商品的库存、更新订单的状态、给用户发放优惠券、发放红包或者积分、给用户发送推送通知用户订单已经支付正在等待出库。

然后，用户就可以从订单系统的查询模块检索自己的订单，此时可以做一些非核心的业务流程。常见的非核心业务有：对商品进行退货、查询订单的物流状态、或者之前没有支付现在对订单进行支付等。

最后，订单系统需要提供一个大促模块，专门去抗双11、618、秒杀等大促活动时的瞬时超高并发，大促模块必须跟正常的下单流程区分开来。

此外，可能会有其他兄弟团队来获取订单系统的数据，比如大数据团队。

假设当前APP的整体负载为：千万注册用户、百万日活、每日几十万订单量、每天高峰期的访问QPS是每秒两三千。当前订单系统架构比较简单，主要是一套订单系统部署了多台机器，做了一个集群，然后只连接一台数据库。

现在的问题是：随着用户量越来越大，数据量会越来越大，高峰期并发量也会越来越高，系统的压力会越来越大，光靠这个架构抗是很困难的，亟需对订单系统进行架构升级和改造。

(2)订单系统的压力指的是什么及压力从哪里来

该订单系统在每天的高峰期大概会有每秒2000的请求量，在非高峰时，则远远达不到这么高的QPS，所以只考虑高峰期的压力即可。

假设该电商APP每天大概有百万的用户在使用，这些用户的生活习惯分析如下：早上刚起床，匆忙洗脸刷牙，然后出门在路上买个早点，该过程不会逛电商APP。接下来会健步如飞去赶地铁，或者坐公交车，在这个过程中如果人挤人，也不会逛电商APP。接着到公司后，就开始一天的工作，在工作过程中也比较难逛电商APP。然后好不容易工作到中午，大家吃完午饭开始午休，有的人刷抖音，有的人玩王者，有的人则可能会逛一逛电商APP。但是对于一个合格的职场员工，上午干的很累，下午还有工作压力，中午也不敢放松太多，中午应该不会逛太多时间。下午继续工作，最后好不容易下班了，接着坐地铁或班车回家时，这个过程中往往是一天最轻松的时刻。到家以后直到睡觉前，也都会适当放松一会儿，比如玩一玩游戏，或者逛电商APP买点自己喜欢的东西。以上就是大部分用户的生活习惯，这些生活习惯直接决定了用户使用该电商APP的频率、时间段和时长。

(3)根据线上统计数据推算出系统的负载

明白了用户的生活习惯后，就可以结合线上的统计数据来推算系统的工作负载了。通过线上的统计数据可以知道：80%的用户都习惯在晚上六点到十一点这几个小时使用该APP，这个时间段刚好是大部分人的休闲时间。所以在晚上六点到十一点这几个小时内，可以认为有80万左右的用户会使用APP。

由于该APP是一个电商APP，用户首先会浏览商品、搜索商品，然后才会提交订单和支付订单，所以用户一般会对APP执行几十次到上百次点击。但大部分点击都是在和商品系统、评论系统进行交互，比如查看商品、查看评价。因此对订单系统而言，访问主要来自提交订单、对订单进行查询和退款等操作。

假设APP每天有三五十万个订单，也就对应了百万次下单操作和订单查询操作。百万次针对订单系统的请求看起来似乎很多，但如果平均到5个小时中，每秒只有几十次请求而已。但是如果真按照这么计算，就大错特错了，因为电商APP有两个特点：

特点一：真实的系统访问负载应该是一个半圆形的曲线，比如从晚上6点开始访问量开始增加，一直到晚上八九点达到顶点，然后访问量慢慢开始下落，到晚上十一点就变为最低。所以系统的访问压力，不能直接按平均值来计算。

特点二：电商APP每天都会有一些限时限量售卖的特价商品。在限时的那段时间里，会有很多用户在等待时间的到来然后点击购买下单，此时订单系统的压力往往是最大的。

根据线上系统接口的统计数据来看，晚上购物最活跃时，订单系统每秒会有超过2000的请求。这就是订单系统的最高负载，其他时候都比这个负载低。

(4)为什么系统的压力会越来越大

假设现在线上的订单系统一共部署了8台机器，每台机器的配置是4核8G，这是互联网公司的标准配置。当然也有不少系统是用2核4G的机器部署的，那也是标准配置。因此高峰期每台机器的请求大概是每秒200~300。

但是这8台部署了订单系统的服务器都是连接同一台数据库服务器的。数据库服务器的配置是16核32G，而且是SSD固态硬盘的，用的是比较高配置的机器，因此性能会更好一些。

在这样的部署情况下，面对高峰期每秒2000左右的请求，还是可以轻松抗住的。因为4核8G的机器一般每秒可以抗几百请求，现在才每秒两三百请求，CPU资源使用率都不超过50%。所以8台4核8G的机器，每台机器每秒可以轻松抗下高峰期的两三百请求。

然后数据库服务器用的是16核32G的配置，之前压测的时候知道它即使每秒上万请求也能扛得下，只不过那已经是它的极限了，会导致数据库服务器的CPU、磁盘、网络、IO、内存的使用率几乎达到极限。但一般面对每秒四五千的请求，这样的数据库服务器是没什么问题的。何况经过线上监控统计，现在数据库服务器在高峰期的每秒请求量也就三四千，因此基本上没啥问题。

(5)如果系统压力越来越大会怎么样

如果该APP用户量越来越大、并发量越来越大、数据量越来越大，这个订单系统会有什么问题？

首先，订单系统会遇到最明显的一个问题，也是最影响用户体验的一个问题，如下：

根据订单系统的业务流程图可以知道，在用户提交订单之后就是要支付订单，在支付成功之后订单系统要干很多事情。

在上图的步骤8里，订单系统除了发放优惠券、发送红包、发送推送通知用户外，还要做很多事情。比如对于一个电商APP而言，卖掉一个商品后，要扣减掉商品的库存，而且一旦用户成功支付了还得更新订单的状态为待发货。现在根据线上系统的统计，这个步骤8的多个子步骤全部执行完毕，加起来大概需要1~2秒的时间。有时候在高峰期，可能会出现需要几秒钟才能完成上述几个步骤。

这会导致什么影响呢？可能会导致用户在支付完一个订单后，界面上会有一个圈圈不停的旋转，等待好几秒后才能提示支付成功。对用户来说，几秒钟的时间，会让人非常不耐烦的。所以针对步骤8的子步骤过多、速度过慢、让用户支付后等待时间过长的问题，就是订单系统第一个亟需解决的问题。

3.订单系统面临的技术问题二：订单退款时经常流程失败导致无法完成退款

(1)支付的第一个问题：流程太长子步骤太多

(2)支付的第二个问题：退款处理复杂

(3)退款的第一个问题：流程太长子步骤过多

(4)退款的第二个问题：第三方支付系统退款失败

(5)支付的第二个问题：用户下单后一直不付款

(6)支付的第三个问题：如何扫描几十万订单没付款

(1)支付的第一个问题：流程太长子步骤太多

前面指出了订单系统现在面临的第一个问题：支付成功后子步骤太多导致的用户体验较差。也就是支付成功后的核心业务流程里混杂的子步骤太多了：扣减库存、更新订单状态、更新积分、发放优惠券、发送红包、发送推送、通知仓储系统发货等。这一连串的步骤在系统高峰期压力大时，可能需要好几秒才能完成，用户体验非常不好。

如下图所示便是订单支付过后的一系列流程：包含了扣减库存、更新订单状态、更新积分、发放优惠券、发送红包、发送推送、通知仓储系统调度发货。

(2)支付的第二个问题：退款处理复杂

前面指出了订单系统的第一个问题，就是支付之后的流程过于复杂，导致耗时太长，用户体验太差。那么订单系统的第二个问题，就是订单支付的反向过程——退款。

用户下一个订单，把钱付给平台后，平台会给用户一系列的利好，比如发券、发积分、发红包。那么在用户申请退款后，平台就需要把用户之前付给平台的钱还给平台了。既然钱退给用户了，那么平台也需要把之前给用户的一些利好都收回来，比如优惠券、积分、红包。

所以，订单退款本质上是一个订单支付的逆向过程，也就是说订单退款应该做如下一些事：重新给商品增加库存、更新订单状态为"已完成"、减少用户的积分、收回用户的优惠券和红包、发送推送告诉用户退款完成了、通知仓储系统取消发货。

最重要的是，需要通过第三方支付系统把钱重新退还给用户。而且如果电商平台都已经给用户发货了，用户才申请退款，那么用户还得把收到的商品寄回给平台，等平台收到商品再把钱退还给用户。当然，这里简单起见，只讨论商品还没发货这种情况。

如下便是退款的流程图：

(3)退款的第一个问题：流程太长子步骤过多

这个退款和支付有一样的问题：都是流程太长，子步骤过多。如果用户点击退款之后要一下子执行这么多步骤，可能需要好几秒的时间，用户体验同样是很差的。不过订单的退款可不只是这一个问题。

(4)退款的第二个问题：第三方支付系统退款失败

其实在退款时，最大的问题还不是步骤太多执行太慢，最大的问题是：假设库存增加完了、订单状态更新了、积分收回了、优惠券收回了、仓储系统中断发货了、然后发送推送告诉用户已经退款了，结果第三方支付系统退款失败了。

比如有可能是第三方支付系统自己的问题导致退款失败，也可能是订单系统在调用第三方支付系统时，因网络问题导致调用失败，从而退款失败。总之，用户以为退款成功了，结果一查自己账户，钱就是没进来，这才是最要命的一个问题。这种情况可能会导致用户再也不愿意来该APP里购物，而且是技术型故障，这不仅仅是用户体验的问题了。

(5)支付的第二个问题：用户下单后一直不付款

现已介绍完用户支付和退款两个流程里的问题，接着来看第三个问题，就是用户在支付之前会干什么。

通常来说，用户在购物车里会加入很多的商品，然后选择下单跳转到一个订单确认界面。在订单确认界面里确认收货地址、发票抬头、优惠券使用等一系列的问题，接着点击确认提交这个订单。

当订单提交到订单系统后，就会在数据库中创建出一个订单，然后就会跳转到支付界面让用户进行付款。但是万一用户在付款界面犹豫了，结果把付款界面给关了。那么就会出现这么一种情况：订单创建了但是没支付，此时订单的状态为"待支付"。而且只要用户提交了订单，订单里涉及到的商品，都会有对应的锁定库存的工作，相当于给用户预先保留好这些商品。订单系统在创建订单时已经调用库存系统锁定了用户要买的商品的库存，结果用户跳转到支付界面后却放弃了支付，如果订单一直不付款，那么它对应的商品库存就会一直锁定，影响其他用户的购买。

所以一般来说，订单系统还会启动一个后台线程，这个后台线程就是专门扫描数据库里那些待付款的订单。如果发现超过24小时还没付款，就把订单状态改成"已关闭"，释放掉锁定的那些商品库存。

(6)支付的第三个问题：如何扫描几十万订单没付款

问题就出在了这个扫描待支付订单上。假设现在数据库中积压了几十万笔待支付的订单，难道要求一个后台线程不停扫描这几十万笔订单吗？这个效率明显是很低的，万一以后有几百万笔未支付订单，难道要不停扫描几百万笔待支付的订单吗？所以这个就是订单支付前最大的一个技术问题。

4.订单系统面临的技术问题三：第三方客户系统的对接耦合性太高导致经常出现问题

(1)重新观察订单支付的核心流程

(2)设计系统的必备经验：跟第三方系统打交道

(3)什么是系统之间的耦合

(4)订单系统有没有跟第三方物流系统耦合

(5)跟第三方系统耦合的痛苦：性能差、不稳定

(6)第三方系统的耦合给订单系统带来了不确定性

(1)重新观察订单支付的核心流程

前面已介绍订单系统的整体情况，也指出了订单系统目前面临的一些问题：包括订单在支付前、支付过程中以及支付完成后退款时面临的一些技术隐患。

订单支付时的核心流程图如下：

针对上述流程图，除了支付后的流程步骤太多耗时太长导致影响用户体验外，还有其他问题吗？

(2)设计系统的必备经验：跟第三方系统打交道

在订单支付时，大部分核心步骤其实都是在自己公司的系统里完成的。比如更新订单的状态是在自己公司的订单系统内部完成的，扣减库存是在自己公司内部的库存系统完成的，增加积分是在自己公司内部的积分系统完成的，派发优惠券红包是在自己公司内部的营销系统完成的。但是这些都做完之后，最关键的一个环节呢？商品的出库发货该找谁？

一般电商公司内部都会有自己的仓储系统，管理各种仓库和商品的发货。通常来说会选择去找一个距离用户最近的一个仓库，然后从里面调度一些商品进行发货。在发货时还需要调用第三方物流公司的系统，通知物流公司去仓库里取货发货。物流公司的物流系统收到货运通知后会通知自己的快递员或运输队到对方仓库里取货，然后派发货物给用户。所以支付订单的核心流程图里需要补充几个步骤：

(3)什么是系统之间的耦合

比如在这个订单支付流程里，订单系统其实是要调用很多其他系统的，有库存系统、积分系统、营销系统、仓储系统等。现在思考一个问题，假设促销系统有一个接口，专门是让订单系统调用了以后去派发优惠券的。现在这个接口接收的参数有5个，订单系统要调用这个接口，就必须传递5个参数进去。

问题来了，负责促销系统的工程师某一天根据需求需要改这个接口，在接口调用时要传递7个参数。一旦它的这个新接口上线，订单系统还是给它传5个参数，那么促销系统就会报错，这个派发优惠券的行为就会失败。在这样的一个情况下应该怎么办？

作为订单系统的负责人，必须要配合促销系统去修改代码，在调用促销系统该接口时传递7个参数。并且还得配合促销系统的新接口去进行测试以及部署上线，必须围绕着促销系统转、配合促销系统。在这种情况下，就说明订单系统跟促销系统是强耦合的。因为促销系统任何一点接口修改，都会牵扯订单系统围着它转，去配合它，耗费订单团队的人力和时间。要动一起动，要静一起静，这就是系统间的耦合。

(4)订单系统有没有跟第三方物流系统耦合

订单系统跟仓储系统耦合，而仓储系统又跟第三方物流系统耦合，这就说明了：订单系统间接耦合了第三方物流系统。订单系统要调用仓储系统的接口去发货，仓储系统在接到订单系统的调用后，要同时去调用第三方物流系统生成物流单，通知物流取货。

所以在上图中，仓储系统必须等第三方物流系统返回确认信息后才能返回结果，订单系统才能结束对仓储系统的调用。在这个情况下，订单系统就跟仓储系统、第三方物流系统，全部耦合在一起了。

(5)跟第三方系统耦合的痛苦：性能差、不稳定

一般来说，跟第三方系统的交互往往是最麻烦的。因为对于自己公司内的系统，即使有问题，所有代码数据库都在自己公司，自己可以去推动优化。但对于第三方系统的调用，就不是那么回事了。假如调用它的接口，有时候速度很快只要20ms，有时候速度很慢要200ms，有时候调用很正常，有时候偶尔会调用失败几次，该怎么办？

所以，不能完全信任第三方系统，它随时有可能出现性能变差、接口失败的问题。这就是系统跟第三方系统耦合在一起的痛苦：对方不可控，导致自己系统的性能和稳定性也不可控。

(6)第三方系统的耦合给订单系统带来了不确定性

订单系统调用仓储系统，接着调用第三方物流系统，所以订单系统很可能被第三方系统给拖累。万一第三方系统的性能突然降低，订单系统的性能就降低了。万一第三方系统接口突然调用失败，订单系统的这次操作也会失败，后续还要考虑重试机制。

所以在该订单支付的核心流程里，其实还有这么一个技术隐患：耦合第三方系统带来的不确定性。

5.订单系统面临的技术问题四：大数据团队需要订单数据应该怎么对接

(1)大数据团队的工作

(2)大数据团队和订单团队的关系

(3)几百行大SQL直接查线上库的危害

(1)大数据团队的工作

大数据团队每天要负责的事情，就是尽可能搜集用户在APP上的各种行为数据。比如用户搜索了什么、点击了什么、评论了什么，以及搜集用户在APP里的交易数据，比如最核心的订单数据。订单数据能直观代表用户在APP里的所有交易。

当大数据团队搜集好大量数据后，就可以用这些数据计算出很多结果。最常见的就是数据报表，比如用户行为报表，订单分析报表等，这些数据报表会提供给运营看，来更好地运营平台。

(2)大数据团队和订单团队的关系

大数据团队会搜集各种各样的数据，其中就包含订单数据。他们需要分析每天几十万个订单，从中提取出运营最关心的APP交易数据报表。假设现在大数据团队刚刚成立，各种基础组件都没搭建好。但是运营需要的一些数据实在太着急，所以大数据团队只能通过如下方式跑出交易报表：

由于目前订单数据库是直接对外暴露的，大数据团队可以直接访问订单数据库。他们有一个数据报表系统，运营每次查看交易报表时，会直接用一个几百行的大SQL，从订单数据库里查数据。

(3)几百行大SQL直接查线上库的危害

首先，订单数据库里的数据量是很大的，订单数据库从最开始每天只有几百个订单，到现在每天几十万订单，每个月都新增千万级订单数据。当运营每次要看交易报表时，都要在千万级数据的数据库表中运行一个几百行的大SQL，这种级别的SQL在这种量级下，快则三五秒，慢则几十秒。

执行几百行的大SQL是非常消耗CPU和磁盘IO的。一旦订单数据库负载很高，那么就会导致订单系统执行的一些增删改查操作的性能大幅下降。

6.订单系统面临的技术问题五：秒杀活动时数据库压力太大应该怎么缓解

(1)当前订单系统的问题总结

(2)日常高峰期的订单系统压力和数据库压力

(3)大促活动下的订单系统压力和数据库压力

(1)当前订单系统的问题总结

一.订单被支付前

二.订单被支付后

三.订单被发起退款

四.订单数据被查询

一.订单被支付前

当用户确认提交了订单，就会锁定对应商品的库存。如果用户一直没有支付，那么就需要一个后台线程不停扫描数据库里的待支付订单，并自动取消长时间没支付的订单。但是如果这种待支付的订单有几十万甚至几百万，那么后台线程不停扫描的性能和效率就会很差。

二.订单被支付后

此时，订单系统要经历更新订单状态、扣减库存、发送推送、增加积分、派发优惠券和红包、通知仓储系统发货等过程。如果这一系列过程都同步执行，那么整个过程的性能就会很差。而且在这个调用链路中，订单系统还跟仓储系统耦合在一起，仓储系统又跟第三方物流系统耦合在一起。如果第三方物流系统出现性能抖动，那么就会导致订单系统核心链路的性能抖动。如果第三方物流系统的接口出现调用失败，那么就会导致订单系统核心链路出现部分失败。

三.订单被发起退款

如果用户要退款，此时会涉及公司内部系统的一系列回滚。比如更新订单状态、增加库存、收回优惠券和红包、减少积分，通知取消发货等。而且还要调用第三方支付系统进行退款，万一退款失败，那么可能就会出现订单状态和钱款不一致。

四.订单数据被查询

由于大数据团队刚刚组建，来不及搭建自己的架构，而且运营急着看数据报表，所以直接在订单数据库中执行几百行的大SQL来得出数据报表。此时就很容易导致订单数据库的CPU和磁盘IO负载过高，从而导致订单系统CRUD操作的性能下降。

(2)日常高峰期的订单系统压力和数据库压力

根据电商APP的用户使用习惯，在平时晚上的高峰使用期，订单系统大概会有每秒2000的请求压力。

如果用户每秒发起2000个请求到订单系统的各类接口，包括下单接口、退款接口、查询接口等，那么订单系统每秒在订单数据库上执行的SQL数量一般可以采用如下方法进行估算：

比如订单系统的各类接口每秒会被调用总共2000次，平均每个接口执行2~3次的数据库操作。不同的接口根据业务复杂度的不同会有不同的处理：有的接口可能处理一个请求要执行五六次数据库操作，有的接口可能要执行一次数据库操作 + 两三个其他系统的接口调用(比如库存系统、营销系统)。总之，业务系统的接口处理逻辑，基本都集中在对自己数据库的操作以及对其他系统的调用上。

所以结合线上数据库的可视化监控界面可知，订单系统的接口调用平均每次会执行2次数据库操作。而观察数据库的监控界面可知，在最高峰时大概会有每秒4000的请求压力。