02 系统面临的现实问题：日益增加的并发与同步响应延迟

订单架构如下：

1. 系统压力来源之一： 日益增加的并发访问量

在当前的案例中，每天几十万的订单量，对应了百万次下单操作和订单查询等操作，如果将其均分到5个小时内，也就是每秒几十次请求而已，但账不是这么算的。

电商系统的访问量受两方面影响：一个是用户习惯，一个是平台的营销策略；前者决定了平均每一天用户访问的最高峰，也就是前面说过的2000/s的请求，后者决定了大促当前的某个时间段内每秒1w请求的结果。

总结一下，就是真实的系统访问负载应该是一个半圆形的曲线：

如图，中间部分是访问高峰期，那么平时的峰值可能达到2000~3000/s的样子。这里假设订单系统由8台服务器，每台4核8G

再添加一台数据库为16核32G的配置

按照以上的配置，8台订单服务器扛住每秒2000的请求是没问题的，同样的数据库服务器也能轻松扛住2000~4000的请求。

压力的来源：公司的业务时日益增长的，也就是说用户会越来越多，订单量也会增多，同样的高峰期的请求量也在日渐增长，一旦增长到高峰期每秒6000个请求，那么8个订单系统还能轻松扛住，但是数据库就不一定了。16核32G的最佳负载是4000/s，再高就有宕机的风险了。而这是一个亟需解决的问题：日益增加的并发请求。

2.系统压力来源之二：同步响应延迟

上图中，第8个步骤里，除了发优惠券、红包、push短信通知外，还要做很多事。比如：支付后要对预占的库存做实际扣减落库；支付成功后，要更新订单状态等。

在我之前做过的电商小程序里，在下订单时就预扣减库存了，就需要在支付失败后做库存归还、优惠券归还等操作。在高峰期或大促期间，数据库的负载是很高的，会导致服务器磁盘、CPU、IO的负载都很高，进而导致数据库SQL执行性能下降。所以高峰期，一个TPS可能要耗时几秒，然后在界面上有个圈一直在刷新进度，直到几秒后才提示支付成功或失败。这种体验相当不好。所以这是亟需解决的第二个问题。

总结：着眼于长远打算，现在系统QPS没有那么高，如果一旦QPS上来，那么会导致硬件方面性能下降，进而影响数据库SQL性能等，最后导致系统挂了。