Para manejar solicitudes web, hay dos arquitecturas web competidoras: arquitecturas basadas en hilos y basadas en eventos.
Arquitectura basada en hilos: La forma más intuitiva de implementar un servidor multiproceso es seguir el enfoque de subproceso por conexión. Es apropiado para sitios que necesitan evitar subprocesos para compatibilidad con bibliotecas no seguras para subprocesos.
También utiliza los mejores módulos de procesamiento múltiple para aislar cada solicitud, de modo que un problema con una sola solicitud no afectará a ningún otro.
Los procesos son demasiado pesados, con un cambio de contexto más lento y un mayor consumo de memoria. Por lo tanto, el enfoque de subproceso por conexión se utiliza para una mejor escalabilidad, aunque la programación con subprocesos es propensa a errores y es difícil de depurar.
Para ajustar el número de subprocesos para obtener el mejor rendimiento general y evitar la creación / destrucción de subprocesos, es una práctica común colocar un subproceso de despachador delante de una cola de bloqueo limitada y un grupo de subprocesos. El despachador bloquea en el zócalo para nuevas conexiones y las ofrece a la cola de bloqueo limitada. Las conexiones que excedan la limitación de la cola se descartarán, pero las latencias para las conexiones aceptadas se vuelven predecibles. Un grupo de subprocesos sondea la cola para las solicitudes entrantes, que luego serán procesadas y respondidas.
Desafortunadamente, siempre hay una relación uno a uno entre las conexiones y los hilos. Las conexiones de larga duración, como las conexiones Keep-Alive, dan lugar a una gran cantidad de hilos de trabajo que esperan en estado inactivo, p. acceso al sistema de archivos, red, etc. Además, cientos o incluso miles de hilos concurrentes pueden desperdiciar una gran cantidad de espacio en la memoria.
Arquitectura dirigida por eventos: El enfoque basado en eventos puede separar los subprocesos de las conexiones, que solo usan subprocesos para eventos en devoluciones de llamada o controladores específicos.
Una arquitectura basada en eventos consiste en creadores de eventos y consumidores de eventos. El creador, que es la fuente del evento, solo sabe que el evento ha ocurrido. Los consumidores son entidades que necesitan saber que el evento ha ocurrido. Pueden estar involucrados en el procesamiento del evento o simplemente pueden verse afectados por el evento.
El patrón del reactor: El patrón del reactor es una técnica de implementación de la arquitectura basada en eventos. En términos simples, utiliza un bloqueo de bucle de evento único en eventos que emiten recursos y los envía a los controladores y devoluciones de llamada correspondientes.
No es necesario bloquear la E/S, siempre que los controladores y las devoluciones de llamada para eventos estén registrados para ocuparse de ellos. Los eventos se refieren a instancias como una nueva conexión entrante, lista para leer, lista para escribir, etc. Esos manejadores / devoluciones de llamada pueden utilizar un grupo de subprocesos en entornos de núcleos múltiples.
Este patrón desacopla el código de nivel de aplicación modular de la implementación del reactor reutilizable.
Hay dos participantes importantes en la arquitectura de Reactor Pattern:
1. Reactor
Un Reactor se ejecuta en un hilo separado, y su trabajo es reaccionar a los eventos de E/S enviando el trabajo al controlador apropiado. Es como un operador telefónico en una empresa que responde llamadas de clientes y transfiere la línea al contacto apropiado.
2. Manejadores
Un controlador realiza el trabajo real que se realizará con un evento de E/S, similar al oficial real de la empresa con el que el cliente desea hablar.
Un reactor responde a los eventos de E/S enviando el controlador apropiado. Los manejadores realizan acciones sin bloqueo.
El patrón arquitectónico Reactor permite que las aplicaciones controladas por eventos demultiplexen y despachen solicitudes de servicio que se entregan a una aplicación desde uno o más clientes.
Un reactor seguirá buscando eventos e informará al controlador de eventos correspondiente para que lo maneje una vez que se active el evento.
El Patrón de Reactor es un patrón de diseño para demultiplexación síncrona y orden de eventos a medida que llegan.
Recibe mensajes, solicitudes y conexiones provenientes de múltiples clientes concurrentes y procesa estas publicaciones secuencialmente utilizando controladores de eventos. El propósito del patrón de diseño del Reactor es evitar el problema común de crear un hilo para cada mensaje, solicitud y conexión. Luego recibe eventos de un conjunto de controladores y los distribuye secuencialmente a los controladores de eventos correspondientes.
Evitar este problema es evitar el famoso problema: C10K.
En resumen: los servidores tienen que manejar más de 10.000 clientes concurrentes, y los hilos no pueden escalar las conexiones usando Tomcat, Glassfish, JBoss o HttpClient.
Entonces, la aplicación que usa el reactor solo necesita usar un hilo para manejar eventos simultáneos.
Básicamente, el Reactor estándar permite una aplicación principal con eventos simultáneos, al tiempo que mantiene la simplicidad del subproceso único.
Un demultiplexor es un circuito que tiene una entrada y más de una salida. Es un circuito utilizado cuando se desea enviar una señal a uno de varios dispositivos.
Un reactor permite que múltiples tareas que bloquean sean procesadas eficientemente usando un solo hilo. El Reactor también gestiona un conjunto de controladores de eventos. Cuando se le llama para realizar una tarea, se conecta con el controlador que está disponible y lo activa.
El patrón Reactor es usado por Node.js, Vert.x, Reactive Extensions, Jetty, Ngnix y otros.
Dejo link:
No hay comentarios.:
Publicar un comentario