获取mongodb数据变更_MongoDB 变更流（Change Stream）介绍

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, 一旦得到任何变更立即写入目标集群。

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

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