使用EventProcessorClient时出现404指定Blob不存在的问题求助

一、启动时Blob 404警告的原因 #

EventProcessorClient启动时，会自动去你的Azure存储容器中查找两类核心Blob：

• 检查点Blob：记录每个分区已处理到的事件偏移量
• 租赁Blob：负责分区负载均衡，避免多客户端重复消费

如果是首次启动、或是之前的Blob被手动删除/清理过，客户端会先尝试读取这些Blob，找不到就抛出404警告，随后自动创建新的Blob文件。这个是SDK的默认初始化逻辑——功能不受影响，但警告会每次启动都触发。

即便新建容器仍出现警告，大概率也是这个预检查逻辑导致的，并非配置错误。你可以通过两点验证：

• 启动客户端后查看存储容器，会自动生成以$Default（你的消费组名）开头的Blob路径，比如$Default/partition1/checkpoint这类文件
• 确认存储账户连接字符串、容器名配置正确，且客户端拥有容器的读写权限（权限不足会抛出403而非404）

二、Epoch冲突异常的原因与解决 #

这个异常和Blob警告无关，属于消费组的接收器冲突问题：

An exception occurred while receiving events for Event Hub. Error Message: 'At least one receiver for the endpoint is created with epoch of '0', and so non-epoch receiver is not allowed. Either reconnect with a higher epoch, or make sure all epoch receivers are closed or disconnected.

EventProcessorClient默认会用epoch锁（默认epoch值为0）抢占分区的独占消费权，确保同一消费组下仅一个客户端处理某分区。如果此时存在其他非epoch模式的接收器（比如：

• 旧的EventHubConsumerClient.ReadEventsAsync服务未彻底停止
• Azure IoT Hub门户的「内置终结点测试工具」仍在运行
• 其他服务使用同一$Default消费组且未启用epoch模式）

就会触发冲突。解决步骤：

1. 彻底关停所有使用$Default消费组的旧客户端、测试工具
2. 建议不要用$Default消费组跑生产代码，新建专属消费组（比如prod-consumer-group），避免和默认工具冲突
3. 若必须使用$Default，确保所有消费该组的客户端统一使用EventProcessorClient（即统一epoch模式），否则会出现重复消费或接收中断

三、总结 #

• Blob 404警告是SDK初始化的预检查行为，属于良性警告，不影响功能；若想消除，可尝试升级至最新版本的Azure.Messaging.EventHubs SDK（部分新版本优化了该警告触发逻辑）
• Epoch异常是真实的消费冲突，必须解决，否则会导致事件接收不稳定

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