适用范围：
NoSQL
可以使用推送模型或拉取模型来处理 Azure Cosmos DB 更改源。 使用 推送 模型时，更改源处理器会将工作推送到具有处理此工作的业务逻辑的客户端。 但是，在检查工作以及存储上次已处理工作的状态时，所遇到的复杂情况将在更改源处理器中进行处理。
使用 拉取 模型时，客户端必须从服务器拉取工作。 在这种情况下，客户端不仅具有处理工作的业务逻辑，还可用于存储上次处理工作的状态、并行处理多个客户端的负载均衡以及处理错误。
从 Azure Cosmos DB 更改源读取时，我们通常建议使用推送模型，因为无需担心：
- 在更改源中轮询以后的更改。
- 存储上次已处理更改的状态。 如果从更改馈送处理器中读取，状态将自动存储在 租约容器中。
- 在使用更改的多个客户端之间进行负载均衡。 例如，如果某个客户端无法赶上处理更改的进度，而另一个客户端具有可用的容量。
- 处理错误。 例如，在代码中出现未经处理的异常或者发生暂时性网络问题后，自动重试未正确处理的已失败更改。
使用 Azure Cosmos DB 更改馈送的大多数方案都采用推送模型选项之一。 但是，在某些情况下，你可能希望对拉取模型进行额外的低级别控制。 其中包括：
- 从特定分区键读取更改。
- 控制客户端接收更改的处理速度。
- 对更改提要中的现有数据进行一次性读取（例如，进行数据迁移）。
使用推送模型读取更改馈送
使用推送模型是从更改源读取数据的最简单方法。 可以通过两种方式使用推送模型从更改源数据流中读取：Azure Functions 触发器和更改源数据流处理器。 Azure Functions 在后台使用更改源处理器，因此这两种读取更改源的方式类似。 可将 Azure Functions 简单地视为更改源处理器的托管平台，两者并非完全不同的更改源读取方式。
Azure Functions
如果你对更改源还不太了解，则 Azure Functions 是最简单的选项。 由于其简易性，它也是大多数更改源用例的建议选项。 为 Azure Cosmos DB 创建 Azure Functions 触发器时，请选择要连接的容器，每当该容器中发生更改时，都会触发 Azure 函数。 由于 Azure Functions 在后台使用更改源处理器，因此它会自动在容器的分区之间并行化更改处理操作。
使用 Azure Functions 进行开发是一种简单体验，可能比在你自己的平台上部署更改源处理器更快。 可以使用 Azure Functions 门户或使用 SDK 以编程方式创建触发器。 Visual Studio 和 VS Code 支持编写 Azure 函数，你甚至可以使用 Azure Functions CLI 进行跨平台开发。 可以在桌面上编写和调试代码，然后一键式部署函数。 若要了解详细信息，请参阅使用 Azure Functions 的无服务器数据库计算和使用更改源与 Azure Functions。
更改源处理器库
支持的 SDK
| .NET V3 | Java | Node.JS | Python |
|---|---|---|---|
| ✓ | ✓ | ✕ | ✕ |
变更提要处理器可让你更好地控制变更提要，并且仍然隐藏大部分复杂性。 更改源处理器库遵循观察程序模式，在此模式中，处理函数由库调用。 更改源处理器会自动检查更改，如果检测到更改，将它们 推送 到客户端。 如果有高吞吐量的更改源，可以实例化多个客户端来读取更改源。 更改源处理器自动将负载划分到不同的客户端之间。 无需实现任何逻辑即可跨多个客户端进行负载均衡，也无需实现任何逻辑即可维护租约状态。
更改馈送处理器保证 至少一次 传递所有变更。 换句话说，如果您使用更改源处理器，则对于更改源中的每个项，处理函数都会被成功调用。 如果处理函数中的业务逻辑中存在未经处理的异常，则会重试失败的更改，直到成功处理这些更改。 为了防止更改源处理器在不断重试同样的更改时<出现问题>，请在处理函数中添加逻辑，在发生异常时，将文档写入死信队列。 若要了解详细信息，请参阅 错误处理。
在 Azure Functions 中，有关如何处理错误的建议是相同的。 仍应在委托代码中添加逻辑，以便在出现异常时将文档写入死信队列。 但是，如果 Azure 函数中存在未经处理的异常，则不会自动重试生成异常的更改。 如果业务逻辑中存在未经处理的异常，Azure 函数会继续处理下一个更改。 Azure 函数不会重试相同的失败更改。
与使用 Azure Functions 时一样，使用更改源处理器库进行开发也很简单。 但是，你要负责为更改源处理器部署一个或多个主机。 主机是使用更改源处理器侦听更改的应用程序实例。 尽管 Azure Functions 提供自动缩放功能，但你要负责缩放你的主机。 有关详细信息，请参阅使用更改源处理器。 更改源处理器库是 Azure Cosmos DB SDK V3 的一部分。
使用拉取模型读取更改源
更改源拉取模型可让你按自己的步调使用更改源。 更改必须由客户端请求，系统不会自动轮询更改。 如果要永久 标记 上次处理的更改（类似于推送模型的租约容器），则需要 保存延续令牌。
使用更改源拉取模型，可以更低级别的控制更改源。 使用拉取模型读取更改源时，有三个选项：
- 读取整个容器的更改。
- 读取特定 FeedRange 的更改。
- 读取特定分区键值的变化。
就像使用更改源处理器时一样，可以在多个客户端之间并行化更改处理操作。 但是，拉取模型不会自动处理客户端之间的负载均衡。 使用拉取模型并行化更改源的处理时，首先需要获取 FeedRange 列表。 FeedRange 跨越一系列分区键值。 你需要有一个协调器进程，用于获取 FeedRanges 并在机器之间分发它们。 然后，可以使用这些 FeedRange 让多台计算机并行读取更改源。
拉取模型没有内置的交付保证，不能确保至少交付一次。 拉取模型为你提供低级控制，让你能决定如何处理错误。
适用于 Cassandra 和 MongoDB 的 API 中的更改源
更改源功能在 MongoDB 的 API 中通过变更流显示，而在 Cassandra 的 API 中通过谓词进行查询。 若要详细了解用于 MongoDB 的 API 的实现详细信息，请参阅 Azure Cosmos DB 的用于 MongoDB 的 API 中的更改流。
本机 Apache Cassandra 提供变更数据捕获 (CDC)。CDC 是一种机制，用于标记要存档的特定表，并在达到 CDC 日志的可配置磁盘空间时拒绝写入这些表。 Azure Cosmos DB for Apache Cassandra 中的更改源功能增强了通过 CQL 使用谓词查询更改的能力。 若要详细了解实现细节，请参阅 Azure Cosmos DB for Apache Cassandra 中的更改源。