在版本 4 中，MongoDB 更改流可以使用两个不同的参数来指定恢复更改流的位置:resumeAfter(一些内部标记)和 startAtOperationTime，一种时间戳类型。
是否可以通过使用在每个更改事件中找到的 resumeAfter 来完全用 startAtOperationTime 替换 clusterTime 以安全恢复更改流？
我特别关心的是我在文档中找不到确切信息的地方是 startAtOperationTime 是否有相同的规则和保证适用于可以恢复的内容以及持续多长时间。此处使用的操作时间是否正确持久化，是否可以始终用作通常用于 resumeAfter 的文档 token 的替代品？
最佳答案
使用这两者中的哪一个，取决于您的用例。
resumeAfter 和 startAtOperationTime 两个选项非常相似，但有细微差别:
startAtOperationTime 需要一个时间戳。而 resumeAfter 获取 Change Stream 事件文档的整个 _id。 startAtOperationTime 可以通过创建新的更改流在 invalidate event 之后恢复通知。虽然 resumeAfter 在无效事件关闭流后无法恢复更改流。 startAtOperationTime 恢复 在 指定时间戳或之后发生的更改。虽然 resumeAfter 在 提供的 token 之后立即恢复更改 。 无论您选择哪一个， token 或时间戳都应在 Replica Set Oplog 窗口时间内。变更流依赖于与分布式
oplog 同步的 MongoDB 全局逻辑时钟(集群时间)，因此任一选项都使用相同的底层技术。值得注意的是，如果您想开始观看集合并处理集合中的现有条目，您可以使用构造的时间戳指定
startAtOperationTime。使用 resumeAfter 会更难做到这一点，因为它需要一个源自事件的 _id 的 token 。此外，MongoDB v4.2 中新增了一个新选项
startAfter，它从事件中获取 _id，并在恢复 token 中指定的操作后恢复更改流。此外，它允许通知在无效事件之后恢复，就像 startAtOperationTime 一样。您可能还会发现 MongoDB 版本上的 compatibility table between resume tokens 很有用
关于mongodb - MongoDB 更改流中 resumeAfter 和 startAtOperationTime 之间的区别，我们在Stack Overflow上找到一个类似的问题：https://stackoverflow.com/questions/55184492/