1. Асинхронная обработка
данных: RabbitMQ, Comet
Андрей Федоровский

2. Задачи для асинхронной работы
• Интерактивный интерфейс, подписка на события
• Взаимодействие со внешними, неподконтрольными сервисами
• Медленный процессинг заданий

3. Comet
• Браузер открывает соединение к серверу*
• Для клиента создается личный канал
• Клиент подписывается на него и на общие каналы, например, счетчик
количества людей онлайн
• Пользователю приходит сообщение – PHP через Comet сервер отправляет
его в сокет клиента.
* Единое для всех вкладок и окон. Подробности здесь:
Highload++ 2012, Г.Арестов. «Использование Comet для создания интерактивных интерфейсов»

4. Gearman
• Деградировала производительность с ростом длины очереди
• Клиент странно работал с резервирующими серверами
• Очередь в памяти + внешний сторадж: Mysql или Tokyo Cabinet*
• Ну и просто медленно работал
* Highload++ 2012, Д. Ананьев. «Практические вопросы использования NoSQL в высоконагруженном проекте»

6. И снова Comet
• 70.000 сообщений в секунду на ядро (тест, 200 байт/сообщение)
• 600.000 очередей (прямо сейчас в продакшне)
• Собственная разработка – проще развивать

7. И снова Comet
• 70.000 сообщений в секунду на ядро (тест, 200 байт/сообщение)
• 600.000 очередей (прямо сейчас в продакшне)
• Собственная разработка – проще развивать
НО
• Нет гарантии доставки
• Нет надежного хранилища очередей
• Нет защиты от падений
• Из распределенной архитектуры – только шардинг

8. Что есть на рынке
• ActiveMQ – Java, JMS
• Kafka – спроектирована под логи, держит малое число очередей
• RabbitMQ – Erlang, AMPQ 0.9
• zeroMQ – голая платформа

9. RabbitMQ
• Publisher
• Exchange
• Queue
• Consumer
• Binding

10. RabbitMQ: гарантии доставки
• Confirm: брокер сообщает отправителю, что сообщение успешно
поставлено в очередь
• Ack[nowledge]: получатель сообщает брокеру, что сообщение обработано
логикой приложения. Приложение также может явно отправить NACK.
• Durable queue / persistent messages: произошел fsync очереди / сообщения
на диск. По умолчанию – периодически.
• Транзакции: fsync происходит гарантированно, но это сильно замедляет.
• AMQP heartbeat.

11. RabbitMQ: несколько серверов
• Clustering – единый виртуальный брокер. На серверах одинаковое ПО,
находиться должны рядом. Сообщения передаются средствами Erlang.
– Зеркалирование очередей по всем нодам кластера.
Если падает мастер – из слейвов выбирается новый.
• Federation – форвардинг сообщений между разными exchange средствами
AMQP. ПО может быть различным, сервера могут быть разнесены.

12. RabbitMQ в Мамбе
• Кластер из 2 нод с полным зеркалированием очередей.
• Durable queues
• Вместо AMQP heartbeat сделали TCP keepalive
• Слейв в 3.0.4, похоже, слегка течет. Ждем фикса.
• Prefetch 1 сообщения
• Отдельная очередь для NACK, иначе во время аварии все тормозит.
• 3 consumer сервера для разбора сообщений в 32 потока.

13. RabbitMQ в Мамбе

14. Процессинг сообщения
• Сабмит сообщения на сайте, оно приходит на фронтенд
• Проверки пользовательских настроек запрета доставки сообщений
• Проверка на спам
• Сохранение сообщения в шарде отправителя
• Сохранение сообщения в шарде получателя
• Генерация уведомлений: email, sms, comet и т.п.

15. Процессинг с RabbitMQ
• Сабмит сообщения на сайте, оно приходит на фронтенд
• Проверки пользовательских настроек запрета доставки сообщений
• Проверка на спам
• Сохранение сообщения в шарде отправителя
• Сохранение сообщения в шарде получателя
• Генерация уведомлений: email, sms, comet и т.п.

16. Спасибо за внимание!
Андрей Федоровский
fedorovsky@mamba.ru