海量数据写入——万级并发的订单系统如何分库？ _分库

一定要分表分库吗？当然不一定。
虽然很多互联网公司的体量很大、用户非常多，但你千万不要被这些现象迷惑了。实际上，90% 以上的系统能够发展到上百万、上千万数据量已经很不错了。对于千万的数据量，开源的 MySQL 都可以很好地应对，更别说一些商业数据库了。
另外，当数据增长到一定量级后，可以在业务层面做一些处理。比如根据业务特点，对无效数据、软删除数据，以及业务上不会再查询的数据进行统一归档，这也是一个成本低、效果明显的方式了。
一定要分库吗？说到分库，他当然能够解决存储的问题，假设原先单库只能最多存储2千万的数据量。采用分库之后，存储架构变成下图所示的分库架构，每个分库都可以存储2千万数据量，容量的上限一下提升了。

文章插图

虽然容量提升了，但也带来了很多其他问题。

分库数据间的数据无法再通过数据库直接查询了，比如跨多个分库的数据需要多次查询或借助其他存储进行聚合再查询。
分库越多，出现问题的可能性越大，维护成本也变得更高。
无法保障跨库间事务，只能借助其他中间件实现最终一致性。

所以在解决容量问题上，可以根据业务场景选择，不要一上来就要考虑分库，分表也是一种选择。
分表是指所有的数据均存在同一个数据库实例中，只是将原先的一张大表按一定规则，划分成多张行数较少的表。
它与分库的区别是，分表后的子表仍在原有库中，而分库则是子表移动到新的数据库实例里并在物理上单独部署。分表的拆分架构如下图所示：

文章插图

不管是打车的订单、电商里的支付订单，还是外卖或团购的支付订单，都是后台服务中最重要的一环，关乎公司的营收。因此我将以订单业务作为案例进行分析。
假设订单只是单量多而每一单的数据量较小，这就适合采用分表。单条数据量小但行数多，会导致写入（因为要构建索引）和查询非常慢，但整体对于容量的占用是可控的。
采用分表后，大表变成小表，写入时构建索引的性能消耗会变小，其次小表的查询性能也更好。如果采用了分库，虽然解决了写入和查询的问题，但每张表所占有的磁盘空间很少，也会产生资源浪费。两种方案的对比如下图所示：

文章插图

在实际场景里，因为要详细记录用户的提单信息，单个订单记录的数据量均较多，所以不存在行数多但单条数据量小的情况。但在其他写入服务里，经常会出现上述场景，你可以优先采用分表的方案。因为分表除了能解决容量问题，还能在一定程度上解决分库所带来的三个问题。
分表后可以通过 join 等完成一些富查询，相比分库简单得多。
分表的数据仍存储在一个数据库里，不会出现很多分库。无须引入一些分库中间件，因此维护成本和开发成本均较低。
因为在同一个数据库里，也可以很好地解决事务问题。
如何选择分库维度？如果你确定要对数据库进行分库，究竟要如何实现呢？
【海量数据写入——万级并发的订单系统如何分库？】首先要解决的问题便是如何选择分库维度。
不同的分库维度决定了部分查询是否能直接使用数据库，以及是否存在数据倾斜的问题。
介绍两种常见的不同维度的分库方式：

按直接满足最重要的业务场景划分
按最细粒度随机分

按直接满足最重要的业务场景划分在业务上，所有的订单数据都是隶属于某一个用户的。可以按订单归属的用户这个字段进行分库，则同一个用户的订单都在某一个分库里。
分库后的场景如下图所示：

文章插图

订单模块除了提供提交订单接口外，还会提供给售卖商家对自己店铺的订单进行查询及修改等功能。这些维度的查询和修改需求，在采用了按购买用户进行分库之后，均无法直接满足了。
这里请你思考一个问题，订单模块最重要的功能是什么？
答案是保证客户（即买家）的各项订单功能能够正常使用，比如下单、下单后立刻（无延迟）查看已购的订单信息、待支付、待发货、待配送的订单列表等。