Tại sao chúng ta cần các nhà môi giới tin nhắn như RabbitMQ qua cơ sở dữ liệu như PostgreSQL?

Tôi chưa quen với các nhà môi giới tin nhắn như RabbitMQ mà chúng ta có thể sử dụng để tạo các nhiệm vụ / hàng đợi tin nhắn cho một hệ thống lập lịch như Celery .

Bây giờ, đây là câu hỏi:

• Tôi có thể tạo một bảng trong PostgreSQL có thể được thêm vào các tác vụ mới và được sử dụng bởi chương trình tiêu dùng như Celery.

• Tại sao tôi muốn thiết lập một công nghệ hoàn toàn mới cho điều này như RabbitMQ?

Bây giờ, tôi tin rằng tỷ lệ không thể là câu trả lời vì cơ sở dữ liệu của chúng tôi như PostgreSQL có thể hoạt động trong môi trường phân tán.

Tôi đã tìm hiểu về những vấn đề mà cơ sở dữ liệu đặt ra cho vấn đề cụ thể và tôi đã tìm thấy:

• bỏ phiếu giữ cho cơ sở dữ liệu bận rộn và hiệu suất thấp
• khóa bảng -> một lần nữa hiệu suất thấp
• hàng triệu hàng nhiệm vụ -> một lần nữa, bỏ phiếu có hiệu suất thấp

Bây giờ, làm thế nào để RabbitMQ hoặc bất kỳ nhà môi giới tin nhắn nào khác giải quyết những vấn đề này?

Ngoài ra, tôi phát hiện ra rằng AMQPgiao thức là những gì nó theo sau. Điều gì tuyệt vời trong đó?

Có thể Redis cũng được sử dụng như một nhà môi giới thông điệp? Tôi thấy nó giống với Memcached hơn RabbitMQ.

Xin hãy làm sáng tỏ điều này!

Hàng đợi của thỏ nằm trong bộ nhớ và do đó sẽ nhanh hơn nhiều so với việc thực hiện điều này trong cơ sở dữ liệu. Hàng đợi tin nhắn chuyên dụng (tốt) cũng sẽ cung cấp các tính năng liên quan đến hàng đợi thiết yếu như điều khiển lưu lượng / điều khiển luồng và khả năng chọn các thuật toán định tuyến khác nhau, để đặt tên cho một cặp (thỏ cung cấp các tính năng này và hơn thế nữa). Tùy thuộc vào quy mô dự án của bạn, bạn cũng có thể muốn tách thông điệp thành phần khỏi cơ sở dữ liệu của mình, để nếu một thành phần chịu tải nặng, nó không cần cản trở hoạt động của người kia.

Đối với các vấn đề bạn đã đề cập:

• bỏ phiếu giữ cho cơ sở dữ liệu buzy và hiệu suất thấp : Sử dụng Rabbitmq, các nhà sản xuất có thể đẩy các bản cập nhật đến người tiêu dùng hiệu quả hơn nhiều so với bỏ phiếu. Dữ liệu được gửi đơn giản đến người tiêu dùng khi cần, loại bỏ nhu cầu kiểm tra lãng phí.

• khóa bảng -> lại hoạt động kém: Không có bảng để khóa: P

• hàng triệu hàng nhiệm vụ -> một lần nữa bỏ phiếu có hiệu suất thấp: Như đã đề cập ở trên, Rabbitmq sẽ hoạt động nhanh hơn vì nó nằm trong RAM và cung cấp kiểm soát luồng. Nếu cần, nó cũng có thể sử dụng đĩa để lưu tạm thời tin nhắn nếu hết RAM. Sau 2.0, Rabbit đã cải thiện đáng kể việc sử dụng RAM. Tùy chọn phân cụm cũng có sẵn.

Liên quan đến AMQP, tôi muốn nói một tính năng thực sự thú vị là "trao đổi" và khả năng để nó chuyển sang các sàn giao dịch khác. Điều này cho phép bạn linh hoạt hơn và cho phép bạn tạo ra một loạt các kiểu định tuyến phức tạp có thể rất hữu ích khi thu nhỏ. Để có một ví dụ tốt, xem:

_{(nguồn: Springsource.com )}

và: http://blog.springsource.org/2011/04/01/routing-topology-for-performance-and-scalability-with-rabbitmq/

Cuối cùng, liên quan đến redis, vâng, nó có thể được sử dụng như một nhà môi giới tin nhắn, và có thể làm tốt. Tuy nhiên, Rabbitmq có nhiều tính năng xếp hàng tin nhắn hơn redis, vì rabbitmq được xây dựng từ đầu để trở thành một hàng đợi tin nhắn dành riêng cho cấp doanh nghiệp đầy đủ tính năng. Mặt khác, Redis được tạo ra chủ yếu để trở thành một kho lưu trữ khóa-giá trị trong bộ nhớ (mặc dù hiện tại nó còn nhiều hơn thế; thậm chí nó còn được gọi là một con dao quân đội Thụy Sĩ). Tuy nhiên, tôi đã đọc / nghe nhiều người đạt được kết quả tốt với Redis cho các dự án có quy mô nhỏ hơn, nhưng chưa nghe nhiều về nó trong các ứng dụng lớn hơn.

Dưới đây là một ví dụ về redis đang được sử dụng trong triển khai trò chuyện bỏ phiếu dài: http://eflorenzano.com/blog/2011/02/16/t Technology-behind-convore /

PostgreQuery 9.5

PostgreQuery 9.5 kết hợp SELECT ... FOR UPDATE ... SKIP LOCKED. Điều này làm cho việc thực hiện các hệ thống xếp hàng làm việc trở nên đơn giản và dễ dàng hơn rất nhiều . Bạn có thể không còn yêu cầu hệ thống xếp hàng bên ngoài vì giờ đây việc tìm nạp các hàng không có phiên nào khác bị khóa và giữ chúng bị khóa cho đến khi bạn xác nhận rằng công việc đã hoàn tất. Nó thậm chí hoạt động với các giao dịch hai pha khi cần phối hợp bên ngoài.

Các hệ thống xếp hàng bên ngoài vẫn hữu ích, cung cấp chức năng đóng hộp, hiệu suất đã được chứng minh, tích hợp với các hệ thống khác, các tùy chọn cho quy mô ngang và liên kết, v.v. Tuy nhiên, đối với các trường hợp đơn giản, bạn không thực sự cần chúng nữa.

Các phiên bản cũ hơn

Bạn không cần những công cụ như vậy, nhưng sử dụng một công cụ có thể giúp cuộc sống dễ dàng hơn. Việc xếp hàng trong cơ sở dữ liệu có vẻ dễ dàng, nhưng trên thực tế bạn sẽ phát hiện ra rằng việc xếp hàng đồng thời đáng tin cậy, hiệu suất cao thực sự khó thực hiện ngay trong cơ sở dữ liệu quan hệ.

Đó là lý do tại sao các công cụ như PGQ tồn tại.

Bạn có thể thoát khỏi việc bỏ phiếu trong PostgreSQL bằng cách sử dụng LISTENvà NOTIFY, nhưng điều đó sẽ không giải quyết được vấn đề đáng tin cậy khi đưa các mục ra khỏi đầu hàng đợi cho chính xác một người tiêu dùng trong khi vẫn duy trì hoạt động đồng thời cao và không chặn chèn. Tất cả các giải pháp đơn giản và rõ ràng mà bạn nghĩ sẽ giải quyết vấn đề đó thực sự không có trong thế giới thực và có xu hướng thoái hóa thành các phiên bản kém hiệu quả hơn của việc tìm nạp hàng đợi một công nhân.

Nếu bạn không cần tìm nạp hàng đợi nhiều nhân viên đồng thời thì sử dụng một bảng xếp hàng duy nhất trong PostgreQuery là hoàn toàn hợp lý.