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

Question

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

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

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

Спасибо

Answer 1

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

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

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

---

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

Answer 2

Различия:

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

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

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

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

Answer 3

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

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

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

Мне нравится рассматривать механизм cron / table как основанный на ОПРОСЕ, а MQ - как основанный на СОБЫТИЯХ.

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

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

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

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

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

Answer 4

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

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