真实订单系统面临的技术挑战
一个真实电商订单系统的整体架构，业务流程及负载情况
一个订单的业务流程
用户通过APP浏览，添加喜欢的商品到购物车，然后下订单支付订单。
另外用户在确定订单的时候还需要确定自己的快递方式，收货地址，是否需要开发票之类的。
这时候我们订单系统最核心的一个环境，就是要根据APP端传递的消息创建订单。
除了在数据库中创建这个订单之外，还会跳转到支付界面，让我们选择支付方式去支付。
当我们收到支付成功通知后，就应该安排给用户发货了，此外还需要负责给用户发放优惠券之类的东西，还有push推送，告诉你准备发货收货等。
订单系统的非核心业务流程
下单模块主要是用于创建订单，异步模块主要是发劵，推送等，查询模块主要是提供订单的查询
此外我们还有些商品支持退货，因此需要一个退货模块
这时候我们想要看一下我们的物流信息，还需要推荐第三方物流系统
这时候老板想要看我们的商品销售场景，这时候就需要大数据接入，对订单数据进行分析，提交给领导们看
最后呢，到双11的时候，这样的大促销，秒杀的场景下，需要专门提供用于抗这样的大促模块
订单系统的真实负载情况
每天的活跃用户一两百万，每天新增订单十几万，在大促时候订单单日百万级别。
QPS峰值2000/s，在大促下1万/s。
系统面临的现实问题
现实情况
这次我们要搞明白系统的压力是从哪里来？
当你去赶地铁的时候，到公司干活的时候，你会看电商APP吗？
我想应该是不会的，一般来说只有中午休息偶尔逛一下，晚上到家之后，会好好放松一下，这时候才会逛一下。
这些问题看起来没有什么意义，但是这些用户的使用习惯决定了它们怎么使用我们的APP，什么时候使用。
根据现实情况算出系统负载
我们了解好了用户的生活习惯，接下来计算一下系统的工作负载。
基本上80%的用户习惯在晚上6点后凌晨11点这几个小时使用，所以可以认为80万左右的用户会使用APP。
一个电商APP，主要是用户浏览商品，搜索商品，然后才会下单和支付订单，一般一个用户会点击十几次到上百次左右。
但是大部分都是和商品系统，评论系统进行交互的。
对我们的订单系统而言，主要访问量是下订单以及对订单的检索，查询，少量退款等操作。每天大概是三五十万个订单，也就对应了百万次下单操作和一些订单查询操作。
在晚上购物最活跃的时候，订单系统下单达到最高峰时段，每秒会超过2000请求，最高负载。
为什么系统的压力会越来越大？
现在线上的订单系统一共部署了8台机器，每台机器的配置是4核8G ，因此高峰期每天机器请求大概是每秒200~300之间
这8台订单系统部署的服务器都是连接到1台数据库服务器的。配置是16核32G，使用SSD固态硬盘。
线上这样的机器部署情况，在高峰期每秒2000以上的请求下是很轻松的,CPU资源使用率都不超过50%。
因为用的是16核32G的配置，因为之前压测的时候知道其每秒上万请求可以做到，但是会导致数据库服务器CPU，磁盘，网络，IO，内存的使用率几乎达到极限。
一般来说每秒四五千的请求的话，这样的数据库服务器没有什么问题，现在数据库服务器在最高峰的每秒请求量也即是三四千的样子。
你们系统的核心流程性能如何？
我们需要思考以下的问题：
- 系统的核心业务流程性能如何？
- 核心流程的每个步骤要耗时多长时间？
- 现在核心流程的性能你还满意吗？是否还有优化空间？
- 在系统高峰期的时候，机器和数据库负载很高，是否对核心流程的性能有影响？
- 如果有影响的话，会有多大的影响？
我们可以在每个代码中去打印一个日志，看一下每个步骤的耗时，看看核心流程的时间耗时是多少？有没有优化空间。
订单退款时候经常失败怎么办？
订单支付流程回顾
退款时候需要干什么？
如果退款失败怎么办？如果用户下单后一直付不了款怎么办？
如果退款失败了用户可能不会再想来我们这里购物了，而且领导会来批评我们。
当用户确认订单完毕，就会从数据库中创建一个订单出来
但是如果在中途，用户把订单关闭了，这订单不是创建了，但是还没有支付，这时就需要锁定库存，保留好商品
但是这个库存不是一直保留的，超过一定时间没有支付，就会把订单状态改为"已关闭"，释放掉哪些商品库存。
如果有几十万订单没有支付，难道一直扫描？
假设我们的数据库累计了几十万笔待支付订单，难道要一直去扫描吗？这个效率太低下了。
这也就是订单支付之前最大的一个技术问题。
你们系统出现过核心流程链路失败的情况吗？
管理系统：对客户进行一些非常关键的核心操作，此时会涉及多个业务功能
互联网系统：在交易过程中的复杂流程
大数据系统：数据报表的清洗，计算，转换，存储
第三方客户系统的对接耦合性太大
如果通知仓储系统发货只是一个非常简单的事情，但是需要送货到他的手上还是要不少事情做吧。
什么叫做系统之间的耦合
当我们促销系统接口发生改变的时候，你的订单系统就需要去配合他，这时候这两个系统就耦合在一起了，就是当别人的接口改了，你手上的工作也要去为了迎合他也做修改。
订单系统有没有第三方物流系统耦合？
通知发货和生产物流订单这个耦合了。
如果别人的物流系统响应时间是200ms，而我们的订单系统只要20ms，那我们却影响不了这就是一个难办的问题
所以第三方系统，永远是不能完全信任
我们的系统很有可能被第三方系统拖累，万一他的性能降低了，我们的系统就降低了，如果他系统调用接口突然失败，我们的也会失败，后续还需要考虑重试机制。
大数据团队需要订单怎么办？
大数据团队是干什么的？
比如在昨天订单购物中的人，老用户有多少人，新用户有多少人，这些都是老板想要的数据，以此去考虑公司运营策略
当我们每天有100万用户访问APP，积累下来的一些浏览行为，访问行为，交易行为都是各种大数据，这个数据量很大，所以被叫为大数据。
而大数据团队负责做的事情就是每天尽可能去搜集100万用户在APP上的各种行为
大数据团队和订单团队的关系
订单团队里面的数据就是提供给大数据团队的，而大数据团队要从我们这里获取这么多数据，就会影响我们的订单系统
最简单的方法就是老板在查询报表的时候从数据库中使用几百行SQL，从我们的订单数据库中直接查出来数据
这种几百行的SQL语句快则三五秒，慢则十几秒，而不仅仅只有老板要看这个数据，还要副总高管等要看
这种情况会让我们的数据库负载很高，从而导致我们的订单系统执行的一些增删改查操作性能大幅度下降
秒杀活动时数据库压力太大怎么办？
当用户每秒2000次请求调用到我们的订单系统中，平均每个接口会执行多少次数据库操作？
可以任务每个接口会执行2~3次数据库操作
所以结合我们线上数据库的可视化监控界面，基本可以知道，平均每次订单系统的接口调用，会执行2次数据库操作，每秒大概4000次左右数据库请求
如果是高配的16核32G机器以及SSD固态硬盘机器，数据库还可以承受，但是在双11这种大促销的时候呢》数据库压力会面临多少？
现在公司注册用户已经千万级别，平时日活用户都百万级别，双11估计会参与用户两三百万
预计QPS每秒1万，数据库请求QPS就会达到2万以上，数据库根本扛不住