MongoDB Stream是如何实现完美数据增量迁移的？
副标题[/!--empirenews.page--]
技术沙龙 | 邀您于8月25日与国美/AWS/转转三位专家共同探讨小程序电商实战
一、背景介绍最近微服务架构火得不行，但本质上也只是风口上的一个热点词汇。 作为笔者的经验来说，想要应用一个新的架构需要带来的变革成本是非常高的。 尽管如此，目前还是有许多企业踏上了服务化改造的道路，这其中则免不了“旧改”的各种繁杂事。 所谓的“旧改”，就是把现有的系统架构来一次重构，拆分成多个细粒度的服务后，然后找时间升级割接一把，让新系统上线。这其中，数据的迁移往往会成为一个非常重要且繁杂的活儿。 拆分服务时数据迁移的挑战在哪？
二、常见方案按照迁移的方案及流程，可将数据迁移分为三类： 1、停机迁移 最简单的方案，停机迁移的顺序如下：
采用停机迁移的好处是流程操作简单，工具成本低，然而缺点也很明显，迁移过程中业务是无法访问的，因此只适合于规格小、允许停服的场景。 2、业务双写 业务双写是指对现有系统先进行改造升级，支持同时对新库和旧库进行写入。之后再通过数据迁移工具对旧数据做全量迁移，待所有数据迁移转换完成后切换到新系统。 示意图：
业务双写的方案是平滑的，对线上业务影响极小，在出现问题的情况下可重新来过，操作压力也会比较小。 笔者在早些年前尝试过这样的方案，整个迁移过程确实非常顺利，但实现该方案比较复杂，需要对现有的代码进行改造并完成新数据的转换及写入，对于开发人员的要求较高。在业务逻辑清晰、团队对系统有足够的把控能力的场景下适用。 3、增量迁移 增量迁移的基本思路是先进行全量的迁移转换，待完成后持续进行增量数据的处理，直到数据追平后切换系统。 示意图：
关键点： 要求系统支持增量数据的记录。对于MongoDB可以利用oplog实现这点，为避免全量迁移过程中oplog被冲掉，在开始迁移前就必须开始监听oplog，并将变更全部记录下来；如果没有办法，需要从应用层上考虑，比如为所有的表(集合)记录下updateTime这样的时间戳，或者升级应用并支持将修改操作单独记录下来。 增量数据的回放是持续的。在所有的增量数据回放转换过程中，系统仍然会产生新的增量数据，这要求迁移工具能做到将增量数据持续回放并将之追平，之后才能做系统切换。 MongoDB 3.6版本开始便提供了Change Stream功能，支持对数据变更记录做监听。这为实现数据同步及转换处理提供了更大的便利，下面将探讨如何利用Change Stream实现数据的增量迁移。 三、Change Stream介绍 Chang Stream（变更记录流）是指collection（数据库集合）的变更事件流，应用程序通过db.collection.watch()这样的命令可以获得被监听对象的实时变更。 在该特性出现之前，你可以通过拉取oplog达到同样的目的；但oplog的处理及解析相对复杂且存在被回滚的风险，如果使用不当的话还会带来性能问题。Change Stream可以与aggregate framework结合使用，对变更集进行进一步的过滤或转换。 参考链接：https://docs.mongodb.com/manual/aggregation/ 由于Change Stream利用了存储在oplog中的信息，因此对于单进程部署的MongoDB无法支持Change Stream功能，其只能用于启用了副本集的独立集群或分片集群。 监听的目标
变更事件 一个Change Stream Event的基本结构如下所示：
字段说明：
Change Steram支持的变更类型有以下几个：
利用以下的shell脚本，可以打印出集合 T_USER上的变更事件：
下面提供一些样例，感受一下： insert事件
update事件
replace事件
delete事件
invalidate事件
更多的Change Event信息可以参考：https://docs.mongodb.com/manual/reference/change-events/ 四、实现增量迁移 本次设计了一个简单的论坛帖子迁移样例，用于演示如何利用Change Stream实现完美的增量迁移方案。 背景如下： 现有的系统中有一批帖子，每个帖子都属于一个频道(channel)，如下表：
新系统中频道字段将采用英文简称，同时要求能支持平滑升级。根据前面篇幅的叙述，我们将使用Change Stream功能实现一个增量迁移的方案。 （编辑：核心网） 【声明】本站内容均来自网络，其相关言论仅代表作者个人观点，不代表本站立场。若无意侵犯到您的权利，请及时与联系站长删除相关内容! |
