Мне нужно создать очередь для обработки. Сама очередь относительно низкая. Там может быть около 1000 записей в час. Выполнение каждой задачи может занимать около минуты каждый и обрабатываться почти сразу после добавления элемента в очередь.
Есть ли какая-то причина, по которой я, возможно, захочу реализовать RabbitMQ вместо чего-то, как у Amazon SQS? Каковы некоторые причины, по которым для приложения потребуется отдельная система очередей, а не что-то вроде SQS?
Для начала Amazon SQS является псевдо-очередью, что означает, что доставка каждого сообщения (если он достигает очереди) гарантируется, но не в режиме FIFO, который обычно происходит в очереди.
Если порядок сообщений важен для вас, и вы хотите, чтобы очередь работала в режиме FIFO, в документации по SQS от Amazon говорится об этом в логике вашего приложения, так как сообщения из SARS Amazon выходят наружу.
По сравнению с этим, насколько я знаю, вы можете реализовать рабочие очереди в RabbitMQ. Если это избавит вас от реализации последовательности очередей сообщений на уровне приложения, это будет более предпочтительным вариантом.
Вот несколько факторов, которые помогут вам решить, к кому идти:
Последовательность сообщений очереди, как указано выше.
Вы можете настроить свой собственный сервер с помощью RabbitMQ, но не в случае Amazon SQS, поэтому здесь задействована стоимость.
Настройка вашего собственного сервера потребует хорошего знания предмета, чтобы вы не оставили ни одного нетронутого угла. Это не относится к Amazon SQS, так как это довольно быстро начать.
Ваш собственный сервер RabbitMQ означает стоимость обслуживания по линии, которая не соответствует Amazon SQS.
Обновления:
SQS будет моим преимуществом над RabbitMQ, вот почему.
Однако RabbitMQ может обеспечить более быстрое время отклика для puts и получает, как правило, в 10s тысяч TPS из моего тестирования. Для SQS для обеспечения такой пропускной способности вам придется масштабироваться горизонтально с несколькими экземплярами. Таким образом, если вы ищете менее 5 мс, RabbitMQ может быть вариантом для рассмотрения, потому что я видел близко к 20 мс-30 мс времени от моего тестирования SQS на 1000 с TPS, что немного выше, чем у RabbitMQ.
Мы просто перенесли нашу инфраструктуру обмена сообщениями из ActiveMQ в SQS и не можем быть более счастливыми. Мы обнаружили, что это дешевле, чем поддержка нашего собственного кластера ActiveMQ в облаке.
Надеюсь это поможет! Дайте нам знать, как это происходит.
Я на самом деле использовал оба в коммерческой среде с разумным.
Короткий ответ: если нет особых angular случаев, лучше использовать AWS SQS. (Вы можете перейти к нижней части для простого резюме)
Кодирование (Tie): У 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): Один вызов API SQS может включать в себя "пакетную обработку до 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 лучше. (Мы также используем Кафку на моей работе) Редко иметь одну единицу работы, которая требует 1000+ запрос/секунду с низкой задержкой. * Подробнее об этом см. ниже
Резюме: Если вы собираетесь работать в AWS и хотите вступить в брак с AQS, тогда 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.