Azure Service Bus延迟消息并保留送达计数的可行方案咨询

目前针对你描述的场景，仍然没有原生的原子性延迟重试机制能同时保留送达计数并避免重复消息，不过相比2016年的方案，现在有更成熟的实践方式，核心依然围绕自定义属性优化实现：

• 保留送达计数的延迟重试流程：

  1. 不直接完成原消息，而是为其添加自定义属性，比如x-retry-attempts（记录重试次数）、x-next-retry-time（标记下次执行时间）
  2. 调用Defer()方法暂存消息，而非放弃或完成原消息
  3. 单独部署定时任务（比如Azure Functions Timer Trigger），定期查询队列中被延迟的消息，检查x-next-retry-time是否到达，若到达则通过ReceiveDeferredMessageAsync取出消息重新处理

• 规避原子性问题：
  所有操作（添加自定义属性+延迟消息）必须在同一个消息锁的有效期内完成，因为Defer()是原子操作，只要锁未过期就不会出现消息重复或丢失。如果锁过期前未完成操作，消息会自动回到队列，此时可通过自定义的重试次数属性判断是否需要重新处理，避免无限循环。

如果使用Azure Service Bus Premium层，可结合Session功能实现更有序的延迟重试，但本质上仍需依赖自定义属性跟踪重试状态，原生延迟API依然无法解决保留原消息送达计数和原子性的痛点。

总结来说，当前原生机制仍未解决你提到的核心问题，基于自定义属性+延迟消息（Defer）的方案是最可靠的实践方式。

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