在线数据迁移，数字化时代的必修课——京东云数据迁移实践
打破数据边界，是数字化时代常挂在嘴边的一句话，数据的价值是在流动中体现的，数据应用也是如此。以往为了满足开发、测试、数据保护容灾和数据分析的需要，我们不断对数据进行复制、备份、迁移，因此数据迁移非常重要。
混合多云时代，用户数据迁移需求与场景激增
今天我们来重点聊聊混合云时代中数据迁移，先来看看常见的几种企业数据迁移的需求与场景：
传统云化型：设备老旧，需要升级，硬件成本升级性价比不高，云上更经济；
价格敏感型：综合对比多家厂商价格，灵活选型采用成本最优方案；
灾备驱动型：需要多云、异构云来架构自己的灾备体系，保证数据的安全
游戏客户：异地开服，服务不同地域的用户，因各地网络质量不一致需要多云模式用于构建服务本地用户的游戏服务器。
泛金融客户：要符合金融安全政策的要求，需要数据的迁移
这些客户都因系统和技术升级、业务的发展、以及安全合规等因素采用混合多云的方案，同时对其数据的迁移有着很高的诉求，在不同的业务模式和需求下也会面临多种问题。
混合多云时代下，数据迁移的困境
数据库的发展多样性提升迁移门槛
混合多云时代，迁移是面临的一大难题，其中数据安全迁移往往又是企业最关注的。提到数据迁移的困难，究其原因先粗略回顾下关系型数据库到非关系型数据库的发展。
关系型数据库，是指采用了关系模型来组织数据的数据库。关系模型是在1970年由IBM的研究员E.F.Codd博士首先提出的，在之后的几十年中，关系模型的概念得到了充分的发展并逐渐成为主流。关系型数据库具备事务一致性、读写实时性、结构化与规范化等特性，因而容易理解、使用方便、易于维护，在虚机时代，互联网还未普及时它是最主流的数据库，典型的代表有Oracle、Microsoft SQL Server、DB2、MySQL等。
但随着互联网的飞速发展，网站用户并发高，海量数据的产生，传统关系型数据库已经不能满足企业的数据存储需求了，非关系型数据库应势而生，它高并发,读写能力强、弱化数据结构一致性,使用更加灵活有良好的可扩展性等优势逐渐成为了企业的首选。
NoSQL一词首先是Carlo Strozzi在1998年提出来的。典型代表Redis， Amazon DynamoDB， Memcached，Microsoft Azure Cosmos DB等
在面对这两种数据库之间的迁移，关系型数据库SQL RDBMS发展久，迁移生态工具齐全，且大部分数据库产品都自带迁移工具；而非关系NoSQL，数据定义更宽松，产品体积轻量，放弃了一致性校验，导致某些数据结构滥用，提升了迁移难度。而迁移工具大部分开放给生态来做，由于发展时间较短，工具完善度不如RDBMS高。
厂商试图“数据绑架”，使迁移雪上加霜
分析完关系型数据库到非关系数据库的发展，可以看到数据存储结构本身已发生了巨大的变化，这从根因上已大幅提升了迁移的难度，而一些云厂商对数据库的再次改造，且对关系型数据库底层改造不透明，导致数据库的复杂性大大加大，试图用数据迁移成本高来长期绑定客户，更是令数据的迁移雪上加霜。
“个体差异”导致通用型解决方案缺失
不同的企业由于自身需求不同与使用场景的多样性，每一个客户，对我们来说都是一个新的案例，我们必须“量身定制”化服务，但在过程中我们也总结出几类常见难点：
难点一：多节点数据库迁移，节点数量不一致
难点二：原生产品跨版本问题，版本不一致且上下版本兼容性不够好
难点三：缓存类数据易失性更高
面临挑战，京东云破局迁移困境
下面通过实际案例和大家分享我们是如何破局迁移困境，帮助用户解脱数据枷锁的。
重大挑战，临危不乱/从容不迫
2019年京东物流为了实现其轻资产化、降低成本、升级架构的三大目的，将其ES开始由本地机房迁移到云上。依托京东云云搜索ES高可用、易扩展、近实时等特性，京东物流成功地将分拣中心自动化系统、冷链流程监控系统、开放订单跟踪系统等上百个系统迁移上云。
在迁移过程中京东云不仅提供了常规的停机迁移方案，还提供了特殊的不停机迁移方案，保证了物流业务不停服。不停机迁移方案如下：在云端创建新集群，将云上集群和用户集群合并成一个大集群，利用Elasticsearch数据分布API（cluster.routing.allocation.exclude）将用户集群中的索引数据迁移到云上集群的数据节点，最后将用户集群和云上集群构成的大集群拆分，关闭用户集群即可完成迁移。（采用这种方式须注意同时满足以下两个条件：用户集群版本和云上集群版本相同；用户集群所有节点和云上集群所有节点网络能够互通。）
通过上述方法，很快就就完成了京东物流近百个系统的数百个集群、数千个节点数据上云工作。在此之上京东云还配套提供了一键报警等核心功能，对上云工作进行全天候、全方位的保障。
截止目前，京东物流已有超过90%的应用在公有云上部署了实例，去年11.11期间业务量超过日常三倍以上的情况下，整体运营平稳。
迁移利器，上云必备
关系型数据库依然是各行业的主流应用之一，怎样更快的将传统关系型数据中的数据迁移上云也是很多行业用户关心的。为此京东云特意打造了一款针对关系型数据库的迁移工具——数据传输DTS。
数据传输DTS 提供实时数据流服务，支持数据迁移、数据订阅和数据同步服务，可简单方便的满足数据上云、业务异步解耦、数据异地灾备、业务系统数据流转等业务场景。目前数据传输DTS支持MySQL、MariaDB、Percona、SQL Server、PostgreSQL等多种数据库迁移，可以简单快速地将本地自建数据库迁移至京东云，源数据库在迁移过程中可继续正常运行，从而最大程度地减少应用程序的停机时间。
不断突破，技术创新
某家在线广告公司需要将Redis从自有机房迁移到云上。由于客户系统承载着大量结算缓存和业务缓存所以要求在迁移过程中不能有业务中断。当时有一些开源工具，但是不满足要求。主要是由于版本问题，客户用的Redis版本是4.0而当时开源的工具只支持3.28及以下版本。本着京东客户业务为先的原则，和鼓励创新的技术精神，我们思考，能不能为客户自研一套工具，能够Cover住Redis数据流转大部分场景的通用工具，于是2019年7月redissyncer 1.0版本诞生，完成了数据源及目标校验、原生集群同步、 大KV的拆解等基本功能。
1.0完后很快迎来了几个客户：
其一是互联网行业用户，Redis单实例，数据体量不大20Gb左右。我们通过启动参数修复、调整每批次Value值等细节优化顺利完成了迁移任务；
第二个用户是游戏行业的用户，用户需要将自有IDC中的Redis迁移到京东云。在使用我们的产品之前，用户自己找过若干开源产品但都不符合要求。由于用户的实例数量较多，在了解过Redissyncer产品特性后，用户决定使用我们的工具自行迁移。
贴近一线，无微不至
经过一个下午的培训远程培训，用户很快上手第一个实例迁移很顺利。在接下来的几天用户通过我们的工具陆续完成迁移工作，并反馈中给予产品很高评价，并特意发来感谢信。
来自客户的认可，是我们不断向前的最大动力！
不断打磨，精益求精
在剖析过更多客户痛点与需求后， 2019年11月底，我们完成了2.0版本的升级，补充了同步模式拆分、断点续传、离线文件加载、跨版本迁移、流式加载等功能。
很快2019年12月我们又迎来了一个金融用户。用户需要将原生Redis集群迁移到自研的Redis集群。目标集群节点数多大16*2即16对主从构成的集群，迁移过程很顺利，经过准备15分钟完成应用割接。
（迁移部署图）
经过实际场景的打磨，我们陆续修复了一些测试中很难遇到的bug，添加了一些新特性。使得产品不仅支持升级迁移同时支持降级迁移；为了提高用户体验，我们参考Redis、MySQL等优秀开源产品的方式做了一个命令行客户端命名为redissyncer-cli。至此，完成了RedisSyncer3.X的升级，这个项目的体系建设基本上可以满足Redis迁移同步场景中的大部分需求了。
不止于此，突破创新
起初，我们把RedisSyncer定位为一个Redis的同步工具。随着开发和用户侧的实践，我们下一步想把RedisSyncer打造成为具备企业级灾备能力的Redis数据同步中间件。从工具到具备企业级灾备能力还是有一定门槛的。所以下一步我们的工作重点是对软件进行分布式改造，最终目标是在任意节点发生故障时任务可自动化持续，实现企业级灾备能力的Redis数据同步中间件。
拥抱开源，包容开放
目前京东云已经积累了覆盖互联网、游戏、金融、物流、零售等多场景领域的迁移经验。随着混合多云趋势到来，我们深知用户迁移之苦，也愿意以兼容开放的心态为客户提供技术服务，真正做到把选择权交给用户，同时为了让更多人享受技术带来的便利，我们将自研RedisSyncer完全开源（开源地址：https://github.com/TraceNature/redissyncer-server），将技术回归社区，给更多用户和开发者带来便利！
