Мне нужно создать очередь на обработку. Сама очередь имеет относительно небольшой объем. В него может быть записано около 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 может обеспечить более быстрое время отклика для операций ввода и вывода, как правило, в десятки тысяч TPS по результатам моего тестирования. Чтобы SQS обеспечил такую пропускную способность, вам придется масштабировать по горизонтали с несколькими экземплярами. Поэтому, если вы ищете путы менее 5 мс, RabbitMQ может быть вариантом для рассмотрения, потому что я видел время задержки около 20-30 мс при тестировании SQS при 1000 с TPS, что немного выше, чем у RabbitMQ.
Мы только что переместили нашу инфраструктуру обмена сообщениями с ActiveMQ на SQS, и мы не можем быть более счастливыми. Мы обнаружили, что это дешевле, чем поддерживать собственный кластер ActiveMQ в облаке.
Надеюсь это поможет! Сообщите нам, как это происходит ...
Я фактически использовал оба в коммерческой среде с разумными.
Короткий ответ: если нет особых угловых случаев, лучше использовать AWS SQS. (Вы можете перейти к нижней части, чтобы получить простое резюме)
Кодирование (галстук): RabbitMQ и AWS SQS имеют установленные библиотеки и множество примеров.
Тайм-аут видимости (SQS): одна вещь, которую SQS предлагает поверх RabbitMQ, - это более широкое понятие тайм-аута видимости. В RabbitMQ, если потребитель умирает до того, как подтвердит, сообщения возвращаются в очередь. Но SQS имеет более широкое понятие тайм-аута видимости, которое не привязано к конкретному вызывающему абоненту. Таким образом, вы можете запустить единицу работы, установить видимость с большим таймаутом (до 12 часов), отключиться, закончить работу другого работника и подтвердить его. В моем дизайне мы широко использовали это и исключили дополнительное обслуживание / хранилище для управления потенциально большими «незавершенными» полезными нагрузками.
Обработка недоставленных писем (RabbitMQ - «зайцем») SQS обеспечивает базовую обработку недоставленных писем в том, что они называют «политикой перезагрузки», которая выгружает сообщения в очередь недоставленных писем (просто еще одну очередь). Он базовый и имеет только понятие количества сообщений. RabbitMQ имеет обмен мертвыми буквами, который обеспечивает отправку сообщений в DLE по истечении срока их действия. Но это своего рода спорный вопрос, поскольку идея «Если вы не наблюдаете за истечением срока действия ваших служб и сообщений, то они попадут в DLE». Для RabbitMQ это небольшая победа, поскольку я считаю этот аргумент интуитивно понятным. Почему вам нужно следить за своей очередью, а не за услугами? (Во всяком случае, это наоборот)
Администрирование (SQS): в SQS нет администрирования. Вы просто платите за вызовы API. Все обычные головные боли, такие как исправления безопасности ОС / приложений, масштабирование (добавление дополнительных узлов), диск, выполняются командами AWS. Он также совместим с FedRamp (для использования в правительстве). Это действительно система «установил и забыл». В то время как RabbitMQ требует обычных исправлений ОС / сервисов, AMI, кластеризации, усиления безопасности и т. Д. Хотя это крайне редко, AMI могут выйти из строя или иногда их нужно перемещать, поэтому кластеризация необходима из коробки. SQS устраняет все эти головные боли.
СТОИМОСТЬ (SQS): один вызов SQS API может включать «пакет до 10 сообщений / размер 256 КБ», а «длинный опрос» может значительно снизить стоимость. Кроме того, существуют стратегии, такие как сжатие сообщений для отправки десятков (некоторые утверждают, что сотни и более) сообщений могут быть отправлены в одной полезной нагрузке для дальнейшего снижения затрат. И это без учета времени, которое люди тратят на мониторинг / исправление / исправление проблем. SQS также отлично подходит для «poc-проектов», как будто он простаивает без каких-либо затрат.
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 будет увеличиваться. Есть несколько способов обойти это. Но я считаю, что такие случаи крайне редки, поскольку большую часть работы можно разделить на несколько очередей. Но для таких случаев, когда требуется 100k / sec, я думаю, что Kafka лучше. (Мы также используем Kafka в моей работе) Редко есть одна единица работы, которая требует 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, то есть не на опросе