Revelando el video en vivo de Facebook transmitido por millones de personas
El autor / Abhishek Mathur es
actualmente el PM técnico del grupo de Facebook, responsable de la infraestructura de transmisión de video y en vivo de Facebook. Se desempeñó como director de proyectos y director de desarrollo de Microsoft, responsable del desarrollo de Azure Active Directory.
Hace unos meses, comenzamos a lanzar la función Live de Facebook Mentions, que permite a figuras públicas certificadas transmitir videos en vivo de sus fans en Facebook a través de Mentions. Hemos aprendido mucho en esta implementación y ya hemos comenzado a probar la función para compartir videos en vivo que usan los usuarios de Facebook. El primer paso es comenzar con este pequeño grupo de usuarios de iPhone en los Estados Unidos.
La creación de una transmisión de video en vivo para Facebook es una actividad de ingeniería desafiante a gran escala. En la función Live de Facebook Mentions, debemos solucionar el problema de los picos de tráfico enormes. Puede haber hasta un millón de fanáticos de figuras públicas en Facebook, y todos estos fanáticos quieren ver el video al mismo tiempo; también tenemos otro objetivo, que es crear una nueva forma de equilibrar la carga. Para comenzar la transmisión de video en vivo a más personas, redujimos el retraso de la transmisión en vivo a unos segundos al permitir que RTMP se reproduzca. Esperamos que estas transmisiones en vivo de baja latencia mejoren la experiencia del usuario y permitan una mayor interacción entre las emisoras y los espectadores. En este artículo, echaremos un vistazo a los problemas que resolvemos en cada versión, y también le explicaré las soluciones que hemos elegido para los problemas de equilibrio de carga y de implementación de RTMP.
Resolver el problema del "efecto de grupo impactante"
Hay millones de fans de algunas figuras públicas en Facebook. Esto significa que cuando las figuras públicas inician una transmisión de video en vivo, necesitamos poder manejar la situación potencial en la que más de un millón de personas ven la transmisión en vivo al mismo tiempo, como la transmisión en vivo de Van Diesel. A los sistemas a gran escala no les gustan los picos de tráfico, especialmente cuando muchas solicitudes ocurren juntas en un instante. Siempre que esto sucede, decimos que nos hemos encontrado con un problema de "efecto asombroso": demasiadas solicitudes pueden sobrecargar el sistema, provocando retrasos en las transmisiones en vivo, pérdida de información y desconexión.
Se puede decir que la mejor manera de prevenir la sobrecarga es evitar que la carga pase por la puerta. En lugar de permitir que el cliente se conecte directamente al servidor de transmisión en vivo, permitimos que la red de cachés perimetrales se distribuya globalmente.
En nuestra implementación, una transmisión de video en vivo se divide en segmentos HLS de 3 segundos. El reproductor de video que muestra la transmisión en vivo continuará solicitando estos segmentos. Un proxy HTTP en el centro de datos perimetral procesará la solicitud del segmento y el centro de datos verificará si el segmento ya existe en una caché perimetral. Si está en la caché, se devolverá. De lo contrario, el proxy emitirá una solicitud HTTP a la caché de origen, que es otra capa de almacenamiento en caché con la misma arquitectura.
Si el segmento no está en la caché de origen, debe realizar una solicitud al servidor que procesa esta transmisión de video en particular.
Luego, el servidor usa el segmento para devolver la respuesta HTTP, este segmento se almacena en caché en cada capa, por lo que el cliente recibirá este segmento antes. Con esta combinación, más del 98% de los segmentos ya están en la caché perimetral más cercana al usuario, y el servidor de origen solo recibirá una pequeña parte de la solicitud.
Esta solución es excelente, pero cuando se encuentra en nuestra escala, se producen algunas fugas: aproximadamente el 1.8% de las solicitudes pasan por la caché perimetral. Cuando se trata de millones de espectadores, este sigue siendo un gran número. Para asegurarnos de que la capa de origen no falle, aplicamos una técnica llamada solicitud de fusión.
Por lo general, las personas ven videos regulares que no son en vivo en diferentes momentos. Si algo se vuelve viral de repente, puede ver picos de tráfico, por lo que no hay una demanda de carga de equilibrio minuto a minuto en este sentido. Pero para la transmisión de video en vivo, una gran cantidad de personas verán el mismo video al mismo tiempo sin previo aviso, lo que causa un problema de carga y un problema de caché. Las personas solicitan el mismo segmento de video al mismo tiempo, y es posible que este segmento aún no esté en la caché. Si no hay un plan para evitar el efecto de grupo estruendoso, la caché perimetral devolverá fallos de caché para todas las solicitudes del cliente, y todas estas solicitudes encontrarán la caché de origen y luego fluirán más allá del servidor de transmisión en vivo. Esto significa que un solo servidor recibirá una gran cantidad de solicitudes.
Para evitar que esto suceda, la caché perimetral devuelve una falta de caché para la primera solicitud y luego coloca la siguiente solicitud en la cola. Una vez que la respuesta HTTP regresa del servidor, este segmento se almacena en la caché perimetral y también se accederá a la solicitud en cola como caché para obtener la respuesta perimetral.
Este método resuelve eficazmente el efecto de grupo y reduce la carga entregada al servidor de origen. El servidor de origen, a su vez, utiliza el mismo mecanismo para procesar solicitudes de múltiples cachés perimetrales; se puede solicitar el mismo objeto desde la caché perimetral en Chicago o desde la caché perimetral en Miami.
Menor latencia
Crear Live para menciones de Facebook es una actividad para garantizar que el sistema no se sobrecargue, mientras que crear Live para usuarios es una actividad para reducir la latencia. Es más probable que las figuras no públicas transmitan en vivo a un pequeño grupo de personas altamente interactivas. Nuestra principal prioridad es permitir que las personas tengan conversaciones cercanas a los efectos en tiempo real sin retrasos vergonzosos en la transmisión de datos. Con el fin de comprimir el retraso a 2 o 3 segundos de la transmisión, decidimos usar RTMP.
RTMP es un protocolo de transmisión que mantiene una conexión TCP persistente entre el reproductor y el servidor durante toda la transmisión en vivo. A diferencia de HLS, RTMP usa un modelo push. En lugar de solicitar cada segmento del reproductor, deje que el servidor continúe enviando datos de video y audio. Cuando las personas solicitan pausar y reanudar o el reproductor no está visible, el cliente aún puede emitir estas instrucciones.
En RTMP, la transmisión en vivo se divide en dos transmisiones: una transmisión de video y una transmisión de audio. Estos flujos se dividen en bloques de 4 KB, que se pueden multiplexar en una conexión TCP, es decir, los bloques de video y audio están intercalados. Cuando la velocidad de bits del video alcanza los 500 Kbps, en comparación con los 3 segundos de duración de cada segmento HLS, cada bloque es de solo 64 ms, lo que hace que el flujo a través de todos los componentes sea más fluido. Siempre que se codifiquen 64 ms de datos de video, la emisora puede enviar los datos; el servidor de transcodificación puede procesar este bloque y generar múltiples velocidades de bits de salida. El bloque se reenvía a través del proxy hasta que llega al jugador.
El modelo push más pequeños bloques reduce la demora entre las emisoras en vivo y los espectadores en un 80%, lo que resulta en una experiencia fluida e interactiva. La mayoría de los productos de transmisión en vivo utilizan HLS porque se basa en HTTP y es fácil de integrar con todas las CDN existentes. Pero queremos lograr el mejor producto de transmisión en vivo, por lo que decidimos implementar RTMP modificando nginx-rtmp y desarrollando un agente RTMP. Las lecciones aprendidas de la ruta HLS nos permitieron implementar una arquitectura RTMP que puede escalar efectivamente a millones de emisoras en vivo.
Sigue adelante
Hemos recibido muchos comentarios positivos sobre la función en vivo de las menciones de Facebook y estamos muy contentos de ver las ideas de la gente para esta nueva función en vivo. Si tiene alguna pregunta sobre cómo construimos Live, contáctenos en el sitio web de Ingeniería de Facebook.
Gracias al ingeniero, al PM y a todos los demás miembros del equipo que hicieron esto posible.
Inglés original:
https://code.facebook.com/posts/1653074404941839/under-the-hood-broadcasting-live-video-to-millions
Lectura relacionada
La tecnología de transmisión en vivo móvil optimiza la experiencia en segundos, haga clic en la imagen para leer (incluido PPT)
Este artículo fue traducido por Li Pan. Si desea obtener más información sobre el contenido técnico de la transmisión de video en vivo, siga la cuenta oficial de WeChat "ArchNotes" para leer los artículos de seguimiento. Indique que es de la arquitectura de alta disponibilidad e incluya el siguiente código QR
Arquitectura de alta disponibilidad
Cambiando la forma en que se construye Internet
Mantenga presionado el código QR para seguir la cuenta oficial de `` Arquitectura de alta disponibilidad ''
Vista previa del evento: el registro para el salón de tecnología "Evolución de la arquitectura bajo alta presión" el 25 de junio está completo. Puede hacer clic en la imagen a continuación para conocer el contenido del salón. Teniendo en cuenta que todavía hay una gran cantidad de usuarios que consultan cómo participar en este salón, puede verlo en línea a través de la siguiente página en vivo, o hacer clic para leer el texto original para ingresar:
http://e.vhall.com/104429432