Tại sao sử dụng AMQP/ZeroMQ/RabbitMQ

Question

như trái ngược với việc viết thư viện của riêng bạn.

Chúng tôi đang làm việc trên một dự án ở đây sẽ là một nhóm máy chủ tự phân chia, nếu một phần phát triển quá nặng, người quản lý sẽ chia nó và đặt nó trên một máy khác như một quá trình riêng biệt. Nó cũng sẽ cảnh báo tất cả các máy khách kết nối này ảnh hưởng đến kết nối đến máy chủ mới.

Tôi tò mò về việc sử dụng ZeroMQ cho liên lạc giữa các máy chủ và liên ngành. Đối tác của tôi muốn cuộn của riêng mình. Tôi đang tìm đến cộng đồng để trả lời câu hỏi này.

Tôi là một lập trình viên khá mới mẻ và đã học về hàng đợi tin nhắn. Như tôi đã googled và đọc, có vẻ như tất cả mọi người đang sử dụng hàng đợi tin nhắn cho tất cả các loại của sự vật, nhưng tại sao? Điều gì làm cho chúng tốt hơn là viết thư viện của riêng bạn? Tại sao chúng quá phổ biến và tại sao lại có quá nhiều?

Answer 1

điều gì làm cho chúng tốt hơn là viết thư viện của riêng bạn?

Khi tung ra phiên bản đầu tiên của ứng dụng của bạn, có lẽ không có gì: nhu cầu của bạn được xác định rõ ràng và bạn sẽ phát triển một hệ thống tin nhắn đó sẽ phù hợp với nhu cầu của bạn: danh sách tính năng nhỏ, mã nguồn nhỏ vv

Các công cụ này là rất hữu ích sau bản phát hành đầu tiên, khi bạn thực sự phải mở rộng ứng dụng của mình và thêm nhiều tính năng khác cho ứng dụng đó. Hãy để tôi cung cấp cho bạn một vài trường hợp sử dụng:

• ứng dụng của bạn sẽ phải nói chuyện với một máy big endian (sparc/powerpc) từ một máy little endian (x86, Intel/AMD). Hệ thống nhắn tin của bạn có một số giả định đặt hàng cuối cùng: đi và sửa nó
• bạn đã thiết kế ứng dụng của mình sao cho nó không phải là hệ thống giao thức/nhắn tin nhị phân và bây giờ nó rất chậm vì bạn dành phần lớn thời gian của mình để phân tích cú pháp. tăng và phân tích cú pháp trở thành nút cổ chai): thích ứng với nó để nó có thể chuyển mã nhị phân/cố định

• lúc đầu bạn có 3 máy bên trong lan, không có sự chậm trễ đáng kể.client/boss/pointy-haired-devil-boss của bạn xuất hiện và cho bạn biết rằng bạn sẽ cài đặt ứng dụng trên WAN mà bạn không quản lý - và sau đó bạn bắt đầu gặp lỗi kết nối, độ trễ xấu, v.v. bạn cần lưu trữ tin nhắn và thử gửi lại sau này: quay lại mã và cắm công cụ này vào (và tận hưởng)

• thư được gửi cần phải có câu trả lời, nhưng không phải tất cả chúng: bạn gửi một số tham số và mong đợi bảng tính thay vì chỉ cần gửi và thừa nhận, quay lại mã và cắm công cụ này vào (và tận hưởng.)

• một số thư quan trọng và việc tiếp nhận/gửi cần sao lưu/kiên trì thích hợp /. Lý do tại sao bạn hỏi ? mục đích kiểm tra

Và nhiều trường hợp sử dụng khác mà tôi quên ...

Bạn có thể thực hiện nó cho mình, nhưng không dành nhiều thời gian làm như vậy: có thể bạn sẽ thay thế nó sau này anyway.

Answer 2

điều gì làm cho chúng tốt hơn là viết thư viện của riêng bạn?

Hệ thống xếp hàng thư là giao dịch, dễ sử dụng về mặt khái niệm với tư cách khách hàng, nhưng khó có được quyền làm người triển khai, đặc biệt là xem xét hàng đợi liên tục. Bạn có thể nghĩ rằng bạn có thể lấy đi bằng cách viết một thư viện nhắn tin nhanh, nhưng không có giao dịch và sự kiên trì, bạn sẽ không có đầy đủ lợi ích của một hệ thống nhắn tin.

Tính bền vững trong ngữ cảnh này có nghĩa là phần mềm trung gian nhắn tin giữ các thư không được lưu trữ trong bộ nhớ vĩnh viễn (trên đĩa) trong trường hợp máy chủ bị hỏng; sau khi khởi động lại, các tin nhắn có thể được xử lý và không cần truyền lại (người gửi thậm chí không biết có vấn đề gì). Giao dịch có nghĩa là bạn có thể đọc tin nhắn từ các hàng đợi khác nhau và viết tin nhắn đến các hàng đợi khác nhau theo cách giao dịch, có nghĩa là tất cả các lần đọc và viết thành công hoặc (nếu một hoặc nhiều lỗi) không thành công. Điều này không thực sự khác nhiều so với giao dịch được biết đến từ giao tiếp với cơ sở dữ liệu và có cùng lợi ích (nó đơn giản hóa việc xử lý lỗi; không có giao dịch, bạn phải đảm bảo rằng mỗi thành viên đọc/ghi thành công và nếu một hoặc nhiều thất bại, bạn có để khôi phục những thay đổi đó đã thành công).

Answer 3

Điều đó rất giống với yêu cầu: tại sao lại sử dụng cơ sở dữ liệu khi bạn có thể tự viết?

Câu trả lời là sử dụng công cụ đã được sử dụng trong một thời gian và được hiểu rõ trong nhiều trường hợp sử dụng khác nhau, trả tiền nhiều hơn và nhiều hơn theo thời gian và yêu cầu của bạn phát triển. Điều này đặc biệt đúng nếu có nhiều hơn một nhà phát triển tham gia vào một dự án. Bạn có muốn trở thành nhân viên hỗ trợ cho một hệ thống xếp hàng nếu bạn thay đổi một dự án mới? Sử dụng một công cụ ngăn chặn điều đó xảy ra. Nó trở thành vấn đề của người khác.

Trường hợp tại điểm: kiên trì. Viết một công cụ để lưu trữ một tin nhắn trên đĩa rất dễ dàng. Viết một persistor có tỷ lệ và hoạt động tốt và ổn định, trong nhiều trường hợp sử dụng khác nhau, và có thể quản lý và giá rẻ để hỗ trợ, rất khó. Nếu bạn muốn xem ai đó phàn nàn về việc khó khăn như thế nào thì hãy xem xét điều này: http://www.lshift.net/blog/2009/12/07/rabbitmq-at-the-skills-matter-functional-programming-exchange

Dù sao, tôi hy vọng điều này sẽ hữu ích. Bằng mọi cách, hãy viết công cụ của riêng bạn. Nhiều người đã làm như vậy. Bất cứ điều gì giải quyết vấn đề của bạn, là tốt.

Answer 4

Tôi đang xem xét sử dụng ZeroMQ bản thân mình - do đó tôi tình cờ gặp phải câu hỏi này.

Hãy giả sử cho thời điểm bạn có khả năng triển khai hệ thống xếp hàng thư đáp ứng tất cả các yêu cầu của bạn. Tại sao bạn sẽ áp dụng ZeroMQ (hoặc thư viện bên thứ ba khác) theo cách tiếp cận của chính bạn? Đơn giản - chi phí.

Giả sử trong một khoảnh khắc ZeroMQ đã đáp ứng tất cả các yêu cầu của bạn. Tất cả những gì cần phải được thực hiện là tích hợp nó vào xây dựng của bạn, đọc một số doco và sau đó bắt đầu sử dụng nó. Đó là nỗ lực ít hơn nhiều so với việc lăn của riêng bạn. Thêm vào đó, gánh nặng bảo trì đã được chuyển sang một công ty khác. Vì ZeroMQ là miễn phí, nó giống như bạn vừa phát triển đội ngũ phát triển của mình để bao gồm (một phần) nhóm ZeroMQ.

Nếu bạn điều hành một doanh nghiệp phát triển phần mềm, tôi nghĩ rằng bạn sẽ cân bằng chi phí/rủi ro khi sử dụng thư viện của bên thứ ba để tự mình triển khai và trong trường hợp này, sử dụng ZeroMQ sẽ thắng tay.

Có lẽ bạn (hoặc đúng hơn là đối tác của bạn) phải chịu đựng, như rất nhiều nhà phát triển thực hiện, từ hội chứng "Not Invented Here"? Nếu vậy, hãy điều chỉnh thái độ của bạn và đánh giá lại việc sử dụng ZeroMQ. Cá nhân, tôi rất thích những lợi ích của thái độ tự hào được tìm thấy ở nơi khác. Tôi hy vọng tôi có thể tự hào về việc tìm kiếm ZeroMQ ... thời gian sẽ nói.

EDIT: Tôi đã xem qua số này video từ các nhà phát triển ZeroMQ nói về lý do tại sao bạn nên sử dụng ZeroMQ.

Answer 5

Nếu bạn có một chút thời gian để thử và triển khai quá trình thực hiện của riêng bạn! Các bài học của bài tập này sẽ thuyết phục bạn về sự khôn ngoan của việc sử dụng một thư viện đã được kiểm tra.

Answer 6

Trước khi viết thư viện riêng của bạn, đọc Hướng dẫn 0MQ đây: http://zguide.zeromq.org/page:all

Rất có thể rằng bạn sẽ hoặc quyết định cài đặt RabbitMQ, nếu không bạn sẽ làm cho thư viện của bạn trên đầu trang của ZeroMQ vì họ đã làm tất cả các phần cứng.