Вторая часть занятия из курса Otus PHP Pro, посвященного очередям. Сегодня мы научимся:

  • настраивать RabbitMQ

  • использовать встроенные механизмы RabbitMQ

  • работать с Apache Kafka

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

Преподаватель: Михаил Каморин

Дата вебинара: 19.05.2022

/**/

RabbitMQ

Скорость и надежность

Basic publish: без гарантий доставки

(warning) здесь потеря данных нам не критична , например, в системах мониторинга процессов

Подтверждение доставки

Сохранение сообщений на диск

Скорость и надежность


Масштабирование RabbitMQ, способ №1: кластер

(звезда) Кластер содержит в себе неск инстансов, в то время как снаружи это выглядит как один инстанс

Особенности кластера

CAP: Consistency, Partition tolerance

  • Consistency: каждый клиент видит одно и то же

  • Partition tolerance: система продолжает работать, если рушится сетевая связанность (например, данные раздваиваются)

Публикация с подтверждением

Преимущества и недостатки кластеров

Масштабирование RabbitMQ, способ №2: Федерация

Особенности федерации

(звезда) Пример удобства: если одна очередь зависла/грузится и т.п., можно пользоваться в этот момент второй очередью/нодой

Согласованное хеширование

Как распределять сообщения по серверам (балансировать)? Варианты алгоритмов балансировки:

  • SERVER_ID = MSG_ID % SERVERS_CNT

    • плохо работает, если периодически меняется кол-во серверов

  • Согласованное хеширование:

    • вычисляем HASH(KEY): признак, по которому все сообщения попадут на 1 сервер/consumer

    • см. круги №2 и №3: от каждого сервера берется кусок, из этих кусков “собирается“ новый сервер

(warning) Примечание:


ПРАКТИКА

Проект под докером, с RabbitMQ: исходники (…)

Описание проекта

У нас приложение типа Twitter: сообщения, авторы, подписчики на авторов

Нужно оперативно доставлять сообщения подписчикам

(warning) важно соблюсти порядок публикации сообщений : сообщения одного юзера всегда будут складываться в одну очередь

(warning) см. Readme.md , тут вся инструкция по поднятию проекта под Windows в докере:

Лог работ:

Конфиг YAML:

Билдим:

  • см. docker-compose.yml : тут все порты

  • Выполняем composer install

  • Запускаем миграции:

  • Шлем тестовые твиты через Postman

Postman: Запуск в синхронном режиме

(т.е. последовательная доставка твита каждому подписчику)

Смотрим RabbitMQ

Мониторинг очереди:

  • 1й кружок — взятие сообщения

  • 2й кружок — обработка сообщения

Смотрим в код:

(звезда) видим что тут мы не в параллельном режиме работаем по рассылке

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

Теперь у нас 10 очередей:

Можем смотреть, как загружена каждая очередь в отдельности:

(минус) это не удобно, лучше исп. внешний мониторинг, см. ниже

Внешний мониторинг через Graphite

В коде: увеличиваем счетчик сообщений

Конфиг services.yml

тут настройки Graphite и очередей / consumer:

Открываем Graphite

(звезда) он будет источником данных для Grafana ниже

Открываем Grafana

… и визуализируем тут:

Выводим кол-во сообщений:

(звезда) если consumer часто падают, то стоит подумать о запуске/исп супервизора (скрипта-демона для мониторинга и рестарта таков)

(звезда) с разбиением серверов на сектора, балансировка будет все точнее (между нодами);

Кол-во секторов на нодах указывается тут:

Хорошая балансировка:


Домашнее задание


Дополнительные материалы


Tags

Комментарии закрыты