ActiveMQ 또는 RabbitMQ 또는 ZeroMQ 또는 [닫힘]

우리는 ActiveMQ vs RabbitMQ vs ZeroMQ의 장단점에 대한 경험을 듣고 싶습니다. 다른 흥미로운 메시지 대기열에 대한 정보도 환영합니다.

편집 : 내 초기 답변은 AMQP에 중점을 두었습니다. 나는 주제에 대한 더 넓은 견해를 제공하기 위해 다시 작성하기로 결정했습니다.

이 3 가지 메시징 기술은 분산 시스템 구축에 대해 서로 다른 접근 방식을 가지고 있습니다

RabbitMQ 는 AMQP 프로토콜의 주요 구현 중 하나입니다 (Apache Qpid와 함께). 따라서 브로커 아키텍처를 구현합니다. 즉, 클라이언트로 메시지를 보내기 전에 중앙 노드에서 메시지가 대기됩니다. 라우팅,로드 밸런싱 또는 지속적인 메시지 큐잉과 같은 고급 시나리오가 단 몇 줄의 코드로 지원되므로이 접근 방식을 통해 RabbitMQ는 사용 및 배포가 매우 쉽습니다. 그러나 중앙 노드가 대기 시간을 추가하고 메시지 엔벨로프가 상당히 크기 때문에 확장 성과 속도가 느려집니다.

ZeroMq 는 금융 분야에서 볼 수있는 것과 같은 높은 처리량 / 낮은 대기 시간 시나리오를 위해 특별히 설계된 매우 가벼운 메시징 시스템입니다. Zmq는 많은 고급 메시징 시나리오를 지원하지만 RabbitMQ와 달리 다양한 프레임 워크 (예 : 소켓 및 장치)를 결합하여 직접 구현해야합니다. Zmq는 매우 유연하지만 메시지를 보내는 것보다 복잡한 작업을 수행하기 전에 80 페이지 정도의 안내서 (Zmq를 사용하지 않더라도 분산 시스템을 작성하는 사람이라면 누구나 읽을 것을 권장합니다)를 공부해야합니다. 2 명의 동료 사이.

ActiveMQ 는 중간에 있습니다. Zmq와 마찬가지로 브로커 및 P2P 토폴로지와 함께 배포 할 수 있습니다. RabbitMQ와 마찬가지로 고급 시나리오를 구현하는 것이 쉽지만 일반적으로 원시 성능을 희생합니다. 메시징의 스위스 군용 칼입니다 :-).

마지막으로 3 가지 제품 모두 :

• 가장 일반적인 언어 (C ++, Java, .Net, Python, Php, Ruby 등)에 대한 클라이언트 API가 있습니다.
• 문서가 강력하다
• 적극적으로 지원됩니다

왜 Sparrow , Starling , Kestrel , Amazon SQS , Beanstalkd , Kafka , IronMQ를 그리워 했습니까?

메시지 대기열 서버

메시지 대기열 서버는 Erlang (RabbitMQ), C (beanstalkd), Ruby (Starling 또는 Sparrow), Scala (Kestrel, Kafka) 또는 Java (ActiveMQ) 등 다양한 언어로 제공됩니다. 간단한 개요는 여기 에서 찾을 수 있습니다

참새

• Alex MacCaw 작성
• Sparrow는 Ruby로 작성된 가벼운 대기열로 "memcache"입니다.

찌르레기

• Blaine Cook이 트위터에 작성
• Starling은 MemCached를 기반으로하는 Message Queue 서버입니다
• 루비로 작성
• 작업을 메모리에 저장 (메시지 큐)
• 문서 : 좋은 튜토리얼, 예를 들어 starling 및 workling에 대한 railscast 또는 starling에 대한이 블로그 게시물

황조롱이

• Robey Pointer 작성
• 스칼라로 작성된 Starling 복제본 (Ruby에서 Scala로 Starling 포트)
• 큐는 메모리에 저장되지만 디스크에 기록됩니다

RabbitMQ

• RabbitMQ는 Erlang의 Message Queue 서버입니다
• 작업을 메모리에 저장 (메시지 큐)

아파치 액티브 MQ

• ActiveMQ는 Java의 오픈 소스 메시지 브로커입니다.

콩 줄기

• Philotic, Inc.가 Facebook 응용 프로그램의 응답 시간을 개선하기 위해 작성
• 주로 C로 작성된 인 메모리 워크 큐 서비스
• 문서 : http://nubyonrails.com/articles/about-this-blog-beanstalk-messaging-queue

아마존 SQS

• 아마존 단순 대기열 서비스

카프카

• 스칼라에서 링크드 인에 작성
• LinkedIn에서 모든 페이지 및 기타보기의 처리를 오프로드하는 데 사용
• 기본적으로 지속성을 사용하고 핫 데이터에 OS 디스크 캐시를 사용합니다 (위의 지속성이 활성화 된 것보다 처리량이 더 높음)
• 오프라인 처리로 온라인을 모두 지원

ZMQ

• 동시성 프레임 워크 역할을하는 소켓 라이브러리
• 클러스터 제품 및 슈퍼 컴퓨팅을 위해 TCP보다 빠름
• inproc, IPC, TCP 및 멀티 캐스트를 통한 메시지 전달
• 팬 아웃, pubsub, 파이프 라인, 요청-응답을 통해 N-to-N 연결
• 확장 가능한 멀티 코어 메시지 전달 앱을위한 비동기 I / O

EagleMQ

• EagleMQ 는 개방형 소스, 고성능 및 경량 큐 관리자입니다.
• C로 작성
• 모든 데이터를 메모리에 저장하고 지속성을 지원합니다.
• 자체 프로토콜이 있습니다. 대기열, 경로 및 채널 작업을 지원합니다.

IronMQ

• IronMQ
• 집필
• 완전 관리 큐 서비스
• 클라우드 버전 및 온 프레미스로 모두 사용 가능

이것이 도움이 되길 바랍니다. 출처

알고 싶은 것보다 더 많은 정보 :

http://wiki.secondlife.com/wiki/Message_Queue_Evaluation_Notes

최신 정보

바울이 댓글에 추가 한 내용을 자세히 설명하면됩니다. 위에서 언급 한 문서는 2010 년 이후, 그래서 소금 한 스푼 읽을 죽었어요. 3 년 동안 많은 것들이 바뀌 었습니다.

실제로 사용 사례에 따라 다릅니다.

0MQ와 ActiveMQ 또는 RabbitMQ를 비교하는 것은 공평하지 않습니다. ActiveMQ 및 RabbitMQ는 설치 및 관리가 필요한 메시징 시스템입니다. 이들은 ZeroMQ보다 훨씬 많은 기능을 제공합니다. 그들은 실제 영구 대기열, 트랜잭션 지원 등을 가지고 있습니다.

ZeroMQ는 경량 메시지 지향 소켓 구현입니다. 또한 프로세스 내 비동기 프로그래밍에도 적합합니다. ZeroMQ를 통해 "엔터프라이즈 메시징 시스템"을 실행할 수는 있지만 스스로 구현해야합니다.

그래서:

ActiveMQ, RabbitMQ, Websphere MQ 및 MSMQ는 "Enterprise Message Queues"입니다

ZeroMQ는 메시지 지향 IPC 라이브러리입니다.

RabbitMQ와 ActiveMQ는 여기에 비교되어 있습니다 . 기본적으로 ActiveMQ는 메시지 전달을 보장하도록 구성되어 덜 안정적인 메시징 시스템에 비해 느리게 인상을 줄 수 있습니다. 다른 메시징 시스템과 같은 성능을 원할 경우 언제든지 성능 구성을 변경할 수 있습니다. 최소한 그 옵션이 있습니다. 확장 성, 성능 및 고 가용성 구성에 대한 포럼 및 ActiveMQ FAQ에 대한 많은 정보가 있습니다. 또한 STOMP와 같은 다른 와이어 형식과 함께 사양이 완성되면 ActiveMQ는 AMQP 1.0을 지원합니다.

ActiveMQ의 또 다른 장점은 Apache 프로젝트이므로 개발자 커뮤니티에는 다양성이 있으며 한 회사와 관련이 없습니다.

ActiveMQ 또는 RabbitMQ를 사용하지 않았지만 ZeroMQ를 사용했습니다. ZeroMQ와 ActiveMQ 등의 큰 차이점은 0MQ는 브로커가 없으며 메시지 전달에 대한 신뢰도가 없다는 것입니다. 많은 메시징 패턴, 스포츠, 플랫폼 및 언어 바인딩을 지원하는 사용하기 쉬운 메시징 API를 찾고 있다면 0MQ를 살펴볼 가치가 있습니다. 완전한 메시징 플랫폼을 찾고 있다면 0MQ가 청구서에 맞지 않을 수 있습니다.

0MQ 사용 방법에 대한 예는 www.zeromq.org/docs:cookbook 을 참조하십시오 .

전기 사용량 모니터링 애플리케이션에서 메시지 전달에 0MQ를 성공적으로 사용했습니다 ( http://rwscott.co.uk/2010/06/14/currentcost-envi-cc128-part-1/ 참조 ).

zeroMQ를 사용하고 있습니다. 간단한 메시지 전달 시스템을 원했고 브로커의 복잡성이 필요하지 않습니다. 또한 거대한 Java 지향 엔터프라이즈 시스템을 원하지 않습니다.

빠르고 간단한 시스템을 원하고 여러 언어를 지원해야하는 경우 (C 및 .net 사용) 0MQ를 참조하십시오.

ActiveMQ에 대해서는 2 센트 만 추가 할 수 있지만 이것이 가장 인기있는 것 중 하나이므로

쓰려는 언어가 중요 할 수 있습니다. ActiveMQ에는 대부분 클라이언트가 있지만 C # 구현은 Java 라이브러리와 비교할 때 완전하지 않습니다.

이것은 일부 기본 기능에 결함이 있음을 의미합니다 (일부 경우 실패, 재전송 지원 없음). .NET이 프로젝트에 중요한 것은 아니기 때문에 개발 속도가 느리고 릴리스 계획이없는 것 같습니다. 트렁크는 종종 고장이 나기 때문에 이것을 고려한다면, 계속 진행하고 싶다면 프로젝트에 기여하는 것을 고려할 수 있습니다.

그런 다음 ActiveMQ 자체에는 많은 멋진 기능이 있지만 매우 이상한 문제가 있습니다. 안정성을 위해 Fuse (Progress) 버전의 activemq를 사용하지만 몇 가지 이상한 "버그"가 있습니다.

• 경우에 따라 메시지 전송을 중지하는 브로커
• 대기열을 작성하는 저널 오류로 인해 더 이상 존재하지 않는 메시지가 표시됩니다 (소비자에게 전달되지는 않지만 여전히)
• 우선 순위는 여전히 구현되지 않았습니다 (인간이 시작된 이후의 이슈 목록에 있음)
• 등

당신이 그 문제와 함께 살 수 있다면 그것은 아주 좋은 제품입니다.

A) .NET을 사용할 때 적극적으로 참여하는 것을 두려워하지 않습니다
.B) java에서 개발 ;-)

ZeroMQ는 실제로 대기열이 없습니다! 정말 실수입니다! 대기열, 주제, 지속성, 아무것도하지 않습니다! 소켓 API 전용 미들웨어입니다. 그것이 당신이 시원하고있는 것이라면! 그렇지 않으면 잊어 버리세요! activeMQ 또는 rabbitmq와 다릅니다.

http://bhavin.directi.com/rabbitmq-vs-apache-activemq-vs-apache-qpid/에 제공된 RabbitMQ ActiveMQ 및 QPID의 기능과 성능을 비교합니다.

개인적으로 위의 세 가지를 모두 시도했습니다. RabbitMQ는 나에게 가장 현명한 성능이지만 장애 조치 및 복구 옵션이 없습니다. ActiveMQ는 가장 많은 기능을 가지고 있지만 속도가 느립니다.

업데이트 : HornetQ 는 당신이 볼 수있는 옵션이며 JMS 기반 솔루션을 찾고 있다면 ActiveMQ보다 더 나은 옵션 인 JMS 불만입니다.

AMQP, Qpid 및 ZeroMQ에 대한 초기 경험에 대해 썼습니다 : http://ron.shoutboot.com/2010/09/25/is-ampq-for-you/

내 주관적인 의견은 AMQP가 지속적 메시징 기능이 정말로 필요하고 브로커가 병목 현상을 일으킬 염려가 없다면 괜찮다는 것입니다. 또한 C ++ 클라이언트는 현재 AMQP에 대해 누락되었지만 (Qpid는 내 지원을 얻지 못했지만 ActiveMQ 클라이언트에 대해서는 확실하지 않음) 진행중인 작업 일 수 있습니다. 그렇지 않으면 ZeroMQ가 될 수 있습니다.

현재 약 3 년 동안 프로덕션 환경에서 ActiveMQ를 사용해 왔습니다. 작업이 완료되는 동안 제대로 작동하고 버그가없는 클라이언트 라이브러리 버전을 정렬하는 것은 문제가 될 수 있습니다. 현재 RabbitMQ로 전환하려고합니다.

이 블로그 게시물 의 의견에서 Twitter가 자체 메시지 대기열을 작성하는 것에 대한 토론 이 있습니다.

Steve는 ActiveMQ, RabbitMQ 등의 광범위한로드 및 스트레스 테스트를 수행했습니다. ActiveMQ는 실제로 매우 느립니다 (Kestrel보다 훨씬 느림). RabbitMQ는 너무 많은 생산자와 너무 적은 소비자와 지속적으로 충돌합니다.

그러나 처음에는 트위터와 같은로드가 없을 것입니다 :)

ActiveMQ만큼 많은 튜닝 구성을 가진 응용 프로그램은 거의 없습니다. ActiveMQ를 두드러지게하는 일부 기능은 다음과 같습니다.

구성 가능한 프리 페치 크기. 구성 가능한 스레딩. 구성 가능한 장애 조치. 생산자에게 구성 가능한 관리 알림. ... 세부 사항 :

http://activemq.net/blog http://activemq.apache.org

Abie, 모두 유스 케이스에 달려 있습니다. 사용 사례에 대한 다른 사람의 계정에 의존하기보다는 사용 사례를 rabbitmq-discuss 목록에 자유롭게 게시하십시오. 트위터에 물어 보면 응답도받을 수 있습니다. 소원, 알렉시스

이미 알고 있듯이 ZeroMQ, 즉 0MQ에 관해서는 초 당 가장 많은 메시지를 얻는 메시지입니다 (마지막으로 확인했을 때 참조 서버에서 초당 약 4 백만 명 이었지만). 문서가 존재하지 않습니다. 서버를 사용하는 방법은 물론 서버를 시작하는 방법을 찾는 데 어려움을 겪을 것입니다. 나는 이것이 아직 아무도 0MQ에 기여하지 않은 이유라고 생각합니다.

즐기세요!

상용 구현에 관심이 있다면 내 채널 에서 너바나를 살펴보십시오 .

너바나는 금융 서비스 산업에서 대규모의 저 지연 거래 및 가격 분배 플랫폼에 많이 사용됩니다.

기업, 웹 및 모바일 도메인에서 광범위한 클라이언트 프로그래밍 언어가 지원됩니다.

투명한 HA 또는로드 밸런싱이 중요한 경우 클러스터링 기능은 매우 발전되어 있습니다.

열반은 개발 목적으로 무료로 다운로드 할 수 있습니다.