01 场景：一个真实电商订单系统的整体架构、业务流程及负载情况

1.电商核心业务——下单流程

1.1 下单流程图

1.2 流程说明：

1. 用户浏览商品系统
2. 添加商品到购物车
3. 选择其中某些商品下订单——提交订单
4. 拉起微信支付、支付宝支付——支付订单
5. 支付成功后，通知第三方仓储、发货系统，准备发货——物流发货

1.3 下单前涉及的业务

1. 选中购物车后，在确认订单页，确认订单中的商品、价格、运费等无误；
2. 选择是否使用优惠券、促销活动、积分等；
3. 确认快递方式（到付等）、收件地址、是否开发票、发票抬头等

2.核心环节——订单创建、支付

2.1 确认订单并跳转支付

2.2 流程说明：

1. 确认订单信息——订单系统返回订单中商品、价格等信息
2. 正式下单——用户确认无误后，提交正式下单，订单系统将订单数据写入数据库
3. 跳转支付——订单系统创建订单成功，跳转支付页，拉起微信支付或支付宝支付
4. 完成支付——用户扫码支付，完成整个下单到支付的流程。

2.3 支付成功后的业务细节

支付的过程调用的第三方支付系统，如：支付宝、微信等等；而在支付后，由第三方支付系统回调支付结果，根据回调支付成功结果，那么需要进行发送优惠券、红包、push短信通知等业务。流程图如下：

3.订单系统

3.1 订单系统的模块划分

1. 主要模块——主要模块也是订单系统的核心功能：下单模块。
2. 查询模块——订单查询功能，查询模块主要提供给用户查询自己的订单信息功能。
3. 异步模块——创建订单并支付成功后，异步模块在支付回调后发优惠券、红包、push短信通知等。
4. 退货模块——客户在查询订单后，有时候会有各种原因想要退货，订单系统需要提供退货功能。
5. 大促模块——类似双11、秒杀等大促场景下，专门用于扛流量洪峰的用于活动的大促模块，需要支持高并发下单场景

3.2 关联第三方

1. 第三方物流系统——查看订单的配送状态，通过订单系统从第三方物流公司的系统中进行查询
2. 数据分析与第三方团队——订单数据是核心数据，大数据团队需要根据该数据做成报表给公司高层查看

3.3 完整的业务场景

思考：以上的场景中，哪些可以用MQ、ES等来实现，达到优护系统性能的目的？

答：查询模块用ES；异步模块用MQ；支付回调相关用MQ保障；第三方对接用MQ解耦达到异步避免性能被拉低；大数据团队需要的数据通过MQ或DB从库实现，避免主库性能损耗。

4.负载情况

虚拟场景： 新兴公司，注册用户几千万，日活量为百万，每日订单量为几十万。每天最高峰QPS为2000/s，秒杀或大促活动时达到1W+/s。

存在的问题：

1. 订单系统日益增长的数据量，每日数据累加的结果；
2. 大促活动是每秒上万的访问压力，高峰期上万，其他时间段回落到几百

导致的性能问题：

1. 数据量累加导致对DB的占满，DB写入磁盘，第一：磁盘利用率高，相对性能低；第二：DB单库单表数据量大，存在SQL执行性能下降等问题；
2. 单库面对上万每秒的QPS会直接被打死，如果添加机器又有点浪费，毕竟高峰期就那么个把小时，不划算