技术特征：
1.一种不停机数据库迁移方法，其特征在于，包括以下步骤：s1、版本v0迁库前的前置操作，用于控制版本v1操作落db-new数据的幂等判断；原有下单流程不变，仅在下单成功情况下新增存储请求四要素在redis的操作，在v0版本上线前保障此版本稳定运行一段时间；操作注意点：(1)redis存储期限：1～2天；(2)redis格式：{trade_center_v0_requestdate_requestorderno_requestsystem_merchantno,normal}其中小写字符代表变量，记录的是确定的值，例如：收单域订单redis存储：{trade_center_v0_20170815_2017081517tppiop1110000000000466_trade_acquiring_3178000000875377,normal}资金域订单redis存储：资金幂等校验没有考虑商户号{trade_center_v0_20170815_2017081517tppiop1110000000000466_trade_deduct,normal}(3)涉及业务：资金下单、收单下单；(4)在v0发版后检查redis数据是否正常；s2、版本v1将数据新增到新数据库db-new的t1-move表中，仅仅处理在move表中的订单，原表中的数据静置后进行数据迁移；v1版本上线前操作：(后续v2版本照此操作)关闭应用大总管后台操作入口；该应用所有定时任务暂停(将所有定时任务状态置为invalid失效)；数据库层面：新增库db-new；在db-new库中新增两套表：t1-new<与db-old所有表名保持一致>，t_move<临时存储新库数据表>；v1版本操作如下：
①
将db-old数据源连接信息替换成db-new的；
②
mapper层所有表名换成t1-move：暂时存储数据，后续会迁移到t1-new表；
③
下单：落t1-move表；a.下单前：先判断请求四要素是否已存储在trade_center_v0_request缓存中，已存在则直接抛出异常——重复下单，不存在则正常落t1-move表；b.下单后：下单成功后存储前缀为ade_center_v1_request的redis缓存，请求四要素拼接作为key；
④
支付(以前就有判断订单是否存在)：支付前根据交易号判断该订单是否存在t1-move表，不存在则直接抛出异常’订单不存在’<数据可能存储在t1-old表>，存在则继续支付；
⑤
接收支付控制kafka处理：新增一条日志打印——首先判断该支付单是否能在t1-move表中查到，如果查不到则打印经支付控制kafka消息转换而来的支付信息，否则继续处
理；发送kafka无需做特殊处理；发版后操作：观察数据落t1-move表正常后，则可以通知dba将db-old数据迁移到db-new的t1-new表中；s3、版本v2发布条件：等待dba将db_old的所有数据迁移到db-new的t1-new表，再发布v2版本；数据库层面：无变化；v2版本操作如下：1)继续使用db-new数据源mapper层所有表名更换为t1(db-new中的表)，相对于上一个版本删除move后缀；2)下单：下单前：先判断请求四要素是否已存储在ade_center_v1_request缓存中，已存在则直接抛出异常——重复下单，不存在则正常落t1-new表；下单后：无需新增redis缓存操作(后续版本交易还是落t1-new表，仅是将代码还原到迁库之前，且只改动数据源)；3)支付(以前就有判断订单是否存在)：支付前根据交易号判断该订单是否存在t1-new表，不存在则直接抛出异常“订单不存在”<数据可能存储在t1-move表>，存在则继续支付；4)接收支付控制kafka处理：新增一条日志打印——首先判断该支付单是否能在t1-move表中查到，如果查不到则打印经支付控制kafka消息转换而来的支付信息，否则继续处理；5)发送kafka无需做特殊处理；发版后操作：观察数据落t1-new表正常后，通知dba将t1-move数据迁移到t1-new表中；s4、版本v3发布条件，等待dba将t1-move的所有数据迁移到t1-new表，再发布v3版本；数据库层面：无变化；v3版本操作如下：a.继续使用db-new数据源；b.mapper层所有表名为t1(db-new中的表)；c.下单、支付逻辑还原到迁库之前；发版后操作：检查数据量是否正确；s5、迁移过程预期问题(1)v0版本发布只涉及上线redis控制正交易唯一性约束问题，理论不会有任何问题；(2)v0到v1版本发布期间(一半机器运行v0，一半机器运行v1)，可能出现下单落在v0，支付落在v1或者下单落在v1，支付落在v0的情况下：正交易：对于老交易来说不受任何影响(老交易都是下单并支付)，对于新交易全部受影响；反交易：新老交易视原交易位置，如果原单不在相应版本的表里，全部受影响；(3)v1版本发布完成后对新老交易的所有正交易均不受影响，所有记录全部落在temp表；对新老交易的反交易，原交易在老表的情况下受影响；(4)在v1和v2发布期间(一半机器运行v1，一半机器运行v2)，可能出现下单落在v1，支
付落在v2或者下单落在v2，支付落在v1的情况下：正交易：对于老交易来说不受任何影响(老交易都是下单并支付)，对于新交易全部受影响；反交易：新老交易视原交易位置，如果原单不在相应版本的表里，全部受影响；(5)v2版本发布完成后对新老交易的所有正交易均不受影响，所有记录全部落在最终表；对新老交易的反交易，在原交易在tmep表的情况下受影响；对新老交易的反交易，原交易在老表里的全部受影响；(6)v2到v3版本发布至完成理论数据全部切到最终表后，无影响；回滚方案迁移到tmp表的过程中发生影响，代码回滚，将tmp表数据移动至老表。
技术总结
本发明公开了一种不停机数据库迁移方法。本发明的有益效果如下：1.能够保障集团业务线上正常运行，无感知情况下做数据库替换；2.迁移过程中分阶段、递进式实施，实施过程中一旦发生异常回滚，提供了完整的补偿机制；3.为复杂业务拆分，多系统共用数据库拆分迁移提供了一套完备的热迁移方案。一套完备的热迁移方案。一套完备的热迁移方案。
技术研发人员：许信
受保护的技术使用者：天翼电子商务有限公司
技术研发日：2021.12.22
技术公布日：2022/4/22