一、容量评估

系统是否需要分库分表？分多少个库多少个表不是拍脑袋决定的，决定分库分表方案前，要评估系统未来的数据量，通过容量、资源评估以后决定的，以笔者参与的一个供应链项目为例：

连锁店平均门店在5左右的大约有1W家
连锁店平均门店在20的大约有2W
预计每个门店每天产生一笔订单
平均每个订单预10条明细
预计每行数据0.5k
每台数据库容量300G
预计要满足三年内的数据容量需求上面的这些数据需要产品通过市场调研，或者根据现有的数据去预计使用系统的门店数和订单量。

有了上面的数据，我们才可以去做容量的评估。

通过上面的数据，可以计算得出：

一月的订单数量：（（1w * 5） + （2w * 2））* 30 = 1350w

一年的订单数量：1350w * 12 = 16200w

三年的明细数量：16200w * 10 * 3 = 486000w

三年以后的数据容量： (486000w * 0.5) / 1000 /1000 = 2430G （此处按1000k = 1m计算，计算一个大概值，当然除了容量的估计，还要考虑网络，cpu，内存等资源）

需要数据库数量：2430G / 300G = 8.1

需要表的数量：486000w / 1000w = 486

最终分库分表方案：8个库，每个库 64 张表

二、在分库分表设计过程中需要考虑的问题

单库写入写入QPS建议在1500以下，不超过2000
单个表的记录条数不超过 1000w（业界推荐，这个也和btree+ 索引数的高度计算有关，此处就不扩张了）
当个库数据库的容量

三、分片键的选择

笔者参与的供应链项目是一个TO-B的系统，每条数据都归属于一个总部（hq_id，单店认为是一个总部），因此采用hq_id作为分片键进行分片，在对数据库操作的过程中，都要带上 hq_id，分库分表中间件通过hq_id重写SQL。

四、分库分表带来的问题

分库分表以后，数据被分散到不同的表中，因此难以利用Mysql的Join特性。但是在互联网公司中，一般是在业务代码中实现数据的Join。
存在分布式事务问题，将数据划分到多个表或者数据库实例以后，可能会出现跨库操作，这就引入了事务问题，因此在进行设计时，尽量按照分库分表规则，将数据划分到同一个实例中。在笔者参与的供应链项目中，按hq_id进行分片，将同一个连锁店的数据划分到了同一个表中，避免了分布式事务。如果的确有特殊的情况，可以通过消息异步刷数据，或者监听binlog进行异步的处理。（通过binlog监听进行异步处理的时候，要注意主从延迟问题）
某些系统可能存在数据统计或者排序的功能，分库分表的中间会将数据捞取到内存中，在内存中排序和统计，但是这种方式不推荐。可以将数据导入到ES或者Hive中去完成数据统计和计算工作
存在多数据源管理，假如存在10个数据库实例，和10个应用层，每个应用层连接每个数据库实例的连接池最小16，最大64，那么每个应用层需要管理的数据库连接最小是： 10 * 16 ，最大是 10 * 64，每个数据库的连接个数最小是：10 * 16，最大是：10 * 64，那么多数据源管理是一个很大的问题。
分库分表以后，采用数据库的自增主键不能保证全局唯一，需要单独设计全局唯一主键，可以参考美团leaf方案（https://tech.meituan.com/2017/04/21/mt-leaf.html）
分库分表扩容问题，在分库分表以后，如果涉及的分片已经达到承受的最大数据量，就需要对集群进行扩容，而且一般是成倍的扩容，通用的扩容方法包括的步骤：

按新旧规则，对新旧数据库进行双写
将双写前的历史数据按照新的分片规则迁移到新的数据库
将旧的分片规则查询改为按新的分片规则查询
将双写逻辑下线，按照新的分片规则写入数据
删除历史数据

在第二步迁移历史数据的时候，由于数据量较大，可能会导致数据的不一致，因此需要做好数据的校验和清洗问题。数据的校验一般包含全量对比和抽样对比。

五、分库分表维度问题

场景一：在电商网站，需要将交易记录保存下来，如果按照买家维度分库分表，那么一个买家的交易记录都被保存到一张表里面，并且买家查询购买记录很方便，但是一个商家要查询自己的销售记录时就比较麻烦，因为一个商家的销售记录被分布在多张表中，需要做数据的聚合，分页。常见的解决方案：

方案一: 在多个分片中查询后合并数据集，这种查询方式效率是最底下的，不推荐使用该方案。

方案二: 记录两份数据，一份数据按照买家维度，一份数据按照商家维度，可以通过消息后者binlog监听异步写入数据

方案三: 将交易数据导入到ES中，通过ES搜索数据，通过ES搜索可能存在短暂的数据延迟。

六、扩展

除了分库分表方案外，我们一般还会采用读写分离架构，将写流量请求到主库，读流量请求到从库。在笔者参与的供应链系统中，会监听从库的binlog变更，然后通过回调通知到处理数据变更的服务。这个时候需要注意由于主从延迟，导致的数据不一致问题。主要流程如下图：

数据写入到主库
数据同步到slave1
binlog监听组件发现数据变更，将数据变更信息通知给数据变更处理服务
回查数据库，读请求请求到了slave2，读取了脏数据
将脏数据写入到缓存或者ES集群中，导致数据不一致问题

解决方案有两种：方案一：通知binlog变更以后，sleep 1秒，然后处理消息方案二：第四步查询数据的操作走主库