微信搜寻【阿丸笔记】，关注 Java/MySQL/ 中间件各系列原创实战笔记，干货满满。
分库分表的文章网上十分多，然而大多内容比拟零散，以解说知识点为主，没有残缺地阐明一个大表的切分、新架构设计、上线的残缺过程。
因而，我联合去年做的一个大型分库分表我的项目，来复盘一下残缺的分库分表从架构设计 到 公布上线的实战总结。
1. 前言
为什么须要做分库分表。这个置信大家多少都有所理解。
海量数据的存储和拜访成为了 MySQL 数据库的瓶颈问题，日益增长的业务数据，无疑对 MySQL 数据库造成了相当大的负载，同时对于零碎的稳定性和扩展性提出很高的要求。
而且单台服务器的资源（CPU、磁盘、内存等）总是无限的，最终数据库所能承载的数据量、数据处理能力都将遭逢瓶颈。
目前来说个别有两种计划。
一种是更换存储，不应用 MySQL，比方能够应用 HBase、polarDB、TiDB 等分布式存储。
如果出于各种起因思考，还是想持续应用 MySQL，个别会采纳第二种形式，那就是分库分表。
文章结尾就说了，网上分库分表文章很多，对知识点解说比拟多，因而，本文将不再过多赘述分库分表计划的范式解决。
而是专一于梳理分库分表从架构设计 到 公布上线的残缺过程，同时总结其中的注意事项和最佳实际。包含：
- 业务重构
- 技术架构设计
- 革新和上线
- 稳定性保障
- 项目管理
尤其是各个阶段的最佳实际，都是血与泪凝聚的经验教训。
2. 第一阶段：业务重构（可选）
对于微服务划分比拟正当的分库分表行为，个别只须要关注存储架构的变动，或者只须要在个别利用上进行业务革新即可，个别不须要着重思考“业务重构”这一阶段，因而，这一阶段属于“可选”。
本次我的项目的第一大难点，在于业务重构。
而本次拆分我的项目波及到的两张大表 A 和 B，单表将近八千万的数据，是从单体利用时代遗留下来的，从一开始就没有很好的畛域驱动 /MSA 架构设计，逻辑发散十分重大，到当初曾经波及 50+ 个在线服务和 20+ 个离线业务的的间接读写。
因而，如何保障业务革新的彻底性、全面性是重中之重，不能呈现有脱漏的状况。
另外，表 A 和 表 B 各自有二、三十个字段，两表的主键存在一一对应关系，因而，本次分库分表我的项目中，还须要将两个表进行重构交融，将多余 / 无用的字段剔除。
2.1 查问统计
在线业务通过分布式链路追踪零碎进行查问，依照表名作为查问条件，而后依照服务维度进行聚合，找到所有相干服务，写一个文档记录相干团队和服务。
这里特地留神下，很多表不是只有在线利用在应用，很多离线算法和数据分析的业务也在应用，这里须要一并的梳理好，做好线下跨团队的沟通和调研工作，免得切换后影响失常的数据分析。
2.2 查问拆分与迁徙
创立一个 jar 包，依据 2.1 的统计后果，与服务 owner 单干将服务中的相干查问都迁徙到这个 jar 包中（本我的项目的 jar 包叫 projected），此处为 1.0.0-SNAPSHOT 版本。
而后将本来服务内的 xxxMapper.xxxMethod() 全副改成 projectdb.xxxMethod()进行调用。
这样做有两个益处：
- 不便做后续的查问拆分剖析。
- 不便后续间接将 jar 包中的查问替换为革新后 中台服务 的 rpc 调用，业务方只需降级 jar 包版本，即可疾速从 sql 调用改为 rpc 查问。
这一步花了几个月的理论，务必梳理各个服务做全面的迁徙，不能脱漏，否则可能会导致拆分剖析不全面，脱漏了相干字段。
查问的迁徙次要因为本次拆分我的项目波及到的服务太多，须要收拢到一个 jar 包，更不便前期的革新。如果理论分库分表我的项目中仅仅波及一两个服务的，这一步是能够不做的。
2.3 联结查问的拆分剖析
依据 2.2 收拢的 jar 包中的查问，结合实际状况将查问进行分类和判断，把一些历史遗留的问题，和曾经废除的字段做一些整顿。
以下举一些思考点。
1）哪些查问是无奈拆分的？例如分页（尽可能地革新，切实改不了只能以冗余列的模式）
2）哪些查问是能够业务上 join 拆分的？
3）哪些表 / 字段是能够交融的？
4）哪些字段须要冗余？
5）哪些字段能够间接废除了？
6）依据业务具体场景和 sql 整体统计，辨认要害的分表键。其余查问走搜寻平台。
思考后失去一个查问革新总体思路和计划。
同时在本我的项目中须要将两张表交融为一张表，废除冗余字段和有效字段。
2.4 新表设计
这一步基于 2.3 对于查问的拆分剖析，得出旧表交融、冗余、废除字段的后果，设计新表的字段。
产出新表设计构造后，必须发给各个相干业务方进行 review，并保障所有业务方都通过该表的设计。有必要的话能够进行一次线下 review。
如果新表的过程中，对局部字段进行了废除，必须告诉 所有业务方进行确认。
对于新表的设计，除了字段的梳理，也须要依据具体查问，从新设计、优化索引。
2.5 第一次降级
新表设计实现后，先做一次 jar 包内 sql 查问的革新，将旧的字段全副更新为新表的字段。
此处为 2.0.0-SNAPSHOT 版本。
而后让所有服务降级 jar 包版本，以此来保障这些废除字段的确是不应用了，新的表构造字段可能齐全笼罩过来的业务场景。
特地留神的是，因为波及服务泛滥，能够将服务依照 非核心 与 外围 辨别，而后分批次上线，避免出现问题导致重大故障或者大范畴回滚。
2.5 最佳实际
2.6.1 尽量不扭转原表的字段名称
在做新表交融的时候，一开始只是简略归并表 A 和 表 B 的表，因而很多字段名雷同的字段做了重命名。
起初字段精简过程中，删除了很多反复字段，然而没有将重命名的字段改回来。
导致前期上线的过程中，不可避免地须要业务方进行重构字段名。
因而，新表设计的时候，除非必不得已，不要批改原表的字段名称！
2.6.2 新表的索引须要认真斟酌
新表的索引不能简略照搬旧表，而是须要依据查问拆分剖析后，从新设计。
尤其是一些字段的交融后，可能能够归并一些索引，或者设计一些更高性能的索引。
2.6 本章小结
至此，分库分表的第一阶段告一段落。这一阶段所需工夫，齐全取决于具体业务，如果是一个历史包袱惨重的业务，那可能须要破费几个月甚至半年的工夫能力实现。
这一阶段的实现品质十分重要，否则可能导致我的项目前期须要重建表构造、从新全量数据。
这里再次阐明，对于微服务划分比拟正当的服务，分库分表行为个别只须要关注存储架构的变动，或者只须要在个别利用上进行业务革新即可，个别不须要着重思考“业务重构”这一阶段。
3. 第二阶段：存储架构设计（外围）
对于任何分库分表的我的项目，存储架构的设计都是最外围的局部！
3.1 整体架构
依据第一阶段整顿的查问梳理后果，咱们总结了这样的查问法则。
- 80% 以上的查问都是通过或者带有字段 pk1、字段 pk2、字段 pk3 这三个维度进行查问的，其中 pk1 和 pk2 因为历史起因存在一一对应的关系
- 20% 的查问千奇百怪，包含含糊查问、其余字段查问等等
因而，咱们设计了如下的整体架构，引入了数据库中间件、数据同步工具、搜索引擎（阿里云 opensearch/ES）等。
下文的阐述都是围绕这个架构来开展的。
3.1.1 mysql 分表存储
Mysql 分表的维度是依据查问拆分剖析的后果确定的。
咱们发现 pk1pk2pk3 能够笼罩 80% 以上的次要查问。让这些查问依据分表键间接走 mysql 数据库即可。
原则上个别最多保护一个分表的全量数据，因为过多的全量数据会造成存储的节约、数据同步的额定开销、更多的不稳定性、不易扩大等问题。
然而因为本我的项目 pk1 和 pk3 的查问语句都对实时性有比拟高的要求，因而，保护了 pk1 和 pk3 作为分表键的两份全量数据。
而 pk2 和 pk1 因为历史起因，存在一一对应关系，能够仅保留一份映射表即可，只存储 pk1 和 pk2 两个字段。
3.1.2 搜寻平台索引存储
搜寻平台索引，能够笼罩残余 20% 的零散查问。
这些查问往往不是依据分表键进行的，或者是带有含糊查问的要求。
对于搜寻平台来说，个别不存储全量数据（尤其是一些大 varchar 字段），只存储主键和查问须要的索引字段，搜寻失去后果后，依据主键去 mysql 存储中拿到须要的记录。
当然，从前期实际后果来看，这里还是须要做一些衡量的：
1）有些非索引字段，如果不是很大，也能够冗余进来，相似笼罩索引，防止多一次 sql 查问；
2）如果表构造比较简单，字段不大，甚至能够思考全量存储，进步查问性能，升高 mysql 数据库的压力。
这里特地提醒，搜索引擎和数据库之间同步是必然存在提早的。所以对于依据分表 id 查问的语句，尽量保障间接查询数据库，这样不会带来一致性问题的隐患。
3.1.3 数据同步
个别新表和旧表间接能够采纳 数据同步 或者 双写的形式进行解决，两种形式有各自的优缺点。
个别依据具体情况抉择一种形式就行。
本次我的项目的具体同步关系见整体存储架构，包含了四个局部：
1）旧表到新表全量主表的同步
一开始为了缩小代码入侵、不便扩大，采纳了数据同步的形式。而且因为业务过多，放心有未统计到的服务没有及时革新，所以数据同步能防止这些状况导致数据失落。
然而在上线过程中发现，当提早存在时，很多新写入的记录无奈读到，对具体业务场景造成了比较严重的影响。（具体起因参考 4.5.1 的阐明）
因而，为了满足利用对于实时性的要求，咱们在数据同步的根底上，从新在 3.0.0-SNAPSHOT 版本中革新成了双写的模式。
2）新表全量主表到全量副表的同步
3）新表全量主表到映射表到同步
4）新表全量主表到搜索引擎数据源的同步
2）、3）、4）都是从新表全量主表到其余数据源的数据同步，因为没有强实时性的要求，因而，为了不便扩大，全副采纳了数据同步的形式，没有进行更多的多写操作。
3.2 容量评估
在申请 mysql 存储和搜寻平台索引资源前，须要进行容量评估，包含存储容量和性能指标。
具体线上流量评估能够通过监控零碎查看 qps，存储容量能够简略认为是线上各个表存储容量的和。
然而在全量同步过程中，咱们发现须要的理论容量的需要会大于预估，具体能够看 3.4.6 的阐明。
具体性能压测过程就不再赘述。
3.3 数据校验
从上文能够看到，在本次我的项目中，存在大量的业务革新，属于异构迁徙。
从过来的一些分库分表我的项目来说，大多是同构 / 对等拆分，因而不会存在很多简单逻辑，所以对于数据迁徙的校验往往比拟漠视。
在齐全对等迁徙的状况下，个别的确比拟少呈现问题。
然而，相似这样有比拟多革新的异构迁徙，校验相对是重中之重！！
因而，必须对数据同步的后果做校验，保障 业务逻辑革新正确 、 数据同步一致性正确。这一点十分十分重要。
在本次我的项目中，存在大量业务逻辑优化以及字段变动，所以咱们独自做了一个校验服务，对数据的全量、增量进行校验。
过程中提前发现了许多数据同步、业务逻辑的不统一问题，给咱们本次我的项目安稳上线提供了最重要的前提保障！！
3.4 最佳实际
3.4.1 分库分表引起的流量放大问题
在做容量评估的时候，须要关注一个重要问题。就是分表带来的查问流量放大。
这个流量放大有两方面的起因：
- 索引表的二次查问。比方依据 pk2 查问的，须要先通过 pk2 查问 pk1，而后依据 pk1 查问返回后果。
- in 的分批查问。如果一个 select…in… 的查问，数据库中间件会依据分表键，将查问拆分落到对应的物理分表上，相当于本来的一次查问，放大为屡次查问。（当然，数据库会将落在同一个分表的 id 作为一次批量查问，而这是不稳固的合并）
因而，咱们须要留神：
- 业务层面尽量限度 in 查问数量，防止流量过于放大；
- 容量评估时，须要思考这部分放大因素，做适当冗余，另外，后续会提到业务革新上线分批进行，保障能够及时扩容；
- 分 64、128 还是 256 张表有个正当预估，拆得越多，实践上会放大越多，因而不要无谓地分过多的表，依据业务规模做适当预计；
- 对于映射表的查问，因为存在显著的冷热数据，所以咱们又在两头加了一层缓存，缩小数据库的压力
3.4.2 分表键的变更计划
本我的项目中，存在一种业务状况会变更字段 pk3，然而 pk3 作为分表键，在数据库中间件中是不能批改的，因而，只能在中台中批改对 pk3 的更新逻辑，采纳先删除、后增加的形式。
这里须要留神，删除和增加操作的事务原子性。当然，简略解决也能够通过日志的形式，进行告警和校准。
3.4.3 数据同步一致性问题
咱们都晓得，数据同步中一个关键点就是（音讯）数据的程序性，如果不能保障承受的数据和产生的数据的程序严格统一，就有可能因为（音讯）数据乱序带来数据笼罩，最终带来不统一问题。
咱们自研的数据同步工具底层应用的音讯队列是 kakfa，，kafka 对于音讯的存储，只能做到部分有序性（具体来说是每一个 partition 的有序）。咱们能够把同一主键的音讯路由至同一分区，这样一致性个别能够保障。然而，如果存在一对多的关系，就无奈保障每一行变更有序，见如下例子。
那么须要通过反查数据源获取最新数据保障一致性。
然而，反查也不是“银弹“，须要思考两个问题。
1）如果音讯变更来源于读写实例，而反查 数据库是查只读实例，那就会存在读写实例提早导致的数据不统一问题。因而，须要保障 音讯变更起源 和 反查数据库 的实例是同一个。
2）反查对数据库会带来额定性能开销，须要认真评估全量时候的影响。
3.4.4 数据实时性问题
提早次要须要留神几方面的问题，并依据业务理论状况做评估和掂量。
1）数据同步平台的秒级提早
2）如果音讯订阅和反查数据库都是落在只读实例上，那么除了上述数据同步平台的秒级提早，还会有数据库主从同步的提早
3）宽表到搜寻平台的秒级提早
只有可能满足业务场景的计划，才是适合的计划。
3.4.5 分表后存储容量优化
因为数据同步过程中，对于单表而言，不是严格依照递增插入的，因而会产生很多”存储空洞“，使得同步完后的存储总量远大于预估的容量。
因而，在新库申请的时候，存储容量多申请 50%。
具体起因能够参考我的这篇文章 为什么 MySQL 分库分表后总存储大小变大了？
3.5 本章小结
至此，分库分表的第二阶段告一段落。
这一阶段踩了十分多的坑。
一方面是设计高可用、易扩大的存储架构。在我的项目停顿过程中，也做了屡次的批改与探讨，包含 mysql 数据冗余数量、搜寻平台的索引设计、流量放大、分表键批改等问题。
另一方面是“数据同步”自身是一个非常复杂的操作，正如本章最佳实际中提及的实时性、一致性、一对多等问题，须要引起高度重视。
因而，更加依赖于数据校验对最终业务逻辑正确、数据同步正确的测验！
在实现这一阶段后，能够正式进入业务切换的阶段。须要留神的是，数据校验依然会在下一阶段施展关键性作用。
4. 第三阶段：革新和上线（谨慎）
前两个阶段实现后，开始业务切换流程，次要步骤如下：
1）中台服务采纳单读 双写 的模式
2）旧表往新表开着数据同步
3）所有服务降级依赖的 projectDB 版本，上线 RPC，如果呈现问题，降版本即可回滚（上线胜利后，单读新库，双写新旧库）
4）查看监控确保没有 中台服务 以外的其余服务拜访旧库旧表
5）进行数据同步
6）删除旧表
4.1 查问革新
如何验证咱们前两个阶段设计是否正当？是否齐全笼罩查问的批改 是一个前提条件。
当新表设计结束后，就能够以新表为规范，批改老的查问。
以本我的项目为例，须要将旧的 sql 在 新的中台服务中 进行革新。
1）读查问的革新
可能查问会波及以下几个方面：
a）依据查问条件，须要将 pk1 和 pk2 的 inner join 改为对应分表键的新表表名
b）局部 sql 的废除字段解决
c）非分表键查问改为走搜寻平台的查问，留神保障语义统一
d）留神写单测防止低级谬误，次要是 DAO 层面。
只有新表构造和存储架构能齐全适应查问革新，能力认为后面的设计临时没有问题。
当然，这里还有个前提条件，就是相干查问曾经全副收拢，没有脱漏。
2) 写查问的革新
除了相干字段的更改以外，更重要的是，须要革新为旧表、新表的双写模式。
这里可能 波及到具体业务写入逻辑 ，本我的项目尤为简单，须要革新过程中 与业务方充沛沟通，保障写入逻辑正确。
能够在双写上各加一个配置开关，不便切换。如果双写中发现新库写入有问题，能够疾速敞开。
同时，双写过程中不敞开 旧库到新库 的数据同步。
为什么呢？次要还是因为咱们我的项目的特殊性。因为咱们波及到几十个服务，为了升高危险，必须分批上线。因而，存在比拟麻烦的两头态，一部分服务是老逻辑，一部分服务是新逻辑，必须保障两头态的数据正确性，具体见 4.5.1 的剖析。
4.2 服务化革新
为什么须要新建一个 服务来 承载革新后的查问呢？
一方面是为了革新可能不便的降级与回滚切换，另一方面是为了将查问收拢，作为一个中台化的服务来提供相应的查问能力。
将革新后的新的查问放在服务中，而后 jar 包中的本来查问，全副替换成这个服务的 client 调用。
同时，降级 jar 包版本到 3.0.0-SNAPSHOT。
4.3 服务分批上线
为了升高危险，须要安顿从非核心服务到外围服务的分批上线。
留神，分批上线过程中，因为写服务往往是外围服务，所以安顿在前面。可能呈现非核心的读服务上线了，这时候会有 读新表、写旧表 的中间状态。
1）所有相干服务应用 重构分支 降级 projectdb 版本到 3.0.0-SNAPSHOT 并部署内网环境；
2）业务服务依赖于 中台服务，须要订阅服务
3）开重构分支（不要与失常迭代分支合并），部署内网，内网预计测试两周以上
应用一个新的 重构分支 是为了在内网测试两周的时候，不影响业务失常迭代。每周更新的业务分支能够 merge 到重构分支上部署内网，而后外网应用业务分支 merge 到 master 上部署。
当然，如果从线上线下代码分支统一的角度，也能够重构分支和业务分支一起测试上线，对开发和测试的压力会较大。
4）分批上线过程中，如果碰到依赖抵触的问题，须要及时解决并及时更新到该文档中
5）服务上线前，必须要求业务开发或者测试，明确评估具体 api 和危险点，做好回归。
这里再次揭示，上线实现后，请不要漏掉离线的数据分析业务！请不要漏掉离线的数据分析业务！请不要漏掉离线的数据分析业务！
4.4 旧表下线流程
1）查看监控确保没有中台服务以外的其余服务拜访旧库旧表
2）查看数据库上的 sql 审计，确保没有其余服务依然读取旧表数据
3）进行数据同步
4）删除旧表
4.5 最佳实际
4.5.1 写完立刻读可能读不到
在分批上线过程中，遇到了写完立刻读可能读不到的状况。因为业务泛滥，咱们采纳了分批上线的形式升高危险，存在一部分利用曾经降级，一部分利用尚未降级的状况。未降级的服务依然往旧表写数据，而降级后的利用会从新表读数据，当提早存在时，很多新写入的记录无奈读到，对具体业务场景造成了比较严重的影响。
提早的起因次要有两个：
1）写服务还没有降级，还没有开始双写，还是写旧表，这时候会有 读新表、写旧表 的中间状态，新旧表存在同步提早。
2）为了防止主库压力，新表数据是从旧表获取变更、而后反查旧表只读实例的数据进行同步的，主从库自身存在肯定提早。
解决方案个别有两种：
1）数据同步改为双写逻辑。
2）在读接口做弥补，如果新表查不到，到旧表再查一次。
4.5.2 数据库中间件惟一 ID 替换自增主键（划重点，敲黑板）
因为分表后，持续应用单表的自增主键，会导致全局主键抵触。因而，须要应用分布式惟一 ID 来代替自增主键。各种算法网上比拟多，本我的项目采纳的是数据库自增 sequence 生成形式。
数据库自增 sequence 的分布式 ID 生成器，是一个依赖 Mysql 的存在，它的基本原理是在 Mysql 中存入一个数值，每有一台机器去获取 ID 的时候，都会在以后 ID 上累加肯定的数量比如说 2000，而后把以后的值加上 2000 返回给服务器。这样每一台机器都能够持续反复此操作取得惟一 id 区间。
然而仅仅有全局惟一 ID 就功败垂成了吗？显然不是，因为这里还会存在新旧表的 id 抵触问题。
因为服务比拟多，为了升高危险须要分批上线。因而，存在一部分服务还是单写旧表的逻辑，一部分服务是双写的逻辑。
这样的状态中，旧表的 id 策略应用的是 auto_increment。如果只有单向数据来往的话（旧表到新表），只须要给旧表的 id 预留一个区间段，sequence 从一个较大的起始值开始就能防止抵触。
但该我的项目中，还有新表数据和旧表数据的双写，如果采纳上述计划，较大的 id 写入到旧表，旧表的 auto_increment 将会被重置到该值，这样单鞋旧表的服务产生的递增 id 的记录必然会呈现抵触。
所以这里替换了单方的区间段，旧库从较大的 auto_increment 起始值开始，新表抉择的 id（也就是 sequence 的范畴）从大于旧表的最大记录的 id 开始递增，小于旧表 auto_increment 行将设置的起始值，很好的防止了 id 抵触问题。
1）切换前：
sequence 的起始 id 设置为以后旧表的自增 id 大小，而后旧表的自增 id 须要改大，预留一段区间，给旧表的自增 id 持续应用，避免未降级业务写入旧表的数据同步到新库后产生 id 抵触；
2）切换后
无需任何革新，断开数据同步即可
3）长处
只用一份代码；
切换能够应用开关进行，不必降级革新；
如果万一中途旧表的 autoincrement 被异样数据变大了，也不会造成什么问题。
4）毛病
如果旧表写失败了，新表写胜利了，须要日志辅助解决
4.6 本章小结
实现旧表下线后，整个分库分表的革新就实现了。
在这个过程中，须要始终保持对线上业务的敬畏，认真思考每个可能产生的问题，想好疾速回滚计划（在三个阶段提到了 projectdb 的 jar 包版本迭代，从 1.0.0-SNAPSHOT 到 3.0.0-SNAPSHOT，蕴含了每个阶段不同的变更，在不同阶段的分批上线的过程中，通过 jar 包版本的形式进行回滚，施展了巨大作用），防止造成重大故障。
5. 稳定性保障
这一章次要再次强调稳定性的保障伎俩。作为本次我的项目的重要指标之一，稳定性其实贯通在整个我的项目周期内，基本上在上文各个环节都曾经都有提到，每一个环节都要引起足够的器重，认真设计和评估计划，做到成竹在胸，而不是靠天吃饭：
1）新表设计必须跟业务方充沛沟通、保障 review。
2）对于“数据同步”，必须有数据校验保障数据正确性，可能导致数据不正确的起因上文曾经提到来很多，包含实时性、一致性的问题。保证数据正确是上线的大前提。
3）每一阶段的变动，都必须做好疾速回滚都预案。
4）上线过程，都以分批上线的模式，从非核心业务开始做试点，防止故障扩充。
5）监控告警要配置全面，呈现问题及时收到告警，疾速响应。不要疏忽，很重要，有几次呈现选过数据的小问题，都是通过告警及时发现和解决的
6）单测，业务功能测试等要充沛
6. 项目管理之跨团队合作
对于“跨团队合作”，本文专门拎进去作为一章。
因为在这样一个跨团队的大型项目革新过程中，迷信的团队合作是保障整体我的项目按时、高质量实现的不可短少的因素。
上面，分享几点心得与领会。
6.1 所有文档后行
团队合作最忌“空口无凭”。
无论是团队分工、进度安顿或是任何须要多人合作的事件，都须要有一个文档记录，用于追踪进度，把控流程。
6.2 业务沟通与确认
所有的表构造革新，必须跟相干业务方沟通，对于可能存在的历史逻辑，进行全面梳理；
所有探讨确定后的字段革新，必须由每个服务的 Owner 进行确认。
6.3 责任到位
对于多团队多人次的合作项目，每个团队都应该明确一个对接人，由我的项目总负责人与团队惟一对接人沟通，明确团队残缺进度和实现品质。
7. 瞻望
其实，从全文的篇幅就可能看出，本次的分库分表我的项目因为简单的业务逻辑革新，费大量的工夫和精力，并且非常容易在革新过程中，引起不稳固的线上问题。
本文复盘了整个分库分表从拆分、设计、上线的整体过程，心愿能对大家有所帮忙。
看到这里，咱们会想问一句。所以，有没有更好的形式呢？
兴许，将来还是须要去联合业界新的数据库中间件技术，可能疾速实现分库分表。
兴许，将来还能够引入新的数据存储技术与计划（polardb、tidb、hbase），基本不再须要分库分表呢？
持续跟进新技术的倒退，我置信会找到答案。
都看到最初了，原创不易，点个关注，点个赞吧～
文章继续更新，能够微信搜寻「阿丸笔记」第一工夫浏览，回复【笔记】获取 Canal、MySQL、HBase、JAVA 实战笔记，回复【材料】获取一线大厂面试材料。
常识碎片从新梳理，构建 Java 常识图谱：github.com/saigu/JavaK…（历史文章查阅十分不便）