Очереди сообщений Очередь таблиц БД с помощью CRON

Ответ 1

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

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

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

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

Ответ 2

Отличия:

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

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

• Труднее запросить то, что находится в вашей очереди. Таблица базы данных имеет хороший способ поиска (sql).

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

Ответ 3

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

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

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

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

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

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

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

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

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

Ответ 4

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

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