2020年， 小编承担的一个高德打车弹外订单管理系统开展了一次扩分库分表和数据库迁移。 该订单管理系统总体布署在阿里云服务器上，服务项目应用阿里云服务器ECS布署，数据库查询选用阿里云服务器RDS，配置中心根据阿里云服务器ACM自 研，数 据同歩根据阿里云服务器DTS自研及其自研分库分表部件、分布式系统ID部件这些。
本次开展扩分库分表的情况是，原4案例4库、每一个库64张表一共256张表，一部分单表已超干万数量级，按当今每日订单数数量级，一年内单表会做到上亿条纪录，单表信息量过交流会产生数据库查询特性难题。
注 ： 【弹内弹外】弹就是指延展性测算，弹内与弹外实际上就是指两个单独的延展性测算网络空间。 弹内关键就是指布署在阿里巴巴生产制造网的延展性云计算平台，最开始是根据原来淘宝网技术性搭建的，关键用以支撑点淘宝网业务流程。 弹外关键就是指布署在阿里巴巴云计算平台的延展性云计算平台，支撑点了阿里云计算业务流程。
1.当今分库分表状况
4案例（16C/64G/3T SSD），4库（每一个案例一个库），每库64张表，共256张表。
根据RDS后台管理一键确诊作用，来计算表室内空间应用状况（这儿 拿接口测试数据库查询举例说明） 。
2.容积测算
案例数
数据库查询的短板关键反映在：硬盘、CPU、运行内存、互联网、线程数，而线程数主要是受 CPU 和运行内存危害。 CPU 和运行内存能够 根据动态性升配来提高，可是SSD硬盘容积较大 适用到6T（32C下列较大 3T、32C及之上较大 6T）。
可是目前兼具成本费，可先将案例扩充一倍，选用八个案例(16C/64G/3T SSD)，每一个案例建4个库（database）、每一个库128张表（这儿事实上是一个成本费选择的全过程，理论上应当采用"多库少表"的标准，单库128张表实际上太多了，单库提议32或64张表为宜） 。
事后假如案例工作压力提高可开展案例配备升級(16C/128G、32C/128G、32C/258G等)；将来如发生单案例升配没法处理，在考虑到扩充案例，只必须将database转移至新案例，转移成本费较小。
表数
按单表数最多1000w条数据信息评定，4096张表可适用日5000w单*三年(10.1压测规范)、日2000w单*5年的构架。（因业务流程表比较多，这里忽视掉一条数据信息尺寸的测算全过程）
库数
32个库，每一个库128张表。将来可较大 扩充到32个案例，不用rehash，只必须转移数据信息。
阿里云服务器RDS规格型号和价钱一览
因扩分库分表牵涉到rehash全过程（256表变4096表），而阿里云服务器DTS只适用同构库数据备份转移，因此大家根据DTS的binlog转kafka工作能力研发了数据库同步分布式数据库。
全部数据备份转移工作中包含：早期提前准备、数据库同步阶段（历史记录全量同歩、增加量数据信息即时同歩、rehash）、数据信息校检阶段（全量校检、即时校检、校检标准配备）、数据信息恢复工具等。
1.准备工作
唯一业务流程ID
在开展数据库同步前，必须先整理全部表的唯一业务流程ID，仅有明确了唯一业务流程ID才可以完成数据信息的同步控制。
必须留意的是：
业务流程中是不是有应用数据库查询自增ID作为业务流程ID应用的，如果有必须业务流程先开展更新改造，还行订单信息业务流程里沒有。
每一个表是不是都是有唯一索引，这一在整理的全过程中发觉有多张表沒有唯一索引。
一旦表格中沒有唯一索引，便会在数据库同步全过程中导致数据信息反复的风险性，因此大家先将沒有唯一索引的表依据业务场景提升唯一索引（有可能是协同唯一索引）。
在这儿顺带提一下，阿里云服务器DTS做同构数据备份转移，应用的是数据库查询自增ID作为唯一ID应用的，这类状况假如做双重同歩，会导致数据信息遮盖的难题。解决方法也是有，以前大家的作法是，新老实体线选用自增ID单双号处理，确保新老案例的自增ID不容易发生矛盾就可以了。由于此次大家应用的研发双重同歩部件，这个问题这儿不细聊。
分表标准整理
分表标准不一样决策着rehash和数据信息校检的不一样。需逐一表整理是客户ID层面分表还是是非非客户ID层面分表、是不是只储备库不分表、是不是不储备库不分表这些。
2.数据库同步
数据库同步总体计划方案见下面的图，数据库同步根据binlog，单独的正中间服务项目做同歩，对业务流程编码无入侵。
下面对每一个阶段开展详细介绍。
历史记录全量同歩
独立一个服务项目，应用游标的方法从旧库分次select数据信息，历经rehash后批量插入（batch insert）到新库，这里必须配备jdbc联接串主要参数rewriteBatchedStatements=true才可以使批处理命令实际操作起效。
此外尤其必须留意的是，历史记录也会存有持续的升级，假如先打开历史记录全量同歩，则刚同歩进行的数据信息有可能并不是全新的。因此这儿的作法是，先打开增加量数据信息单边同歩（从旧库到新库），这时仅仅打开库存积压kafka信息并不会真实消費；随后在逐渐历史记录全量同歩，当历史时间全量数据库同步进行后，在打开消費kafka信息开展增加量数据库同步（提升全量同歩高效率降低库存积压也是重要的一环），那样来确保转移数据信息全过程中的数据信息一致。
增加量数据信息即时同歩
增加量数据库同步充分考虑灰度切流可靠性、容灾备份和可回退工作能力，选用即时双重同歩计划方案，切流全过程中一旦新库发生可靠性难题或是新库发生数据信息一致难题，可迅速回退切回旧库，确保数据库查询的平稳和数据信息靠谱。
增加量数据信息即时同歩选用根据阿里云服务器DTS的数据信息定阅自研数据库同步部件data-sync完成，关键计划方案是DTS数据信息定阅工作能力会全自动将被定阅的数据库查询binlog变为kafka，data-sync部件定阅kafka信息、将信息开展过虑、合拼、排序、rehash、拆表、大批量insert/update，最终再递交offset等一系列实际操作，最后进行数据信息同歩工作中。
过虑循环系统信息：必须过虑掉循环系统同歩的binlog信息，这个问题较为关键后边将开展独立详细介绍。
数据信息合拼：同一条纪录的好几条实际操作只保存最终一条。为了更好地提升特性，data-sync部件收到kafka信息后不容易马上开展数据信息运转，只是多存到当地阻塞队列，随后由当地计划任务每X秒将当地序列中的N条数据信息开展数据信息运转实际操作。这时N条数据信息有可能是相同一张表同一条纪录的实际操作，因此这里只必须保存最终一条（类似redis aof重写） 。
update转insert：数据信息合拼时，假如数据信息中有insert update只保存最终一条update，会实行不成功，因此这里必须将update变为insert句子。
按新表合拼：将最后要递交的N条数据信息，依照新表开展分拆合拼，那样能够 立即依照新表层面开展数据库查询批量操作，提升插进高效率。
全部全过程中几个难题必须留意：
难题1：如何避免因多线程信息无次序而造成 的数据信息一致难题？
最先kafka多线程信息是存有次序难题的，可是要了解的是binlog是次序的，因此dts在对详尽开展kafka信息递送时也是次序的，这里要做的便是一个库确保只有一个顾客就能确保数据信息的次序难题、不容易发生数据信息情况遮盖，进而处理数据信息一致难题。
难题2：是不是会出现丢信息难题，例如顾客服务项目重新启动等状况下？
这儿沒有选用全自动递交offset，只是每一次消費数据信息最后进库进行后，将offset多线程存到一个mysql表格中，假如顾客服务项目重新启动服务器宕机等，重新启动后从mysql取得全新的offset逐渐消費。那样唯一的一个难题很有可能会发生一瞬间一部分信息反复消費,可是由于上边详细介绍的binlog是次序的,因此能确保数据的最后一致。
难题3：update转insert是否会丢字段名？
binlog是全字段名推送,不容易存有丢字段名状况。
难题4：循环系统信息难题。
后边开展独立详细介绍。
rehash
上文有提及，由于是256表变4096表，因此数据信息每一条都必须历经一次rehash再次做分库分表的测算。
说起rehash，就迫不得已先详细介绍下当今订单信息数据信息的分库分表对策，订单信息ID中沉余了客户ID的后四位，根据客户ID后四位做hash测算明确库号和表号。
数据库同步全过程中，从旧库到新库，必须取得订单信息ID中的客户ID后四位模4096，明确数据信息在新库中的库表部位；从新库到旧库，则必须用客户ID后四位模256，明确数据信息在旧库中的库表部位。
双重同歩时的binlog循环系统消費难题
想像一下，业务流程写一条数据信息到旧案例的一张表，因此造成了一条binlog；data-sync分布式数据库收到binlog后，将该纪录载入到新案例，因此在新案例也造成了一条binlog；这时data-sync分布式数据库又收到了该binlog......持续循环系统，信息愈来愈多，数据信息次序也打乱。
怎么解决该难题呢？大家选用数据信息上色计划方案，只需可以标志载入到数据库查询中的数据信息使data-sync分布式数据库载入并非业务流程载入，时下次接受到该binlog数据信息的情况下就不用开展再度信息运转。
因此data-sync分布式数据库规定，每一个数据库实例建立一个事务管理表，该事务管理表tb_transaction仅有id、tablename、status、create_time、update_time几个字段，status默认设置为0。
再返回上边的难题，业务流程写一条数据信息到旧案例的一张表，因此造成了一条binlog；data-sync分布式数据库收到binlog后，以下实际操作：
- # 打开事务管理，用事务管理确保一下sql的原子性和一致性
- start transaction;
- set autocommit = 0;
- # 升级事务管理表status=1，标志后边的业务流程数据信息逐渐上色
- update tb_transaction set status = 1 where tablename = ${tableName};
- # 下列是业务流程造成binlog
- insert xxx;
- update xxx;
- update xxx;
- # 升级事务管理表status=0，标志后边的业务流程数据信息丧失上色
- update tb_transaction set status = 0 where tablename = ${tableName};
- commit;
这时data-sync分布式数据库将上边这种句子装包一起递交到新案例，新案例升级数据信息后也会生产制造相匹配上边句子的binlog；当data-sync分布式数据库再度接受到binlog时，只需分辨碰到tb_transaction表status=1的数据信息逐渐，后边的数据信息都立即丢掉不必，直至碰到status=0时，再再次读取数据，为此来确保data-sync分布式数据库总是运转业务流程造成的信息。
3.数据信息校检
数据信息校检控制模块由数据信息校检服务项目data-check控制模块来完成，主要是根据数据库查询方面的数据对比，逐一核查每一个数据字段是不是一致，不一致得话会历经配备的校检标准来开展再试或是警报。
全量校检
以旧库为标准，查看每一条数据信息在新库是不是存有，及其个字段名是不是一致。
以新库为标准，查看每一条数据信息在旧库是不是存有，及其个字段名是不是一致。
即时校检
计划任务每五分钟校检，查看近期5 1分钟旧库和新库升级的数据信息，做diff。
差别数据信息开展二次、三次校检（因为高并发和数据信息延迟时间存有），三次校检都不一样则警报。
4.数据恢复
历经数据信息校检，一旦发觉数据信息不一致，则必须对数据信息开展修补实际操作。
数据恢复有二种计划方案，一种是适用大范畴的数据信息不一致，选用重设kafka offset的方法，再次消費数据信息信息，将有什么问题的数据信息开展遮盖。
第二种是适用小范畴的数据信息不一致，数据恢复控制模块全自动获取数据信息校检data-check控制模块纪录的sls日志，开展日志分析，转化成同歩句子，升级到总体目标库。
1.总体灰度切流计划方案
总体灰度计划方案：SP 客户层面来完成，SP层面：借助灰度自然环境切量来做，客户层面：依靠客户ID后四位百分数切流。
灰度切量的全过程一定要相互配合停写（秒级），为何要停写，由于数据库同步存有一定延迟时间（一切正常ms级），而全部业务流程实际操作一定要确保都是在一个案例上，不然在旧库中业务流程刚改动了一条数据信息，这时转换到新库假如数据信息都还没同歩回来便是旧数据信息会出现数据信息一致难题。因此流程应该是：
先停写
观查数据信息所有同歩完
在转换数据库
最终关掉停写，逐渐一切正常业务流程载入
2.切流前提前准备——ABC认证
尽管在切流以前，在接口测试进过去了很多的检测，可是接口测试终究和工作环境不一样，工作环境数据库查询一旦出难题就可能是大灾难，尽管上边详细介绍了数据信息校验和数据恢复步骤，可是把难题阻拦在产生以前是做服务项目可靠性最重要的工作中。
因而大家明确提出了ABC认证的定义，灰度自然环境ABC认证提前准备：
新选购两个数据库实例，当今订单信息库为A，新买的两个为各自为B、C
配备DTS从A单项工程同歩到B（dts适用同构不用rehash的数据库同步），B作为旧库的认证库，C库作为新库
用B和C作为生产制造演习认证
当B和C演习进行以后，在将A和C配备为宣布的双重同歩
3.灰度切流流程
实际灰度计划方案和数据库转换步骤：
编码提早配备好两个数据库查询分库分表标准。
根据ACM配备灰度占比。
编码阻拦mybatis要求，依据客户id后四位牙模型，和ACM设定中设定的灰度占比较为，将新库标志根据ThreadLocal传送到分库分表部件。
分辨当今是不是有灰度授权管理，如击中将新库标志根据ThreadLocal传送到分库分表部件。
分库分表部件依据ACM配备取得新储备库的分表标准，开展数据库查询存取数据。
切量的时候会相互配合ACM配备灰度占比击中的客户开展停写。
全部数据备份转移全过程還是非常复杂的，時间也不是很充足（全过程中还穿插着十一全链路压测更新改造），在比较有限的時间内集大伙儿之手反复探讨发掘很有可能存在的不足，随后论述解决方法，绝不放过一切一个很有可能发生难题的阶段，還是这句话，把难题阻拦在产生以前是做服务项目可靠性最重要的工作中。
全过程中的关键点還是许多的，从数据备份转移的准备工作到数据信息同步测试，从灰度步骤明确到宣布生产制造转换，尤其是融合业务流程和数据信息的特性，有很多必须考虑到的关键点，原文中沒有一一列举。
最后历经近2个月的焦虑不安工作中，无业务流程编码入侵、零安全事故、稳定地完成了扩分库分表和数据备份转移的工作中。
