Java 메시징 및 대기열 시스템에서 지속성을 사용하는 경우

Question

(Java) 메시징에 대한 무역 연구를 수행 중입니다. & 주요 웹 응용 프로그램의 백엔드 프레임 워크를 곧 다시 설계하기위한 대기열 시스템 (Amazon EC2 Cloud에서 , x-large 인스턴스). 나는 현재 ActiveMQ와 RabbitMQ를 평가 중이다.

계획에는 5 개의 다른 대기열이 있으며 하나는 데드 - 레터 대기열입니다. 하루에 보내는 메시지 수는 40K ~ 400K 사이입니다. 메시지 내용이 데이터 저장소의 XML 파일 위치에 대한 포인터가 될 계획이므로 메시지는 약 64 바이트가 될 것으로 예상합니다. 그러나 평가를 위해 평균 파일 크기가 3KB 인 원시 XML을 메시지에 보내고 싶습니다.

내 주요 질문 : 매일 얼마나 지속되어야하는 메시지가 언제/얼마나 지속되어야합니까? 위에서 지정한 금액을 고려하여 모든 메시지를 유지하는 것이 합리적입니까? 지속성이 성능을 떨어 뜨린다는 것을 알고 있습니다. 그러나 유지하지 않으면 많은 RAM이 사용되고 있습니다. 여러분 중 일부는 무엇을 추천합니까?

또한 ActiveMQ (JMS) vs RabbitMQ (AMQP)와 관련하여 많은 온라인 정보가 있음을 알고 있습니다. 나는 수많은 연구와 테스트를 해왔다. 두 가지 구현이 내 필요에 맞을 것으로 보인다. 위에 제공된 정보 (파일 크기 및 메시지 수)를 고려해 볼 때 내가 놓친 특정 공급 업체를 사용하는 이유를 누구나 지적 할 수 있습니까?

감사합니다.

Answer 1

일일 기준으로 얼마나 많은 메시지를 보존해야합니까? 위에 표시된 금액 인 을 고려하여 모든 메시지를 유지하려면 이 합리적입니까?

JMS 지속성은 데이터베이스를 대체하지 않으므로 데이터 생성자와 생성자 사이의 수명이 짧은 버퍼로 간주되어야합니다. 즉, 언급 한 메시지의 볼륨/크기는 현대 JMS 시스템의 지속성 어댑터에 세금을 부과하지 않고 (필요에 따라 확장 된 기간 동안 메시지를 버퍼링하는 데 사용될 수 있음)

지속성이 성능을 저하시킬 수 있음을 알고 있습니다. 그러나 지속하지 않으면 많은 RAM이 사용되고 있습니다. 무엇을 추천할까요?

제 경험상, 메시지 지속성은 중요한 성능 저하가 아니며 거의 항상 메시지를 보장하기 위해 수행됩니다. 대부분의 응용 프로그램에서 프로세스 업스트림 (생산자) 또는 다운 스트림 (소비자)은 병목 현상 (특히 데이터베이스 I/O)이됩니다 ...하지 JMS 나는 온라인 RabbitMQ (AMQP) 대 의 ActiveMQ (JMS)에 대한 많은 정보가 있다는 것을 알고, 또한 저장

지속성. 나는 많은 연구를했으며 테스트를 마쳤습니다. 두 가지 구현이 내 필요에 맞을 것으로 보인다. 위의 정보 (파일 크기 및 메시지 수 : )를 고려해 볼 때 내가 놓친 특정 공급 업체 을 사용하는 이유를 누구나 지적 할 수 있습니까?

저 볼륨 및 고 볼륨 메시징 모두에 대해 많은 프로젝트에서 ActiveMQ를 성공적으로 사용했습니다. Apache Camel 같은 라우팅 엔진과 함께 사용하는 것이 좋습니다. integration 및 complex routing patterns

Answer 2

메시징 시스템은 임시 저장소로 사용해야합니다. 응용 프로그램은 가능한 빨리 메시지를 가져 오도록 설계되어야합니다. 메시지 수가 많을수록 성능이 떨어집니다. 메시지를 가져 오는 경우 메모리 사용량은 줄이면서 성능은 향상됩니다. 성능 향상을 위해 메시지가 메모리에 보관되므로 영구 또는 비 메모리가 계속 사용되는지 여부는 메시지 유형이 영구적 인 경우에만 디스크에 백업됩니다.

메시지 지속성에 대한 결정은 메시지가 얼마나 중요한지와 메시징 공급자가 다시 시작될 때까지 지속되어야하는지 여부에 따라 결정됩니다.

IBM WebSphere MQ를 살펴볼 수 있습니다. 그것은 귀하의 요구 사항을 충족시킬 수 있습니다. JMS는 물론 애플리케이션 개발을위한 독점적 인 API를 가지고 있습니다.

Answer 3

ActiveMQ는 TIBCO EMS 또는 Solace가 권장하는 더 비싼 오픈 소스 JMS에 적합한 선택입니다.

그러나 JMS는 실제로 한 번만 배달되도록 만들어졌으며 더 이상 지속성이 사양에서 벗어났습니다. 당연히 데이터베이스에 갈 수도 있지만 무게가 크고 비싸기도합니다.

(참고 : 저는 CodeStreet에서 일합니다) 우리의 'ReplayService for JMS'입니다. 고성능 파일 기반 디스크 저장 영역에 모든 유형의 JMS 메시지 (또는 기본 WebSphere MQ 메시지)를 저장합니다. 각 메시지에는 발행시에 겹쳐 쓸 수있는 nanosecond 타임 스탬프와 globalMsgID가 자동으로 할당됩니다. 따라서 XML 메시지는 ReplayServer에 의해 기록 될 수 있으며 실제 메시지에는 globalMsgID가 참조로 포함될 수 있습니다. 어쩌면 일부 속성?

수신자가 globalMsgID를 받으면 필요하면 ReplayServer에서 해당 메시지를 재생할 수 있습니다.

그러나 400K * 3KB XML 메시지는 ActiveMQ 등에서 쉽게 처리 할 수 ​​있어야합니다. 또한 보내기 전에 XML 메시지를 압축해야합니다.