前言
我们开源了一个订阅分发mysql的binlog的项目，一直用的非常好，忽然有天开发说能不能支持mongodb的数据订阅呢，mongodb的使用度也挺广泛的。安排。经过简单的了解后发现mongodb也有类似binlog的机制，最终花了两天时间把功能完成，并统一抽象集成到binlog开源项目中，使用和binlog同一套订阅分发模型管理mongodb数据源。整个过程非常顺利，比整mysql的binlog要简单的多了。
oplog简介
先来聊聊mongodb的主备机制，和mysql的binlog类似，在mongodb中，有一个系统库“”local”，库里有一个集合“oplog.rs”，这个集合类似于binlog文件，里面记录了mongodb的所有操作。从节点通过读取oplog.rs里的数据做到数据同步。
解析oplog
和订阅mysql的binlog一样（模拟一个从节点mysql）。我们的订阅服务要像从节点那样读取解析oplog.rs里的数据。解析前先看下oplog.rs的document的数据结构
上图是一个插入的数据的日志，可见oplog的doc中共有如下字段，含义分别如下：
ts:操作的时间戳（非常重要）
t:term最初在主数据库上生成操作的。(含义不明)
h：本次操作的唯一hashid
v: 版本号
op：操作类型,有六种类型，我们只需要关注其中的i(插入)、u(更新)、d(删除)即可
ns：库名和集合名称，中间使用“.”连接
o：本次操作的document内容
o2:只有op操作类型时u更新时，才会有这个字段，代表更新的条件语句
$set：o2获取后的文档里的属性，代表更新的字段
如上字段，完成一次oplog的解析，只需要ts、op、ns、o、o2、$set即可，其中ts非常重要，可以类比为binlog中的position。同步mysql的数据时，通过记录消费binlog的位置，也就是position，可以有效避免订阅服务停机后，消费记录丢失的问题。同步mongodb时，通过记录ts的值，来记录消费的位置，可以到达和订阅binlog一样的效果。和mysql订阅不同的是，mongodb的同步需要同步服务自己查询，而且oplog在mongodb4.0之前的版本有大小限制，超过设置的容量后，老的数据就会被丢失，在4.0之后的版本已经解除了这个限制。
代码
上面已经分析了oplog的结构以及订阅步骤，下面我们直接构建查询即可，需要注意，每次获取到的ts值，需要存储记录下来，已便重新订阅时，从上次断开的记录重新开始。下面直接看代码，重点逻辑都以注释详尽
结语
上面代码只是一个简单的测试用例，完整的应用还需要考虑ts的记录更新，事件的抽象，数据的分发等。我们已经开源的binlog订阅分发项目目前支持数据源在线管理，订阅数据（库、表）在线管理，如果能够使用同一套管理后台管理binlog和oplog的订阅在好不过。要实现和binlog统一管理模型，配置和分发方面基本不需要改动，然后从顶层数据源方面做区分实现即可。
目前我们整合管理的功能都已经开发好了，关于oplog部分的代码还没提交到github上，后面会和大家相见。
以上就是剖析后oplog订阅mongodb的数据变更就没那么难了的详细内容，更多关于oplog订阅mongodb的数据变更的资料请关注www.887551.com其它相关文章！