ActiveMQ hoặc RabbitMQ hoặc ZeroMQ hoặc [đã đóng]

Chúng tôi rất muốn nghe bất kỳ trải nghiệm nào với những ưu và nhược điểm của ActiveMQ vs RabbitMQ vs ZeroMQ. Thông tin về bất kỳ hàng đợi tin nhắn thú vị khác cũng được chào đón.

Chỉnh sửa: Câu trả lời ban đầu của tôi tập trung mạnh vào AMQP. Tôi quyết định viết lại nó để cung cấp một cái nhìn rộng hơn về chủ đề này.

3 công nghệ nhắn tin này có các cách tiếp cận khác nhau trong việc xây dựng các hệ thống phân tán:

RabbitMQ là một trong những triển khai hàng đầu của giao thức AMQP (cùng với Apache Qpid). Do đó, nó thực hiện một kiến ​​trúc môi giới, có nghĩa là các tin nhắn được xếp hàng trên một nút trung tâm trước khi được gửi đến máy khách. Cách tiếp cận này làm cho RabbitMQ rất dễ sử dụng và triển khai, bởi vì các kịch bản nâng cao như định tuyến, cân bằng tải hoặc xếp hàng tin nhắn liên tục được hỗ trợ chỉ trong một vài dòng mã. Tuy nhiên, nó cũng làm cho nó ít có khả năng mở rộng hơn và chậm hơn vì vì nút trung tâm thêm độ trễ và phong bì thư khá lớn.

ZeroMq là một hệ thống nhắn tin rất nhẹ được thiết kế đặc biệt cho các tình huống có thông lượng cao / độ trễ thấp giống như các tình huống bạn có thể tìm thấy trong thế giới tài chính. Zmq hỗ trợ nhiều kịch bản nhắn tin nâng cao nhưng trái với RabbitMQ, bạn sẽ phải tự thực hiện hầu hết chúng bằng cách kết hợp các phần khác nhau của khung (ví dụ: ổ cắm và thiết bị). Zmq rất linh hoạt nhưng bạn sẽ phải nghiên cứu 80 trang hoặc hướng dẫn (tôi khuyên bạn nên đọc cho bất kỳ ai viết hệ thống phân tán, ngay cả khi bạn không sử dụng Zmq) trước khi có thể làm bất cứ điều gì phức tạp hơn gửi tin nhắn giữa 2 đồng nghiệp.

ActiveMQ nằm ở giữa. Giống như Zmq, nó có thể được triển khai với cả cấu trúc liên kết môi giới và P2P. Giống như RabbitMQ, việc triển khai các kịch bản nâng cao dễ dàng hơn nhưng thường phải trả giá bằng hiệu năng thô. Đó là con dao nhắn tin của quân đội Thụy Sĩ :-).

Cuối cùng, cả 3 sản phẩm:

• có ứng dụng khách cho các ngôn ngữ phổ biến nhất (C ++, Java, .Net, Python, Php, Ruby, mật)
• có tài liệu mạnh
• được hỗ trợ tích cực

Tại sao bạn bỏ lỡ Sparrow , Starling , Kestrel , Amazon SQS , Beanstalkd , Kafka , IronMQ ?

Máy chủ xếp hàng tin nhắn

Máy chủ hàng đợi tin nhắn có sẵn bằng nhiều ngôn ngữ khác nhau, Erlang (RabbitMQ), C (beanstalkd), Ruby (Starling hoặc Sparrow), Scala (Kestrel, Kafka) hoặc Java (ActiveMQ). Một tổng quan ngắn có thể được tìm thấy ở đây

Chim sẻ

• được viết bởi Alex MacCaw
• Sparrow là một hàng đợi nhẹ được viết bằng Ruby mà Nói tiếng memcache

Starling

• được viết bởi Blaine Cook tại Twitter
• Starling là một máy chủ xếp hàng tin nhắn dựa trên MemCached
• viết bằng Ruby
• lưu trữ các công việc trong bộ nhớ (hàng đợi tin nhắn)
• tài liệu: một số hướng dẫn tốt, ví dụ như railscast về starling và workling hoặc blog này đăng về starling

Kestrel

• được viết bởi Robey Pulum
• Bản sao Starling được viết bằng Scala (một cảng của Starling từ Ruby đến Scala)
• Hàng đợi được lưu trong bộ nhớ, nhưng đăng nhập vào đĩa

ThỏMQ

• RabbitMQ là một máy chủ xếp hàng tin nhắn trong Erlang
• lưu trữ các công việc trong bộ nhớ (hàng đợi tin nhắn)

Hoạt động của Apache

• ActiveMQ là một nhà môi giới thông điệp mã nguồn mở trong Java

Đậu bắp

• được viết bởi Philotic, Inc. để cải thiện thời gian phản hồi của ứng dụng Facebook
• dịch vụ làm việc trong bộ nhớ chủ yếu được viết bằng C
• Tài liệu: http://nubyonrails.com/articles/about-this-blog-beanstalk-messaging-queue

Amazon SQS

• Dịch vụ xếp hàng đơn giản trên Amazon

Kafka

• Viết tại LinkedIn ở Scala
• Được sử dụng bởi LinkedIn để giảm tải xử lý tất cả các trang và các chế độ xem khác
• Mặc định cho việc sử dụng kiên trì, sử dụng bộ đệm đĩa hệ điều hành cho dữ liệu nóng (có thông lượng cao hơn sau đó bất kỳ tính năng nào ở trên có bật liên tục)
• Hỗ trợ cả trực tuyến khi xử lý ngoại tuyến

ZMQ

• Thư viện socket hoạt động như một khung đồng thời
• Nhanh hơn TCP, đối với các sản phẩm được phân cụm và siêu máy tính
• Mang thông điệp qua inproc, IPC, TCP và multicast
• Kết nối N-to-N qua fanout, pubsub, đường ống, yêu cầu trả lời
• Asynch I / O cho các ứng dụng truyền thông điệp đa lõi có thể mở rộng

EagleMQ

• EagleMQ là một trình quản lý hàng đợi mã nguồn mở, hiệu suất cao và nhẹ.
• Viết bằng C
• Lưu trữ tất cả dữ liệu trong bộ nhớ và hỗ trợ kiên trì.
• Nó có giao thức riêng của nó. Hỗ trợ làm việc với hàng đợi, tuyến đường và kênh.

SắtMQ

• SắtMQ
• Viết bằng cờ vây
• Dịch vụ xếp hàng được quản lý đầy đủ
• Có sẵn cả phiên bản đám mây và tại cơ sở

Tôi hy vọng rằng điều này sẽ hữu ích cho chúng tôi. nguồn

Nhiều thông tin hơn bạn muốn biết:

http://wiki.secondlife.com/wiki/Message_Queue_Evalval_Notes

CẬP NHẬT

Chỉ cần giải thích những gì Paul thêm vào trong bình luận. Các trang đề cập ở trên là đã chết sau năm 2010, vì vậy đọc với một nhúm muối. Rất nhiều thứ đã được thay đổi trong 3 năm.

Nó thực sự phụ thuộc vào trường hợp sử dụng của bạn.

So sánh 0MQ với ActiveMQ hoặc RabbitMQ là không công bằng. ActiveMQ và RabbitMQ là các Hệ thống Nhắn tin yêu cầu cài đặt và quản trị. Họ cung cấp featurewise nhiều hơn ZeroMQ. Họ có hàng đợi thực sự bền bỉ, Hỗ trợ cho các giao dịch, v.v.

ZeroMQ là một triển khai ổ cắm định hướng thông điệp nhẹ. Nó cũng thích hợp cho lập trình không đồng bộ trong quá trình. Có thể chạy "Hệ thống nhắn tin doanh nghiệp" trên ZeroMQ, nhưng bạn sẽ phải tự mình thực hiện rất nhiều.

Vì thế:

ActiveMQ, RabbitMQ, Websphere MQ & MSMQ là "Hàng đợi tin nhắn doanh nghiệp"

ZeroMQ là một Thư viện IPC định hướng thông điệp.

Có một so sánh giữa RabbitMQ và ActiveMQ ở đây . Ra khỏi hộp, ActiveMQ được cấu hình để đảm bảo gửi tin nhắn - có thể mang lại ấn tượng chậm so với các hệ thống nhắn tin kém tin cậy. Bạn luôn có thể thay đổi cấu hình cho hiệu suất nếu bạn muốn và có ít nhất hiệu năng tốt như bất kỳ hệ thống nhắn tin nào khác. Ít nhất bạn có tùy chọn đó. Có rất nhiều thông tin trên các diễn đàn và Câu hỏi thường gặp về ActiveMQ về cấu hình để nhân rộng, hiệu suất và tính sẵn sàng cao. Ngoài ra, ActiveMQ sẽ hỗ trợ AMQP 1.0 khi thông số kỹ thuật được hoàn thành, cùng với các định dạng dây khác, như STOMP.

Một điểm cộng nữa cho ActiveMQ là một dự án Apache, vì vậy có sự đa dạng trong cộng đồng nhà phát triển - và nó không bị ràng buộc với một công ty.

Tôi chưa sử dụng ActiveMQ hoặc RabbitMQ nhưng đã sử dụng ZeroMQ. Sự khác biệt lớn như tôi thấy giữa ZeroMQ và ActiveMQ, v.v. là 0MQ không có môi giới và không được xây dựng đáng tin cậy để gửi tin nhắn. Nếu bạn đang tìm kiếm một API nhắn tin dễ sử dụng hỗ trợ nhiều kiểu nhắn tin, vận chuyển, nền tảng và ràng buộc ngôn ngữ thì 0MQ chắc chắn đáng xem. Nếu bạn đang tìm kiếm một nền tảng nhắn tin đầy đủ thì 0MQ có thể không phù hợp với hóa đơn.

Xem www.zeromq.org/docs:cookbook để biết nhiều ví dụ về cách sử dụng 0MQ.

Tôi sử dụng thành công 0MQ để gửi tin nhắn trong ứng dụng theo dõi sử dụng điện (xem http://rwscott.co.uk/2010/06/14/ciencost-envi-cc128-part-1/ )

Tôi đang sử dụng zeroMQ. Tôi muốn một hệ thống chuyển tin nhắn đơn giản và tôi không cần sự phức tạp của một nhà môi giới. Tôi cũng không muốn có một hệ thống doanh nghiệp định hướng Java lớn.

Nếu bạn muốn có một hệ thống nhanh, đơn giản và bạn cần hỗ trợ nhiều ngôn ngữ (tôi sử dụng C và .net) thì tôi khuyên bạn nên xem 0MQ.

Tôi chỉ có thể thêm 2 xu của mình về ActiveMQ nhưng vì đây là một trong những phổ biến nhất:

Ngôn ngữ bạn muốn viết có thể quan trọng. Mặc dù ActiveMQ không có máy khách, nhưng việc triển khai C # của họ vẫn chưa hoàn thành so với Thư viện Java.

Điều này có nghĩa là một số chức năng cơ bản không ổn định (giao thức chuyển đổi dự phòng mà ... à ... không thành công trong một số trường hợp, không hỗ trợ giao hàng lại) và đơn giản là không có ở đó. Vì .NET dường như không quan trọng lắm đối với dự án, nên việc phát triển khá chậm và dường như không có bất kỳ kế hoạch phát hành nào. Thân cây thường bị hỏng nên nếu bạn xem xét điều này, bạn có thể muốn xem xét đóng góp cho dự án nếu bạn muốn mọi thứ đi trước.

Sau đó, có ActiveMQ có rất nhiều tính năng hay nhưng cũng có một số vấn đề rất lạ. Chúng tôi sử dụng phiên bản Fuse (Tiến trình) của activemq vì lý do ổn định nhưng thậm chí sau đó có một số "lỗi" kỳ lạ mà bạn muốn ghi nhớ:

• Các nhà môi giới ngừng gửi tin nhắn trong một số trường hợp
• Nhật ký Lỗi khiến hàng đợi hiển thị các tin nhắn không còn ở đó nữa (chúng không được gửi đến người tiêu dùng nhưng vẫn còn)
• Ưu tiên vẫn chưa được thực hiện (nằm trong danh sách Các vấn đề kể từ khi bắt đầu loại người)
• Vân vân.

Tất cả và tất cả, nó là một sản phẩm khá đẹp NẾU bạn có thể sống với các vấn đề của nó:

A) không ngại chủ động tham gia khi sử dụng .NET
B) phát triển trong java ;-)

ZeroMQ thực sự không có hàng đợi! Đó là một sai lầm thực sự! Nó không có hàng đợi, chủ đề, kiên trì, không có gì! Nó chỉ là một phần mềm trung gian cho API socket. Nếu đó là những gì bạn đang tìm kiếm mát mẻ! Nếu không thì quên nó đi! nó không giống như activeMQ hay rabbitmq.

Có một so sánh về các tính năng và hiệu suất của RabbitMQ ActiveMQ và QPID được đưa ra tại
http://bhavin.directi.com/rabbitmq-vs-apache-activemq-vs-apache-qpid/

Cá nhân tôi đã thử tất cả ba điều trên. RabbitMQ là hiệu suất tốt nhất theo tôi, nhưng nó không có tùy chọn chuyển đổi dự phòng và khôi phục. ActiveMQ có nhiều tính năng nhất, nhưng chậm hơn.

Cập nhật: HornetQ cũng là một tùy chọn bạn có thể xem xét, đó là Khiếu nại JMS, một tùy chọn tốt hơn ActiveMQ nếu bạn đang tìm kiếm một giải pháp dựa trên JMS.

Tôi đã viết về trải nghiệm ban đầu của mình về AMQP, Qpid và ZeroMQ tại đây: http://ron.shoutboot.com/2010/09/25/is-ampq-for-you/

Ý kiến ​​chủ quan của tôi là AMQP vẫn ổn nếu bạn thực sự cần các phương tiện nhắn tin liên tục và không quá lo lắng rằng nhà môi giới có thể là một nút cổ chai. Ngoài ra, ứng dụng khách C ++ hiện đang thiếu AMQP (Qpid không giành được sự hỗ trợ của tôi; tuy nhiên không chắc chắn về ứng dụng khách ActiveMQ), nhưng có thể đang hoạt động. ZeroMQ có thể là cách khác.

Tôi đã sử dụng ActiveMQ trong môi trường sản xuất khoảng 3 năm nay. Trong khi nó hoàn thành công việc, xếp hàng các phiên bản của thư viện khách hoạt động đúng và không có lỗi có thể là một vấn đề. Hiện đang tìm cách chuyển sang RabbitMQ.

Có một số cuộc thảo luận trong các bình luận của bài đăng trên blog này , về việc Twitter viết hàng đợi tin nhắn của riêng họ, điều này có thể thú vị.

Steve đã thực hiện kiểm tra tải trọng và căng thẳng trên ActiveMQ, RabbitMQ, v.v. ActiveMQ thực sự khá chậm (chậm hơn nhiều so với Kestrel), RabbitMQ liên tục gặp sự cố với quá nhiều nhà sản xuất và quá ít người tiêu dùng.

Bạn có thể sẽ không có tải giống như Twitter ban đầu :)

Rất ít ứng dụng có nhiều cấu hình điều chỉnh như ActiveMQ. Một số tính năng giúp ActiveMQ nổi bật là:

Cấu hình kích thước Prefetch. Cấu hình luồng. Cấu hình dự phòng. Thông báo hành chính cấu hình cho nhà sản xuất. ... chi tiết tại:

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

Abie, tất cả là do trường hợp sử dụng của bạn. Thay vì dựa vào tài khoản của người khác về trường hợp sử dụng của họ, vui lòng đăng trường hợp sử dụng của bạn lên danh sách thảo luận của thỏmq. Hỏi trên twitter cũng sẽ giúp bạn có một số phản hồi. Lời chúc tốt đẹp nhất

Về ZeroMQ hay còn gọi là 0MQ, như bạn có thể đã biết, đó là tin nhắn sẽ mang lại cho bạn nhiều tin nhắn nhất mỗi giây (chúng là khoảng 4 triệu mỗi giây trên máy chủ ref của họ lần trước tôi đã kiểm tra), nhưng như bạn cũng có thể đã biết, tài liệu là không tồn tại. Bạn sẽ có một thời gian khó khăn để tìm cách khởi động (các) máy chủ, chứ chưa nói đến cách sử dụng chúng. Tôi đoán đó là một phần lý do tại sao không ai đóng góp về 0MQ.

Chúc vui vẻ!

Nếu bạn cũng quan tâm đến việc triển khai thương mại, bạn nên xem Nirvana từ các kênh của tôi .

Nirvana được sử dụng nhiều trong ngành Dịch vụ Tài chính cho các nền tảng phân phối giá và giao dịch có độ trễ thấp quy mô lớn.

Có hỗ trợ cho một loạt các ngôn ngữ lập trình máy khách trên các lĩnh vực doanh nghiệp, web và di động.

Các khả năng phân cụm cực kỳ tiên tiến và đáng xem nếu HA trong suốt hoặc cân bằng tải là quan trọng đối với bạn.

Nirvana là miễn phí để tải về cho mục đích phát triển.