阿里日订单超量后，要做什么系统才能撑住压力？

转自公众号“二马读书”

背景

---

几年前我曾经服务过的一家电商公司，随着业务增长我们每天的订单量很快从30万单增长到了100万单，订单总量也突破了一亿。当时用的Mysql数据库。根据监控，我们的每秒最高订单量已经达到了2000笔（不包括秒杀，秒杀TPS已经上万了。秒杀我们有一套专门的解决方案，详见。不过，直到此时，订单系统还是单库单表，幸好当时数据库服务器配置不错，我们的系统才能撑住这么大的压力。

业务量还在快速增长，再不重构系统早晚出大事，我们花了一天时间快速制定了重构方案。

重构？说这么高大上，不就是分库分表吗？的确，就是分库分表。不过除了分库分表，还包括管理端的解决方案，比如运营，客服和商务需要从多维度查询订单数据，分库分表后，怎么满足大家的需求？分库分表后，上线方案和数据不停机迁移方案都需要慎重考虑。为了保证系统稳定，还需要考虑相应的降级方案。

为什么要分库分表？

---

当数据库产生性能瓶颈：IO瓶颈或CPU瓶颈。两种瓶颈最终都会导致数据库的活跃链接数增加，进而达到数据库可承受的最大活跃连接数阈值。终会导致应用服务无连接可用，造成灾难性后果。可以先从代码，sql，索引几方面进行优化。如果这几方面已经没有太多优化的余地，就该考虑分库分表了。

1、IO瓶颈

• 磁盘读IO瓶颈。由于热点数据太多，数据库缓存完全放不下，查询时会产生大量的磁盘IO，查询速度会比较慢，这样会导致产生大量活跃连接，最终可能会发展成无连接可用的后果。可以采用一主多从，读写分离的方案，用多个从库分摊查询流量。或者采用分库+水平分表（把一张表的数据拆成多张表来存放，比如订单表可以按user_id来拆分）的方案。
• 第二种：磁盘写IO瓶颈。由于数据库写入频繁，会产生频繁的磁盘写入IO操作，频繁的磁盘IO操作导致产生大量活跃连接，最终同样会发展成无连接可用的后果。这时只能采用分库方案，用多个库来分摊写入压力。再加上水平分表的策略，分表后，单表存储的数据量会更小，插入数据时索引查找和更新的成本会更低，插入速度自然会更快。

2、CPU瓶颈

• SQL问题。如果SQL中包含join，group by，order by，非索引字段条件查询等增加CPU运算的操作，会对CPU产生明显的压力。 这时可以考虑SQL优化，创建适当的索引，也可以把一些计算量大的SQL逻辑放到应用中处理。
• 单表数据量太大。由于单张表数据量过大，比如超过一亿，查询时遍历树的层次太深或者扫描的行太多，SQL效率会很低，也会非常消耗CPU。这时可以根据业务场景水平分表。

分库分表方案

---

分库分表主要有两种方案：

1. 利用MyCat，KingShard这种代理中间件分库分表。好处是和业务代码耦合度很低，只需做一些配置即可，接入成本低。缺点是这种代理中间件需要单独部署，所以从调用连路上又多了一层。而且分库分表逻辑完全由代理中间件管理，对于程序员完全是黑盒，一旦代理本身出问题（比如出错或宕机），会导致无法查询和存储相关业务数据，引发灾难性的后果。如果不熟悉代理中间件源码，排查问题会非常困难。曾经有公司使用MyCat，线上发生故障后，被迫修改方案，三天三夜才恢复系统。CTO也废了！
2. 利用Sharding-Jdbc，TSharding等以Jar包形式呈现的轻量级组件分库分表。缺点是，会有一定的代码开发工作量，对业务有一些侵入性。好处是对程序员透明，程序员对分库分表逻辑的把控会更强，一旦发