¿Cómo maneja PHP la alta concurrencia?

¿El siguiente contenido es una reproducción del blog de Hanbin Xu? ¿Construcción de un sistema web de mil millones de niveles, desde una sola máquina hasta un clúster distribuido?

Cuando el número de visitas diarias a un sistema Web aumente gradualmente de 100.000 a 10 millones, o incluso supere los 100 millones, el sistema Web estará bajo una presión cada vez mayor. Para resolver los problemas causados ​​por estas presiones de rendimiento, necesitamos construir un mecanismo de almacenamiento en caché de múltiples niveles en el nivel de arquitectura del sistema web. En diferentes etapas de estrés, encontraremos diferentes problemas, que pueden resolverse construyendo diferentes servicios y arquitecturas.

¿Equilibrio de carga de red?

El equilibrio de carga web (Load Balancing), en pocas palabras, es la distribución de "carga de trabajo" a nuestros clústeres de servidores. Es muy importante proteger los servidores web back-end mediante el uso de métodos de distribución adecuados.

Existen muchas estrategias de equilibrio de carga, comencemos con las más simples.

1. Redirección HTTP

Cuando el usuario envía una solicitud, el servidor web devolverá una nueva URL modificando la etiqueta Ubicación en el encabezado de respuesta HTTP y luego el navegador continuará. para solicitar esto La nueva URL, esta es en realidad la redirección de la página. Mediante la redirección se logra el propósito de "equilibrar la carga". Por ejemplo, cuando descargamos un paquete de código fuente PHP, cuando hacemos clic en el enlace de descarga, para resolver el problema de la velocidad de descarga en diferentes países y regiones, nos devolverá una dirección de descarga más cercana. El código de retorno HTTP para una redirección es 302

Esta redirección es muy fácil de implementar y se puede personalizar mediante varias políticas. Sin embargo, no funciona bien cuando se accede a él a gran escala. Además, la experiencia del usuario no es buena ya que las solicitudes reales se redirigen, lo que aumenta la latencia de la red.

2. Equilibrio de carga del proxy inverso

El trabajo principal del servicio de proxy inverso es principalmente reenviar solicitudes HTTP, desempeñando el papel de retransmisión entre el navegador y el servidor de red back-end. . Debido a que funciona en la capa HTTP (capa de aplicación), que es la séptima capa en la estructura de red de siete capas, también se le llama "equilibrio de carga de siete capas".

Nginx es un proxy inverso muy flexible que le permite personalizar libremente estrategias de reenvío, asignar pesos de tráfico del servidor, etc. Un problema común con los servidores proxy inversos son los datos de sesión almacenados por el servidor web porque la estrategia general de equilibrio de carga es distribuir las solicitudes de forma aleatoria. No se garantiza que las solicitudes del mismo usuario que inició sesión se asignen a la misma máquina web, lo que puede provocar problemas de no encontrar la sesión.

Hay dos soluciones principales:

1. Configurar las reglas de reenvío del proxy inverso para que las solicitudes del mismo usuario lleguen a la misma máquina (mediante el análisis de las cookies). las reglas de reenvío consumirán más CPU y aumentarán la carga en el servidor proxy.

2. La información de la sesión está dedicada a un servicio de almacenamiento independiente, como redis/memchache. Se recomienda esta solución.

El servicio de proxy inverso también puede activar el caché. Si está activado, aumentará la carga del proxy inverso y debe usarse con precaución. La implementación y despliegue de esta estrategia de equilibrio de carga es muy simple y el rendimiento es relativamente bueno. Pero tiene un problema de "punto único de falla", que puede causar muchos problemas si se bloquea. Además, en las últimas etapas del aumento del número de servidores web, puede convertirse en un cuello de botella en el propio sistema.

3. Equilibrio de carga de IP

El servicio de equilibrio de carga de IP funciona en la capa de red (modificar IP) y en la capa de transporte (modificar puerto, capa 4). La capa (Capa 7) tiene un rendimiento mucho mayor. El principio es modificar la dirección IP y la información del puerto del paquete de datos en la capa IP para lograr el equilibrio de carga. Esto también se conoce como "equilibrio de carga de Capa 4". Un método de equilibrio de carga común es LVS (servidor virtual Linux), que se implementa a través de IPVS (servidor virtual IP).

Cuando el servidor de equilibrio de carga recibe un paquete IP de un cliente, modifica la dirección IP o el puerto de destino del paquete IP, luego lo descarta sin cambios en la red interna y luego el paquete fluye hacia el servidor web real. .

Una vez que el servidor real completa el procesamiento, devuelve el paquete al servidor de equilibrio de carga, que modifica la dirección IP de destino a la dirección IP del usuario y, finalmente, lo devuelve al cliente.

El método anterior se llama LVS-NAT. Además, existen LVS-RD (enrutamiento directo) y LVS-TUN (túnel IP). Los tres son métodos LVS, pero existen ciertas diferencias entre ellos. , el problema del espacio no se repetirá.

El rendimiento del equilibrio de carga IP es mucho mayor que el del proxy inverso de Nginx. Solo procesa paquetes a la capa de transporte sin agruparlos más y luego los reenvía directamente al servidor real. Sin embargo, es más complejo de configurar y construir.

4. Equilibrio de carga de DNS

DNS (Sistema de nombres de dominio) es responsable de los servicios de resolución de nombres de dominio. La URL del nombre de dominio es en realidad un alias del servidor y lo que realmente está asignado. es la dirección IP. El proceso de resolución se completa mediante la asignación de nombre de dominio a IP. Se puede configurar un nombre de dominio para que corresponda a varias IP. Por tanto, DNS también se puede utilizar como servicio de equilibrio de carga.

Esta estrategia de equilibrio de carga es sencilla de configurar y tiene un rendimiento excelente. Sin embargo, las reglas no se pueden definir libremente, cambiar las IP asignadas o cuando falla una máquina es engorroso y hay un retraso en la entrada en vigor del DNS.

5.Equilibrio de carga DNS/GSLB

Nuestro método de implementación de CDN (red de distribución de contenido) comúnmente utilizado se basa en realidad en asignar el mismo nombre de dominio a múltiples IP y, además, a través de GSLB ( Equilibrio de carga global del servidor) implementado. El equilibrio de carga del servidor (GSLB) asigna la IP de un nombre de dominio de acuerdo con reglas específicas y, en general, devuelve la IP cercana al usuario al usuario en función de la ubicación geográfica, lo que reduce el consumo de salto entre los nodos de enrutamiento en la transmisión de la red.

"Búsqueda", el proceso real es que LDNS (DNS local) primero obtiene el servidor de nombres raíz de nivel superior (por ejemplo, .NET.NET.NET.NET.NET.NET. NET.NET .NETcom), luego obtenga el DNS autorizado del nombre de dominio especificado y luego obtenga el CDN real que se usa generalmente en sistemas web para resolver el problema de cargar recursos estáticos de gran tamaño (html/Js/ CSS/imágenes, etc.), de modo que estos contenidos que dependen en gran medida de las descargas de la red puedan estar lo más cerca posible de los usuarios, mejorando así la experiencia del usuario.

Por ejemplo, accedí a una imagen en imgcache.gtimg.cn (la CDN creada por Tencent no utiliza el nombre de dominio qq.com porque impide que mit ajuste la política de escritura en el disco. Si el costo de la máquina Le permite resolver el problema a nivel de hardware, puede elegir el RAID (matriz redundante de discos independientes) más antiguo o el SSD (unidad de estado sólido) relativamente nuevo

5.Almacenamiento NoSQL

Ya sea lectura o escritura de bases de datos, cuando el tráfico aumenta aún más, eventualmente llegará a la situación "cuando la mano de obra es limitada". El costo de continuar agregando máquinas es relativamente alto y es posible que realmente no resuelva el problema. En este momento, para los datos, puede considerar usar una base de datos NoSQL. La mayoría del almacenamiento NoSQL usa métodos de valor clave. Se recomienda usar el Redis anterior como memoria caché y también se puede usar como almacenamiento. los datos se pueden registrar directamente en el disco.

En este caso, separamos algunos datos leídos y escritos con frecuencia en la base de datos y los colocamos en nuestro nuevo clúster de almacenamiento Redis, lo que redujo aún más la presión sobre el original. Al mismo tiempo, la base de datos MySQL, debido a que Redis en sí es un caché a nivel de memoria, el rendimiento de lectura y escritura mejorará enormemente.

Muchas de las arquitecturas de soluciones adoptadas por empresas nacionales de Internet de primer nivel son similares. a las soluciones anteriores, pero el servicio de almacenamiento en caché utilizado no es necesariamente Redis. Tendrán más opciones e incluso puede desarrollar su propio servicio NoSQL de acuerdo con sus propias características comerciales.

6. problema de consulta

Después de haber creado todos los servicios anteriores, creemos que los sistemas web se han vuelto muy poderosos. Todavía decimos que las consultas de nodos nulos todavía son solicitudes de datos que no existen. base de datos.

Por ejemplo, si solicito consultar información personal que no existe, el sistema la buscará paso a paso en todos los niveles de caché y finalmente encontrará la base de datos en sí y luego devolverá la conclusión no encontrada al front-end. Dado que todos los niveles de caché no son válidos, este tipo de solicitud consume recursos del sistema. Si se consulta una gran cantidad de nodos vacíos, puede afectar los servicios del sistema.

Esto lo he sufrido en mi experiencia laboral anterior. Por lo tanto, para mantener la estabilidad del sistema web, es muy necesario diseñar un mecanismo de filtrado de nodos vacíos adecuado.

El método que utilizamos en ese momento fue diseñar una tabla de mapeo de registros simple. Almacene los registros existentes en la memoria caché de modo que, si todavía hay consultas de nodos vacíos, se bloqueen en la capa de caché.

Implementación remota (distribución geográfica)

Después de completar la arquitectura anterior, ¿es nuestro sistema lo suficientemente potente? La respuesta es no. La optimización es ilimitada y, aunque los sistemas de red pueden parecer más potentes en la superficie, la experiencia del usuario puede no ser necesariamente la mejor. Porque los estudiantes del noreste de China, al acceder a un servicio de Internet en Shenzhen, seguirán sintiendo que la distancia de la red es lenta. En este momento, necesitamos implementarlo de forma remota para acercar el sistema web a los usuarios.

1. Concentración central y dispersión de nodos

Los estudiantes que han jugado juegos en línea a gran escala saben que los juegos en línea tienen muchas regiones, que generalmente están divididas por regiones, como Guangdong y Beijing. . área. Si un jugador está en Guangdong y va a jugar al área de Beijing, obviamente se sentirá estancado que en el área de Guangdong. De hecho, el nombre de la región ya indica la ubicación del servidor, por lo que si un jugador en Guangdong se conecta a un servidor en Beijing, la velocidad de la red será más lenta.

Cuando su sistema o servicio crece lo suficiente, debe comenzar a pensar en la implementación externa. Mantenga sus servicios lo más cerca posible de sus usuarios. Ya hemos mencionado que los recursos estáticos de la Web pueden almacenarse en CDN y luego distribuirse "por todo el país" a través de DNS/GSLB. Sin embargo, CDN solo resuelve el problema de los recursos estáticos, pero no puede concentrar los servicios de back-end de un sistema enorme en una ciudad fija.

Esta vez, comenzó la implementación externa. La implementación fuera del sitio generalmente sigue: el núcleo está centralizado y los nodos están dispersos.

-?Núcleo centralizado: en el proceso de implementación real, siempre hay algunos datos y servicios que no se pueden implementar en múltiples conjuntos, o el costo de implementación de múltiples conjuntos es enorme. Para estos servicios y datos, todavía se mantiene un conjunto de servicios y datos, y la ubicación de implementación se selecciona en un lugar geográficamente concentrado y la comunicación con cada nodo se realiza a través de líneas internas de la red.

-? Dispersión de nodos: implemente algunos servicios en múltiples conjuntos, distribuidos en varios nodos de la ciudad, de modo que las solicitudes de los usuarios puedan elegir el nodo más cercano para acceder al servicio tanto como sea posible.

Por ejemplo, decidimos implementarlo en Shanghai como nodo central, y en Beijing, Shenzhen, Wuhan y Shanghai como nodos distribuidos (Shanghai también es un nodo distribuido). Nuestra arquitectura de servicio se muestra en la figura:

Lo que hay que agregar es que el nodo de Shanghai y el nodo central están ubicados en la misma sala de computadoras, mientras que otros nodos distribuidos están ubicados en sus propias salas de computadoras. .

Hay muchos juegos en línea a gran escala en China que adoptan aproximadamente la estructura anterior. Colocarán contenido con una pequeña cantidad de datos, como las cuentas principales de los usuarios, en nodos centrales, mientras que la mayoría de los datos de juegos en línea, como equipos, tareas y otros datos y servicios, se colocarán en nodos regionales. Por supuesto, también existe un mecanismo de almacenamiento en caché entre los nodos centrales y los nodos regionales.

2. Recuperación ante desastres del nodo y protección contra sobrecargas

La recuperación ante desastres del nodo significa que si un nodo falla, debemos establecer un mecanismo para garantizar que el servicio aún esté disponible. Sin duda, el método más común de recuperación ante desastres aquí es cambiar a un nodo de la ciudad cercana. Si el nodo de Tianjin del sistema falla, cambiaremos el tráfico de la red al nodo cercano de Beijing. Por consideraciones de equilibrio de carga, es posible que sea necesario conmutar el tráfico a varios nodos geográficos cercanos simultáneamente. Por otro lado, el nodo central en sí debe ser tolerante a desastres y tener respaldo. Una falla del nodo central afectará los servicios a nivel nacional.

La protección contra sobrecarga significa que un nodo ha alcanzado su capacidad máxima y no puede continuar aceptando más solicitudes. El sistema debe tener un mecanismo de protección. Si un servicio ya está completamente cargado pero continúa aceptando nuevas solicitudes, es probable que el resultado sea un tiempo de inactividad que afecte el servicio de todo el nodo. Para garantizar el uso normal de al menos la mayoría de los usuarios, es necesaria la protección contra sobrecargas.

Para resolver la protección contra sobrecarga, generalmente hay 2 direcciones:

-? Denegación de servicio, dejar de aceptar nuevas solicitudes de conexión después de detectar la carga completa. Las colas en los inicios de sesión de juegos en línea son un ejemplo.

-? Desviar a otros nodos. En este caso, la implementación del sistema es más compleja y también implica equilibrio de carga.

Resumen

Los sistemas web crecerán a medida que aumente la escala de acceso y crecerán gradualmente desde necesidades que pueden ser satisfechas por un servidor hasta un clúster grande "monstruoso". El proceso de conversión de este sistema web en un gigante es en realidad el proceso de resolución de problemas. En diferentes etapas, es necesario resolver diferentes problemas y surgen nuevos problemas sobre las viejas soluciones.

La optimización del sistema es infinita, el software y la arquitectura del sistema se han desarrollado rápidamente y las nuevas soluciones resuelven viejos problemas y también plantean nuevos desafíos.