Асинхронная обработка данных: RabbitMQ, Comet

4,544 views

Published on

РИТ-2013: Доклад о решениях по асинхронной обработке данных, внедреннных в Мамбе. 1) собственный Comet-сервер, 2) Неудачное внедрение Gearman, 3) RabbitMQ: основы работы, тонкости и особенности внедрения.

Published in: Technology
3 Comments
6 Likes
Statistics
Notes
  • На 15-м слайде показано время работы скрипта формирования страницы сообщения. В момент, указанный стрелкой, доля сообщений, проходящих через RabbitMQ, увеличивается с, кажется, 50% до 100%. Ну то есть видно, что скрипт, с точки зрения автора сообщения, стал отрабатывать быстрее (слева - шкала в мс).
    Понятно, что чуда не произошло, нагрузка никуда не делась, но часть стадий обработки письма (те, которые выделены зеленым на 17-м слайде) стали обрабатываться консьюмер-скриптами из RabbitMQ.
    В результате общая нагрузка на серверную ферму осталась прежней, но латентность сервиса для пользователей уменьшилась. Кроме того, это развязало нам руки и мы стали способны проводить длительные проверки контента сообщения так, чтобы автор сообщения быстро получал обратно фокус и мог начинать писать следующее.
       Reply 
    Are you sure you want to  Yes  No
    Your message goes here
  • Что происходит на 15-ом слайде?
       Reply 
    Are you sure you want to  Yes  No
    Your message goes here
  • если в кролика очень быстро(менее чем за секунду) пульнуть пачку( ~ 10-15k ) сообщений и их никто не разбирает, то дальше он через tcp backpressure начинает тормозить sender'а.

    и это грустно, потому что забрать могут и позже.
       Reply 
    Are you sure you want to  Yes  No
    Your message goes here
No Downloads
Views
Total views
4,544
On SlideShare
0
From Embeds
0
Number of Embeds
795
Actions
Shares
0
Downloads
17
Comments
3
Likes
6
Embeds 0
No embeds

No notes for slide

Асинхронная обработка данных: RabbitMQ, Comet

  1. 1. Асинхронная обработкаданных: RabbitMQ, CometАндрей Федоровский
  2. 2. Задачи для асинхронной работы• Интерактивный интерфейс, подписка на события• Взаимодействие со внешними, неподконтрольными сервисами• Медленный процессинг заданий
  3. 3. Comet• Браузер открывает соединение к серверу*• Для клиента создается личный канал• Клиент подписывается на него и на общие каналы, например, счетчикколичества людей онлайн• Пользователю приходит сообщение – PHP через Comet сервер отправляетего в сокет клиента.* Единое для всех вкладок и окон. Подробности здесь:Highload++ 2012, Г.Арестов. «Использование Comet для создания интерактивных интерфейсов»
  4. 4. Comet сервер• 4 http-front• 1 брокер• 1 хаб
  5. 5. Gearman• Деградировала производительность с ростом длины очереди• Клиент странно работал с резервирующими серверами• Очередь в памяти + внешний сторадж: Mysql или Tokyo Cabinet*• Ну и просто медленно работал* Highload++ 2012, Д. Ананьев. «Практические вопросы использования NoSQL в высоконагруженном проекте»
  6. 6. И снова Comet• 50.000 сообщений в секунду на ядро (тест, 200 байт/сообщение)• 600.000 очередей (прямо сейчас в продакшне)• Собственная разработка – проще развивать• Превосходный параллелизм
  7. 7. И снова Comet• 50.000 сообщений в секунду на ядро (тест, 200 байт/сообщение)• 600.000 очередей (прямо сейчас в продакшне)• Собственная разработка – проще развивать• Превосходный параллелизмНО• Нет гарантии доставки• Нет надежного хранилища очередей• Нет защиты от падений• Не тестировали на длинных очередях
  8. 8. Требования• Гарантия доставки сообщения• Сохранность сообщений при авариях разного вида• Распределенность: параллелизуемость, устойчивость• Клиентские библиотеки для php, c++• Скорость работы: 1-10 тысяч сообщений на 1 ядро
  9. 9. Что есть на рынке• ActiveMQ – Java, JMS• Kafka – спроектирована под логи, держит малое число очередей• RabbitMQ – Erlang, AMPQ 0.9• ZeroMQ – голая платформа
  10. 10. RabbitMQ• Publisher• Exchange• Queue• Consumer• Binding
  11. 11. RabbitMQ: гарантии доставки• Confirm: брокер сообщает отправителю, что сообщение успешнопоставлено в очередь• Ack[nowledge]: получатель сообщает брокеру, что сообщение обработанологикой приложения. Приложение также может явно отправить NACK.• Durable queue / persistent messages: произошел fsync очереди / сообщенияна диск. По умолчанию – периодически.• Транзакции: fsync происходит гарантированно, но это сильно замедляет.• AMQP heartbeat.
  12. 12. RabbitMQ: несколько серверов• Clustering – единый виртуальный брокер. На серверах одинаковое ПО,находиться должны рядом. Сообщения передаются средствами Erlang.– Зеркалирование очередей по всем нодам кластера.Если падает мастер – из слейвов выбирается новый.• Federation – форвардинг сообщений между разными exchange средствамиAMQP. ПО может быть различным, сервера могут быть разнесены.
  13. 13. RabbitMQ в Мамбе• Кластер из 2 нод с полным зеркалированием очередей (haall)• Durable queues• Вместо AMQP heartbeat сделали TCP keepalive• Слейв в 3.0.4 слегка течет. Ждем фикса.• Prefetch 1 сообщения• Отдельная очередь для NACK, иначе во время аварии все тормозит.• 3 consumer сервера для разбора сообщений в 32 потока.
  14. 14. RabbitMQ в Мамбе
  15. 15. Процессинг сообщения• Сабмит сообщения на сайте, оно приходит на фронтенд• Проверки пользовательских настроек запрета доставки сообщений• Проверка на спам• Сохранение сообщения в шарде отправителя• Сохранение сообщения в шарде получателя• Генерация уведомлений: email, sms, comet и т.п.
  16. 16. Процессинг с RabbitMQ• Сабмит сообщения на сайте, оно приходит на фронтенд• Проверки пользовательских настроек запрета доставки сообщений• Проверка на спам• Сохранение сообщения в шарде отправителя• Сохранение сообщения в шарде получателя• Генерация уведомлений: email, sms, comet и т.п.
  17. 17. Итого, асинхронные решенияМежду клиентом и сервером• Realtime уведомления клиентао событиях для него• Очень большое числоклиентских соединений• Малая длина очередей• Ненадежное хранилищеComet серверМежду сервисами• Отложенная обработка событий• Фиксированное малое числоконнектов• Очень длинные очереди• Гарантии доставки, надежныйстораджRabbitMQ
  18. 18. Спасибо за внимание!Андрей Федоровскийfedorovsky@mamba.ru

×