MongoDB Change Stream初体验

Change Stream是MongoDB从3.6开始支持的新特性。这个新特性有哪些奇妙之处，会给我们带来什么便利？本次的文章将就这个主题进行初步讨论。

Change Stream是什么？

顾名思义，Change Stream即变更流，是MongoDB向应用发布数据变更的一种方式。即当数据库中有任何数据发生变化，应用端都可以得到通知。我们可以将其理解为在应用中执行的触发器。至于应用想得到什么数据，以什么形式得到数据，则可以通过聚合框架加以过滤和转换。这点将在后文中讨论。

Change Stream的原理

我们先来回顾一下MongoDB复制集大致是如何工作的：

1. 应用通过驱动向数据库发起写入请求；
2. 在同一个事务中，MongoDB完成oplog和集合的修改；
3. oplog被其他从节点拉走；
4. 从节点应用得到的oplog，同样在一个事务中完成对oplog和集合的修改；

至此，复制集同步完成。可以发现，整个同步过程是依赖于oplog来进行的。也就是说oplog实际上已经包含了我们需要的所有变更数据。如果观测oplog的变化，是否就能够得到所有变更的数据了呢？对，change stream正是基于这个原理实现的。但事情并没有这么简单！我们来看一下问题有可能出在什么地方。

如何从断点恢复

现实世界中，没有哪个应用是可以不间断运行的。不考虑bug导致的问题，正常的应用升级也会导致应用中断运行。那么在应用恢复的时候，从哪里开始继续获取变更呢？oplog当然是可以帮我们做到这点的，但你必须对MongoDB足够了解，才知道有oplogReplay这样的参数，以及其他一些问题。

如何有效地处理订阅

假设在一个应用中需要订阅10个不同集合的变更情况，是否需要开10个tailable cursor去获取oplog的变更呢？如果是100个集合呢？出于效率考虑显然不应该这么做。那么整个过程就会变成一个生产者-消费者模式，由一个线程负责从oplog获取变更，由订阅的线程负责消费这些变更。虽然实现也不是那么复杂，并且多半可以找到开源实现，但是涉及多线程就已经足够让初学者头疼一阵的了。
公平地说，上面这些还不算严重的问题，下面这些问题可能会更让人头疼。

如何管理权限

想要tail oplog，必须对local.oplog.rs有读权限。实际上这相当于对整个数据库都有了读权限，因为所有的变更都会在这里体现出来。DBA可能会阻止你这么做，因为这实在不是一个很安全的做法。

如何数据回滚

极端情况下，如果应用处理不当，MongoDB中可能发生数据回滚rollback的问题。如果仅仅通过跟踪oplog，则会出现已经通知出去的变更被回滚的情况。

幸运的是上面这些问题现在都不是问题了，因为change stream帮我们规避了这些复杂的细节。

使用方法

由于各种驱动都会有不同的语法和API，从shell中尝试使用change stream可能是简便的方法。这并不妨碍你随后在各种驱动中的使用，因为shell中能实现的功能在驱动中一定有对应的语法。下面就以shell为例看看change stream应该如何使用。

打开一个shell，订阅你需要关注的集合
比如：

var cursor = db.bar.watch();