Проектирование масштабируемой архитектуры очереди сообщений

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

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

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

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

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

Короче:

Это сложная проблема. Не изобретай велосипед.

Есть много технологий, которые решают уровень очереди сообщений. Они включают

• ZeroMQ
• RabbitMQ
• Апач Кафка
• Redis, с BLPOP или PUBSUB (я спрашивал, как это сделать здесь ).
• Другие реализации AMQP, кроме RabbitMQ

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

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

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

Узнайте о модели очереди обмена RabbitMQ / AMQP. Для вас может подойти маршрутизация - это поддерживается Redis PUBSUB, но я не помню, чтобы его поддерживал ZeroMQ - и разветвления - это то, чем пользовался мой магазин, хотя они и были плохо реализованы в опросе Memcached (чёрт!) Довольно долгое время ,

Как выбрать один?

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

• клиентские библиотеки действительно работают ? Легко ли поддерживать в них связь? (ZeroMQ, Redis: да. RabbitMQ: нет).
• Мониторинг и управление легко с консоли сервера? (Redis: да, RabbitMQ: да, ZeroMQ: не то, что я помню, но мы не использовали его так долго)
• поддерживают ли клиенты внутренние очереди, поэтому при коротких перебоях происходит небольшая потеря данных? (ZeroMQ, Redis: да. RabbitMQ: нет.)

Конечно, если вы работаете, скажем, в высокочастотном торговом магазине, это будет вашей меньшей заботой. Вы будете более готовы вкладывать время разработки в библиотеку на стороне клиента в обмен на более высокую пропускную способность в конце. Но я пишу это больше, чтобы предупредить вас, что эти технологии имеют тенденцию выходить на рынок на основе их производительности, а не их готовых функциональных возможностей. Если вы являетесь веб-стартапом, вас гораздо больше интересует последнее, чем первое, и, соответственно, что-то вроде Redis, которое более оптимизировано для простоты использования при хорошей производительности, чем для сложности использования при высокой производительности, вероятно, лучший выбор, чем RabbitMQ. (Мне действительно не нравится RabbitMQ).