标签:兴趣 无法 一个 调用 其他 类型 部分 rop 提交
Change Stream是MongoDB用于实现变更追踪的解决方案,类似于关系型数据库的触发器,但原理不完全相同
Change Stream | 触发器 | |
---|---|---|
触发方式 | 异步 | 同步(事务保证) |
触发位置 | 应用回调事件 | 数据库触发器 |
触发次数 | 每个订阅事件的客户端 | 1次(触发器) |
故障恢复 | 从上一次断点重新触发 | 事务回滚 |
Change Stream是基于oplog实现的。它在oplog上开启一个tailable cursor来追踪所有复制集上的变更操作,最终调用应用中定义的回调函数
被追踪的变更事件主要包括:
Change Stream只推送已经在大多数节点上提交的变更操作。级“可重复度”的变更,这个验证是通过{readConcern:"majority"}实现的,因此
如果只对某些类型的变更时间感兴趣,可以使用聚合管道的过滤步骤过滤事件
var cs = db.collection.watch([{
$match:{
operationType:{
$in:{"insert","delete"}
}
}
}])
默认是没有开启Change Stream功能的,在配置文件中设置
replication:
enableMajorityReadConcern: true
假如在一系列写入操作的过程中,订阅Change Stream的应用在接收到“写3”之后与 t0 时刻崩溃,重启后后续变更怎么办?
想要从上次中断的地方继续获取变更流,只需要保留上次变更通知中的_id即可
上图所示是一次Change Stream回调所返回的数据。没跳这样的数据都带有一个_id,这个_id可以用于断点恢复,例如:
var cs = db.collection.watch([],{resumeAfter:<_id>})
即可从上一条通知中断处继续获取后续的变更通知
标签:兴趣 无法 一个 调用 其他 类型 部分 rop 提交
原文地址:https://www.cnblogs.com/xiaoqingtian/p/13511027.html