Очередь сообщений. База данных против выделенного MQ

17

Я после совета относительно очереди сообщений. У нас есть требования для «заданий», которые будут опубликованы в очереди сообщений.

Первоначальным предложением было просто использовать экземпляр SQL Server и обрабатывать сообщения от него. Все, что я прочитал в Интернете, говорит о том, что использование базы данных для очереди сообщений не является масштабируемым решением. По этой причине была предложена идея использовать RabbitMQ или какой-либо другой сторонний MQ.

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

У нас уже есть база данных на наших клиентах, которую мы могли бы использовать для этого, чтобы она не добавляла дополнительной поддержки, необходимой нашим клиентам, тогда как если бы мы добавили сторонний MQ, то была бы дополнительная поддержка конфигурации сети и т. Д., Что Значительное количество пользователей много.

Другой вариант, который я рассматривал, позволял пользователям выбирать между ними. Если они малый пользователь, то решение Sql Server будет в порядке, но если они крупный пользователь, мы разрешаем им настраивать стороннее решение MQ.

Я не продам ни одного решения, мне интересно, есть ли у кого-нибудь что-то, что я должен рассмотреть или посоветовать.

user1653400
источник
1
Являются ли эти «задания» «запущенными и забытыми», или процессу придется позвонить домой, чтобы сообщить серверу о состоянии этой работы?
c_maker
Насколько масштабируемым это должно быть? Вы просматриваете несколько сотен тысяч сообщений в день или несколько миллиардов?
Blrfl
Спасибо за комментарии: существует требование, чтобы задание было помечено как неполное (считается выполненным, если не помечено как неполное / не выполненное). Я бы подумал не более 20 000 сообщений в день. Скорее всего всего несколько тысяч.
user1653400
Используйте наиболее подходящий инструмент для работы. Если вам нужна очередь сообщений, используйте очередь сообщений, а не базу данных. Я видел людей, использующих таблицы базы данных в качестве очередей сообщений, и считаю это анти-паттерном. Вы можете использовать отвертку в качестве молотка, но молоток работает лучше, если вам нужно вбить гвоздь. В большинстве случаев это происходит потому, что они понимают базы данных, а не очереди сообщений.
Джеспер
Здесь есть несколько хороших указателей: rusanu.com/2010/03/26/using-tables-as-queues
Майкл Грин

Ответы:

18

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

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

Ваш комментарий ссылается на скорость 20 000 сообщений в день, что означает, что вам нужно поддерживать среднюю скорость 0,23 сообщений в секунду (одно каждые 4,3 секунды). Если ваш проект окажется на два порядка успешнее, чем вы ожидали, ваши требования перейдут к обработке 23 сообщений в секунду, и это было бы заданием, которое мне было бы очень удобно отдать моему четырехлетнему мобильному телефону или Raspberry. Число Пи. Это все еще не масштабное приложение, даже если вы добавите еще пару порядков.

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

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

Blrfl
источник
У меня есть база данных, в которой ежедневно совершаются миллионы транзакций. который мне нужно обработать через смс. В настоящее время я использую таблицу SQL в качестве очереди, но я застреваю, когда собираю большое количество данных. Я не могу использовать MQ, потому что мне нужно направить мои смс на основе конфигурации в реальном времени. Если я использую MQ, то он не использует текущую конфигурацию для клиента. как мы меняем провайдера на бэкэнд, когда какой-то провайдер не может обработать Так ты парень, что предложить мне в моем сценарии?
Mayur Rathod
@mayurRathod Эта тема выглядит как корм для отдельного вопроса. Произносите это внимательно, потому что запрос конкретных инструментов или ресурсов будет закрыт как не по теме.
Blrfl
9

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

Если у вас есть только одна «очередь заданий», которую вы хотите обработать «в автономном режиме», тогда таблица SQL подойдет.

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

Ewan
источник
5

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

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

  1. Разрешить, что данные могут быть на мб, но не в дб
  2. Разрешить, что данные могут быть в дБ, но не в мб
  3. Установка двухфазной фиксации или распределенных транзакций между db и mq, которая может быть сложной

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

Эсбен Сков Педерсен
источник
4

Для практичности, основные причины использования очереди сообщений:

  • Мне не нужно было изобретать велосипед. Разработка даже самой простой очереди сообщений с использованием базы данных требует как минимум нескольких часов обдумывания, нескольких часов кодирования и так далее. По сравнению с реализацией очереди сообщений время, необходимое для настройки и / или автоматизации конфигурации, является тривиальным
  • Очереди сообщений имеют приятный и понятный интерфейс для производителя и потребителя. Это, наверное, самая важная вещь при написании приложения. Без интерфейса очереди сообщений - это просто набор данных.
  • Очереди сообщений дают больше возможностей, которые могут понадобиться в будущем

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

imel96
источник
1

Я создал решение для очереди сообщений Mssql, которое может обрабатывать 20 тыс. Операций в секунду в соответствии с тестом производительности, и большую часть времени нам требуется 10 / сек. Я думаю, что тот факт, что вы действительно можете иметь встроенный приоритет, является функцией, которой не хватает в выделенной очереди сообщений. И это было основным требованием в моем случае.

Стефан Райер
источник