Мені потрібно створити чергу для обробки. Сама черга порівняно невелика. На неї може бути близько 1000 записів на годину. Виконання кожного завдання може зайняти близько хвилини кожне і обробляється майже відразу після додавання елемента до черги.
Чи є якась причина, що я можу захотіти застосувати RabbitMQ замість чогось готового, як Amazon SQS? З яких причин програма потребує власної системи черги замість чогось типу SQS?
Відповіді:
Для початку, Amazon SQS - це псевдочерга, що означає доставку кожного повідомлення (якщо воно потрапляє в чергу) гарантоване, але не за способом FIFO, що зазвичай відбувається в черзі.
Якщо порядок повідомлень важливий для вас, і ви хочете, щоб черга працювала за методом FIFO, в документації Amazon SQS зазначено, що це обробляється у вашій логіці програми, оскільки повідомлення з Amazon SQS будуть надходити до вас не з послідовності.
Порівняно з цим, наскільки мені відомо, ви можете реалізувати черги працівників у RabbitMQ. Якщо це позбавляє вас від реалізації послідовності повідомлень черги на рівні програми, то це буде більш кращим варіантом.
Ось декілька факторів, які допоможуть вам вирішити, на який з них піти:
Послідовність повідомлень у черзі, як згадано вище.
Ви можете налаштувати свій власний сервер за допомогою RabbitMQ, але не у випадку Amazon SQS, тому тут бере участь вартість.
Налаштування власного сервера вимагатиме знання предмета, щоб ви не залишили кут недоторканим. Це не стосується Amazon SQS, оскільки почати з нього досить швидко.
Ваш власний сервер RabbitMQ означає, що вартість технічного обслуговування нижча, ніж у випадку з Amazon SQS.
Оновлення:
SQS був би моїм уподобанням перед RabbitMQ, ось чому.
Однак RabbitMQ може забезпечити більш швидкий час відгуку на пути та отримання, як правило, через 10 тисяч TPS від мого тестування. Щоб SQS забезпечував таку пропускну здатність, вам доведеться масштабувати горизонтально за допомогою декількох екземплярів. Отже, якщо ви шукаєте менше 5 мс, RabbitMQ може бути варіантом для розгляду, оскільки я бачив близько 20 мс-30 мс часу випробування на SQS на 1000 с TPS, що трохи вище, ніж RabbitMQ.
Ми щойно перенесли нашу інфраструктуру обміну повідомленнями з ActiveMQ на SQS і не можемо бути щасливішими. Ми виявили, що це дешевше, ніж підтримка власного кластера ActiveMQ у хмарі.
Сподіваюся, це допомагає! Повідомте нас, як це відбувається ..
Я насправді використовував обидва в комерційному середовищі з розумним.
Коротка відповідь: якщо немає конкретних кутових випадків, краще скористатися AWS SQS. (Ви можете перейти до кінця, щоб отримати простий підсумок)
Кодування (Tie): RabbitMQ та AWS SQS мають створені бібліотеки та безліч прикладів.
Час очікування видимості (SQS): Одне, що пропонує SQS через RabbitMQ, - це більш широке поняття часу очікування видимості. У RabbitMQ, якщо споживач помирає до того, як він заблокується, повідомлення повертаються назад у чергу. Але SQS має більш широке уявлення про час очікування видимості, яке не прив'язане до конкретного абонента. Таким чином, ви можете розпочати одиницю роботи, встановити видимість із великим тайм-аутом (до 12 годин), відключитись, допрацювати ще одного працівника та перевірити його. За моїм задумом, ми широко використовуємо це і усунули додаткові послуги / сховища для управління потенційно великими корисними навантаженнями, що виконуються.
Обробка мертвих листів (RabbitMQ - «заєць»). SQS забезпечує основну передачу мертвих листів, що вони називають «політикою повторного керування», яка скидає повідомлення до черги мертвих листів (просто черги). Це основне і має лише поняття про кількість повідомлень. У RabbitMQ є біржі мертвих листів, які забезпечують надсилання повідомлень у Int DLE після закінчення терміну їх дії. Але це свого роду спірне питання, оскільки ідея "Якщо ви не стежите за тим, чи термін дії ваших служб і повідомлень закінчується, це потрапить у ДЛЕ". Це невеликий виграш для RabbitMQ, оскільки я вважаю цей аргумент інтуїтивним. Чому ви стежите за своєю чергою, а не за послугами? (Якщо що, то все навпаки)
Адміністрування (SQS): Адміністрування SQS відсутнє. Ви просто платите за дзвінки через API. Усі звичайні головні болі, такі як виправлення безпеки для ОС / програми, масштаб (додайте більше вузлів), диск обробляються командами AWS. Він також відповідає стандарту FedRamp (для державного використання). Це справді система "налаштування і забуття". Якщо RabbitMQ вимагає звичайних виправлень для ОС / сервісів, AMI, кластеризацію, посилення безпеки тощо. Хоча це надзвичайно рідко, AMI можуть падати або іноді вимагати переміщення, тому кластеризація потрібна нестандартно. SQS усуває всі ці головні болі.
ВАРТІСТЬ (SQS): Один виклик API SQS може включати "пакет до 10 повідомлень / розмір 256 тис.", А "тривале опитування" може різко скоротити вартість. Крім того, існують такі стратегії, як стиснення повідомлень, щоб переслати десятки (деякі заявляють сотні або більше) повідомлень, які можуть бути надіслані в одному корисному навантаженні, щоб додатково зменшити вартість. І це до того, як ми врахуємо час, який люди витрачають на моніторинг / виправлення / виправлення проблем. SQS також чудово підходить для "проектів", так як якщо він сидить без діла, це не коштує.
FIFO (TIE): У 2016 році AWS представила підтримку FIFO за додаткову вартість ~ 0,01 дол. США / млн. Дзвінків API (0,05 дол. США проти 0,04 дол. США за мільйон усіх API - до знижок). Ви можете вибрати використовувати FIFO чи ні. Для не-FIFO ми рідко бачимо дублікати повідомлень.
Зберігання (SQS): AWS не стягує плату за зберігання, але у вас обмеження на 14 днів. На RabbitMQ вам доведеться розподіляти, розширювати та керувати дисковим простором, що вимагає пікової ємності та додаткових буферів. Це просто більше головних болів.
Метрики (SQS): SQS надає готові метрики. І хоча ви могли б додати їх до AWS, це просто більше роботи.
Місцевий розробник: більшість сучасних магазинів люблять мати місцеве оточення. Зараз є кілька варіантів, які дозволяють докерам RabbitMQ та SQS.
Висока пропускна здатність / дуже велике повідомлення (RabbitMQ - начебто). Коли ви натискаєте SQS> 1000 запитів / сек, затримка SQS зростатиме. Є кілька стратегій, щоб обійти це. Але я вважаю, що ці випадки надзвичайно рідкісні, оскільки більшість робіт можна розділити на кілька черг. Але для таких випадків, коли потрібно 100 к / с, я вважаю, що Кафка краще. (Ми також використовуємо Кафку на своїй роботі) Рідко буває одна одиниця роботи, яка вимагає 1000+ запитів / секунду з низькою затримкою. * Див. Далі це пояснення
Короткий зміст: Якщо ви збираєтеся бути в AWS і бажаєте одружитися на SQS, то SQS - це не простий спосіб. Але вам слід читати далі, оскільки є важливі речі, які слід врахувати.
Класична стратегія для RabbitMQ (та інших черг) полягає у створенні декількох типів черг, оптимізованих для певних видів робіт. Потім точно налаштуйте кожну з цих черг та згрупуйте подібні роботи за невеликою кількістю цих (часто дуже великих за розміром) черг. Оскільки SQS не має адміністративних накладних витрат, насправді краще виділити виділену чергу для кожної роботи. Роблячи це, це дозволяє масштабувати, а також усуває насиченість черги (неправомірна робота, що насичує чергу та заглушає інших працівників), покращує огляд роботи (метрики за замовчуванням) тощо.
Нова стратегія дозволила моїм командам краще бачити розподіл роботи. Часи "оновлення екземпляра для більшого навантаження" минули. У минулому ми побачили б великий незрозумілий сплеск, який спричинив би побічні ефекти для інших служб або просто здогадався, що сукупні цифри виглядають абсолютно правильно '. Тепер, коли трафік відокремлений, ми фактично розкрили багато проблем, які раніше залишалися непоміченими, і можемо чітко пояснити, скільки трафіку куди йде. І хоча дуже можливо впровадити метрики та інструменти, SQS надає все це нестандартно.
Ще є великі випадки, коли 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.
Якщо ви чутливі до вартості, Amazon SQS, мабуть, працює дорожче. Я кажу, мабуть, тому, що вам все одно потрібно десь розмістити ваш сервер RabbitMQ. SQS надає вам перші мільйони запитів безкоштовно, а потім стягує 0,4 дол. США за це за мільйон запитів. Існує хитрість, щоб зменшити ваші витрати за допомогою SQS, хоча, увімкнувши тривале опитування, тобто встановивши для параметра receive_message_wait_time значення 20 секунд. Це не означає, що ваші повідомлення надсилатимуться лише кожні 20 секунд, це швидше означає, що SQS не стягуватиме з вас "запит", якщо ваша черга порожня (кожні 20 секунд).
Якщо ви використовуєте 1000 запитів на годину, ви переглядаєте 744000 на місяць. Безкоштовно в межах вільного рівня і приблизно 0,74 * 0,4 $ = 0,2976 $ поза рівня. Що ви, можливо, могли б ще зменшити, включивши час очікування. Отже, у вашому випадку SQS може насправді працювати дешевше, оскільки більшість хостингів починається мінімум з 5 доларів США (якщо у вас немає вільного рівня EC2 від AWS). З найменшим варіантом у вас повинно бути добре, оскільки RMQ рекомендує запускати близько 128 МБ оперативної пам'яті.
Я вважаю, що SQS набагато зручніший для користувачів, а RabbitMQ - більш технічний, якщо ви так схильні.
Оновлення:
Я насправді знайшов AWS Simple Notification Service, який більше підходить для того, що мені потрібно https://stackoverflow.com/a/13692720/5403449, в першу чергу тому, що він працює на основі push, тобто не опитує