Las aplicaciones en línea a gran escala han recorrido un largo camino en las dos décadas anteriores. Estas innovaciones han alterado nuestra percepción del desarrollo de software. Facebook, Instagram y Twitter, por ejemplo, son todas plataformas escalables.
Estos sistemas deben construirse para administrar volúmenes masivos de tráfico y datos, ya que miles de millones de personas los usan al mismo tiempo en todo el mundo. Esto es cuando diseño de sistemas entra en la imagen.
El proceso de establecer la arquitectura, las interfaces y los datos de un sistema que cumple con ciertos criterios se conoce como diseño del sistema. A través de sistemas cohesivos y eficientes, el diseño del sistema satisface las demandas de su negocio u organización.
Una vez que su empresa u organización haya determinado sus criterios, puede comenzar a incorporarlos en un diseño de sistema físico que satisfaga las demandas de sus consumidores.
Ya sea que elija ir con un desarrollo a medida, soluciones comerciales o una combinación de ambos, la forma en que diseñe su sistema determinará cómo lo construya.
Echaremos un vistazo detallado al diseño del sistema de la línea de tiempo de Twitter en esta publicación, completa con un tutorial. Empecemos.
Paso 1: Resuma el caso de uso y las restricciones
Caso de uso
- Un usuario sube un tweet.
- El servicio envía notificaciones push y correos electrónicos a los seguidores de tweets.
- Se visualiza la línea de tiempo del usuario (actividad del usuario)
- El usuario mira la línea de tiempo de inicio (actividad de las personas que el usuario sigue)
- Las palabras clave son buscadas por el usuario.
- El servicio es realmente accesible.
Fuera del ámbito
- Los tweets se envían a Twitter Firehose y otras transmisiones mediante este servicio.
- El servicio elimina tweets según la configuración de visibilidad del usuario.
- Si el usuario no sigue a la persona a la que se responde, oculta la respuesta.
- Observa la opción 'ocultar retweets'.
- Análisis
Restricciones y suposiciones
supuestos estatales
- El tráfico no se distribuye por igual.
- Debería ser sencillo enviar un tweet.
- A menos que tenga millones de seguidores, enviar un tweet a todos sus seguidores debería ser rápido.
- Hay 100 millones de usuarios activos.
- 15 mil millones de tweets cada mes o 500 millones de tweets cada día
- Cada tweet tiene un fanout de 10 entregas en promedio.
- Todos los días, fanout entrega 5 mil millones de tweets.
- Fanout entrega 150 mil millones de tweets cada mes.
- 250 mil millones de solicitudes de lectura mensuales
- 10 mil millones de búsquedas mensuales
Cronograma
- La línea de tiempo debe ser fácil de navegar.
- Twitter se trata más de leer que de escribir.
- Optimizar para lectura rápida de tweets
- El consumo de tweets lleva mucho tiempo.
Buscar
- El proceso de búsqueda debe ser rápido.
- Lleva mucho tiempo buscar.
Calcular uso
Tamaño de cada tuit:
- ID de tweet de 8 bytes
- ID de usuario de 32 bytes
- 140 bytes de texto
- medios: promedio de 10 KB
- Total: ~10 KB
Cada mes, se generan 150 TB de contenido de tweet nuevo.
- * 500 millones de tweets cada día * 30 días al mes * 10 KB por tweet
- En tres años, ha habido 5.4 PB de contenido de tweet nuevo.
Hay 100,000 solicitudes de lectura por segundo.
- * (400 solicitudes por segundo / mil millones de solicitudes por mes) 1 mil millones de solicitudes de lectura cada mes
Hay 6,000 tweets cada segundo.
- * (400 solicitudes por segundo / mil millones de solicitudes por mes) 1 mil millones de tweets cada mes
En fanout, se envían 60 mil tweets por segundo.
- Fanout entrega 150 mil millones de tweets cada mes* (400 solicitudes por segundo / mil millones de solicitudes por mes).
4,000 solicitudes de información cada segundo
- * (400 solicitudes por segundo / mil millones de solicitudes por mes) 1 mil millones de búsquedas cada mes
Algunas conversiones útiles
- Cada mes pasan 2.5 millones de segundos.
- 2.5 millones de solicitudes al mes a 1 solicitud por segundo
- 100 millones de solicitudes por mes x 40 solicitudes por segundo
- 1 millones de solicitudes por mes = 400 solicitudes por segundo
Paso 2: diagrama de alto nivel
Paso 3: Explicación de los componentes principales
Podríamos guardar los propios tweets del usuario para completar la línea de tiempo del usuario (actividad del usuario) en una base de datos relacional si envía un tweet. Es más difícil enviar tweets y desarrollar la línea de tiempo de inicio (actividad de las personas que sigue el usuario).
Una base de datos relacional típica se vería abrumada por la distribución de tweets a todos los seguidores (60 mil tweets entregados cada segundo). Probablemente querremos optar por un almacenamiento de datos de escritura rápida como una base de datos NoSQL o memoria caché.
La lectura secuencial de 1 MB desde la memoria toma aproximadamente 250 microsegundos, pero la lectura desde SSD toma 4 veces más y la lectura desde disco toma 80 veces más.
Un almacén de objetos se puede utilizar para almacenar datos como imágenes y videos.
- El servidor web, que actúa como proxy inverso, recibe un tweet del cliente.
- El servidor web envía la solicitud al servidor de la API de escritura.
- La API Write guarda el tweet en una base de datos SQL en la línea de tiempo del usuario.
La API de escritura se pone en contacto con Fan-Out Service y realiza las siguientes tareas.
- Encuentra a los seguidores del usuario en la caché de memoria consultando el servicio de gráfico de usuario.
- En un Memory Cache, el tweet se guarda en la línea de tiempo de inicio de los seguidores del usuario.
- 1,000 seguidores = 1,000 búsquedas e inserciones = operación O(n).
- El tweet se guarda en el Servicio de índice de búsqueda para una búsqueda rápida.
- El almacén de objetos se utiliza para almacenar medios.
- Envía alertas automáticas a los seguidores a través del Servicio de notificación.
- Para enviar alertas de forma asincrónica, utiliza una cola.
Podemos utilizar una lista nativa de Redis con la siguiente estructura si nuestra caché de memoria es Redis:
La línea de tiempo de inicio del usuario se actualizaría con el nuevo tweet, que se almacenaría en la memoria caché. Utilizaremos la siguiente API REST pública:
La línea de tiempo del usuario es vista por el usuario.
- El servidor web recibe una solicitud de línea de tiempo del usuario del cliente.
- El servidor web envía la solicitud al servidor de la API de lectura.
- La API de lectura consulta la base de datos SQL para el período de tiempo del usuario.
La API REST funcionaría de manera similar a la línea de tiempo de inicio, con la excepción de que todos los tweets se originarían en el usuario y no en las personas a las que siguen.
Un usuario busca palabras clave:
- El servidor web recibe una solicitud de búsqueda del cliente.
- El servidor web envía la solicitud al servidor API de búsqueda.
Paso 4: línea de tiempo de Twitter
La creación de una línea de tiempo es una tarea difícil. Se requiere un servidor de generación de línea de tiempo que se vincule a la web o servidores de aplicaciones.
Cada vez que un usuario inicia sesión, el servicio de línea de tiempo realiza un seguimiento de los tweets más recientes de los usuarios en la tabla de seguidores y actualiza la línea de tiempo del usuario.
Aquí no implementamos ningún tipo de sistema de clasificación; en cambio, asumimos que los 5 mejores tweets de los seguidores del usuario se presentan en la línea de tiempo en orden de tiempo de creación. Podemos mantener un límite de actualización de 50 tweets. Todavía dejamos de actualizar o construir una línea de tiempo después de alcanzar ese umbral hasta que el usuario actualice la página.
Las preocupaciones sobre la alta latencia y el rendimiento surgirán de la creación de feeds de usuarios en vivo. En cambio, crear una transmisión sin conexión que se pueda presentar al instante es la mejor manera de mejorar el rendimiento. Ejecute servidores de línea de tiempo dedicados que hagan ping al servidor de aplicaciones de forma regular para actualizar la fuente en función de la hora en que se creó.
El algoritmo de clasificación debe tener en cuenta señales cruciales y proporcionar peso para garantizar que la línea de tiempo de un usuario no esté dominada por material de una o más de las cuentas que sigue.
Más precisamente, podemos elegir funciones relacionadas con la relevancia de cualquier elemento del feed, como la cantidad de Me gusta, comentarios, acciones compartidas y tiempo de actualización. Cada uno de estos criterios debe usarse para calificar el tweet, y luego esa clasificación debe usarse para mostrar los tweets en la línea de tiempo.
¿Deberíamos alertar constantemente a los usuarios cuando haya nuevo contenido disponible para su suministro de noticias? Los usuarios pueden encontrar beneficioso recibir alertas cuando haya nuevos datos disponibles. Sin embargo, en los dispositivos móviles, cuando el uso de datos es bastante costoso, puede desperdiciar ancho de banda.
Como resultado, podemos optar por no enviar datos a los dispositivos móviles y, en su lugar, permitir que los usuarios "Pull to Refresh" para nuevas publicaciones.
Paso 5: Diseño a escala
Un cuello de botella potencial es el Servicio Fanout. Los usuarios de Twitter con millones de seguidores tendrán que esperar varios minutos para que se publiquen sus tweets. Esto podría provocar una carrera con las respuestas al tweet, lo que podríamos evitar reordenando los tweets en el momento del servicio.
También podríamos evitar la difusión de tuits de personas con un gran número de seguidores. En su lugar, podemos hacer una búsqueda de tweets de personas muy seguidas, integrar los resultados de la búsqueda con los resultados de la línea de tiempo de inicio del usuario y luego reordenar los tweets en el momento del servicio.
Las mejoras adicionales incluyen:
- Guarde solo unos pocos cientos de tweets en la caché de memoria para cada línea de tiempo de inicio.
- En la caché de memoria, solo se guarda la información de la línea de tiempo de inicio de los usuarios activos.
- Podemos reconstruir la cronología a partir de la base de datos SQL si un usuario no ha estado activo en los 30 días anteriores.
- Para averiguar quién es el usuario, utilice el Servicio de gráfico de usuario.
- Agregue los tweets a la caché de memoria recuperándolos de la base de datos SQL.
- El servicio de información de tweets solo puede guardar los tweets de un mes.
- En el Servicio de información del usuario, solo se guardan los usuarios activos.
- Para mantener baja la latencia, lo más probable es que Search Cluster necesite mantener los tweets en la memoria.
Conclusión
Aunque Twitter es una organización grande, tiene una mejor comprensión del diseño del sistema. Hice todo lo posible para brindarle una descripción general de alto nivel de la línea de tiempo de Twitter.
Espero que haya obtenido información útil de él y pueda darle un buen uso.
Deje un comentario