Mi verdadera pregunta es, ¿puede la pila de tecnología anterior escalar 1 000 000 de mensajes por segundo (texto, imágenes, videos)?
Seguro que puede. Con el diseño adecuado y suficiente hardware. La pregunta que su cliente debería hacerse realmente no es si se puede hacer que sea tan grande, sino a qué costo y practicidad se puede hacer y si esas son las mejores opciones.
Veamos cada pieza que has mencionado:
nodo.js - Para una aplicación centrada en E/S, es una excelente opción para escalar a gran escala y se puede escalar implementando muchas CPU en un clúster (tanto multiproceso por servidor como multiservidor). La practicidad de este tipo de escala depende en gran medida del tipo de datos compartidos a los que necesitan acceder todos estos procesos del servidor. Por lo general, el almacén de datos finalmente termina siendo el cuello de botella más difícil de escalar porque es fácil agregar más servidores al procesamiento de solicitudes. No es tan fácil colocar más hardware en un almacén de datos centralizado. Hay formas de hacerlo, pero depende mucho de las demandas de la aplicación sobre cómo hacerlo y qué tan difícil es.
socket.io - Si necesita un envío de servidor eficiente de mensajes pequeños, entonces socket.io es probablemente la mejor manera de hacerlo porque es el más eficiente para enviar al cliente. Sin embargo, no es bueno en todos los tipos de transporte. Por ejemplo, no estaría moviendo imágenes o videos grandes a través de socket.io, ya que hay más formas diseñadas específicamente para hacerlo. Por lo tanto, el uso de socket.io depende mucho de para qué quiere usarlo exactamente la aplicación. Si desea enviar un video a un cliente, también puede enviar solo una URL y hacer que el cliente se dé la vuelta y solicite el video a través de una URL http normal utilizando tecnología conocida de alta escala.
Redis - Una vez más, excelente para algunas cosas, no excelente en todo. Entonces, realmente depende de lo que estés tratando de hacer. Lo que expliqué anteriormente es que el diseño de su almacén de datos y la cantidad de transacciones a través de él es probablemente donde radican sus problemas reales de escala. Si estuviera comenzando este trabajo, comenzaría con la comprensión de las necesidades de almacenamiento de datos para un servidor, transacciones por segundo de varios tipos, estrategia de almacenamiento en caché, redundancia, conmutación por error, persistencia de datos, etc... y diseñaría la alta escalar el acceso a los datos primero. No estaría completamente seguro de que redis fuera la opción preferida. Probablemente sugeriría que necesita un tipo de base de datos de gran escala como consultor al principio del proyecto.
Nginx - Muchos sitios de gran escala usan nginx, por lo que sin duda es una buena herramienta. Si es exactamente la herramienta adecuada para usted depende de su diseño. Probablemente trabajaría en esta parte al final porque parece menos central para el diseño y una vez que el resto del sistema esté diseñado, puede considerar lo que necesita aquí.
Entonces... estas son generalmente buenas herramientas para usar si se usan de la manera correcta. Redis sería un signo de interrogación según las necesidades de almacenamiento de la aplicación real (ha proporcionado cero requisitos y no se puede seleccionar una base de datos con cero requisitos). Una respuesta más razonada se basaría en reunir un conjunto de requisitos de alto nivel que analicen lo que el sistema debe poder hacer para servir a 1,000,000 de lo que sea. Esos requisitos podrían compararse con las capacidades conocidas de algunas de estas piezas para comenzar un estadio de béisbol en la escala de un sistema. Luego, tendría que armar algunas pruebas comparativas para ejecutar algunas pruebas en ciertas partes del sistema. Tanto el éxito del fracaso dependería de cómo se creó la aplicación y cómo se usaron las herramientas como de qué herramientas se seleccionaron. Es probable que pueda hacer una escala exitosa con muchos tipos diferentes de herramientas. Diablos, Facebook se ejecuta en PHP (bueno, un PHP personalizado altamente modificado que no es PHP típico en absoluto en tiempo de ejecución).
