Очереди сообщений По сравнению с Очередью Таблицы базы данных через КРОН
Для подробного объяснения см., что заголовок "Избегает Дублирования в const и не - const Функция членства", на p. 23, в Объекте 3 "Использования const, когда это возможно", в Эффективный C++ , 3-й редактор Scott Meyers, ISBN-13: 9780321334879.
Вот (упрощенное) решение Meyers:
struct C {
const char & get() const {
return c;
}
char & get() {
return const_cast<char &>(static_cast<const C &>(*this).get());
}
char c;
};
два броска и вызов функции могут быть ужасными, но это корректно. У Meyers есть полное объяснение почему.
4 ответа
Очередь сообщений (по крайней мере, распределенная, например, RabbitMQ ) дает вам возможность распределять работу по физическим узлам. У вас все еще должен быть процесс на каждом узле, чтобы исключить работу из очереди и обработать ее.
Я думаю, это в конечном итоге сводится к вашим требованиям. Вы можете достичь более управляемого решения в масштабе с использованием очередей сообщений: вы можете легче разделить узлы.
Конечно, есть кривая обучения ... так что снова нужно вернуться к вашим целевым целям.
Примечание что на каждом узле вы все еще можете повторно использовать свою таблицу cron / db, пока (и если) вы не захотите изменить реализацию. Вот что здорово в развязке, когда можно .
Отличия:
Как только сообщение помещено в очередь, оно может быть немедленно доставлено. Так что, если ваш cron обычно запускается каждые 5 минут, вы можете быстрее обрабатывать сообщения с очередями.
Если ваша система очередей поддерживает транзакции, то она автоматически повторно доставит сообщение, если обработка завершится неудачно.
Может быть сложнее узнать, что находится в вашей очереди. В таблице базы данных есть удобный способ поиска (sql).
Если у вас есть несколько серверов / процессов / потоков, обрабатывающих сообщения, система очередей будет следить за тем, чтобы сообщение было доставлено только одному из них. С таблицей БД вам нужно справиться с этим с помощью кода приложения (блокировка, флаги и т. Д.)
Этот вопрос задают довольно часто, и обычно нет веских причин переходить на MQ, если вы хорошо знакомы с базами данных. Вот один пример потока .
Я считаю, что вы можете избежать кривой обучения, если ваши требования к данным не включают исключительно большие объемы, что маловероятно, если вы используете cron, а не процесс с таймер (не говоря уже о нескольких процессах с таймерами).
Во-первых, очереди часто поддерживаются реальными таблицами БД и могут поддерживать надежность сообщений. Помимо этого, очередь - это естественный способ избавиться от работы, которая должна выполняться асинхронно, что, если вы проектируете на этом принципе с самого начала, очень мощно.
Помимо того факта, что таблица (сущность) имеет набор жестких столбцов (атрибутов), как эта таблица, состоящая из набора составляющих записей, так и очередь, являются не чем иным, как списками материалов. Вы используете очередь как таблицу в качестве формальной очереди, просто вы опрашивать его на регулярной основе (cron).
MQ добавляют еще одну отличную функцию, хотя обычно синхронизируют доступ к самому сообщению (вы можете или не можете делать это в своем SQL, чтобы получить следующее).
I хотелось бы рассматривать механизм cron / table как основанный на POLL, а MQ как на основе EVENT.
Преимущество очереди, на мой взгляд, состоит в том, что она заботится о синхронизации и обновлении статуса. MQ могут быть настроены для «широковещательной рассылки» (темы) или предоставления сообщения группе потребителей или слушателей.
MQ, хотя и асинхронные, скорее всего, будут работать между вашим окном cron. Откуда вы знаете, что количество сообщений, которые вы обрабатываете в своей таблице, может быть выполнено до того, как следующее задание cron запустится и попытается перейти на предыдущее задание?
Несколько потребителей для MQ позволяют вам масштабировать работу по своему усмотрению . В приведенном выше примере, если вы увидели, что ваша средняя загрузка (точно такая же в очереди процессов ОС)) больше, чем вам нужно, вы можете настроить другого потребителя для обработки указанной нагрузки, переводя ее в автономный режим как метрики спроса.
MQ могут быть настроены таким образом, чтобы иметь различные рабочие параметры, такие как приоритет сообщения и производительность (некоторые очереди могут оставаться в памяти, другие - на диске).
Обратной стороной является то (как уже упоминалось), что очередь Иногда бывает сложно запросить и получить метрики. Я всегда нахожу системы MQ, у которых есть резервное хранилище БД, так что я могу сам наблюдать за очередью с помощью SQL.