行业案例：某电商平台亿级订单DB分库分表架构.pdf

某电商平台分库分表的背景

下面的例子和数据，来自O2O电商平台，每日优鲜。

一家电商公司，随着业务增长每天的订单量很快从30万单增长到了100万单，订单总量也突破了一亿。

当时用的Mysql数据库。根据监控，我们的每秒最高订单量已经达到了2000笔（不包括秒杀，秒杀TPS

已经上万了。

重构？说这么高大上，不就是分库分表吗？的确，就是分库分表。

不过除了分库分表，还包括管理端的解决方案，比如运营，客服和商务需要从多维度查询订单数据

分库分表后，怎么满足大家的需求？

分库分表后，上线方案和数据不停机迁移方案都需要慎重考虑。为了保证系统稳定，还需要考虑相应的

降级方案。

技术选型

稳妥起见，该电商平台选用了第二种方案，使用更轻量级的Sharding-Jdbc。

分库分表架构规划：

目标：我们希望经过本次重构，系统能支撑两年，两年内不再大改。

业务方预期：两年内日单量达到1000万。相当于两年后日订单量要翻10倍。

悲观的预估

根据上面的数据，我们分成了16个数据库,每个库分了16张表，按user_id做hash。

即便按照每天1000万的订单量规划，两年总单量是73亿,每个库的数据量平均是4.56亿（4.56亿=73

亿/16）,，每张表的数据量平均是2850万（2850万=4.56亿/16）,虽然有点超出了1000W的建议值，但

是这是按照两年之后理想的值做的预估。实际没有那么多。

乐观的预估

即便按照每天100万的订单量规划，两年总单量是7.3亿,每个库的数据量平均是0.456亿（0.456亿=7.3

亿/16），每张表的数据量平均是285万（285万=0.456亿/16）。

分库分表主要是为了APP用户端下单和查询使用，按user_id的查询频率最高，其次是order_id。所以

我们选择user_id做为shardingcolumn，按user_id做hash，将相同用户的订单数据存储到同一个数

据库的同一张表中。这样用户在网页或者App上查询订单时只需要路由到一张表就可以获取用户的所有

订单了，这样就保证了查询性能。

对于提升查询性能？

有读者可能会问，查询直接查数据库，会不会有性能问题？是的。

方案主要有：

1异构索引

2读写分离

异构索引

查询的时候，走异构索引。

在上层加了Redis，Redis做了分片集群，用于存储活跃用户最近50条订单。

这样一来，只有少部分在Redis查不到订单的用户请求才会到数据库查询订单，这样就减小了数据库查

询压力，

读写分离

而且每个分库还有两个从库，查询操作只走从库，进一步分摊了每个分库的压力。

管理端技术方案

分库分表后，不同用户的订单数据散落在不同的库和表中，如果需要根据用户ID之外的其他条件查询订

单。

例如，运营同学想从后台查出某天iphone7的订单量，就需要从所有数据库的表中查出数据然后在聚合

到一起。

这就回到一个问题，很多小伙伴问：分库分表后，怎么关联？