背景介绍
最近微服务架构火的不行,但本质上也只是风口上的一个热点词汇。
作为笔者的经验来说,想要应用一个新的架构需要带来的变革成本是非常高的。
尽管如此,目前还是有许多企业踏上了服务化改造的道路,这其中则免不了”旧改”的各种繁杂事。
所谓的”旧改”,就是把现有的系统架构来一次重构,拆分成多个细粒度的服务后,然后找时间升级割接一把,让新系统上线。这其中,数据的迁移往往会成为一个非常重要且繁杂的活儿。
> 拆分服务时数据迁移的挑战在哪?
常见方案
按照迁移的方案及流程,可将数据迁移分为三类:
1. 停机迁移
最简单的方案,停机迁移的顺序如下:
采用停机迁移的好处是流程操作简单,工具成本低;然而缺点也很明显,迁移过程中业务是无法访问的,因此只适合于规格小、允许停服的场景。
2. 业务双写
业务双写是指对现有系统先进行改造升级,支持同时对新库和旧库进行写入。
之后再通过数据迁移工具对旧数据做全量迁移,待所有数据迁移转换完成后切换到新系统。
示意图:
业务双写的方案是平滑的,对线上业务影响极小;在出现问题的情况下可重新来过,操作压力也会比较小。
笔者在早些年前尝试过这样的方案,整个迁移过程确实非常顺利,但实现该方案比较复杂,需要对现有的代码进行改造并完成新数据的转换及写入,对于开发人员的要求较高。
在业务逻辑清晰、团队对系统有足够的把控能力的场景下适用。
3. 增量迁移
增量迁移的基本思路是先进行全量的迁移转换,待完成后持续进行增量数据的处理,直到数据追平后切换系统。
示意图:
关键点
> MongoDB 3.6版本开始便提供了Change Stream功能,支持对数据变更记录做监听。
这为实现数据同步及转换处理提供了更大的便利,下面将探讨如何利用Change Stream实现数据的增量迁移。
Change Stream 介绍
Chang Stream(变更记录流) 是指collection(数据库集合)的变更事件流,应用程序通过db.collection.watch()这样的命令可以获得被监听对象的实时变更。
在该特性出现之前,你可以通过拉取 oplog达到同样的目的;但 oplog 的处理及解析相对复杂且存在被回滚的风险,如果使用不当的话还会带来性能问题。
Change Stream可以与aggregate framework结合使用,对变更集进行进一步的过滤或转换。
由于Change Stream 利用了存储在 oplog 中的信息,因此对于单进程部署的MongoDB无法支持Change Stream功能,
其只能用于启用了副本集的独立集群或分片集群。
监听的目标
名称 | 说明 |
---|---|
单个集合 | 除系统库(admin/local/config)之外的集合,3.6版本支持 |
单个数据库 | 除系统库(admin/local/config)之外的数据库集合,4.0版本支持 |
整个集群 | 整个集群内除去系统库( (admin/local/config)之外的集合 ,4.0版本支持 |
变更事件
一个Change Stream Event的基本结构如下所示:
字段说明
名称 | 说明 |
---|---|
_id | 变更事件的Token对象 |
operationType | 变更类型(见下面介绍) |
fullDocument | 文档内容 |
ns | 监听的目标 |
ns.db | 变更的数据库 |
ns.coll | 变更的集合 |
documentKey | 变更文档的键值,含_id字段 |
updateDescription | 变更描述 |
updateDescription.updatedFields | 变更中更新字段 |
updateDescription.removedFields | 变更中删除字段 |
clusterTime | 对应oplog的时间戳 |
txnNumber | 事务编号,仅在多文档事务中出现,4.0版本支持 |
lsid | 事务关联的会话编号,仅在多文档事务中出现,4.0版本支持 |
Change Steram支持的变更类型有以下几个:
类型 | 说明 |
---|---|
insert | 插入文档 |
delete | 删除文档 |
replace | 替换文档,当执行replace操作指定upsert时,可能是insert事件 |
update | 更新文档,当执行update操作指定upsert时,可能是insert事件 |
invalidate | 失效事件,比如执行了collection.drop或collection.rename |
利用以下的shell脚本,可以打印出集合 T_USER上的变更事件:
下面提供一些样例,感受一下
insert 事件
update事件
replace事件
delete事件
invalidate 事件
执行db.T_USER.drop() 可输出
更多的Change Event 信息可以 参考这里
实现增量迁移
本次设计了一个简单的论坛帖子迁移样例,用于演示如何利用Change Stream实现完美的增量迁移方案。
背景如下:
现有的系统中有一批帖子,每个帖子都属于一个频道(channel),如下表
频道名 | 英文简称 |
---|---|
美食 | Food |
情感 | Emotion |
宠物 | Pet |
家居 | House |
征婚 | Marriage |
教育 | Education |
旅游 | Travel |
新系统中频道字段将采用英文简称,同时要求能支持平滑升级。
根据前面篇幅的叙述,我们将使用Change Stream 功能实现一个增量迁移的方案。
相关表的转换如下图:
原理
topic 是帖子原表,在迁移开始前将开启watch任务持续获得增量数据,并记录到 topic_incr表中;接着执行全量的迁移转换,之后再持续对增量表数据进行迁移,直到无新的增量为止。
接下来我们使用Java程序来完成相关代码,mongodb-java–driver 在 3.6 版本后才支持 watch 功能,需要确保升级到对应版本:
1. 定义Channel频道的转换表
1. 为 topic 表预写入1w条记录
上述实现中,每个帖子都分配了随机的频道(channel)
1. 开启监听任务,将topic上的所有变更写入到增量表。
代码中通过watch 命令获得一个MongoCursor对象,用于遍历所有的变更。
FullDocument.UPDATE_LOOKUP选项启用后,在update变更事件中将携带完整的文档数据(FullDocument)。
watch()命令提交后,mongos会与分片上的mongod(主节点)建立订阅通道,这可能需要花费一点时间。
ChangeTask 实现逻辑如下:
每一个变更任务会不断对topic产生写操作,触发一系列ChangeEvent产生。
以doUpdate为例,实现代码如下:
1. 启动一个全量迁移任务,将 topic 表中数据迁移到 topic_new 新表。
在全量迁移开始前,先获得当前时刻的的最大 _id 值(可以将此值记录下来)作为终点。
随后逐个完成迁移转换。
注:增量迁移过程中,变更操作仍然在进行
增量迁移的实现是一个**不断 tail **的过程,利用 **_id 字段的有序特性 ** 进行分段迁移;即记录下当前处理的 _id 值,循环拉取在 该 _id 值之后的记录进行处理。
增量表(topic_incr)中除了DELETE变更之外,其余的类型都保留了整个文档,因此可直接利用 replace + upsert 追加到新表。
查看 topic 表和 topic_new 表,发现两者数量是相同的。
为了进一步确认一致性,我们对两个表的分别做一次聚合统计:
topic表
topic_new表
前者输出结果:
后者输出结果:
前后对比的结果是一致的!
后续优化
前面的章节演示了一个增量迁移的样例,在投入到线上运行之前,这些代码还得继续优化:
BTW,数据迁移一定要结合业务特性、架构差异来做考虑,否则还是在耍流氓。
小结
服务化系统中扩容、升级往往会进行数据迁移,对于业务量大,中断敏感的系统通常会采用平滑迁移的方式。
MongoDB 3.6 版本后提供了 Change Stream 功能以支持应用订阅数据的变更事件流,本文使用 Stream 功能实现了增量平滑迁移的例子,这是一次尝试,相信后续这样的应用场景会越来越多。
相关参考
Use-ChangeStreamToHandle Temperature
作 者
zale 唐卓章,华为技术专家,多年互联网研发/架设经验,关注NOSQL 中间件高可用及弹性扩展,在分布式系统架构性能优化方面有丰富的实践经验,目前从事物联网平台研发工作,致力于打造大容量高可用的物联网服务。