Change Stream是MongoDB从3.6开始支持的新特性。这个新特性有哪些奇妙之处,会给我们带来什么便利?本次的文章将就这个主题进行初步讨论。
Change Stream 是什么?
顾名思义,Change Stream即变更流,是MongoDB向应用发布数据变更的一种方式。即当数据库中有任何数据发生变化,应用端都可以得到通知。我们可以将其理解为在应用中执行的触发器。至于应用想得到什么数据,以什么形式得到数据,则可以通过聚合框架加以过滤和转换。这点将在后文中讨论。
Change Stream 的原理
我们先来回顾一下MongoDB复制集大致是如何工作的:
应用通过驱动向数据库发起写入请求;
在同一个事务中,MongoDB完成oplog和集合的修改;
oplog被其他从节点拉走;
从节点应用得到的oplog,同样在一个事务中完成对oplog和集合的修改;
至此,复制集同步完成。可以发现,整个同步过程是依赖于oplog来进行的。也就是说oplog实际上已经包含了我们需要的所有变更数据。如果观测oplog的变化,是否就能够得到所有变更的数据了呢?对,change stream正是基于这个原理实现的。但事情并没有这么简单!我们来看一下问题有可能出在什么地方。
如何从断点恢复
现实世界中,没有哪个应用是可以不间断运行的。不考虑bug导致的问题,正常的应用升级也会导致应用中断运行。那么在应用恢复的时候,从哪里开始继续获取变更呢?oplog当然是可以帮我们做到这点的,但你必须对MongoDB足够了解,才知道有oplogReplay这样的参数,以及其他一些问题。
如何有效地处理订阅
假设在一个应用中需要订阅10个不同集合的变更情况,是否需要开10个tailable cursor去获取oplog的变更呢?如果是100个集合呢?出于效率考虑显然不应该这么做。那么整个过程就会变成一个生产者-消费者模式,由一个线程负责从oplog获取变更,由订阅的线程负责消费这些变更。虽然实现也