读取 Azure Cosmos DB 更改源
适用范围：
NoSQL
可以使用推送模型或拉取模型来处理 Azure Cosmos DB 更改源。 使用推送模型时，更改源处理器会将工作推送到具有用于处理此工作的业务逻辑的客户端。 但是，在检查工作以及存储上次已处理工作的状态时，所遇到的复杂情况将在更改源处理器中进行处理。
使用拉取模型时，客户端必须从服务器拉取工作。 在这种情况下，客户端不仅具有用于处理工作的业务逻辑，而且还存储上次已处理工作的状态，在并行处理工作的多个客户端上处理负载均衡，并且处理错误。
从 Azure Cosmos DB 更改源读取时，我们通常建议使用推送模型，因为这样就无需考虑以下事项：
- 在更改源中轮询以后的更改。
- 存储上次已处理更改的状态。 如果从更改源处理器进行读取，则状态会自动存储在租约容器中。
- 在使用更改的多个客户端之间进行负载均衡。 例如，如果某个客户端无法赶上处理更改的进度，而另一个客户端具有可用的容量。
- 处理错误。 例如，在代码中出现未经处理的异常或者发生暂时性网络问题后，自动重试未正确处理的已失败更改。
使用 Azure Cosmos DB 更改源的大多数方案都会使用推送模型选项之一。 但在某些情况下，你可能想要对拉取模型进行更低级别的控制。 其中包括：
- 从特定的分区键读取更改
- 控制客户端接收要处理的更改的速度
- 对更改源中的现有数据执行一次性读取（例如，执行数据迁移）
使用推送模型读取更改源
使用推送模型是从更改源读取数据的最简单方法。 可以通过两种方式从推送模型读取更改源：Azure Functions Azure Cosmos DB 触发器和更改源处理器。 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 配合使用。
更改源处理器库
更改源处理器库可让你更好地控制更改源，同时还能消除大部分复杂性。 更改源处理器库遵循观察程序模式，在此模式中，处理函数由库调用。 更改源处理器将自动检查更改，如果找到更改，则将这些更改“推送”到客户端。 如果有高吞吐量的更改源，可以实例化多个客户端来读取更改源。 更改源处理器自动在不同客户端之间划分负载。 你不需要实现任何用于在多个客户端之间进行负载均衡的逻辑，或者任何用于维护租约状态的逻辑。
更改源处理器保证传递所有更改“至少一次”。 换言之，如果你使用更改源处理器，系统会针对更改源中的每个项成功调用处理函数。 如果处理函数中的业务逻辑发生未经处理的异常，则会不断重试已失败的更改，直到成功处理这些更改。 若要防止更改源处理器陷入不断重试相同更改的状态，请在处理函数中添加逻辑，以便在出现异常时将文档写入死信队列。 详细了解错误处理。
在 Azure Functions 中，有关如何处理错误的建议是相同的。 仍应在委托代码中添加逻辑，以便在出现异常时将文档写入死信队列。 但是，如果 Azure 函数中发生未经处理的异常，系统不会自动重试生成异常的更改。 如果业务逻辑中发生未经处理的异常，Azure 函数会继续处理下一项更改。 Azure 函数不会重试相同的已失败更改。
与使用 Azure Functions 时一样，使用更改源处理器库进行开发也很简单。 但是，你要负责为更改源处理器部署一个或多个主机。 主机是使用更改源处理器侦听更改的应用程序实例。 尽管 Azure Functions 提供自动缩放功能，但你要负责缩放你的主机。 有关详细信息，请参阅使用更改源处理器。 更改源处理器库是 Azure Cosmos DB SDK V3 的一部分。
使用拉取模型读取更改源
更改源拉取模型可让你按自己的步调使用更改源。 更改必须由客户端请求，系统不会自动轮询更改。 若要将上次已处理的更改永久“加入书签”（类似于推送模型的租约容器），需要保存一个继续标记。
使用更改源拉取模型可以对更改源进行更低级别的控制。 使用拉取模型读取更改源时，有三个选项：
- 读取整个容器的更改
- 读取特定 FeedRange 的更改
- 读取特定分区键值的更改
就像使用更改源处理器时一样，可以在多个客户端之间并行化更改处理操作。 但是，拉取模型不会自动处理客户端之间的负载均衡。 使用拉取模型并行化更改源的处理时，首先需要获取 FeedRange 列表。 FeedRange 跨越一系列分区键值。 需要通过一个业务流程协调程序进程来获取 FeedRange 并在计算机之间分配这些 FeedRange。 然后，可以使用这些 FeedRange 让多台计算机并行读取更改源。
拉取模型不提供内置的“至少一次”传递保证。 拉取模型允许进行较低级别的控制，可让你确定如何处理错误。
适用于 Cassandra 和 MongoDB 的 API 中的更改源
在 API for MongoDB 中，更改源功能显示为更改流；在 API for Cassandra 中，它是以包含谓词的查询形式提供的。 若要详细了解 API for MongoDB 的实现细节，请参阅 Azure Cosmos DB for MongoDB 中的更改流。
本机 Apache Cassandra 提供变更数据捕获 (CDC)。CDC 是一种机制，用于标记要存档的特定表，并在达到 CDC 日志的可配置磁盘空间时拒绝写入这些表。 Azure Cosmos DB for Apache Cassandra 中的更改源功能增强了通过 CQL 使用谓词查询更改的能力。 若要详细了解实现细节，请参阅 Azure Cosmos DB for Apache Cassandra 中的更改源。
后续步骤
现在，可以通过以下文章继续详细了解更改源：