1. 什么是Change Stream
Change Stream 是MongoDB用于实现变更追踪的解决方案，类似于关系数据库的触发器，但原理不完全相同：

|              |  Change Stream  |  触发器        |  
|--------------|-----------------|---------------|  
|   触发方式    |  异步           |  同步（事务保证） |  
|   触发位置    |  应用回调事件    |  数据库触发器   |  
|   触发次数    |  每个订阅事件的客户端  |  1次（触发器） |  
|   故障恢复    |  从上次断点重新触发  |  事务回滚    |  

2. Change Stream 实现原理
Change Stream 是基于oplog实现的。它在oplog上开启一个tailable cursor 来追踪复制集上的变更操作，
最终调用应用中定义的回调函数。被追踪的变更事件主要包括：

· insert/update/delete：插入、更新、删除；  

. drop：集合被删除；  

. rename：集合被重命名；  

. dropDatabase：数据库被删除；  

. invalidate: drop/rename/dropDatabase 将导致invalidate被触发，并关闭 change stream;  

3. Change Stream 与可重复读
Change Stream 只推送已经在大多数节点上提交的变更操作。即“可重复读”的变更。
这个验证是通过{readConcern:"majority"}实现的。因此：

· 未开启majority readConcern的集群无法使用Change Stream;  

· 当集群无法满足{w:"majority"}时，不会触发Change Stream（例如PSA架构中的S因故宕机）。  

4. Change Stream 变更过滤
如果只对某些类型的变更事件感兴趣，可以使用聚合管道的过滤步骤过滤事件。
例如：
```
var cs = db.collection.watch([{
$match: {
operationType: {
$in: ['insert', 'delete']
}
}
}])
```
5. Change Stream 故障恢复
假设在一系列写入操作的过程中，订阅Change Stream的应用在接收到“写3”之后于t0时刻崩溃，重启后后续的变更怎么办？
[!qr](./images/026_t_1.png)
想要从上次中断的地方继续获取变更流，只需要保留上次变更通知中的_id即可。
右侧所示是一次Change Stream回调所返回的数据。每条这样的数据都带有一个_id,这个_id可以用于断点恢复。例如：

var cs = db.collection.watch(\[\],{resumeAfter:<\_id>})  
即可从上一条通知中断处继续获取后续的变更通知。  

6. Change Stream 使用场景
· 跨集群的变更复制——在源集群中订阅Change Stream, 一旦得到任何变更立即写入目标集群。

· 微服务联动——当一个微服务变更数据库时，其他微服务得到通知并做出响应的变更。  

· 其他任何需要联动的场景。