Hola Recientemente encontré una descripción bastante interesante de la arquitectura de los canales Pusher y decidí traducirla para usted. En mi opinión, el autor describió muy fácilmente los enfoques para construir una arquitectura altamente cargada y escalable. Lo más probable es que el artículo sea útil para principiantes, así como para especialistas de campos relacionados.
En la oficina de Pusher, tenemos un pequeño mostrador con un número cada vez mayor. Muestra el número de mensajes entregados para toda la existencia de canales Pusher. El viernes a las 22:20 UTC, el número aumentó en una categoría y alcanzó los 10,000,000,000,000. Tiene 13 ceros - 10 billones.
Puede pensar que el recuento total de mensajes es una métrica hinchada inútil. Pero ese número es un indicador clave del éxito de Pusher Channels, nuestro producto de comunicación en tiempo real. En primer lugar, este contador refleja la confianza depositada en nosotros por los usuarios. En segundo lugar, mide la escalabilidad de nuestro sistema. Para aumentar el número, en Pusher debemos asegurarnos de que los usuarios confíen en el envío de mensajes a nuestro servicio, y debemos estar seguros de que nuestro sistema es capaz de procesar estos mensajes. Pero, ¿qué debemos entregar 10 billones de mensajes? A ver
Alrededor de 200,000 mensajes se envían por segundo a través de los canales Pusher, y millones en las horas pico. Por ejemplo, cuando el New York Times utilizó el servicio para mantener a sus lectores informados sobre el progreso de las elecciones presidenciales de los Estados Unidos.
Veamos primero los canales Pusher como una gran caja negra a través de la cual van todos estos mensajes:
Pusher Channels es un sistema de tipo publicación-suscripción. Los clientes se suscriben a canales (por ejemplo, "btc-usd" o "private-user-jim"), mientras que otros clientes les envían mensajes. Si un millón de personas están suscritas al canal "btc-usd" y alguien envía el costo real de bitcoin allí, entonces los canales Pusher deberán entregar un millón de mensajes. Hacemos esto en unos pocos milisegundos.
Un servidor no puede entregar tantos mensajes en tan poco tiempo. Por lo tanto, utilizamos tres técnicas probadas en el tiempo: abanico, fragmentación y equilibrio de carga. Veamos qué hay en la caja negra.
Millones de suscriptores se distribuyen en aproximadamente 170 potentes servidores perimetrales, cada uno de los cuales tiene aproximadamente 20,000 conexiones. Cada uno de estos servidores recuerda la lista de canales que son interesantes para sus clientes y se suscribe a ellos en el servicio central de Redis . Incluso si 2000 clientes están interesados en "btc-usd" en el servidor perimetral, solo necesita suscribirse una vez. Por lo tanto, cuando llega un nuevo mensaje al canal, Redis envía 170 mensajes a servidores perimetrales, que ya envían 20,000 mensajes a sus suscriptores. Este enfoque se llama despliegue.
Pero el despliegue no es suficiente para nosotros, porque todavía hay un componente central de Redis a través del cual pasan todos los que envían mensajes. Esta centralización limita el número de mensajes enviados por segundo. Para evitar esta limitación, el servicio central de Redis consta de muchos fragmentos de Redis. Cada canal, a su vez, se adjunta al fragmento Redis mediante el hash de su nombre. Cuando el cliente quiere enviar un mensaje, va al servicio de descanso. Este último codifica el nombre del canal y, en función del resultado, determina el fragmento Redis necesario al que se debe enviar el mensaje. Este enfoque se llama fragmentación.
Parece que solo estamos cambiando la centralización de un servicio Redis a un servicio de descanso. Pero esto no es así, ya que el servicio de descanso en sí consta de unos 90 servidores que realizan el mismo trabajo: reciben solicitudes de publicación, calculan fragmentos de Redis y les envían mensajes. Cuando un editor quiere enviar un mensaje, va a uno de los muchos servidores de descanso. Este enfoque se llama equilibrio de carga.
Juntos, el abanico, el fragmentación y el equilibrio de carga permiten que el sistema tenga un componente central. Esta propiedad es clave para lograr la escalabilidad horizontal, que permite enviar millones de mensajes por segundo.
Examinamos los componentes centrales del servicio Pusher Channels, pero hay otras partes, como las métricas (cómo obtenemos este número de 10 billones), webhooks (cómo informamos a los clientes sobre eventos interesantes), autorización (restricción de acceso a canales), datos sobre activos usuarios, limitación de tarifas (¿cómo nos aseguramos de que nuestros clientes usen exactamente tantos recursos como pagaron y que no interfieran con otros clientes)? Toda esta funcionalidad adicional debe implementarse sin sacrificar el ancho de banda, el tiempo de entrega de mensajes y la disponibilidad de nuestro servicio en su conjunto.