Очереди сообщений против очереди таблицы БД через CRON

Question

У нас скоро будет большой проект с довольно большой обработкой мультимедиа (изображения, видео), а также вывод электронной почты и т. Д., Такого рода вещи, которые мы обычно помещаем в таблицу с именем "email_queue", и мы используем cron для запуска скрипта обработайте очередь в таблице.

Я много читал о системах очереди сообщений, таких как beanstalkd, и даже настроил их. Его было легко и приятно использовать, проблема в том, что я не уверен, что я что-то упустил.

Может ли кто-нибудь подробно рассказать о преимуществах использования системы очередей, а не таблицы и CRON? Поскольку я действительно не вижу, что они из себя представляют.

Спасибо

Answer 1

Отличия:

1. Как только сообщение помещено в очередь, оно может быть немедленно доставлено. Таким образом, если ваш cron обычно запускается каждые 5 минут, вы можете обрабатывать его быстрее.

2. Если ваша система очереди поддерживает транзакции, то она автоматически повторно доставит сообщение, если обработка не удалась.

3. Может быть сложнее запросить то, что находится в вашей очереди. У таблицы базы данных есть хороший способ поиска (sql).

4. Если у вас есть несколько серверов / процессов / потоков, обрабатывающих сообщения, система очередей будет следить за тем, чтобы сообщение доставлялось только одному из них. С таблицей БД вы должны обрабатывать это с помощью кода приложения (блокировка, флаги и т. Д.)

Answer 2

Очередь сообщений (по крайней мере распределенная, например, RabbitMQ ) дает вам возможность распределять работу по физическим узлам. Вам все еще нужно иметь процесс на каждом узле, чтобы исключить работу и обработать ее.

Я полагаю, это в конечном итоге сводится к вашим требованиям. Вы можете получить более управляемое решение в масштабе с использованием очередей сообщений: вы можете легче разъединить ваши узлы.

Конечно, есть кривая обучения ... так что она снова возвращается к вашим целевым целям.

---

Обратите внимание, что на каждом узле вы все еще можете повторно использовать свою таблицу cron / db, пока (и если) не захотите изменить реализацию. Вот что здорово в разделении, когда ты можешь .

Answer 3

Во-первых, очереди часто поддерживаются реальными таблицами БД и могут поддерживать устойчивость сообщений. Кроме того, очередь является естественным способом отодвинуть работу, которая должна выполняться асинхронно, что, если вы разрабатываете этот принципал с самого начала, очень мощно.

Кроме того факта, что таблица (сущность) имеет набор жестких столбцов (атрибутов), и эта таблица состоит из набора составляемых записей, а также очереди, это не что иное, как списки материалов, которые вы используете. queue-as-a-table как формальная очередь, просто при регулярном (cron) опросе.

В MQ добавлена ​​еще одна изящная функция, хотя обычно для синхронизации доступа к самому сообщению (вы можете или не можете делать это в своем SQL, чтобы получить следующую вещь).

Мне нравится рассматривать механизм cron / table как основанный на POLL, а MQ - как основанный на EVENT.

Преимущество очереди, по моему мнению, заключается в том, что она заботится о синхронизации, обновлении статуса. MQ можно настроить на «трансляцию» (тему) или сделать сообщение доступным для группы потребителей или слушателей.

MQ, хотя асинхронный, скорее всего, будет работать между вашим окном cron. Откуда вы знаете, что количество сообщений, которые вы обрабатываете в своей таблице, может быть выполнено до того, как будет выполнено следующее задание cron и попытается выполнить предыдущее задание?

Несколько потребителей для MQ позволяют вам масштабировать работу по своему усмотрению. В приведенном выше примере, если вы увидели, что ваш load average (точно такой же в очереди процессов ОС) больше, чем вам нравится, вы можете выделить другого потребителя для обработки указанной нагрузки, включая и отключая его по мере необходимости.

MQ могут быть настроены на разные рабочие параметры, такие как приоритет сообщений и производительность (некоторые очереди могут оставаться в памяти, другие сохраняются на диске).

Недостаток - это то, что (как уже упоминалось) иногда затрудняет запрос к очереди и для которой можно получить метрики. Я всегда нахожу системы MQ с резервным хранилищем БД, так что я могу сам наблюдать за очередью с помощью SQL.

Answer 4

Этот вопрос задают довольно часто, и обычно нет веских причин использовать MQ, если вы знакомы с базами данных. Вот один пример потока .

Я полагаю, что вы, возможно, захотите избежать кривой обучения, если ваши требования к данным не включают исключительно большие объемы, что маловероятно, если вы занимаетесь хронологией, а не процессом с таймером (гораздо реже с несколькими процессами с таймерами).