Instant Messaging Systems
Programming
System Analysis and Design
IT Infrastructure
Distributed systems
June 2018 26

Как Pusher Channels доставил уже 10.000.000.000.000 сообщений

Original author: Jim Fisher
Translation

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


В офисе компании Pusher у нас висит небольшой счетчик с постоянно увеличивающейся цифрой. Он показывает количество доставленных сообщений за всё время существования Pusher Channels. В пятницу в 22:20 по UTC число увеличилось на один разряд и достигло 10.000.000.000.000. В нём 13 нулей — 10 трлн.



Вы можете подумать, что счётчик общего количества сообщений — бесполезная кичливая метрика. Но это число — ключевой индикатор успеха Pusher Channels, нашего продукта для коммуникации в режиме реального времени. Во-первых, данный счётчик отражает доверие, оказанное нам пользователями. Во-вторых, он измеряет масштабируемость нашей системы. Чтобы цифра увеличивалась, мы в Pusher должны сделать так, чтобы пользователи доверяли отправку сообщений нашему сервису, и мы должны быть уверены в том, что наша система способна обработать эти сообщения. Но что нам стоит доставить 10 трлн сообщений? Давайте посмотрим.


В секунду через Pusher Channels отправляют около 200.000 сообщений, в пиковые моменты — миллионы. Например, когда New York Times использовала сервис, чтобы держать своих читателей в курсе хода выборов президента США.


Давайте сначала посмотрим на Pusher Channels как на большой чёрный ящик, через который проходят все эти сообщения:



Pusher Channels — это система типа publish—subscribe. Клиенты подписываются на каналы (например, “btc-usd” или “private-user-jim”), а другие клиенты отправляют в них сообщения. Если миллион человек подписан на канал “btc-usd” и кто-то отправит туда актуальную стоимость биткоина, то Pusher Channels нужно будет доставить миллион сообщений. Мы делаем это за несколько миллисекунд.


Один сервер не может доставить такое количество сообщений сообщений за столь короткое время. Поэтому мы используем три проверенных временем приёма: fan-out, шардинг и балансировку нагрузки. Давайте посмотрим, что там в чёрном ящике.



Миллионы подписчиков распределены по примерно 170 мощным edge-серверам, каждый из которых держит примерно 20.000 соединений. Каждый такой сервер помнит список каналов, которые интересны его клиентам, и подписывается на них в центральном Redis-сервисе. Даже если на edge-сервере 2000 клиентов заинтересованы в “btc-usd”, ему нужно подписаться на него всего один раз. Таким образом, когда в канал приходит новое сообщение, Redis отправляет 170 сообщений на edge-серверы, которые уже отправляют 20.000 сообщений своим подписчикам. Этот подход называется fan-out.


Но только fan-out нам недостаточно, поскольку всё равно есть один центральный Redis-компонент, через который проходят все, кто отправляет сообщения. Такая централизованность ограничивает количество отправляемых сообщений в секунду. Чтобы обойти это ограничение, центральный Redis-сервис состоит из многих Redis-шардов. Каждый канал, в свою очередь, прикреплён к Redis-шарду путём хеширования своего имени. Когда клиент хочет отправить сообщение, он идёт в rest сервис. Последний хеширует имя канала и по результату определяет необходимый Redis-шард, на который следует отправить сообщение. Такой подход называется шардинг.


Звучит так, будто мы просто сдвигаем централизацию с Redis-сервиса на rest-сервис. Но это не так, поскольку rest-сервис сам состоит из около 90 серверов, которые выполняют одинаковую работу: принимают запросы на публикацию, вычисляют Redis-шарды и отправляют на них сообщения. Когда паблишер хочет отправить сообщение, он идёт на один из многих rest-серверов. Этот подход называется балансировка нагрузки.


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


Мы рассмотрели центральные компоненты сервиса Pusher Channels, но есть и другие части, такие как метрики (как мы получаем это число в 10 трлн), webhooks (как мы сообщаем клиентам об интересных событиях), авторизация (ограничение доступа к каналам), данные об активных пользователях, rate limiting (как мы убеждаемся, что наши клиенты используют именно столько ресурсов, за сколько они заплатили, и что они не мешают другим клиентам). Весь этот дополнительный функционал должен быть реализован без ущерба пропускной способности, времени доставки сообщений и доступности нашего сервиса в целом.

+2
1.8k 11
Comments 2