Azure Event Bus消息进入死信队列时长咨询（含重试策略测试场景）

Great question—this is a super common point of confusion when tuning retry policies for Azure Event Bus. Let’s break this down into two core scenarios, since that’s what you’re asking about:

1. Messages Dead-Lettered Due to Expiration #

If a message sits in a queue or topic subscription longer than its configured Time-To-Live (TTL) without being consumed, it will automatically move to the dead-letter queue.

• The default TTL for Event Bus messages is 14 days, but you can customize this per message or at the queue/topic level (down to 1 minute).
• For example: If you set a TTL of 5 minutes for a message, it will enter the DLQ exactly 5 minutes after being published if no consumer picks it up and completes it in that window.

2. Messages Dead-Lettered After Retry Failures #

This is where retry policies come into play. The total time until a message hits the DLQ depends on how you’ve configured retries (default vs. custom) and the behavior of your consumer.

Default Retry Behavior #

Out of the box, Azure Event Bus uses an exponential backoff retry strategy for failed message deliveries:

• It will retry up to 3 times by default.
• The retry intervals start at 1 second, then double each time: 1s → 2s → 4s.
• Total time before dead-lettering (excluding consumer processing time): ~7 seconds (1+2+4) from the first failed delivery attempt.

One important caveat here: This assumes your consumer throws an exception (or doesn’t complete the message) before the message lock expires. If your consumer holds the lock longer than the default 30-second MaxLockDuration, the lock will expire, and the message will be requeued even if no exception is thrown—this counts as a retry too. So if your processing logic takes 40 seconds, you’ll hit a lock expiration retry before any exception-based retries.

Custom Retry Policies #

If you’re using the SDK (like ServiceBusReceiver or EventProcessorClient in .NET) to define custom retry rules, you control the timeline entirely:

• Set MaxRetries to define how many times the message will be retried.
• Choose between fixed delays, exponential backoff, or even a custom retry pattern.
• Example: If you set MaxRetries=5 and a fixed RetryDelay=10s, the total time before dead-lettering would be roughly 5*10s = 50 seconds (plus whatever time your consumer spends processing the message each attempt).

Manual Dead-Lettering #

If your consumer explicitly calls DeadLetterAsync (for example, if it detects a message that can never be processed), the message moves to the DLQ immediately—no waiting for retries or expiration.

Quick Recap #

• TTL expiration: Time equals your configured TTL value (default 14 days).
• Retry failures: Total time = sum of all retry intervals + consumer processing time per attempt + lock expiration delays (if applicable), determined by your retry policy settings.
• Manual dead-lettering: Instantaneous.

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