Redis Vs RabbitMQ như một hệ thống nhắn tin / môi giới dữ liệu giữa Logstash vàasticsearch

Chúng tôi đang xác định một kiến ​​trúc để thu thập thông tin nhật ký của người gửi hàng Logstash được cài đặt trong nhiều máy khác nhau và lập chỉ mục dữ liệu trong một máy chủ tìm kiếm đàn hồi tập trung và sử dụng Kibana làm lớp đồ họa. Chúng tôi cần một hệ thống nhắn tin đáng tin cậy giữa người gửi hàng Logstash và đàn hồi để cấp phép giao hàng. Những yếu tố nào cần được xem xét khi chọn Redis thay vì RabbitMQ làm hệ thống nhắn tin / môi giới dữ liệu giữa người gửi hàng Logstash và người đàn hồi hoặc ngược lại?

Sau khi đánh giá cả Redis và RabbitMQ, tôi đã chọn RabbitMQ làm nhà môi giới của chúng tôi vì những lý do sau:

1. RabbitMQ cho phép bạn sử dụng lớp bảo mật tích hợp bằng cách sử dụng chứng chỉ SSL để mã hóa dữ liệu bạn đang gửi cho nhà môi giới và điều đó có nghĩa là không ai sẽ đánh hơi dữ liệu của bạn và có quyền truy cập vào dữ liệu tổ chức quan trọng của bạn.
2. RabbitMQ là một sản phẩm rất ổn định có thể xử lý số lượng lớn các sự kiện trong một giây và nhiều kết nối mà không bị chai.
3. Trong tổ chức của chúng tôi, chúng tôi đã sử dụng RabbitMQ và có kiến ​​thức nội bộ tốt về việc sử dụng nó và tích hợp sẵn sàng với đầu bếp.

Về việc mở rộng quy mô, RabbitMQ có một triển khai cụm tích hợp mà bạn có thể sử dụng ngoài bộ cân bằng tải để triển khai môi trường môi giới dự phòng.

Cụm RabbitMQ của tôi là Active Active hay Active Passive?

Bây giờ đến điểm yếu hơn của việc sử dụng RabbitMQ:

1. hầu hết các chủ hàng của Logstash không hỗ trợ RabbitMQ nhưng mặt khác, công cụ tốt nhất, có tên là Beaver, có một triển khai sẽ gửi dữ liệu đến RabbitMQ mà không gặp vấn đề gì.
2. Việc triển khai Beaver với RabbitMQ trong phiên bản hiện tại của nó hơi chậm về hiệu suất (đối với mục đích của tôi) và không thể xử lý tốc độ 3000 sự kiện / giây từ một máy chủ và thỉnh thoảng dịch vụ bị lỗi.
3. Hiện tại, tôi đang thực hiện một bản sửa lỗi để giải quyết vấn đề hiệu suất cho RabbitMQ và giúp Beaver shipper hoạt động ổn định hơn. Giải pháp đầu tiên là thêm nhiều quy trình có thể chạy đồng thời và sẽ cung cấp cho người gửi hàng nhiều quyền lực hơn. Giải pháp thứ hai là thay đổi Beaver để gửi dữ liệu không đồng bộ đến RabbitMQ về mặt lý thuyết sẽ nhanh hơn nhiều. Tôi hy vọng rằng tôi sẽ hoàn thành việc triển khai cả hai giải pháp vào cuối tuần này.

Bạn có thể theo dõi vấn đề tại đây: https://github.com/josegonzalez/python-beaver/issues/323

Và kiểm tra yêu cầu kéo tại đây: https://github.com/josegonzalez/python-beaver/pull/324

Nếu bạn có thêm câu hỏi, hãy để lại bình luận.

Redis được tạo ra như một kho lưu trữ dữ liệu giá trị quan trọng mặc dù có một số khả năng môi giới thông điệp cơ bản .

RabbitMQ được tạo ra như một nhà môi giới tin nhắn. Nó có rất nhiều khả năng môi giới tin nhắn một cách tự nhiên.

Tôi đã thực hiện một số nghiên cứu về chủ đề này. Nếu hiệu suất là quan trọng và sự bền bỉ thì không, RabbitMQ là một lựa chọn hoàn hảo. Redis là một công nghệ được phát triển với một mục đích khác.

Sau đây là danh sách những ưu điểm khi sử dụng RabbitMQ so với Redis:

• RabbitMQ sử dụng Giao thức xếp hàng thư nâng cao (AMQP) có thể được định cấu hình để sử dụng SSL, lớp bảo mật bổ sung.
• RabbitMQ mất khoảng 75% thời gian Redis chấp nhận tin nhắn.
• RabbitMQ hỗ trợ mức độ ưu tiên cho các tin nhắn, có thể được sử dụng bởi công nhân để sử dụng các tin nhắn có mức độ ưu tiên cao trước.
• Không có cơ hội để mất tin nhắn nếu bất kỳ công nhân nào gặp sự cố sau khi sử dụng tin nhắn, điều này không xảy ra với Redis.
• RabbitMQ có một hệ thống định tuyến tốt để hướng tin nhắn đến các hàng đợi khác nhau.

Một vài nhược điểm khi sử dụng RabbitMQ:

• RabbitMQ có thể hơi khó bảo trì, khó khắc phục sự cố.
• Node-name hoặc node-ip dao động có thể gây mất dữ liệu, nhưng nếu được quản lý tốt, các thông điệp lâu bền có thể giải quyết được vấn đề.

Tôi đã tự hỏi điều tương tự. Các khuyến nghị trước đó của Logstash folks khuyên Redis thay vì RabbitMQ ( http://logstash.net/docs/1.1.1/tutorials/getting-started-centralized ), tuy nhiên phần ghi chú đó không còn tồn tại trong tài liệu hiện tại mặc dù có lưu ý chung về việc sử dụng nhà môi giới để đối phó với mức tăng đột biến tại đây https://www.elastic.co/guide/en/logstash/current/deploy-and-scaling.html .

Mặc dù tôi cũng đang sử dụng RabbitMQ khá vui vẻ, nhưng tôi hiện đang khám phá một nhà môi giới Redis, vì giao thức AMQP có thể quá mức cần thiết cho trường hợp sử dụng ghi nhật ký của tôi.

Các câu hỏi nhanh để hỏi:

1. tại sao bạn cần một nhà môi giới? Nếu bạn đang sử dụng logstash hoặc logstash-forwarder để đọc các tệp từ các máy chủ này, cả hai đều sẽ chậm lại nếu đường ống bị tắc nghẽn.
2. bạn có kinh nghiệm nào về quản lý thỏ hoặc redis không? Tất cả mọi thứ đều bình đẳng, công cụ bạn biết cách sử dụng là công cụ tốt hơn.

Trong lĩnh vực ý kiến, tôi đã điều hành redis với tư cách là một nhà môi giới, và rất ghét nó. Tất nhiên, đó có thể là do tôi thiếu kinh nghiệm với redis (không phải vấn đề với bản thân sản phẩm), nhưng nó là liên kết yếu nhất trong đường ống và luôn thất bại khi chúng tôi cần nhất.