¿Por qué se requiere una arquitectura asincrónica para lograr la escalabilidad? ¿Puede por favor proporcionar una aplicación / ejemplo de la vida real?

¿Puedes citar la fuente de la afirmación? Algunos dicen que asíncrono lo resuelve, algunos dicen que multihilo lo hará. No sé la respuesta, supongo que no hay una bala de plata, dependerá de lo que estés construyendo.

Lo que ocurre con la programación asíncrona es que no bloquea , por lo que incluso si no puede usar múltiples hilos, no necesita bloquear su hilo principal hasta que tenga la respuesta para cada instrucción / operación. Estrictamente hablando, no realizará dos cosas a la vez (dos operaciones en el tiempo de una instrucción de computadora), pero puede tener el hilo libre para nuevas instrucciones para comenzar o girar como si fuera simultáneamente.

Lo que esto significa para un servidor , como uno HTTP basado en Node, es que cada vez que hay una acción que pertenece a una instrucción, pero no requiere la CPU, los usuarios no necesitan esperar. Por ejemplo, si varios usuarios solicitan una página y en las instrucciones para responder hay varias otras solicitudes que son asíncronas (para la base de datos, el sistema de caché, etc.), el hilo no se bloqueará en espera de tales respuestas que en realidad no depende de ello. Debido a eso, el servidor podrá comenzar a responder varias solicitudes mucho más rápido que un servidor síncrono de bloqueo normal, que esperaría a que todo se haga dentro de una sola instrucción hasta que se libere el hilo.

Puede parecer que esto contribuye a la escalabilidad, pero de hecho es mucho más complicado que eso.

Ahora, cuando hablamos de arquitectura asincrónica, es otro nivel de pensamiento. “Recientemente”, muchos están tratando de llevar este concepto a lo que se llama arquitectura ” sin servidor “, lo que significa que solo las funciones / instrucciones puras se almacenan bajo un enfoque diferente, como AWS Lambda. Con eso, cada instrucción obtiene los recursos necesarios para ejecutarse solo cuando sea necesario y de forma asincrónica. El servidor y los recursos se administran automáticamente e, idealmente, no debe preocuparse. Eso, realmente suena como algo que puede conducir a una verdadera escalabilidad . Sin embargo, lo que escucho es que el enfoque no es aplicable al 100% de las bases de código y la forma de programar y conectar todas las partes sigue siendo muy diferente y nueva para que suceda perfectamente, especialmente la resolución de problemas.

P: ¿Por qué se requiere una arquitectura asincrónica para lograr la escalabilidad? ¿Puede por favor proporcionar una aplicación / ejemplo de la vida real?

Respuesta corta: no se requiere una ‘arquitectura asincrónica’ para lograr escalabilidad. Los subprocesos livianos son suficientes para lograr una arquitectura masivamente escalable (uso eficiente de recursos compartidos) sin la necesidad de E / S asíncronas o un modelo de programación complejo.

Vea la respuesta de Anton Carver a ¿Qué lenguajes de programación admiten hilos muy ligeros en su implementación de referencia?

Vea la respuesta de Anton Carver a ¿Qué idioma es mejor para cientos de miles de solicitudes simultáneas?

La E / S asincrónica es más aplicable a problemas relacionados con la comunicación en tiempo real, por ejemplo: video interactivo (videoconferencias), tickers de stock, etc.

Aclaración : por IO asíncrono, me refiero a IO impulsado por señal / interrupción. La mensajería asincrónica / RPC (donde el programador ejecuta otro hilo ligero en lugar de bloquear) es absolutamente un requisito de un sistema distribuido escalable. La respuesta de Anton Carver a ¿Por qué las cosas son difíciles de sincronizar en sistemas distribuidos?

Aclaración adicional: es la “realidad” la que es asíncrona, no la arquitectura del software.

Imagine un restaurante de Mc Donald’s con 4 empleados que sirven en el mostrador. En aras de la discusión, imagine que pueden tomar 4 clientes, 1 cada uno, al mismo tiempo, y no podrían servir el siguiente lote hasta que se atiendan los 4.

Ahora, puede ver que el tiempo para atender el lote dependerá del tiempo necesario para atender la solicitud que necesita más tiempo (ya sea porque el empleado es más lento que los demás o porque el pedido para cumplir es mayor). Los otros tres probablemente estarán inactivos esperando en el mostrador.

Ahora, imagine que para establecer que todo el mundo ha terminado, deben tocar el hombro de los demás cuando hayan terminado. La cantidad de tapping aumenta cuadráticamente con el número de empleados.

El desacoplamiento y la independencia permiten una paralelización masiva.