3.1 业务场景：亿级订单数据如何实现快速读写

这次项目的对象是电商系统。该系统中大数据量的实体有两个：用户和订单。每个实体涵盖的数据量见表3-1。

表3-1 数据量

某天，领导召集IT部门人员开会，说：“根据市场推广的趋势，我们的订单很快就会上亿，每天会有100万的新订单。不要问我这个数据怎么出来的，总之，领导交代，让IT部门提前做好技术准备，以防到时候系统撑不住”。

那时候同事们内心是这样想的：“又听市场吹牛吧”。领导看了同事们的表情，也知道大家在想什么，他说：“我知道你们不相信，我也不相信。但是现在领导给大家任务了，要求系统可以支持上亿订单和每日百万新订单，服务器可以采购。”

做这个规划之前，存储订单的数据库表是一个单库单表。可以预见，在不久的将来数据库的I/O和CPU就可能支撑不住，因为订单系统原来就不是很快。

然后项目组做了简单的功能，插入一些测试数据，订单量到2000万的时候，响应时长就不可接受了。

为了使系统能承受这种日百万级新订单的压力，项目组探讨过很多解决方案，最终决定使用分表分库：先将订单表拆分，再进行分布存储。

原来的订单表就是一个sale数据库里面的一张order表，之后就会创建多个order数据库order1，order2，order3，order4，……，每个数据库里面又有多张订单表t_order_1，t_order_2，t_order_3，……。

当然，订单子表也是多张：t_order_item_1，t_order_item_2，t_order_item_3，……。

订单数据根据一定的规律分布存储在不同order库里的不同order表中。

其实项目组并不是一开始就打算用分表分库，当初也评估了一下拆分存储的其他技术方案。接下来介绍当时是怎么选型的。