切换Event Hub处理Function App后为何从epoch 0开始读取？

核心原因 #

你的问题本质是租赁锁未正确释放+Function版本间租赁格式兼容性导致的：

• 仅禁用旧App的函数，旧App的宿主进程可能仍在后台运行，持续持有Event Hub分区的租赁锁，新App无法接管现有租赁，只能初始化新的epoch（从0开始读取）。
• Functions 1.x和4.x的Event Hub触发器租赁存储格式存在差异，即使共享同一存储账户，旧App的租赁信息可能无法被新App直接识别，除非旧App完全释放租赁。

解决方案 #

1. 必须完全停止旧Function App（而非仅禁用函数） #

仅禁用函数无法彻底终止旧App的宿主进程，进程会继续维持租赁锁。完全停止旧App会：

• 立即终止所有运行中的进程
• 释放对Event Hub所有分区的租赁锁
• 让新App能够正常获取并延续原有的消费位置

2. 确保两个App共享同一租赁存储账户 #

检查新App的AzureWebJobsStorage配置（Event Hub触发器默认使用此存储保存租赁），必须和旧App使用同一个存储账户。如果存储账户不同，新App无法读取旧App的消费位置记录，只能从头开始。

3. 安全切换的操作流程 #

1. 在Azure门户中找到旧Function App，执行停止操作（不要仅禁用函数）
2. 等待5-10分钟，确保旧App的所有进程已退出，租赁锁完全释放
3. 启用新App的Event Hub触发器函数并启动新App
4. 查看新App的运行日志，确认消费起始偏移量是旧App停止时的位置，而非epoch 0

4. 极端情况的补救措施 #

如果按上述步骤操作后，新App仍从epoch 0开始读取：

• 可以手动删除存储账户中对应消费组的租赁容器（容器名称通常以azure-webjobs-eventhub-开头），删除后新App会从Event Hub的最新位置开始消费，避免全量重复处理
• 注意：此操作会丢失之前的消费位置记录，仅在确认旧App不再使用时执行

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