확장 가능한 메시지 큐 아키텍처 설계

최근에 확장 가능한 엔터프라이즈 컴퓨터 아키텍처의 뉘앙스를 배우기 시작했으며 중앙 구성 요소 중 하나가 메시징 대기열입니다. 모든 프로그래밍 패러다임에서 최대한 많은 것을 배우기 위해 자체 버전의 메시징 대기열 서비스를 구현하려고합니다.

지금까지 초기 디자인은 스레드 소켓 리스너에서 실행되지만 두 개의 개별 처리 노드에서 동일한 메시지가 두 번 다운로드되는 것을 방지하기 위해 읽기가 시작될 때 메시지 큐 색인 레지스터가 잠기고 레지스터가 완료된 후 잠금이 해제됩니다 업데이트되었습니다. 따라서 이는 스레드 될 필요성을 없애고 메시징 큐 서비스가 실행중인 서버의 처리 속도에 따라 확장 가능한 시스템의 크기에 한계가 있음을 의미합니다.

이를 해결하는 방법은 여러 서버에서 메시지 큐 서비스를 실행하는 것이지만 동일한 메시지가 두 번 다운로드 될 가능성이 높아집니다. 이러한 문제가 발생하지 않도록하는 유일한 방법은 서버 또는 단일 서버의 스레드가 정보를 동기화 한 후 이러한 재발급을 감지 한 후 처리 노드에서 중지하도록 명령 취소 콜백을 포함하는 것입니다. 현재 작업을 수행하고 다음 메시지에 대한 메시지 큐를 다시 쿼리하지만 다시 전송되는 트래픽의 대부분이 동기화 및 취소 콜백으로 인해 병목 현상이 발생하고 정보 처리 속도가 느려질 수 있습니다. 많은 처리 노드가 널 작업을 수행하고 시간을 낭비하고 있습니다.

이 문제를 해결할 수있는 마지막 방법은 각 메시지 대기열 서버 (및 각 서버의 각 스레드)가 대기열의 위치와 관련하여 특정 오프셋을 갖도록하는 것입니다. 특히 특정 순서로 처리해야 할 경우 응용 프로그램 유형.

그렇다면 기존 엔터프라이즈 급 메시지 대기열 서비스가 이러한 문제를 어떻게 피할 수 있는지 보여줄 수있는 메시지 대기열 아키텍처 디자인이 있습니까?

한마디로 :

이것은 어려운 문제입니다. 바퀴를 재발 명하지 마십시오.

메시지 큐 계층을 해결하는 많은 기술이 있습니다. 그들은 포함

• ZeroMQ
• RabbitMQ
• 아파치 카프카
• BLPOP 또는 PUBSUB와 함께 Redis (이 작업을 수행하는 방법을 여기에 요청 했습니다 ).
• RabbitMQ 이외의 다른 AMQP 구현

나는이 기침 을하는 전문 지식을 토끼 기침을 사용 하지 않는다고 실제로 주장하지 않기 때문에 각각의 단점을 논의하는 것이 범위를 벗어난 것이라고 생각합니다 .

이러한 기술을 사용하고 싶지 않더라도 해당 설명서를 읽으십시오.

이것은 하나의 시스템에서 가능한 디자인 패턴에 대해 교육합니다. ZeroMQ의 설명서를 읽으면 우아하게 구현 된 많은 고전적인 메시지 큐 아키텍처에 대해 알 수 있습니다. ZeroMQ를 사용하지 않더라도 이러한 패턴을 알면 해당 패턴을 구현할 수 있는지 묻는 다른 대기열 기술을 평가하는 데 도움이됩니다.

RabbitMQ / AMQP의 교환 대기열 모델에 대해 알아보십시오. 라우팅은 당신을 위해 올 수 있습니다-이것은 Redis PUBSUB에 의해 지원되지만 ZeroMQ에 의해 지원되는 것을 기억하지 못합니다-팬 아웃은 Memcached 설문 조사 (yuck!)를 통해 제대로 구현되지는 않았지만 내 상점에서 사용하고있는 것입니다. .

하나를 선택하는 방법?

SLA가 웹 응용 프로그램에 전형적인 신생 기업에서 근무합니다. 데이터 손실이 거의없이 서비스를 신속하게 복원 할 수있는 한 일부 중단은 가능합니다. 트위터 나 텀블러와 같은 스케일링 문제에 대해서는 생각할 필요가 없었으므로, 실제로 처리량에 대해서는 생각할 필요가 없었습니다. 말하자면, SLA와 유사한 SLA를 구현하는 경우 다음 고려 사항이 고려됩니다.

• 클라이언트 라이브러리가 실제로 작동 합니까? 연결을 유지하는 것이 쉬운가? (ZeroMQ, Redis : 예. RabbitMQ : 아니요).
• 서버 콘솔에서 모니터링 및 관리가 용이합니까? (Redis : 예, RabbitMQ : 예, ZeroMQ : 기억하지는 않지만 오랫동안 사용하지 않았습니다)
• 클라이언트가 내부 대기열을 지원하므로 중단시 데이터 손실이 거의 발생하지 않습니까? (ZeroMQ, Redis : 예. RabbitMQ : 아니요)

물론, 당신이 고주파 거래소를 위해 일하고 있다면, 이들은 당신의 덜 걱정할 것입니다. 결국 처리량을 높이는 대신 클라이언트 측 라이브러리에 개발 시간을 더 투자 할 의향이 있습니다. 그러나 저는 이 기술이 기본 기능이 아닌 성능을 기준으로 마케팅하는 경향이 있음을 경고하기 위해 더 많이 쓰고 있습니다. 웹 스타트 업인 경우 전자보다 후자에 훨씬 더 관심이 있으며 따라서 Redis와 같은 것은 우수한 성능에서의 사용 편의성보다 우수한 성능의 사용 편의성에 더 최적화되어있을 것입니다. RabbitMQ보다 더 나은 선택입니다. (정말 RabbitMQ를 좋아하지 않습니다).