일관된 해시 교환으로 바인드 된 만료 된 큐의 치명적인 문자 메시지

Question

특정 소스와 관련된 이벤트를 처리하고 있습니다. 각 소스에는 해시로 사용할 수있는 키 또는 ID가 있습니다. 각 소스의 이벤트를 순서대로 처리해야하지만 수평 적 확장 성을 달성하려면 여러 소스의 이벤트를 병렬 처리 할 수 ​​있습니다. 수백 개의 소스 키가있을 것입니다.

메시지를 RabbitMQ에 제출할 때 라우팅 키의 일부로 키를 설정 한 다음 consistent-hash-exchange을 사용하여 동일한 출처의 이벤트가 동일한 큐로 라우팅되도록 할 계획입니다. 나는 TTL을 사용하여 소비자로부터 개인 큐를 동적으로 바인딩 할 생각을하고있었습니다 (소비자가 다운되면 정상적으로 제거되도록). 처음에는 이중화를 위해 2 ~ 3 명의 소비자를 보유하게 될 것이지만 증가 된 메시지 수로 인해 확장하려는 경우 다른 소비자를 시작할 수 있습니다.

소비자가 다운되어 대기열에 메시지가 있으면 어떻게됩니까? 이상적으로는 대기열의 메시지가 consistent-hash-exchange (다른 대기열에 라우팅 됨) (원래 대기열이 더 이상 존재하지 않으므로)으로 다시 라우팅되도록해야합니다.

약 dead lettering에 대한 RabbitMQ 설명서는 소비자 대기열의 TTL 시나리오 또는 대기열 삭제시 발생하는 상황을 명시 적으로 언급하지 않습니다.

내 접근 방식이 맞습니까? 특정 라우팅 키로 주문을 유지하면서 찾고있는 소비자 내결함성을 어떻게 얻을 수 있습니까?

참고 : 죽은 문자 메시지를 교환기로 라우팅하는 과정에서 원래 다른 대기열로 라우팅되는 만료 된 대기열로 라우팅 된 새 메시지가 나오면 더욱 경미한 경쟁 조건이 있다는 것을 알고 있습니다. 따라서 특정 인스턴스에서 순서가 끊어집니다.

Answer 1

여기에 답해야 할 질문이 하나 더 있습니다. 동일한 순서로 시도해 보겠습니다.

My question is what happens if a consumer is down and there are messages in its queue?
메시지의 외부 (질문의 나머지 부분) - 메시지는 ACK가 전송되거나 TTL이 만료 될 때까지 대기열에 남아 있습니다.

The RabbitMQ documentation about dead lettering doesn't explicitly mention the scenario of TTL on consumer queues, or what happens when the queue gets deleted.
그것은 은 메시지가 주어진 TTL 내에서 애크되지 않은 경우,이 DLX에의를 얻을 수 있도록 기본적으로 ...The TTL for the message expires... 말을한다. 큐 TTL의 경우 check this link - 기본적으로 큐의 "만료 시간"입니다. 또한 대기열이 삭제되면 메시지가 사라집니다 (물론 미러링을 고려하지 않은 경우).

"이제는 의미가 있습니까?" 서로 다른 출처의 메시지에 대해서는 분명합니다. 병렬 처리가 가능한만큼 처리해야합니다. 거기에는 충돌이 없습니다 (일반적으로 아니오).

순차 처리의 경우 기본적으로 정확히 하나의 소스를 필요로하는 하나의 소비자가 필요합니다. 이제이 소비자를 모니터링하기 위해 워치 독을 추가하여 충돌이 발생하면 다시 시작하거나, 응답이없는 경우 다시 시작하십시오. consume (amqp) 메서드 대신 get을 사용하는 것이 좋습니다. 적어도 (적어도 나를 위해) 상당히 유스 케이스 특정 (성능, 새로운 메시지 등이 얼마나 자주 있는지) 때문에이 방법을 권장하거나 권장하지는 못하지만, 그렇게하면 달성하기가 더 쉽다고 말할 수 있습니다. "더 동기적인"행동.

그리고 확실히 (지금 당신이 노트에 쓴 것을 참고하십시오) 실제로 시퀀스의 원래 순서를 유지하려면 DLX-ing 메시지 (높은 TTL 등)를 시도하고 피해야합니다. :))