Hàng đợi tin nhắn. Cơ sở dữ liệu so với MQ chuyên dụng

Tôi sau khi tư vấn về việc xếp hàng tin nhắn. Chúng tôi có các yêu cầu cho "công việc" phải được đăng lên hàng đợi tin nhắn.

Đề xuất ban đầu chỉ là sử dụng một phiên bản SQL Server và xử lý các thông báo từ đó. Tất cả mọi thứ tôi đã đọc trên internet cho thấy rằng sử dụng cơ sở dữ liệu cho Hàng đợi Tin nhắn không phải là một giải pháp có thể mở rộng. Vì lý do này, ý tưởng sử dụng RabbitMQ hoặc một số MQ bên thứ 3 khác đã được đề xuất.

Một điều khác cần tính đến là yêu cầu "xử lý công việc" sẽ không thấp hơn 30 giây, do đó, quá trình thực hiện công việc sẽ thăm dò cơ sở dữ liệu cứ sau 30 giây. Đối với tôi, điều này có vẻ không tệ lắm và có lẽ sẽ hoạt động tốt mà không cần thêm một tải lớn vào Cơ sở dữ liệu.

Chúng tôi đã có sẵn Cơ sở dữ liệu cho các khách hàng của mình, chúng tôi có thể sử dụng cho việc này vì vậy nó sẽ không hỗ trợ thêm cho khách hàng của chúng tôi, trong khi nếu chúng tôi thêm MQ bên thứ 3, sẽ có thêm hỗ trợ cho cấu hình mạng, v.v. đáng kể có rất nhiều người dùng.

Tùy chọn khác mà tôi đang xem xét là cho phép người dùng lựa chọn giữa một trong hai. Nếu họ là một người dùng nhỏ thì giải pháp Sql Server sẽ ổn, nhưng nếu họ là người dùng lớn hơn thì chúng tôi cho phép họ định cấu hình giải pháp MQ của bên thứ 3.

Tôi không bán bất kỳ giải pháp nào, tôi tự hỏi nếu có ai có bất cứ điều gì tôi nên xem xét hoặc tư vấn.

Tất cả mọi thứ tôi đã đọc trên internet cho thấy rằng sử dụng cơ sở dữ liệu cho Hàng đợi Tin nhắn không phải là một giải pháp có thể mở rộng.

Thực tế thường bị bỏ qua bởi " không sử dụng X vì nó không có tỷ lệ " (liên kết chứa ngôn ngữ mà một số người có thể thấy khó chịu) là quy mô không phải lúc nào cũng quan trọng. Tôi sẽ đi xa hơn để nói rằng nếu bạn nhìn vào mọi ứng dụng trên bề mặt của hành tinh trong tổng hợp, quy mô hiếm khi quan trọng.

Nhận xét của bạn trích dẫn tỷ lệ 20.000 tin nhắn hàng ngày, điều đó có nghĩa là bạn đang cần phải hỗ trợ tốc độ trung bình 0,23 tin nhắn mỗi giây (cứ sau 4,3 giây). Nếu dự án của bạn trở nên thành công hơn hai bậc so với dự kiến ​​của bạn, yêu cầu của bạn sẽ chuyển sang xử lý 23 tin nhắn mỗi giây, đó là nhiệm vụ tôi rất thoải mái khi trao cho điện thoại di động bốn tuổi hoặc Raspberry của tôi Số Pi. Đây vẫn không phải là một ứng dụng quy mô cao ngay cả khi bạn giải quyết một vài đơn đặt hàng lớn khác.

Tôi đã xem (may mắn thay, từ bên lề) kết thúc tồi tệ bởi vì họ đã dành quá nhiều thời gian quá sớm để ám ảnh về quy mô sẽ không xảy ra hoặc không có thời gian trên đó và bị nghiền nát bởi quy mô mà cuối cùng đã làm. Giống như mọi thứ khác, có một phương tiện hạnh phúc. Nếu bạn nghĩ rằng quy mô lớn cho ứng dụng của bạn là một khả năng thực tế, thì sẽ không khó để tạo ra một trường hợp kinh doanh để thực hiện một lượng nhỏ công việc bổ sung để xây dựng đủ trừu tượng xung quanh các phần không thể mở rộng mà không tốn kém để triển khai ngay bây giờ . Làm điều này có nghĩa là sau này , nếu cần phát sinh quy mô, bạn có cách (và có thể là doanh thu) để thay thế bán buôn các bộ phận đó mà không phải suy nghĩ lại toàn bộ hệ thống.

Mặc dù khối lượng tin nhắn của ứng dụng của bạn sẽ không làm cho cơ sở dữ liệu hoặc hệ thống xếp hàng tin nhắn bị đổ mồ hôi ngay cả trên phần cứng khiêm tốn, nhưng bạn có thể có các yêu cầu khác về cách xử lý các giao dịch tin nhắn của mình để làm cho một hoặc một lựa chọn khác tốt hơn. Những yêu cầu đó là những gì bạn nên được đánh giá.

Hàng đợi tin nhắn thực sự trở thành của riêng họ khi bạn có nhiều người trong số họ và định tuyến tin nhắn giữa họ, fanout đến nhiều hơn một người tiêu dùng, v.v.

Nếu bạn chỉ có một 'hàng đợi công việc' trong số những thứ bạn muốn xử lý 'off line' thì một bảng SQL sẽ hoạt động tốt.

Đừng quên đảm bảo rằng bạn có một số cách đánh dấu công việc đang thực hiện, dọn dẹp những công việc cũ và cảnh báo khi hệ thống dừng lại. Nhưng đối với một hàng đợi duy nhất quản lý thủ công những việc này sẽ ít công việc hơn là duy trì một giải pháp xếp hàng riêng biệt.

Như quy mô khác đã đề cập có lẽ không quan trọng ở đây. Vấn đề với việc sử dụng hai cơ chế lưu trữ khác nhau là tính tích hợp giao dịch.

Nếu đi với hàng đợi tin nhắn chuyên dụng, bạn cần chọn một trong các cách sau trong trường hợp thất bại.

1. Cho phép dữ liệu có thể trên mb nhưng không phải trong db
2. Cho phép dữ liệu có thể bằng db nhưng không phải bằng mb
3. Thiết lập hai pha giao dịch hoặc giao dịch phân tán giữa db một mq có thể phức tạp

Tất cả những vấn đề này sẽ biến mất nếu bạn chỉ lưu dữ liệu ở một nơi bằng cách sử dụng một giao dịch bình thường. Vì lý do này, sử dụng db làm hàng đợi nhiệm vụ là một giải pháp hoàn toàn tốt.

Để thực tế, lý do chính để tôi sử dụng hàng đợi tin nhắn là:

• Tôi đã không phải phát minh lại bánh xe. Thiết kế ngay cả hàng đợi tin nhắn đơn giản nhất bằng cơ sở dữ liệu đòi hỏi ít nhất một vài giờ suy nghĩ, một vài giờ mã hóa, v.v. So với việc thực hiện hàng đợi tin nhắn, thời gian cần thiết để định cấu hình và / hoặc tự động hóa cấu hình là không đáng kể
• Hàng đợi tin nhắn có giao diện đẹp và rõ ràng cho nhà sản xuất và người tiêu dùng. Đây có lẽ là điều quan trọng nhất trong ứng dụng viết. Không có giao diện, hàng đợi tin nhắn về cơ bản chỉ là một tập hợp dữ liệu
• Hàng đợi tin nhắn cung cấp thêm các tính năng có thể cần thiết trong tương lai

Về việc cho phép người dùng lựa chọn, đó thực sự là một chi tiết triển khai mà người dùng không nên quan tâm. Người dùng sẽ có cùng giao diện và sẽ không có sự khác biệt đối với người dùng nếu cơ sở dữ liệu hoặc hàng đợi tin nhắn được sử dụng. Khi một thiết kế duy nhất được đặt, một lựa chọn có thể xảy ra cho người dùng là có bao nhiêu nút cần được triển khai để đáp ứng nhu cầu của họ.

Tôi đã tạo ra một giải pháp hàng đợi tin nhắn Mssql có thể xử lý 20k thao tác mỗi giây, theo một bài kiểm tra hiệu suất và chúng tôi cần 10 / giây hầu hết thời gian. Tôi nghĩ rằng thực tế là bạn thực sự có thể có mức độ ưu tiên được tích hợp sẵn là một tính năng mà hàng đợi tin nhắn chuyên dụng thiếu. Và đây là một yêu cầu chính trong trường hợp của tôi.