Thiết kế kiến ​​trúc hàng đợi tin nhắn có thể mở rộng

Gần đây tôi đã bắt đầu tìm hiểu các sắc thái của kiến ​​trúc máy tính doanh nghiệp và có thể mở rộng và một trong những thành phần trung tâm là hàng đợi nhắn tin. Để học được nhiều nhất có thể từ bất kỳ mô hình lập trình nào, tôi đang cố gắng thực hiện phiên bản dịch vụ xếp hàng nhắn tin của riêng mình.

Cho đến nay, thiết kế ban đầu của tôi chạy trên một trình nghe ổ cắm có luồng, nhưng để ngăn chặn cùng một thông điệp được tải xuống hai lần bởi hai nút xử lý riêng biệt, thanh ghi chỉ mục hàng đợi tin nhắn bị khóa khi bắt đầu đọc và mở khóa sau khi đăng ký được mở cập nhật. Như vậy, điều này phủ nhận sự cần thiết phải được xâu chuỗi, và có nghĩa là có một mức trần cho kích thước của một hệ thống có thể mở rộng dựa trên tốc độ xử lý của máy chủ mà dịch vụ hàng đợi nhắn tin đang chạy.

Cách khắc phục điều này sẽ là chạy dịch vụ xếp hàng tin nhắn trên nhiều máy chủ, nhưng điều này sẽ làm tăng khả năng cùng một tin nhắn được tải xuống hai lần. Cách duy nhất để ngăn chặn các sự cố như vậy xảy ra là bao gồm một cuộc gọi lại thu hồi mà (sau các máy chủ, hoặc thậm chí các luồng trên một máy chủ, đã đồng bộ hóa thông tin của chúng và phát hiện việc phát hành lại như vậy) sẽ ra lệnh cho nút xử lý dừng nút xử lý của nó công việc hiện tại và truy vấn lại hàng đợi tin nhắn cho tin nhắn tiếp theo, nhưng một lần nữa, sẽ có một mức trần mà hầu hết lưu lượng được gửi sẽ được đồng bộ hóa và hủy bỏ các cuộc gọi lại, gây ra tắc nghẽn và làm chậm quá trình xử lý thông tin để nhiều nút xử lý sẽ thực hiện các thao tác null và lãng phí thời gian.

Cách cuối cùng tôi có thể nghĩ ra để giải quyết vấn đề này là để mỗi máy chủ hàng đợi tin nhắn (và mỗi luồng trên mỗi máy chủ) sẽ có một phần bù cụ thể về vị trí của hàng đợi, nhưng điều đó có thể có vấn đề dựa trên loại ứng dụng, đặc biệt nếu việc xử lý được yêu cầu phải được thực hiện theo một thứ tự cụ thể.

Vì vậy, tất cả những gì đang được nói, có bất kỳ thiết kế nào của kiến ​​trúc hàng đợi tin nhắn có thể cho tôi thấy làm thế nào các dịch vụ xếp hàng tin nhắn cấp doanh nghiệp hiện tại tránh được những vấn đề này không?

Nói ngắn gọn:

Đây là một vấn đề khó khăn. Đừng phát minh lại bánh xe.

Có nhiều công nghệ giải quyết lớp xếp hàng tin nhắn. Chúng bao gồm

• ZeroMQ
• ThỏMQ
• Kafka Apache
• Redis, với BLPOP hoặc PUBSUB (Tôi đã hỏi làm thế nào để làm điều này ở đây ).
• Các triển khai AMQP khác ngoài RabbitMQ

Tôi nghĩ đó là ra khỏi phạm vi đối với tôi để thảo luận về những hạn chế của mỗi, không kém bởi vì tôi không thực sự khẳng định chuyên môn để làm tốt này ho không sử dụng Rabbit ho .

Ngay cả khi bạn không muốn sử dụng bất kỳ công nghệ nào trong số này, hãy đọc tài liệu của họ.

Điều này sẽ giáo dục bạn về các mẫu thiết kế có thể có trên một hệ thống. Đọc tài liệu của ZeroMQ sẽ giáo dục bạn về nhiều kiến ​​trúc xếp hàng tin nhắn cổ điển mà họ đã thực hiện một cách ân cần. Ngay cả khi bạn không sử dụng ZeroMQ, việc biết các mẫu này sẽ giúp bạn đánh giá các công nghệ xếp hàng khác bằng cách hỏi xem bạn có thể triển khai mẫu đó ở đó không.

Tìm hiểu về mô hình hàng đợi trao đổi của RabbitMQ / AMQP. Việc định tuyến có thể đến với bạn - điều này được Redis PUBSUB hỗ trợ nhưng tôi không nhớ là mình được ZeroMQ hỗ trợ - và fanout là thứ mà cửa hàng của tôi đã sử dụng, mặc dù được triển khai kém qua cuộc thăm dò Memcached (yuck!) .

Làm thế nào để chọn một?

Tôi làm việc tại một công ty khởi nghiệp có SLA là điển hình cho ứng dụng web - một số lần ngừng hoạt động là được, miễn là chúng tôi có thể nhanh chóng khôi phục dịch vụ với ít mất dữ liệu. Chúng tôi chưa phải suy nghĩ về các vấn đề mở rộng như Twitter hay Tumblr, vì vậy chúng tôi thực sự không phải suy nghĩ về khối lượng thông lượng. Điều đó đang được nói, nếu bạn đang thực hiện một SLA tương tự như của tôi, những cân nhắc này sẽ xuất hiện trong tâm trí:

• các thư viện khách hàng thực sự làm việc ? Có dễ dàng để duy trì một kết nối trong họ? (ZeroMQ, Redis: có. RabbitMQ: không).
• giám sát và quản lý có dễ dàng từ bảng điều khiển máy chủ không? (Redis: có, RabbitMQ: có, ZeroMQ: không phải tôi nhớ nhưng chúng tôi đã không sử dụng nó lâu như vậy)
• khách hàng có hỗ trợ hàng đợi nội bộ để mất ít dữ liệu xảy ra khi mất điện không? (ZeroMQ, Redis: có. RabbitMQ: không.)

Tất nhiên, nếu bạn đang làm việc cho một cửa hàng giao dịch cao tần, đây sẽ là những mối quan tâm ít hơn của bạn. Bạn sẽ sẵn sàng đưa thời gian phát triển vào thư viện phía khách hàng để đổi lấy thông lượng cao hơn cuối cùng. Nhưng tôi viết điều này nhiều hơn để cảnh báo bạn rằng các công nghệ này có xu hướng tiếp thị trên cơ sở hiệu suất của chúng, chứ không phải chức năng vượt trội của chúng. Nếu bạn là một web-khởi động, bạn đang xa quan tâm nhiều hơn trong sau này so với trước đây, và theo đó, một cái gì đó giống như Redis, được nhiều tối ưu hóa cho dễ sử dụng ở hiệu suất tốt hơn so với khó khăn trong việc sử dụng ở hiệu suất tuyệt vời, có lẽ là một sự lựa chọn tốt hơn RabbitMQ. (Tôi thực sự không thích RabbitMQ).