Tôi cần tạo một hàng đợi để xử lý. Bản thân hàng đợi có khối lượng tương đối thấp. Có thể có khoảng 1.000 lượt viết cho nó mỗi giờ. Việc thực hiện mỗi tác vụ có thể mất khoảng một phút mỗi tác vụ và được xử lý gần như ngay sau khi mục được thêm vào hàng đợi.
Có lý do gì mà tôi có thể muốn triển khai RabbitMQ thay vì một thứ gì đó có sẵn như Amazon SQS không? Một số lý do tại sao một ứng dụng cần hệ thống xếp hàng riêng của nó thay vì một cái gì đó như SQS?
Câu trả lời:
Đầu tiên, Amazon SQS là một hàng đợi giả có nghĩa là việc phân phối mọi thư (nếu nó đến hàng đợi) được đảm bảo nhưng không phải theo kiểu FIFO thường xảy ra trong một hàng đợi.
Nếu thứ tự của thư quan trọng đối với bạn và bạn muốn hàng đợi hoạt động theo kiểu FIFO, thì tài liệu Amazon SQS nêu rõ cách xử lý điều này trong logic ứng dụng của bạn vì các thư từ Amazon SQS sẽ đến với bạn không theo trình tự.
So với điều này, theo như tôi biết, bạn có thể triển khai hàng đợi công nhân trong RabbitMQ. Nếu điều đó khiến bạn phải triển khai trình tự thông báo hàng đợi ở cấp ứng dụng thì đây sẽ là một lựa chọn thích hợp hơn.
Dưới đây là một số yếu tố để giúp bạn quyết định nên chọn cái nào:
Trình tự tin nhắn xếp hàng như đã nói ở trên.
Bạn có thể thiết lập máy chủ của riêng mình với RabbitMQ nhưng không phải trong trường hợp của Amazon SQS, vì vậy chi phí sẽ liên quan ở đây.
Việc thiết lập máy chủ của riêng bạn sẽ đòi hỏi kiến thức tốt về chủ đề này để bạn không để lọt bất kỳ góc nào. Đây không phải là trường hợp của Amazon SQS vì nó khá nhanh để bắt đầu.
Máy chủ RabbitMQ của riêng bạn có nghĩa là chi phí bảo trì không phải là trường hợp của Amazon SQS.
Cập nhật:
SQS sẽ là sở thích của tôi so với RabbitMQ, đây là lý do tại sao.
Tuy nhiên, RabbitMQ có thể cung cấp thời gian phản hồi nhanh hơn cho các lần đặt và nhận, thường trong 10 giây trong số hàng nghìn TPS từ thử nghiệm của tôi. Để SQS cung cấp loại thông lượng đó, bạn sẽ phải mở rộng quy mô theo chiều ngang với nhiều phiên bản. Vì vậy, nếu bạn đang tìm kiếm thời gian đặt dưới 5ms, RabbitMQ có thể là một lựa chọn để xem xét vì tôi đã thấy thời gian đặt gần 20ms-30ms từ thử nghiệm SQS của tôi ở 1000 giây TPS, cao hơn một chút so với RabbitMQ.
Chúng tôi vừa chuyển cơ sở hạ tầng nhắn tin của mình từ ActiveMQ sang SQS và không thể vui hơn nữa. Chúng tôi nhận thấy nó rẻ hơn so với việc duy trì cụm ActiveMQ của riêng chúng tôi trên đám mây.
Hi vọng điêu nay co ich! Hãy cho chúng tôi biết nó diễn ra như thế nào ..
Tôi thực sự đã sử dụng cả hai trong một môi trường thương mại với sự hợp lý.
Câu trả lời ngắn gọn là trừ khi có các trường hợp góc cụ thể, tốt hơn là bạn nên sử dụng AWS SQS. (Bạn có thể bỏ qua phần cuối để xem tóm tắt đơn giản)
Mã hóa (Tie): RabbitMQ và AWS SQS đều có thư viện thiết lập và rất nhiều ví dụ.
Thời gian chờ hiển thị (SQS): Một điều mà SQS cung cấp trên RabbitMQ là khái niệm rộng hơn về thời gian chờ hiển thị. Trong RabbitMQ, nếu người tiêu dùng chết trước khi nó hoạt động, các thông báo sẽ được đưa trở lại hàng đợi. Nhưng SQS có một khái niệm rộng hơn về thời gian chờ hiển thị không bị ràng buộc với một người gọi cụ thể. Vì vậy, bạn có thể bắt đầu một đơn vị công việc, đặt chế độ hiển thị với thời gian chờ lớn (tối đa 12 giờ), ngắt kết nối, nhờ một nhân viên khác hoàn thành và tiếp tục. Trong thiết kế của tôi, chúng tôi tận dụng điều này một cách rộng rãi và loại bỏ dịch vụ / bộ nhớ bổ sung để quản lý khối lượng lớn tiềm ẩn 'đang xử lý'.
Xử lý thư chết (RabbitMQ - bởi một 'thỏ rừng') SQS cung cấp việc gửi thư chết cơ bản mà họ gọi là "Chính sách điều khiển lại" đưa thư vào Hàng đợi Thư chết (chỉ là một hàng đợi khác). Nó cơ bản và chỉ có khái niệm về số lượng tin nhắn. RabbitMQ có Trao đổi thư chết cung cấp các thư được đẩy vào DLE khi chúng hết hạn. Nhưng đây là một cuộc tranh luận giống như ý tưởng "Nếu bạn không xem các dịch vụ và tin nhắn của mình hết hạn, thì nó sẽ hạ cánh trong DLE". Đó là một chiến thắng nhẹ cho RabbitMQ vì tôi thấy rằng phản đối lập luận đó trực quan. Tại sao bạn lại giám sát hàng đợi của mình mà không phải các dịch vụ của bạn? (Nếu có gì thì ngược lại)
Quản trị (SQS): Không có quản trị đối với SQS. Bạn chỉ cần trả tiền cho các cuộc gọi API. Tất cả các vấn đề đau đầu thông thường như bản vá bảo mật hệ điều hành / ứng dụng, quy mô (thêm nhiều nút), đĩa đều do nhóm AWS xử lý. Nó cũng tuân thủ FedRamp (cho chính phủ sử dụng). Nó thực sự là một hệ thống 'thiết lập và quên đi'. Trong trường hợp RabbitMQ yêu cầu các bản vá hệ điều hành / dịch vụ thông thường, AMI, phân cụm, tăng cường bảo mật, v.v. Mặc dù rất hiếm, nhưng AMI có thể giảm hoặc đôi khi yêu cầu di chuyển xung quanh vì vậy cần phân cụm ngay lập tức. SQS loại bỏ tất cả những đau đầu.
CHI PHÍ (SQS): Một lệnh gọi API SQS có thể bao gồm 'hàng loạt tối đa 10 thư / kích thước 256k' và 'bỏ phiếu dài' có thể cắt giảm đáng kể chi phí. Hơn nữa, có những chiến lược như nén tin nhắn để đẩy hàng chục (một số yêu cầu hàng trăm hoặc nhiều hơn) tin nhắn có thể được gửi trong một trọng tải duy nhất để giảm chi phí hơn nữa. Và đây là trước khi chúng ta xem xét thời gian mọi người dành để giám sát / vá / sửa các vấn đề. SQS cũng tuyệt vời cho các 'dự án poc' như thể nó không hoạt động, không tốn phí.
FIFO (TIE): Vào năm 2016, AWS đã giới thiệu hỗ trợ FIFO với chi phí bổ sung là ~ 0,01 đô la / triệu lệnh gọi api (0,05 đô la so với 0,04 đô la cho tất cả các API - trước khi giảm giá). Bạn có thể chọn sử dụng FIFO hoặc không. Đối với không phải FIFO, chúng tôi hiếm khi thấy các thông báo trùng lặp.
Lưu trữ (SQS): AWS không tính phí lưu trữ nhưng bạn có giới hạn là 14 ngày. Trên RabbitMQ, bạn sẽ phải phân bổ, mở rộng và quản lý không gian đĩa yêu cầu dung lượng lưu trữ cao nhất cộng với bộ đệm bổ sung. Nó chỉ là đau đầu hơn.
Số liệu (SQS): SQS cung cấp các số liệu ngoài hộp. Và trong khi bạn có thể thêm chúng vào AWS, nó chỉ là công việc nhiều hơn.
Nhà phát triển địa phương (cà vạt): Hầu hết các cửa hàng hiện đại thích có môi trường địa phương. Hiện có một số tùy chọn cho phép các docker của RabbitMQ và SQS.
Thông lượng cao / thông báo rất lớn (RabbitMQ - đại loại) Khi bạn đẩy SQS> 1000 yêu cầu / giây, độ trễ của SQS sẽ tăng lên. Có một số chiến lược để vượt qua nó. Nhưng tôi thấy những trường hợp này là cực kỳ hiếm vì hầu hết công việc có thể được phân vùng thành nhiều hàng đợi. Nhưng với những trường hợp cần 100k / giây như thế này thì mình nghĩ Kafka tốt hơn. (Chúng tôi cũng sử dụng Kafka trong công việc của tôi) Rất hiếm khi có một đơn vị công việc nào đòi hỏi hơn 1000 yêu cầu / giây với độ trễ thấp. * Xem thêm bên dưới để giải thích điều này
Tóm tắt: Nếu bạn sẽ gia nhập AWS và sẵn sàng kết hôn với SQS, thì SQS là điều không cần bàn cãi. Nhưng bạn nên đọc tiếp vì có những điều quan trọng cần xem xét.
Chiến lược cổ điển cho RabbitMQ (và các hàng đợi khác) là tạo một số loại hàng đợi được tối ưu hóa cho một số loại công việc nhất định. Sau đó, tinh chỉnh từng hàng đợi này và nhóm các công việc tương tự thành một số nhỏ trong số các hàng đợi này (thường có kích thước rất lớn). Vì SQS không có chi phí quản trị, thực sự tốt hơn là phân bổ hàng đợi dành riêng cho từng công việc. Bằng cách đó, nó cho phép mở rộng quy mô nhưng cũng loại bỏ tình trạng bão hòa hàng đợi (công việc vi phạm làm bão hòa hàng đợi và át đi những người lao động khác), xem tốt hơn công việc (số liệu mặc định), v.v.
Chiến lược mới đã cho phép các nhóm của tôi có cái nhìn tốt hơn về cách phân bổ công việc. Đã qua rồi thời 'nâng cấp phiên bản để tải nhiều hơn'. Trước đây, chúng tôi sẽ thấy một sự gia tăng đột biến lớn không giải thích được có thể gây ra tác dụng phụ cho các dịch vụ khác hoặc chỉ đoán rằng các con số tích lũy có vẻ đúng '. Bây giờ lưu lượng truy cập được tách biệt, chúng tôi thực sự đã phát hiện ra nhiều vấn đề mà trước đây không được chú ý và có thể giải thích rõ ràng lượng lưu lượng truy cập đang đi đến đâu. Và trong khi rất có thể triển khai các chỉ số và công cụ, SQS cung cấp tất cả những điều này.
Vẫn có những trường hợp tuyệt vời nên xem xét nghiêm túc RabbitMQ
- Very large legacy code base that uses RabbitMQ with extensive tooling and knowledgeable support staff
- Messages that needs to be in the same work stream for > 14 days
- Very large messages that has very low latency requirements with it
- Cloud agnostic code base requirements. If you must run your code on other platforms (e.g. Azure/Google/bare metal), then SQS is not an option
- Large volume of data for a single pipeline that can't be broke up and other solutions (e.g. Kafka) are not viable. But at a super large volume, Kafka is a lot faster. While SQS will push large payloads to S3, you are now incurring additional cost.
Nếu bạn nhạy cảm với chi phí, Amazon SQS có thể sẽ đắt hơn. Tôi nói có lẽ vì bạn vẫn cần lưu trữ máy chủ RabbitMQ của mình ở đâu đó. SQS cung cấp cho bạn một triệu yêu cầu đầu tiên miễn phí và sau đó tính phí 0,4 đô la sau đó cho mỗi triệu yêu cầu. Tuy nhiên, có một mẹo nhỏ để giảm chi phí của bạn với SQS bằng cách bật tính năng thăm dò ý kiến dài, tức là cài đặt get_message_wait_time của bạn thành 20 giây. Điều này không có nghĩa là tin nhắn của bạn sẽ chỉ gửi sau mỗi 20 giây, nó có nghĩa là SQS sẽ không tính phí 'yêu cầu' của bạn nếu hàng đợi của bạn trống (cứ sau 20 giây).
Nếu bạn sử dụng 1000 yêu cầu mỗi giờ, bạn đang xem 744000 một tháng. Miễn phí trong cấp miễn phí và khoảng 0,74 * 0,4 đô la = 0,2976 đô la ngoài cấp. Mà bạn có thể giảm thêm bằng cách cho phép thời gian chờ. Vì vậy, trong trường hợp của bạn, SQS thực sự có thể hoạt động rẻ hơn vì hầu hết các dịch vụ lưu trữ bắt đầu từ mức tối thiểu là $ 5 trở lên (trừ khi bạn có cấp EC2 miễn phí từ AWS). Bạn sẽ ổn với tùy chọn nhỏ nhất vì RMQ chỉ khuyến nghị khởi động khoảng 128mb ram.
Tôi thấy SQS thân thiện hơn với người dùng và RabbitMQ kỹ thuật hơn nếu bạn theo cách đó.
Cập nhật:
Tôi thực sự thấy Dịch vụ thông báo đơn giản của AWS phù hợp hơn với những gì tôi cần https://stackoverflow.com/a/13692720/5403449 chủ yếu vì nó dựa trên push, tức là không bỏ phiếu