Nginx la arquitectura y los principios básicos

escenarios de aplicación Nginx

Nginx los tres escenarios principales:

• Servicio de Recursos estática
• Servicio proxy inverso
• Servicio API

Servicio de Recursos estática

Nginx puede servir recursos estáticos por el sistema de archivos local, tales como páginas HTML estáticas puros y así sucesivamente.

Servicio proxy inverso

Muchas aplicaciones de servicio de la eficiencia operativa es muy baja, QPS, TPS, concurrencia está limitado, es necesario poner una gran cantidad de aplicaciones y servicios forman un clúster para proporcionar alta disponibilidad de servicios a los usuarios, esta vez necesidad de revertir funcionalidad de proxy Nginx , y la expansión dinámica de servicios de aplicaciones requiere el equilibrio de carga, otro, Nginx necesidades capa tampón por hacer. Por lo tanto los servicios de proxy inverso son principalmente tres funciones:

• proxy inverso
• Equilibrio de carga
• cache

Servicio API

A veces, el servicio de la aplicación en sí tiene un montón de problemas de rendimiento, pero mucho mejor que los servicios de aplicaciones de base de datos de servicio, escenario de negocios es relativamente simple, concurrencia y TPS a ser mucho más alta que las aplicaciones, así que esta vez puede acceder a la base de datos directamente hacia o desde el Redis Nginx también se puede lograr la aplicación de servicio API de servidor de seguridad con un potente concurrencia de Nginx.

Fundación Arquitectura Nginx

máquina de estados Nginx

Cuando los servicios externos Nginx, hay tres tráfico llegará a Nginx: web, correo electrónico, el tráfico TCP. Después de tres flujo alcanza la Nginx, respectivamente, será tratada por la máquina de estados de capa de transporte, la máquina de estado de capa de aplicación, la máquina de estado MAIL. Cuando la memoria no es suficiente para almacenar en caché todos los recursos estáticos, degenerará en disco para llamadas de bloques, se necesita un grupo de subprocesos de mango en este momento, para cada solicitud procesada registros de acceso y registros de error, el registro se graba en el disco.

estructura de procesos Nginx

Nginx Hay cuatro procesos:

• proceso maestro. proceso maestro es el proceso padre, otros procesos son procesos secundarios, Maestro de procesos de trabajo para gestionar el proceso
• proceso de trabajo. Hay varios procesos de trabajo, que es responsable de manejar las peticiones específicas. Nginx Por qué multiproceso de proceso en lugar de la estructura multi-hilo? Debido a Nginx para asegurar una alta disponibilidad, compartirán un espacio de direcciones entre varios subprocesos, cuando ciertos módulos de terceros conducido a un fallo de segmentación, que hará que todo el proceso que se bloquee Nginx. El modelo multi-proceso no tiene este problema
• administrador de caché y el proceso de cargador de caché. Además de la memoria caché para ser utilizado por varios procesos de trabajo, sino también mediante el proceso de la memoria caché, cargador de caché como caché de carga, director de gestión de la caché no el almacenamiento en caché, la memoria caché se utiliza realmente para cada solicitud o para el proceso de trabajo. La comunicación entre estos procesos se llevan a cabo a través de memoria compartida

¿Por qué proceso de trabajo necesita una gran cantidad?

Esto se debe a que, Nginx utiliza un modelo orientado a eventos, se espera que el proceso de trabajo de principio a fin puede llenar una CPU, por lo que se puede utilizar de manera más eficiente piezas enteras de la CPU, mejorar la tasa de acierto de caché de la CPU, el proceso de trabajo también puede junto con la unión de un núcleo de la CPU.

El uso de los padres y la gestión de la señal infantil Nginx

Hablando de Nginx delante de la línea de comandos, de hecho, muchos de señal Nginx es enviar una señal al proceso maestro a través de lograr.

proceso maestro

proceso maestro supervisa el proceso de trabajo y supervisar la realización de la necesidad de enviar una señal a la Chld proceso padre cuando el proceso hijo especificado por la salida de Linux. Este error se produce cuando, inmediatamente tirar de los trabajadores.

proceso maestro puede recibir las siguientes señales:

• PLAZO, INT
• DEJAR
• HUP
• USR1
• USR2
• CABRESTANTE

El proceso de trabajo

proceso de trabajo puede recibir las siguientes señales:

• PLAZO, INT
• DEJAR
• HUP
• USR1
• CABRESTANTE

Una señal correspondiente a la línea de comandos

• recarga: HUP
• reabrir: USR1
• parada: PLAZO
• dejar de fumar: QUIT

TORNO USR2 y ninguna señal correspondiente se transmite a través de sólo matan.

La diferencia entre el tope y dejar de fumar es, uno es inmediatamente salida, es una detención leve.

El archivo de configuración de recarga verdad recarga

1. Enviar una señal HUP al proceso maestro
2. El proceso de verificar si el problema del archivo de configuración maestro sintaxis
3. Abrir un puerto de monitor nuevo proceso maestro (si una nueva configuración de puerto)
4. proceso maestro para empezar a utilizar el nuevo proceso de trabajo de archivo de configuración
5. QUIT proceso maestro envía una señal al proceso de trabajo de edad
6. manija de apagado del monitor de procesos de trabajo de edad, terminó con el proceso después del final de la conexión actual

La verdad de despliegue en caliente

En el artículo anterior, sobre el flujo de despliegue en caliente, el despliegue de calor de proceso específica es una especie de cómo?

1. Reemplazará el archivo antiguo en el nuevo archivo Nginx Nginx (nota de que la copia de seguridad)
2. USR2 envía una señal al proceso maestro
3. modificar el nombre del archivo pid proceso maestro sufijo .oldbin
4. proceso maestro para iniciar nuevos procesos con un nuevo archivo maestro Nginx
5. Enviar dejar de señal para el proceso antiguo maestro, cerrar el antiguo maestro
6. Rollback, enviar la señal HUP al proceso antiguo maestro, el nuevo envío master QUIT

El elegante desvío proceso de trabajo

1. Ajuste el temporizador worker_shutdown_timeout
2. manija de cierre oyentes
3. Cerrar las conexiones inactivas
4. A la espera de que todas las conexiones de recirculación cerrada
5. Salir del proceso

Allí, el papel del temporizador, si el tiempo de espera, pero la conexión no ha procesado todavía se verá obligado a retirarse del proceso. Además, sólo puede manejar Nginx HTTP elegante cerrado, WebSocket, TCP, UDP proxy no puede hacerlo, trabajador no analiza los datos.

Estos contenidos, el proceso se ha completado la línea de comandos y señales Nginx. La próxima vez que empezó a hablar HTTP módulo.

Nº recibir la atención del público mapa de conocimiento Nginx