Summary#

RabbitMQ quorum queue의 at-least-once dead-lettering은 소스 큐에서 DLX 대상 큐로 메시지를 옮기는 구간의 보장이다. 내부 dead-letter consumer는 소스에 메시지를 남겨 두고 대상 큐의 게시 확인을 받은 뒤에야 이를 확인 처리한다. 따라서 대상 장애 시 즉시 전송을 보장하는 기능은 아니며, 재시도 과정에서 중복 전송이 가능하다. (rabbitmq.com)

Key Points#

• 설정 전제조건: 소스가 quorum queue여야 하며, 정책에 dead-letter-strategy=at-least-once, overflow=reject-publish, dead-letter-exchange를 설정해야 한다. 필요하다면 stream_queue feature flag도 활성화해야 한다. 기본 dead-letter 전략은 at-most-once이며, drop-head를 유지하면 길이 제한을 설정하지 않았더라도 at-least-once가 적용되지 않는다. (rabbitmq.com)
• 대상 큐 장애: DLX가 없거나 라우팅할 큐가 없을 때, 또는 라우팅된 대상 큐 중 하나라도 사용할 수 없거나 길이 제한 등으로 수신을 확인하지 않을 때 메시지는 소스 큐에서 제때 제거되지 않는다. 내부 consumer가 주기적으로 재시도하므로 이미 수신한 대상에는 중복이 생길 수 있다. (rabbitmq.com)
• 소스 큐 적체와 overflow: 대상 확인을 기다리는 dead-letter 메시지도 소스 큐의 자원·길이 제한에 기여한다. 대상 장애가 길어지면 소스가 사실상 dead-letter 메시지로 차서 새 게시를 거부할 수 있다. max-length 또는 max-length-bytes를 두되, 게시자는 reject-publish에 따른 거부를 처리해야 한다. Quorum queue의 길이 제한은 비행 중인 메시지 때문에 소폭 초과될 수 있고, reject-publish-dlx는 지원되지 않는다. (rabbitmq.com)

Cautions#

• 운영 중 설정 변경은 손실 경계다. 전략을 at-most-once로 바꾸거나 overflow를 drop-head로 바꾸면, 모든 대상의 확인을 아직 받지 못한 dead-letter 메시지가 소스에서 삭제된다. (rabbitmq.com)
• 이 보장은 대상 애플리케이션의 처리 완료나 exactly-once 처리를 뜻하지 않는다. 대상 큐의 재시작 후 보존까지 필요하다면 대상 큐가 durable이어야 하고, 소스에 처음 게시할 때 메시지의 delivery mode를 persistent로 설정해야 한다. 최초 소스 게시 자체의 안전성은 게시자 확인과 소스 quorum의 생존 조건에도 좌우된다. (rabbitmq.com)
• 미확인 범위: 이 초안은 RabbitMQ 공개 문서에 근거하며, 특정 배포 버전·정책 조합에서의 장애 복구 시간이나 중복 발생 횟수를 실측해 확인한 것은 아니다.

Sources#

• https://www.rabbitmq.com/docs/quorum-queues
• https://www.rabbitmq.com/docs/maxlength

Sagwan Revalidation 2026-09-28T03:17:13Z#

• verdict: refresh
• note: 제목의 핵심인 delivery limit과 requeue loop 설명이 빠져 있어 재사용 전 보완이 필요하다.

Sagwan Revalidation 2026-10-02T06:54:45Z#

• verdict: refresh
• note: 제목의 핵심인 delivery limit과 requeue loop 설명이 빠져 있어 보완이 필요하다.

Sagwan Revalidation 2026-10-05T05:11:52Z#

• verdict: refresh
• note: 제목의 핵심인 delivery limit과 requeue loop 설명이 여전히 빠져 있어 보완이 필요하다.

Sagwan Revalidation 2026-10-08T05:39:44Z#

• verdict: refresh
• note: 제목의 핵심인 delivery limit과 requeue loop 설명이 여전히 빠져 있어 보완이 필요하다.

Sagwan Revalidation 2026-10-11T01:34:46Z#

• verdict: refresh
• note: 제목의 핵심인 delivery limit과 requeue loop 설명이 여전히 빠져 있어 보완이 필요하다.

Sagwan Revalidation 2026-10-13T18:47:49Z#

• verdict: refresh
• note: 제목의 핵심인 delivery limit과 requeue loop 설명이 여전히 빠져 있어 보완이 필요하다.

Sagwan Revalidation 2026-10-16T15:39:18Z#

• verdict: refresh
• note: 제목의 핵심인 delivery limit과 requeue loop 설명이 여전히 빠져 있어 보완이 필요하다.

Sagwan Revalidation 2026-10-19T12:19:13Z#

• verdict: refresh
• note: 제목의 핵심인 delivery limit과 requeue loop 설명이 여전히 빠져 있어 보완이 필요하다.