在前面的文章中探讨了架构优化的两种方案：冷热分离、查询分离。
- 冷热分离
- 查询分离
查询分离其实就是利用了非关系数据库的高性能，但是不足之处也很明显：当主数据量越来越多，写操作缓慢；这种问题如何破局？可见任何一种优化方案都不是最终的银弹，只有不断的优化演变
这篇文章就来介绍一下解决方案：分库分表，将围绕以下几点介绍：
- 拆分后的存储选型？
- 分库分表的实现思路？
- 分库分表的不足？
拆分后的存储选型？
在介绍选型之前先来介绍下架构背景，笔者曾经做过电商系统的优化，该系统中包含的两个主体：
- 用户：数据量上千万，每日增长10W+
- 订单：数据量上亿，每日百万级的增长
对于如此量级的数据，单库单表的情况下，无论是IO还是CPU都扛不住，架构上的优化是必然。
经过了多次探讨尝试，最终选择了分库分表。
说到分库分表首先想到的就是存储选型，关于持久层的选型主流的无非有如下几种：
- 关系型数据库：MySQL、Oracle.........
- NoSQL：MongoDB、ES......
- NewSQL：TiDB........
1. 关系型数据库
关系型数据库目前市面上主流无非三种：MySQL、Oracle、SqlServer，笔者更倾向于MySQL，也是很多新型企业在用的一种数据库，因此本篇文章也将重点围绕MySQL展开
在任何系统中关系型数据库的地位都是不可或缺的，它的强约束性、事务的控制、SQL语法、锁....这些功能可谓是久经考验，因此在功能上 MySQL 能满足我们所有的业务需求。
2. NoSQL
说到NoSQL，第一个想到就是MongoDB ，它的分片功能从并发性和数据量这两个角度已经能满足一般大数据量的需求，但是仍然需要考虑如下几点：
- 约束性：MongoDB 不是关系型数据库而是文档型数据库，它的每一行记录都是一个结构灵活可变的 JSON，比如存储非常重要的订单数据时，我们就不能使用 MongoDB，因为订单数据必须使用强约束的关系型数据库进行存储。
- 业务功能考量：事务的控制、SQL语法、锁以及各种千奇百怪的SQL在已有的架构上都曾久经考验，但是MongoDB在这些功能需要上并不能满足
- 业务改造考量：未拆分前使用关系型数据库，使用NoSQL之后对于SQL的改造比较麻烦，项目周期更长
3. NewSQL
NewSQL目前比较主流则是TiDB，该技术比较新，虽然能够满足大数据量的存储，但是在选择上还是需要做些考量：
熟悉程度考量：如果你所在公司架构组对于NewSQL比较数据或者已经有在使用，则可以选择
稳定性考量：关系型数据毕竟是久经考验，在稳定性方面肯定是比较好，但是NewSQL的稳定性却无法去考量，建议初期阶段可以将一些不太重要的数据使用NewSQL存储
基于MySQL的分库分表
什么是分表分库？分表是将一份大的表数据拆分存放至多个结构一样的拆分表；分库就是将一个大的数据库拆分成多个结构一样的小库。
前面介绍的三种拆分存储技术，在我以往的项目中我都没使用过，而是选择了基于 MySQL 的分表分库，主要是有一个重要考量：分表分库对于第三方依赖较少，业务逻辑灵活可控，它本身并不需要非常复杂的底层处理，也不需要重新做数据库，只是根据不同逻辑使用不同 SQL 语句和数据源而已。
目前市面上主流的分库分表分为两种模式：Proxy模式、Client模式
Proxy模式属于业务无侵入型，直接代理数据库，对于开发者一切都是无感知的，SQL 组合、数据库路由、执行结果合并等功能全部存放在一个代理服务中，比如MyCat、ShardingSphere都对Proxy模式提供了支持
Client模式属于业务侵入型，将分库分表的逻辑放在客户端，客户端需要引入一个jar，比如Sharding-JDBC，架构图如下：
市面上对于分库分表中间件如下：
两种模式的优缺点也很明显：
- Proxy模式：资源解耦，业务无侵入；缺点则是运维成本相对较高
- Client模式：代码灵活控制，运维成本低；缺点则是语言限制，升级不方便
分库分表的实现思路
在落实分表分库解决方案时，我们需要考虑 5 个要点。
1. 分片键如何选择？
针对订单这个业务，其中涉及到以下几个主要的字段：
- user_id：用户id
- order_id：订单id
- order_time：下单时间
- store_id：店铺id
经过考量，最终选择了user_id作为ShardingKey，为什么呢？
选择user_id作为ShardingKey需要结合业务场景，订单系统中常见的业务：
- C端用户需要查询所有的订单（user_id）
- 后台需要根据城市查询所有订单（user_city_id）
- B端商家需要统计自己店铺的下单量（store_id）
以上三种业务场景，判断下优先级，C端用户肯定是需要优先满足，因此使用user_id作为ShardingKey
这样在查询时需要将user_id传递过来才能定位到指定库、表
选择字段作为分片键时，我们一般需要考虑三点要求：数据尽量均匀分布在不同表或库、跨库查询操作尽可能少、这个字段的值不会变（这点尤为重要）。
2. 分片的策略是什么？
选择user_id作为ShardingKey之后，需要考虑使用分片策略了，主要分为如下三种
- 范围分片
假如user_id是自增的数字，则可以根据user_id范围进行分片，每100万份分为一个库，每10万份分为一个表，此时单个库中将分为10张表，如下表：
- Hash取模
这种方案是根据Hash值进行分片，比如Hash函数为：hash(user_id%8)，这里是将user_id对8这个特定值取模，最终分为了8张表；这里一般为了方便后续扩容，建议选择2的N次方
- 范围分片和Hash取模混合
比如先按照范围对user_id拆分，每100万份分为一个库，在对这100万份数据进行Hash取模（hash(user_id%8)）拆分成8个表
当然以上三种方案的优缺点也是非常明显，这里不再赘述了
需要注意的是：在拆分之前，为了避免频繁的扩容，一定要对未来5年或者10年数据增长做个判断，预留更多的分片
3. 业务代码如何修改
业务代码的修改这里就不好说了，和自身的业务是强关联。
但是，在这里我想分享一些个人观点。近年来，分表分库操作愈发容易，不过我们需要注意几个要点。
我们已经习惯微服务了，对于特定表的分表分库，其影响面只在该表所在的服务中，如果是一个单体架构的应用做分表分库，那真是伤脑筋。
在互联网架构中，我们基本不使用外键约束。
随着查询分离的流行，后台系统中有很多操作需要跨库查询，导致系统性能非常差，这时分表分库一般会结合查询分离一起操作：先将所有数据在 ES 索引一份，再使用 ES 在后台直接查询数据。如果订单详情数据量很大，还有一个常见做法，即先在 ES 中存储索引字段（作为查询条件的字段），再将详情数据存放在 HBase 中（这个方案我们就不展开了）。
4. 历史数据迁移？
历史数据的迁移非常耗时，有时迁移几天几夜都很正常。而在互联网行业中，别说几天几夜了，就连停机几分钟业务都无法接受，这就要求我们给出一个无缝迁移的解决方案。
还记得讲解查询分离时，我们说过的方案吗？我们再来回顾下，如下图所示：
历史数据迁移时，我们就是采用类似的方案进行历史数据迁移，如下图所示：
此数据迁移方案的基本思路：存量数据直接迁移，增量数据监听 binlog，然后通过 canal 通知迁移程序搬运数据，新的数据库拥有全量数据，且校验通过后逐步切换流量。
数据迁移解决方案详细的步骤如下：
- 上线 canal，通过 canal 触发增量数据的迁移；
- 迁移数据脚本测试通过后，将老数据迁移到新的分表分库中；
- 注意迁移增量数据与迁移老数据的时间差，确保全部数据都被迁移过去，无遗漏；
- 第二步、第三步都运行完后，新的分表分库中已经拥有全量数据了，这时我们可以运行数据验证的程序，确保所有数据都存放在新数据库中；
- 到这步数据迁移就算完成了，之后就是新版本代码上线了，至于是灰度上还是直接上，需要根据你们的实际情况决定，回滚方案也是一样。
5. 未来的扩容方案是什么？
随着业务的发展，如果原来的分片设计已经无法满足日益增长的数据需求，我们就需要考虑扩容了，扩容方案主要依赖以下两点。
- 分片策略是否可以让新表数据的迁移源只是 1 个旧表，而不是多个旧表，这就是前面我们建议使用 2 的 N 次方分表的原因；
- 数据迁移：我们需要把旧分片的数据迁移到新的分片上，这个方案与上面提及的历史数据迁移一样，我们就不重复啰唆了。
分表分库的不足
分表分库的解决方案讲完了，以上就是业界常用的一些做法，不过此方案仍然存在不足之处。
- 增量数据迁移：如何保证数据的一致性及高可用性
- 短时订单量大爆发：分表分库仍然扛不住时解决方案是什么？
