4.19. 링 대기열 구성
일반적으로 AMQ Broker의 대기열은 first-in, first-out (FIFO) 의미 체계를 사용합니다. 즉, 브로커는 메시지를 큐의 테두리에 추가하고 헤드에서 제거합니다. 링 큐는 지정된 고정 메시지 수를 보유하는 특수한 유형의 큐입니다. 브로커는 새 메시지가 도착하지만 큐에 이미 지정된 메시지 수를 보유하면 큐의 헤드에서 메시지를 제거하여 고정된 대기열 크기를 유지합니다.
예를 들어, 크기 3
으로 구성된 링 대기열과 메시지 A
,B
,C
, D
를 순차적으로 전송하는 생산자가 있다고 가정합니다. C
메시지가 큐에 도달하면 큐의 메시지 수가 구성된 링 크기에 도달했습니다. 이 시점에서 메시지 A
는 큐의 헤드에 있고, 메시지 C
는 tail에 있습니다. 메시지 D
가 큐에 도달하면 브로커는 메시지를 큐의 tail에 추가합니다. 고정된 큐 크기를 유지하기 위해 브로커는 큐의 헤드에 있는 메시지를 제거합니다(즉, 메시지 A
). 이제 메시지 B
가 큐의 헤드에 있습니다.
4.19.1. 링 대기열 구성
다음 절차에서는 링 큐를 구성하는 방법을 보여줍니다.
절차
-
<
;broker_instance_dir> /etc/broker.xml
구성 파일을 엽니다. 명시적 링 크기 세트가 없는 일치하는 주소의 모든 큐에 대한 기본 링 크기를 정의하려면
address-setting
요소에서default-ring-size
의 값을 지정합니다. 예를 들면 다음과 같습니다.<address-settings> <address-setting match="ring.#"> <default-ring-size>3</default-ring-size> </address-setting> </address-settings>
default-ring-size
매개변수는 자동 생성된 대기열의 기본 크기를 정의하는 데 특히 유용합니다.default-ring-size
의 기본값은-1
입니다(즉, 크기 제한 없음).특정 큐에서 링 크기를 정의하려면
queue
요소에ring-size
키를 추가합니다. 값을 지정합니다. 예를 들면 다음과 같습니다.<addresses> <address name="myRing"> <anycast> <queue name="myRing" ring-size="5" /> </anycast> </address> </addresses>
브로커가 실행되는 동안 ring-size
의 값을 업데이트할 수 있습니다. 브로커가 업데이트를 동적으로 적용합니다. 새 ring-size
값이 이전 값보다 작으면 브로커는 새 크기를 적용하기 위해 대기열의 헤드에서 메시지를 즉시 삭제하지 않습니다. 큐로 전송된 새 메시지는 이전 메시지의 삭제 작업을 계속 수행하지만 대기열은 클라이언트의 정상적인 메시지 사용을 통해 당연히 그렇게 할 때까지 큐가 새로운 크기에 도달하지 않습니다.
4.19.2. 링 대기열 문제 해결
이 섹션에서는 링 큐의 동작이 구성과 다른 것으로 표시되는 상황을 설명합니다.
In-delivery messages and rollbacks
메시지가 소비자에게 전달 중일 때 메시지는 "중간" 상태에 있습니다. 여기서 메시지는 기술적으로 큐에서 더 이상 없지만 아직 승인되지 않았습니다. 메시지는 소비자가 승인할 때까지 전송 중 상태로 유지됩니다. in-delivery 상태에 남아 있는 메시지는 링 대기열에서 제거할 수 없습니다.
브로커가 전송 중인 메시지를 제거할 수 없기 때문에 클라이언트는 링 크기 구성에서 허용하는 것보다 링 큐에 더 많은 메시지를 보낼 수 있습니다. 예를 들어 다음 시나리오를 고려하십시오.
-
생산자는
ring-size="3"
로 구성된 링 큐에 세 개의 메시지를 보냅니다. 모든 메시지는 즉시 소비자에게 전달됩니다.
이 시점에서
messageCount
=3
및deliveringCount
=3
입니다.생산자는 또 다른 메시지를 큐에 보냅니다. 그런 다음 메시지가 소비자에게 전달됩니다.
이제
messageCount
=4
및deliveringCount
=4
입니다.4
의 메시지 수는 구성된 링 크기3
보다 큽니다. 그러나 브로커는 큐에서 전달 중인 메시지를 제거할 수 없기 때문에 이러한 상황을 허용할 수 있습니다.이제 소비자가 메시지를 승인하지 않고 닫히고 있다고 가정합니다.
이 경우 인증되지 않은 4개의 메시지가 브로커에 다시 취소되고 사용된 반대 순서로 큐 헤드에 추가됩니다. 이 작업은 구성된 링 크기에 큐를 둡니다. 링 대기열은 헤드의 메시지 위에 있는 큐의 tail의 메시지를 선호하므로 대기열은 대기열의 헤드에 다시 추가된 마지막 메시지가기 때문에 큐에서 보낸 첫 번째 메시지를 삭제합니다. 트랜잭션 또는 코어 세션 롤백은 동일한 방식으로 처리됩니다.
코어 클라이언트를 직접 사용하거나 AMQ Core Protocol JMS 클라이언트를 사용하는 경우 consumerWindowSize
매개변수(1024 * 1024바이트)의 값을 줄임으로써 전달 중인 메시지 수를 최소화할 수 있습니다.
예약된 메시지
예약된 메시지가 큐로 전송되면 일반 메시지와 같이 큐의 tail에 메시지가 즉시 추가되지 않습니다. 대신 브로커는 예약된 메시지를 중간 버퍼에 보관하고 메시지의 세부 정보에 따라 큐의 헤드로 전달할 메시지를 예약합니다. 그러나 예약된 메시지는 여전히 대기열의 메시지 수에 반영됩니다. in-delivery 메시지와 마찬가지로 이 동작은 브로커가 링 대기열 크기를 적용하지 않는 것처럼 보일 수 있습니다. 예를 들어 다음 시나리오를 고려하십시오.
12:00에서 생산자는
ring-size="3"
로 구성된 링 큐에A
라는 메시지를 보냅니다. 메시지가 12:05에 대해 예정되어 있습니다.이 시점에서
messageCount
=1
및scheduledCount
=1
.12:01에서 생산자는 메시지
B
를 동일한 링 대기열에 보냅니다.이제
messageCount
=2
및scheduledCount
=1
입니다.12:02에서 생산자는
C
메시지를 동일한 링 대기열에 보냅니다.이제
messageCount
=3
및scheduledCount
=1
입니다.12:03에서 생산자는 메시지를 동일한 링 대기열에 보냅니다.
이제
messageCount
=4
및scheduledCount
=1
입니다.큐의 메시지 수는 이제 구성된 링 크기인
3
개보다 1개 큰4
입니다. 그러나 예약된 메시지는 아직 큐에 기술적으로 표시되지 않습니다(즉, 브로커에 있으며 대기열에 배치되도록 예약됨). 예약된 제공 시간인 12:05에서 브로커는 큐의 헤드에 메시지를 넣습니다. 그러나 링 큐가 이미 구성된 크기에 도달했기 때문에 예약된 메시지A
가 즉시 제거됩니다.
페이징 메시지
예약된 메시지 및 전달 메시지와 유사하게 paged 메시지는 브로커가 시행하는 링 대기열 크기로 계산되지 않습니다. 메시지는 대기열 수준이 아닌 주소 수준에서 실제로 페이징되기 때문입니다. 호출된 메시지는 기술적으로 큐에 표시되지 않지만 큐의 messageCount
값에 반영됩니다.
링 큐가 있는 주소에는 페이징을 사용하지 않는 것이 좋습니다. 대신 전체 주소가 메모리에 적합할 수 있는지 확인합니다. 또는 address-full-policy
매개변수를 DROP
,BLOCK
또는 FAIL
값으로 구성합니다.
추가 리소스
- 브로커는 소급 주소를 구성할 때 링 대기열의 내부 인스턴스를 생성합니다. 자세한 내용은 4.20절. “retroactive 주소 구성” 에서 참조하십시오.