Привет! На этот раз я собираюсь обсудить процесс построения очереди сообщений. Уже существует множество надежных, проверенных временем и готовых к работе решений (RabbitMQ, ZeroMQ и т. Д.). Так зачем мне писать собственную очередь сообщений с нуля?

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

Я поискал некоторые уже существующие библиотеки, но меня это не удовлетворило, и я решил начать разработку собственной очереди сообщений с нуля под названием RedisSMQ (Redis Simple Message Queue), которая могла бы максимально использовать Redis и Node.js для максимальной производительности. и простота использования.

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

1. Настойчивость.

2. Атомарность.

3. Отказоустойчивость и высокая доступность.

4. Мониторинг.

5. Простота и удобство использования.

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

Обзор базового RedisSMQ

Очереди

Очереди - это просто СПИСКИ с несколькими производителями и потребителями. Чтобы опубликовать сообщение в очереди, производители используют команду LPUSH.

У каждого потребителя есть уникальная очередь обработки, которая создается каждый раз при запуске потребителя.

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

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

Потребители

Потребитель - это отдельный процесс. Каждого потребителя можно запустить из CLI. Таким образом, потребителей можно рассматривать как «рабочих».

Каждая очередь может иметь неограниченное количество одновременных потребителей.

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

Сердцебиение

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

Считается, что потребитель активен и работает нормально, если его пульс отправляется в течение периода времени менее 10 секунд. Контрольный сигнал потребителя отправляется каждую секунду.

Уборщик мусора

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

У каждого потребителя есть экземпляр сборщика мусора.

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

Экземпляр сборщика мусора периодически сканирует все очереди обработки всех потребителей одной и той же очереди.

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

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

Статистика и мониторинг

RedisSMQ обновляет статистику всех потребителей и производителей каждую секунду. Статистика и мониторинг помогают нам:

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

Статистика предоставляется в режиме реального времени и включает:

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

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

Резюме

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

Чтобы получить более подробную информацию о RedisSMQ и его реализации, посетите страницу проекта на GitHub.