Computación de alto rendimiento [alto rendimiento de un solo servidor]

Por supuesto, la perspectiva del arquitecto debe prestar especial atención al diseño de la arquitectura de alto rendimiento, y el diseño de la arquitectura de alto rendimiento se centra principalmente en dos aspectos:

• Intente mejorar el rendimiento de un solo servidor y maximizar el rendimiento de un solo servidor
• Si un solo servidor no puede soportar el rendimiento, diseñe una solución de clúster de servidores

Además de los dos puntos anteriores, si el sistema final puede lograr un alto rendimiento también está relacionado con la implementación y codificación específicas. Pero el diseño de la arquitectura es la base de un alto rendimiento. Si el diseño de la arquitectura no logra un alto rendimiento, habrá un margen limitado para mejorar la implementación y la codificación específicas. Hablando vívidamente, el diseño de la arquitectura determina el límite superior del rendimiento del sistema y los detalles de implementación determinan el límite inferior del rendimiento del sistema.

Alto rendimiento de un solo servidor

Una de las claves para el alto rendimiento de un solo servidor es el modelo de programación de red adoptado por el servidor. Hay dos puntos clave en el diseño del modelo de programación de red:

• Cómo el servidor gestiona los enlaces
• Cómo el servidor maneja la solicitud

Y estos dos puntos están relacionados en última instancia con el modelo de E / S y el modelo de proceso del sistema operativo:

• Modelo de E / S: bloqueo, no bloqueo, síncrono, asíncrono
• Modelo de proceso: proceso único, proceso múltiple, hilo múltiple, hilo único

PPC

PPC es la abreviatura de Process per Connection, y su significado es crear un nuevo proceso cada vez que hay una nueva conexión para atender la solicitud de la conexión. Este es el modelo adoptado por el servidor de red UNIX tradicional. El proceso básico es el siguiente:

• El proceso padre acepta el enlace y luego bifurca el proceso hijo
• El proceso hijo procesa la solicitud relacionada con el enlace y luego el proceso hijo cierra la conexión
• Después de que el proceso principal bifurca el proceso secundario, llama a close. De hecho, no cierra la conexión, sino que reduce el recuento de referencias del descriptor de archivo conectado. Cuando la conexión se cierra realmente, después de que el proceso secundario también llama a close, vincula la descripción del archivo correspondiente Una vez que el recuento de referencias de símbolos se convierte en 0, el sistema operativo realmente cerrará la conexión

El modo PPC es sencillo de implementar y es más adecuado para situaciones en las que el número de conexiones al servidor no es tan elevado. Por ejemplo, el servidor de la base de datos. Para los servidores comerciales normales, antes del auge de Internet, debido a que el tráfico y la concurrencia del servidor no eran tan grandes, este modelo funcionaba bastante bien. Tras el auge de Internet, la concurrencia y las visitas de los servidores han aumentado drásticamente de decenas a decenas de miles, destacando las desventajas de este modelo, principalmente en los siguientes aspectos:

• La bifurcación es costosa: desde la perspectiva del sistema operativo, el costo de crear un proceso es muy alto, requiere que se asignen muchos recursos del kernel y la imagen de memoria debe copiarse del proceso principal al proceso secundario. Incluso si el sistema operativo actual utiliza la tecnología Copiar al escribir (Copiar al escribir) al copiar imágenes de memoria, el costo total de crear un proceso sigue siendo muy alto
• Comunicación complicada entre los procesos padre e hijo: cuando el proceso padre "bifurca" el proceso hijo, los descriptores de archivo se pueden pasar del proceso padre al proceso hijo a través de la copia de imágenes de memoria, pero una vez que se completa la "bifurcación", la comunicación entre los procesos padre e hijo es más problemática, y IPC (interproceso Comunicación) y otros esquemas de comunicación de procesos. Por ejemplo, el proceso hijo necesita decirle al proceso padre cuántas solicitudes ha procesado antes de cerrar para respaldar el proceso padre para las estadísticas globales, luego el proceso hijo y el proceso padre deben usar el esquema de IPC para transmitir información.
• El aumento en el número de procesos ejerce una mayor presión sobre el sistema operativo: si cada conexión tiene un tiempo de supervivencia más largo y entran nuevas conexiones continuamente, el número de procesos aumentará y la frecuencia de programación y conmutación de procesos del sistema operativo también aumentará. Cuanto más alto llegues, mayor será la presión sobre el sistema. Por lo tanto, en general, el número máximo de conexiones simultáneas que puede manejar la solución PPC es de solo unos pocos cientos

prefork

En vista de las diferentes deficiencias del modo PPC, se han producido diferentes soluciones. En el modo PPC, se "bifurca" un nuevo proceso para procesar la solicitud de conexión cuando entra la conexión. Debido a que el proceso de "bifurcación" es costoso, el usuario puede sentirse lento al acceder a él. La aparición del modo prefork es para resolver este problema. Prefork es crear un proceso por adelantado (pre-fork). El sistema crea un proceso por adelantado cuando se inicia y luego comienza a aceptar las solicitudes de los usuarios. Cuando entra una nueva conexión, puede ser Eliminando la operación del proceso "fork", permitiendo a los usuarios acceder más rápido y mejor experiencia, el diagrama básico de prefork:

• La clave para la realización de prefork es que múltiples procesos secundarios aceptan el mismo socket. Cuando ingresa una nueva conexión, el sistema operativo garantiza que solo un proceso puede aceptar con éxito, pero también hay un problema aquí: el fenómeno de "grupo de choque" significa que aunque solo hay Un proceso hijo puede aceptar correctamente, pero todos los procesos hijo bloqueados al aceptar se activarán, lo que lleva a una programación de procesos y un cambio de contexto innecesarios. El sistema operativo puede resolver este problema. El núcleo se ha resuelto después de la versión 2.6 de Linux. Acepta el problema del grupo sorpresa
• El modo prefork, como PPC, todavía tiene los problemas de la complicada comunicación del proceso entre padres e hijos y un número limitado de conexiones simultáneas compatibles, por lo que no hay muchas aplicaciones prácticas en la actualidad.
• El servidor Apache proporciona el modo prefork MPM, que se recomienda para sitios que requieren confiabilidad o compatibilidad con software antiguo. De forma predeterminada, admite un máximo de 256 conexiones simultáneas.

TPC

TPC es la abreviatura de Thread per Connection, y su significado es crear un nuevo hilo cada vez que hay una nueva conexión para manejar la solicitud de esta conexión. En comparación con los procesos, los subprocesos son más ligeros y el costo de crear subprocesos es mucho menor que el de los procesos. Al mismo tiempo, varios subprocesos comparten el espacio de memoria del proceso y la comunicación de subprocesos es más simple que la comunicación de procesos. Por lo tanto, TPC realmente resuelve o debilita el alto costo de la bifurcación PPC y la complicada comunicación entre los procesos padre e hijo.

El proceso básico de TPC es el siguiente:

• El proceso padre acepta la conexión (aceptar en la figura)
• El proceso padre crea un hilo secundario (pthread en la figura)
• El subproceso secundario maneja las solicitudes de lectura y escritura de la conexión (el subproceso secundario lee, procesa el negocio, escribe en la figura)
• El hilo secundario cierra la conexión (cierre en el hilo secundario en la figura)

No es difícil encontrar que, en comparación con PPC, el proceso principal no necesita cerrar el enlace. La razón es que el subproceso secundario comparte el espacio de proceso del proceso principal y el descriptor del archivo conectado no se copia, por lo que solo se requiere un cierre.

Aunque TPC resuelve los problemas del alto costo de la bifurcación y la complicada comunicación del proceso, también presenta nuevos problemas:

• En primer lugar, aunque crear un subproceso es más barato que crear un proceso, no está exento de costes. Todavía existen problemas de rendimiento cuando hay una alta concurrencia (como decenas de miles de conexiones por segundo)
• En segundo lugar, no hay necesidad de comunicación entre procesos, pero la exclusión mutua y el intercambio entre subprocesos introduce complejidad, lo que puede conducir a problemas de interbloqueo accidentalmente.
• Por último, varios subprocesos se afectarán entre sí. Cuando un subproceso es anormal, puede hacer que todo el proceso se cierre (como la memoria fuera de límites)
• Además de introducir nuevos problemas, TPC todavía tiene el problema de los costos de programación y conmutación de subprocesos de la CPU. Por lo tanto, la solución TPC es básicamente similar a la solución PPC. En el escenario de varios cientos de conexiones concurrentes, la solución PPC es más adoptada, porque la solución PPC no tendrá el riesgo de interbloqueo y no habrá interacción entre múltiples procesos. Mayor estabilidad

prehilo

• En el modo TPC, cuando entra una conexión, se crea un nuevo subproceso para manejar la solicitud de conexión. Aunque la creación del subproceso es más liviana que la creación del proceso, todavía hay un precio determinado. El modo de subproceso previo es para resolver este problema
• Similar al prefork, el modo prehilo creará hilos por adelantado y luego comenzará a aceptar solicitudes de usuarios. Cuando ingrese una nueva conexión, puede omitir la operación de creación de hilos, lo que hará que los usuarios se sientan más rápidos y tengan una mejor experiencia.
• Debido a que el intercambio de datos y la comunicación entre varios subprocesos son más convenientes, de hecho, la implementación del preproceso es más flexible que la prefork. Las implementaciones comunes son las siguientes:
  • El proceso principal acepta y luego entrega la conexión a un hilo para su procesamiento.
  • Todos los subprocesos secundarios intentaron aceptar. Al final, solo un
    
    Qiancheng aceptado tuvo éxito. El diagrama básico del esquema es el siguiente . El modo de trabajo MPM del servidor Apache es esencialmente un esquema previo al subproceso, pero con una ligera mejora, el servidor Apache creará múltiples procesos, cada uno Cree varios subprocesos en el proceso. Esto es principalmente para la estabilidad. Incluso si un subproceso en un proceso secundario es anormal y hace que todo el proceso secundario se cierre, habrá otros procesos secundarios que continuarán brindando servicios y no harán que todo el servidor se cuelgue. .
    En teoría, el preproceso puede admitir más conexiones simultáneas que el prefork. El modo de trabajo MPM del servidor Apache admite 16 × 25 = 400 subprocesos de procesamiento simultáneo de forma predeterminada.

Reactor

El principal problema de la solución PPC es que cada conexión tiene que crear un proceso, y el proceso se destruye una vez finalizada la conexión. Esto en realidad es un gran desperdicio. Para resolver este problema, una idea natural es reutilizar los recursos, es decir, no separar más Cree un proceso para cada conexión, pero cree un grupo de procesos, asigne la conexión al proceso, un proceso puede manejar el negocio de múltiples conexiones

• Después de la introducción del método de procesamiento de grupos de recursos, surgirá una nueva pregunta: ¿Cómo puede el proceso manejar de manera eficiente el negocio de múltiples conexiones? Cuando un proceso está conectado, el proceso puede adoptar el flujo de procesamiento de "lectura-> procesamiento comercial-> escribir". Si no hay datos para leer en la conexión actual, el proceso se bloqueará en la operación de lectura. Este método de bloqueo se conecta uno por uno No hay ningún problema en el escenario del proceso, pero si un proceso maneja múltiples conexiones, el proceso se bloquea en la operación de lectura de una determinada conexión. En este momento, incluso si otras conexiones tienen datos legibles, el proceso no puede manejarlos. Obviamente, esto no se puede hacer. Alto rendimiento
• La forma más sencilla de resolver este problema es cambiar la operación de lectura a sin bloqueo, y luego el proceso sondea continuamente múltiples conexiones. Este método puede resolver el problema del bloqueo, pero la solución no es elegante. Primero, el sondeo consume CPU; segundo, si un proceso maneja decenas de miles de conexiones, la eficiencia del sondeo es muy baja

Para resolver mejor los problemas anteriores, una idea natural es procesar solo cuando hay datos en la conexión. Esta es la fuente de la tecnología de multiplexación de E / S, el término multiplexación de E / S Es más común en la industria de las comunicaciones. Por ejemplo, multiplexación por división de tiempo (GSM), multiplexación por división de código (CDMA), multiplexación por división de frecuencia (GSM), etc., que significa "el proceso y la tecnología de transmisión de múltiples señales o flujos de datos en un canal", pero si toma Aplicar este significado al campo de la computadora causará confusión, porque puramente desde el significado superficial, el "canal" en el campo de la comunicación es similar a la "conexión" en el campo de la computadora, y el "flujo de datos" en el campo de la comunicación es similar al "flujo de datos" en el campo de la computadora. "Es similar. Si copia directamente la definición de multiplexación en el campo de la comunicación al campo de la computadora, entenderá la multiplexación como "transmitir múltiples datos en una conexión, que es demasiado diferente de la multiplexación de E / S real". Multiplexación de E / S en el campo de las redes informáticas, donde "multiplex" se refiere a múltiples conexiones y "multiplexación" se refiere a múltiples conexiones que multiplexan el mismo objeto de bloqueo Este objeto de bloqueo está relacionado con la implementación específica. Tome Linux como ejemplo, si usa select, la imagen de bloqueo común es el fd_set usado por select, si usa epoll, es el descriptor de archivo creado por epoll_create

En resumen, la tecnología de multiplexación de E / S tiene los siguientes dos puntos clave de implementación:

• Cuando varias conexiones comparten un objeto de bloqueo, el proceso solo necesita esperar en un objeto de bloqueo en lugar de sondear todas las conexiones
• Cuando una conexión tiene nuevos datos que se pueden procesar, el sistema operativo notificará el proceso y el proceso regresa del estado bloqueado para iniciar el procesamiento comercial.

La multiplexación de E / S combinada con grupos de subprocesos resuelve perfectamente los problemas de los modelos PPC y TPC, y "grandes dioses" le dieron un muy buen nombre: Reactor, chino significa "reactor", de hecho, aquí está " "Respuesta" significa "reacción al evento", que puede entenderse en términos sencillos como "Cuando llega un evento, tengo la respuesta correspondiente". El modo Reactor también se llama modo Dispatcher (muchos sistemas de código abierto verán la clase de este nombre, que en realidad implementa el modo Reactor), que está más cerca del significado del modo en sí, es decir, evento de monitoreo unificado de multiplexación de E / S, recibido Envío a un proceso
. Los componentes centrales del modelo Reactor incluyen Reactor y el grupo de recursos de procesamiento (grupo de procesos o grupo de subprocesos). Reactor es responsable de monitorear y distribuir eventos, y el grupo de recursos de procesamiento es responsable del procesamiento de eventos. A primera vista, la implementación de Reactor Es relativamente simple, pero de hecho, en combinación con diferentes escenarios comerciales, la implementación específica del modo Reactor es flexible y cambiante, reflejado principalmente en los siguientes dos puntos:

• El número de Reactor se puede cambiar: puede ser un Reactor o varios Reactores
• La cantidad de grupos de recursos se puede cambiar: tomando el proceso como ejemplo, puede ser un solo proceso o múltiples procesos (los subprocesos son similares)

Combinando los dos factores anteriores, hay teóricamente 4 opciones, pero debido a que el esquema de implementación de "proceso único de reactor múltiple" es más complicado y no tiene ventajas de rendimiento que el esquema de proceso único de reactor único ", entonces" proceso único de reactor múltiple " "El esquema es solo un esquema teórico y no tiene aplicación en la práctica. El modo Reactor final tiene los siguientes tres esquemas de implementación típicos:

• Reactor único, proceso único / hilo único
• Reactor único multiproceso
• Multi-Reactor multiproceso / hilo.

El esquema anterior elige específicamente el proceso o el hilo, y más está relacionado con el lenguaje de programación y la plataforma. Por ejemplo, el lenguaje Java generalmente usa subprocesos (por ejemplo, Netty) y el lenguaje C usa procesos y subprocesos (por ejemplo, Nginx usa procesos y Memcache usa subprocesos).

Proceso / hilo único de reactor único

El diagrama esquemático del esquema de proceso / hilo único de Reactor es el siguiente (tome el proceso como ejemplo)

Seleccionar, aceptar, leer, enviar son API de programación de red estándar, el envío y el "procesamiento comercial" son operaciones completadas por Xu Yahao
El plan se describe en detalle a continuación:

• El objeto Reactor monitorea los eventos de conexión a través de select y los distribuye a través del despacho después de recibir el evento.
• Si se trata de un evento de establecimiento de conexión, el aceptador lo maneja. El aceptador acepta la conexión a través de aceptar y crea un controlador para manejar varios eventos posteriores después de la conexión.
• Si no es un evento de establecimiento de conexión, Reactor llamará al Handler correspondiente a la conexión (el Handler creado en el paso 2) para responder
• Handler completará el proceso comercial completo de lectura-> procesamiento comercial-> enviar

La ventaja del modelo de proceso único de reactor único es que es muy simple, no hay comunicación entre procesos, no hay competencia de procesos y todos se completan en el mismo proceso. Pero sus deficiencias también son muy obvias, las manifestaciones específicas son las siguientes:

• Solo hay un proceso y no se puede usar el rendimiento de la CPU de varios núcleos; solo se pueden implementar varios sistemas para utilizar la CPU de varios núcleos, pero esto traerá complejidad en la operación y el mantenimiento. Originalmente, solo se necesita mantener un sistema. Este método requiere mantenimiento en una máquina. Múltiples sistemas
• Cuando el controlador está procesando el negocio en una determinada conexión, todo el proceso no puede manejar los eventos de otras conexiones, lo que puede conducir fácilmente a cuellos de botella en el rendimiento.

Por lo tanto, la solución de proceso único de Reactor único tiene pocos escenarios de aplicación en la práctica, y solo es adecuada para escenarios donde el procesamiento empresarial es muy rápido En la actualidad, el software de código abierto más famoso utiliza Redis de proceso único de Reactor único.

El sistema de escritura en lenguaje C generalmente usa un solo proceso de Reactor, porque no hay necesidad de crear subprocesos en el proceso; mientras que la escritura en lenguaje Java generalmente usa un solo subproceso de Reactor, debido a que la máquina virtual Java es un proceso, hay muchos subprocesos en la máquina virtual, negocios El hilo es solo uno de los hilos

Reactor único multiproceso

Para evitar las deficiencias de la solución de un solo proceso / subproceso de reactor único, es obvio introducir multiproceso / multiproceso, lo que conduce a la segunda solución: El
diagrama de la solución de un solo reactor, de múltiples monedas, de un solo reactor, de múltiples subprocesos es el siguiente: La

descripción detallada de la solución es la siguiente:

• En el hilo principal, el objeto Reactor monitorea los eventos de conexión a través de select y los distribuye a través del envío después de recibir el evento.
• Si se trata de un evento de establecimiento de conexión, el aceptador lo maneja. El aceptador acepta la conexión a través de aceptar y crea un controlador para manejar varios eventos posteriores después de la conexión.
• Si no es un evento de establecimiento de conexión, Reactor llamará al Handler correspondiente a la conexión (el Handler creado en el paso 2) para responder
• El controlador solo es responsable de responder a los eventos y no realiza el procesamiento comercial; después de que el controlador lee los datos a través de la lectura, se enviarán al procesador para el procesamiento comercial
• El procesador completará el procesamiento comercial real en un proceso de sub-dinero independiente, y luego enviará el resultado de la respuesta al Manejador del proceso principal para su procesamiento; el Manejador devuelve el resultado de la respuesta al cliente mediante el envío después de recibir la respuesta

La solución multihilo de reactor único puede hacer un uso completo de la potencia de procesamiento de múltiples núcleos y múltiples CPU, pero también tiene los siguientes problemas:

• El acceso y el intercambio de datos multiproceso son más complicados. Por ejemplo, después de que el subproceso secundario completa el procesamiento comercial, el resultado debe pasarse al Reactor del subproceso principal para su envío, lo que implica el mecanismo de exclusión mutua y protección de los datos compartidos. Tomando el NIO de Java como ejemplo, Selector es seguro para subprocesos, pero el conjunto de claves devuelto por Selector.selectKeys () no es seguro para subprocesos. El procesamiento de las claves seleccionadas debe ser de un solo subproceso o se toman medidas sincronizadas para proteger
• Reactor es responsable de monitorear y responder a todos los eventos y solo se ejecuta en el hilo principal. Se convertirá en un cuello de botella de rendimiento cuando la concurrencia alta sea instantánea.

El esquema "single Reactor multi-thread" se menciona aquí, pero no se menciona el esquema de "single Reactor multiproceso". La razón principal es que si se utilizan varios procesos, después de que el proceso secundario completa el procesamiento comercial, el resultado se devuelve al proceso principal y se notifica al proceso principal para enviarlo a Qué cliente es muy problemático, porque el proceso padre solo monitorea eventos en cada conexión a través de Reactor y luego lo distribuye El proceso hijo no es una conexión cuando se comunica con el proceso padre. Si desea simular la comunicación entre el proceso principal y el proceso secundario como una conexión y agregar Reactor al monitor, es más complicado. Cuando se utiliza multiproceso, debido a que el multiproceso comparte datos, es muy conveniente comunicarse entre subprocesos. Aunque se debe prestar más atención al problema de sincronización cuando se comparten datos entre subprocesos, la complejidad es menor que la complejidad de la comunicación entre procesos mencionada anteriormente. un montón de

Multi-Reactor Multiproceso / Hilo

Para resolver el problema de Reactor único y multihilo, el método más intuitivo es cambiar el Reactor único a Reactor múltiple, lo que lleva a la tercera solución: Reactor múltiple y múltiples procesos / hilos.
El diagrama esquemático del esquema de subprocesos / multiprocesos de reactores múltiples es el siguiente (tome el proceso como ejemplo)

. La descripción detallada del esquema es la siguiente:

• El objeto mainReactor en el proceso padre monitorea el evento de establecimiento de conexión a través de select, y recibe el evento a través del Aceptador después de recibir el evento, y asigna la nueva conexión a un proceso hijo
• El subReactor del proceso hijo agrega la conexión asignada por mainReactor a la cola de conexión para monitorear y crea un Handler para manejar varios eventos de la conexión
• Cuando ocurre un nuevo evento, subReactor llamará al controlador correspondiente (es decir, el controlador creado en el paso 2) para responder
• El controlador completa el proceso comercial completo de lectura -> procesamiento comercial -> enviar

La solución multiproceso / subproceso de reactor múltiple parece ser más complicada que la de subproceso múltiple de reactor único, pero la implementación real es más sencilla. Las razones principales son las siguientes:

• Las responsabilidades del proceso principal y el proceso secundario son muy claras, el proceso principal solo es responsable de recibir nuevas conexiones y el proceso secundario es responsable de completar el procesamiento comercial posterior
• La interacción entre el proceso principal y el proceso secundario es muy simple, el proceso principal solo necesita pasar la nueva conexión al proceso secundario y el proceso secundario no necesita devolver datos
• Los procesos secundarios son independientes entre sí y no es necesario sincronizarlos ni compartirlos (aquí solo se limita a la selección, lectura, envío, etc. relacionados con el modelo de red, no es necesario sincronizarlos ni compartirlos, es posible que el "procesamiento comercial" aún deba sincronizarse y compartirse)

En la actualidad, el conocido sistema de código abierto que usa múltiples Reactor y múltiples procesos es Nginx, y se usan múltiples Reactor y múltiples subprocesos para implementar Memcache y Netty.

Nginx utiliza un modelo multiproceso de reactores múltiples, pero la solución es diferente del multiproceso estándar de reactores múltiples. La diferencia específica muestra que solo se crea el puerto de escucha en el proceso principal, y el mainReactor no se crea para "aceptar" la conexión. En cambio, el Reactor del proceso secundario "acepta" la conexión, y solo un proceso secundario a la vez es controlado por el bloqueo para "aceptar". Después de que el proceso "acepte" la nueva conexión, se colocará en su propio Reactor para su procesamiento y no se asignará a otros procesos secundarios.

Proactor

Reactor es un modelo de red síncrona sin bloqueo, porque las operaciones reales de lectura y envío requieren la sincronización de los procesos del usuario. El "síncrono" aquí significa que el proceso del usuario es síncrono al realizar operaciones de E / S como leer y enviar. Si la operación de E / S se cambia a asíncrona, el rendimiento se puede mejorar aún más. Este es el modelo de red asíncrona Proactor

La traducción china de Proactor como "dispositivo proactivo" es más difícil de entender. La palabra similar es proactivo, que significa "activo", por lo que podemos entenderlo mejor al traducirlo en "dispositivo activo". Reactor puede entenderse como "Te notificaré cuando llegue el evento y tú lo manejarás", mientras que Proactor puede entenderse como "Yo manejaré el evento cuando llegue y te avisaré cuando se procese el evento". "Yo" aquí es el kernel del sistema operativo, y "eventos" son eventos de E / S como nuevas conexiones, datos para leer y datos para escribir.

Diagrama del modelo de Proactor:

El plan se describe en detalle a continuación:

• Proactor Initiator es responsable de crear Proactor y Handler, y de registrar tanto Proactor como Handler en el kernel a través del Procesador de operaciones asincrónicas.
• El procesador de operaciones asincrónicas es responsable de procesar las solicitudes de registro y completar las operaciones de E / S
• El procesador de operaciones asincrónicas notifica a Proactor después de completar las operaciones de E / S
• Proactor vuelve a llamar a diferentes controladores para el procesamiento comercial de acuerdo con diferentes tipos de eventos
• Handler completa el procesamiento comercial, Handler también puede registrar un nuevo Handler en el proceso del kernel

En teoría, Proactor es más eficiente que Reactor. La E / S asíncrona puede hacer un uso completo de la función DMA y permitir que las operaciones de E / S y los cálculos se superpongan. Sin embargo, para lograr una verdadera E / S asíncrona, el sistema operativo necesita hacer mucho trabajo. En la actualidad, la verdadera E / S asíncrona se implementa a través de IOCP en Windows, mientras que AIO en Linux no es perfecta, por lo que se implementa una alta red concurrente en Linux. El modo de reactor es el modo principal de programación. Entonces, incluso si boost asio afirma implementar el modelo proactor, de hecho usa IOCP en Windows, pero en Linux es un modelo asíncrono simulado por el modo Reactor (usando epoll)