本文介绍了在日订单量达到100万单后，如何进行订单中心的重构以应对数据库的IO和CPU瓶颈。文章详细讨论了分库分表的原因，提出了两种分库分表方案，最终选择了Sharding-Jdbc作为解决方案。此外，还阐述了如何通过Redis和ES解决管理端查询需求，以及如何实现不停机数据迁移，确保业务连续性。最后提到了降级方案和未来的分库分表优化策略。
作者简介：曾任职于阿里巴巴，每日优鲜等互联网公司，任技术总监。
最近很多读者朋友留言，希望“二马”多写一些实际工作经历以及工作中遇到的问题和技术解决方案。应大家要求，本文介绍一次订单中心重构的经历。
背景
几年前我曾经服务过的一家电商公司，随着业务增长我们每天的订单量很快从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。这时可以根据业务场景水平分表。
分库分表方案
分库分表主要有两种方案：
利用MyCat，KingShard这种代理中间件分库分表。好处是和业务代码耦合度很低，只需做一些配置即可，接入成本低。缺点是这种代理中间件需要单独部署，所以从调用连路上又多了一层。而且分库分表逻辑完全由代理中间件管理
最低0.47元/天 解锁文章
扫一扫
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
