共计 3639 个字符，预计需要花费 10 分钟才能阅读完成。
突破数据边界，是数字化时代常挂在嘴边的一句话，数据的价值是在流动中体现的，数据利用也是如此。以往为了满足开发、测试、数据保护容灾和数据分析的须要，咱们一直对数据进行复制、备份、迁徙，因而数据迁徙十分重要。
混合多云时代，用户数据迁徙需要与场景激增
明天咱们来重点聊聊混合云时代中数据迁徙，先来看看常见的几种企业数据迁徙的需要与场景：
传统云化型：设施老旧，须要降级，硬件老本降级性价比不高，云上更经济；
价格敏感型：综合比照多家厂商价格，灵便选型采纳老本最优计划；
灾备驱动型：须要多云、异构云来架构本人的灾备体系，保证数据的平安
游戏客户：异地开服，服务不同地区的用户，因各地网络品质不统一须要多云模式用于构建服务本地用户的游戏服务器。
泛金融客户：要合乎金融平安政策的要求，须要数据的迁徙
这些客户都因零碎和技术升级、业务的倒退、以及平安合规等因素采纳混合多云的计划，同时对其数据的迁徙有着很高的诉求，在不同的业务模式和需要下也会面临多种问题。
混合多云时代下，数据迁徙的窘境
数据库的倒退多样性晋升迁徙门槛
混合多云时代，迁徙是面临的一大难题，其中数据安全迁徙往往又是企业最关注的。提到数据迁徙的艰难，究其原因先粗略回顾下关系型数据库到非关系型数据库的倒退。
关系型数据库，是指采纳了关系模型来组织数据的数据库。关系模型是在 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/TraceNatur…），将技术回归社区，给更多用户和开发者带来便当！
