ActiveMQ 클러스터링이있는 Apache Camel

Question

Servicemix 3.3.1/Camel 2.1/AMQ 5.3 응용 프로그램을 클러스터링하기위한 옵션을 결정하려고합니다. 대량의 메시지 처리를 수행하고 있으며 고 가용성과 수평 확장 성을 클러스터해야합니다.

다음은 기본적으로 내 응용 프로그램이하는 일입니다 ... http-> queue-> process-> database-> topic

( "Jetty :http://0.0.0.0/inbound") .to ("ActiveMq : Inboundqueue ");

( "ActiveMq : Inboundqueue? maxConcurrentConsumers = 50") .Process (decode ()) .process (transfer ()) .process (validate ()) .process ( "activemq : topic : ouboundtopic"). );

그래서 나는 모든 servicemix와 acitvemq 클러스터링 페이지를 읽었지만 여전히 어떤 방법으로 갈지 확실하지 않습니다.

HA에 마스터/슬레이브 설정을 사용할 수는 있지만 확장성에 도움이되지 않습니다.

브로커 네트워크에 대해 읽었지만 이것이 어떻게 적용되는지 잘 모르겠습니다. 예를 들어, 클러스터의 여러 노드에 동일한 낙타 경로를 배포하면 정확히 "상호 작용"하는 방법은 무엇입니까? HTTP 프로듀서가 One Node (NODEA)에서 지적하면 NODEB로 어떤 메시지가 전송됩니까? 노드 A/B간에 대기열/주제가 공유됩니까? 그렇다면 메시지가 분할되거나 복제되는 방법은 무엇입니까? 또한 외부 클라이언트가 내 "아웃 바운드 픽"을 정확히 구독하는 방법 (및 모든 메시지를받는 등)은 어떻게 구독합니까?

또는 여러 Servicemix 인스턴스간에 중개인을 공유해야한다고 생각했습니다. 관리 할 대기열/주제 세트가 하나만 있고 더 많은 인스턴스를 추가하여 확장 할 수 있다는 점에서 더 깨끗합니다. 그러나 이제 나는 단일 브로커의 확장 성으로 제한되어 있으며 단일 실패 지점으로 돌아 왔습니다 ...

누군가 나에게 상충 관계를 명확히 할 수 있다면 ... 감사합니다.

Answer 1

ServiceMix/Camel/ActiveMQ를 사용할 때 확장 할 수있는 여러 가지 전략이 있습니다. 각 소프트웨어는 많은 옵션을 제공하기 때문에 앱의 일부 부분이 확장 해야하는 부분에 따라 취할 수있는 다양한 경로가 있습니다. 아래는 몇 가지 전략의 높은 수준의 목록입니다.

• 인바운드 부두 인스턴스의 수를 늘리십시오. 이는 웹 서버의 더 많은 인스턴스를 시작하고 여러 인스턴스에서 요청을로드 밸런싱 요청을하거나 여러 URL을 노출시키고 모든 요청을 ActiveMQ에서 동일한 인바운드 큐로 전송해야합니다.

• ActiveMQ 인스턴스 수를 늘리십시오 - 추가 ActiveMQ 인스턴스를 시작하고 함께 네트워킹하여 브로커 네트워크를 만들어냅니다. 일부 서클에서는 네트워크의 모든 브로커에서 주어진 대기열을 사용할 수 있기 때문에 이것은 이것을 분산 대기열이라고합니다. 그러나 여러 개의 ActiveMQ 인스턴스를 시작하려면 Servicemix의 추가 인스턴스를 시작하는 것이 좋습니다.

• ServiceMix 인스턴스의 수를 늘리십시오 - Servicemix의 각 인스턴스는 ActivemQ의 인스턴스를 포함합니다. ServiceMix 인스턴스 수를 늘리면 ActiveMQ 인스턴스의 수를 늘릴뿐만 아니라 (브로커 네트워크를 형성하기 위해 네트워크로 연결할 수 있음) 이러한 Servicemix 인스턴스에 더 많은 응용 프로그램 사본을 배포 할 수 있습니다. . ActiveMQ 또는 Servicemix 인스턴스 수를 늘려야하는 경우 각 인스턴스에 대해 적절한 양의 동시 소비자로 소비 애플리케이션을 배포 할 수 있습니다. 메시지는 분할되거나 복제되지 않으며 소비자 수요에 따라 위치에 상관없이 대기열의 모든 소비자에게 라운드 로빈 방식으로 배포됩니다. 즉, 네트워크의 ActiveMQ 인스턴스에 소비자가 없으면 소비 할 큐 인스턴스에 메시지가 없습니다. 이것은 나의 마지막 제안으로 이어지고, 인바운드 대기열을 폴링하는 소비자의 수를 늘립니다.

• 인바운드 대기열에서 JMS 소비자의 수를 늘리십시오. 이는 아마도 처리량을 늘리는 가장 쉽고 강력하며 관리하기 쉬운 방법 일 것입니다. 소비 애플리케이션의 추가 인스턴스를 배포하여 인바운드 큐의 메시지와 경쟁 할 수 있도록 가장 쉬운 일입니다 (로컬 큐와 경쟁하는지 또는 브로커 네트워크를 통해 배포되는 대기열에 관계없이). 이는 동시 소비자의 수를 늘리거나 소비자를 포함하는 애플리케이션의 일부를 분할하여이를 많은 Servicemix 인스턴스에 배포함으로써 조금 더 관여하는 것만 큼 간단 할 수 있습니다. 일반적으로 어렵지 않기 때문에 가장 강력합니다. 스케일링 이벤트 구동 응용 프로그램은 항상 소비자 수를 늘려서 수행됩니다. 소비 애플리케이션이 전적으로 분리되어 배포 할 수있는 능력을 제공 할 수 있도록 응용 프로그램이 포장되는 방식을 변경할 수 있기 때문에 가장 관리하기 쉽습니다.

이 마지막 제안은 응용 프로그램을 확장하는 가장 강력한 방법입니다. 들어오는 HTTP 엔드 포인트가 많은 양의 트래픽을 처리 할 수있는 한 인바운드 대기열의 소비자 만 늘릴 필요가 있습니다. 이를 수행하는 가장 큰 이유는 소비자 또는 그들이 물러나는 콩이 모든 무거운 리프팅, 주요 처리 및 검증을 수행하기 때문입니다. 일반적 으로이 과정은 궁극적으로 가장 많은 리소스가 필요합니다.

바라건대 이것은 실제로 앱의 일부를 실제로 확장 해야하는 앱의 일부에 따라 한 방향으로 가기 시작하는 데 필요한 정보를 제공합니다. 궁금한 점이 있으면 알려주십시오.

브루스