Cosmos Change Feed Processor推送模型实则为轮询？技术问询

你观察到的情况没错：Change Feed Processor 底层确实是基于轮询机制实现的，但文档却称其为“推送模型”，核心差异在于视角的不同——底层实现是拉取逻辑，但对外暴露的编程模型是推送体验。

先看官方文档描述：

With a push model, the change feed processor pushes work to a client that has business logic for processing this work. However, the complexity in checking for work and storing state for the last processed work is handled within the change feed processor.

你梳理的库生命周期逻辑也完全准确：

1. Read the change feed.
2. If there are no changes, sleep for a predefined amount of time (customizable with WithPollInterval in the Builder) and go to #1.
3. If there are changes, send them to the delegate.
4. When the delegate finishes processing the changes successfully, update the lease store with the latest processed point in time and go to #1.

针对你的疑问逐一解答：

1. 你的理解完全正确：只有当前委托线程处理完变更并成功更新 lease 后，Processor 才会进入下一轮的变更拉取/轮询流程。
2. 为什么叫推送模型而非拉取模型？
   • 这是从开发者的使用视角定义的：作为开发者，你不需要自己编写轮询逻辑、维护最后处理位置、管理分片与 lease 这些复杂操作——所有底层的拉取、状态追踪、重试逻辑都被封装在 Change Feed Processor 内部。
   • 你只需要提供处理变更的业务逻辑（委托方法），Processor 会主动将获取到的变更“推”给你的处理逻辑，对你来说就像是变更主动上门，而非你主动去拉取。
   • 对比纯拉取模型：如果是纯拉取方案，你得自己定期调用 Cosmos API 拉取变更、手动记录处理位置、处理失败重试、甚至要实现分片负载均衡，这些工作量巨大。而 Change Feed Processor 把这些繁琐细节都接管了，对外呈现出“推送”的简洁体验。

简单总结：底层实现是拉取（轮询），但对外暴露的编程模型是推送——这是封装带来的体验差异。

内容的提问来源于stack exchange，提问作者Arunim Chopra