Para describir una buena arquitectura de servidor de manera popular, lo más básico e importante es apoyar a millones de jugadores en línea al mismo tiempo sin problemas . Estos dos puntos corresponden a alta concurrencia y alta disponibilidad respectivamente.
Este artículo presenta sistemáticamente alta concurrencia y alta disponibilidad en el servidor del juego.
La alta concurrencia y la alta disponibilidad son tareas complementarias. Cuando apoyamos a millones de jugadores en línea al mismo tiempo, pero no podemos garantizar la disponibilidad estable del servidor, entonces es imposible hablar sobre el soporte de alta concurrencia; y si el servidor a menudo tiene problemas cuando el número de jugadores es grande, entonces tampoco se puede llamar alta disponibilidad.
1. Expansión horizontal
La expansión horizontal es la base para una alta concurrencia y alta disponibilidad. Al admitir la expansión horizontal, teóricamente podemos obtener una capacidad de carga ilimitada agregando máquinas para admitir una alta concurrencia; sobre esta base, si un proceso es anormal, se pueden sustituir otros procesos Proporciona servicios para lograr una alta disponibilidad.
La siguiente figura es un ejemplo. Para una arquitectura que no admite la expansión horizontal, solo hay un proceso de batalla en el servidor del juego para proporcionar servicios de batalla para todos los jugadores. Aquí hay dos problemas: 1. Un proceso solo puede usar la computación recursos de una máquina como máximo Hay un límite superior de rendimiento. 2. Si el proceso o la máquina / red es anormal, todo el sistema no está disponible.
No admite expansión horizontal
Hay dos modelos de implementación comunes para la expansión horizontal:
- El servidor de lobby está completamente conectado con todos los procesos de batalla. Cuando necesites acceder al servicio de batalla, debes verificar la dirección de proceso del servicio en el administrador y luego ir directamente al proceso. (Imagen izquierda)
- Cuelgue una ruta frente al proceso de batalla. La ruta registra el proceso de batalla de cada batalla y las solicitudes relacionadas se enviarán al proceso correspondiente. (Imagen de la derecha)
Dos modelos de expansión horizontal
1.1 Con estado frente a sin estado
Desde la perspectiva de si el estado se guarda en la memoria del proceso, los servicios se pueden dividir en con estado y sin estado:
- Servicio con estado: el estado se guarda en la memoria del proceso. Por ejemplo, el servicio de batalla guarda información de la batalla (estado del personaje del jugador, estado de la mafia, etc.) en la memoria, y la operación del jugador o la lógica de la batalla cambiará la información de la batalla. Debido a que el estado en el juego es más complicado y la frecuencia de los cambios comerciales es relativamente alta, la mayor parte del negocio del juego se proporciona en forma de servicios con estado.
- Servicio sin estado: El servicio solo procesa el proceso y no guarda los datos. Generalmente, los datos se guardan en la base de datos back-end. La lógica de este servicio generalmente tiene muchas operaciones de base de datos. Este tipo de servicio se usa ampliamente en la industria de Internet y la web, como recarga e inicio de sesión, que son comunes en los juegos. (Los servicios sin estado pueden tener algunas variables temporales para solicitar memoria durante la ejecución de un proceso)
El servicio sin estado en sí no salva el estado, por lo que el bloqueo del proceso no perderá información. Además, como se presentará a continuación, los servicios sin estado son más tolerantes con las excepciones debido al uso de métodos de enrutamiento asignados aleatoriamente, por lo que, desde la perspectiva de la alta disponibilidad, los servicios sin estado son mejores.
Sin embargo, debido a que la apatridia no guarda el estado, todas las operaciones estatales son operaciones de base de datos, lo que genera mayores costos de desarrollo (el código es más complicado de escribir) y una mayor presión de la base de datos. Por lo tanto, la apatridia no es adecuada para todos los servicios. Generalmente, el estado es simple Para servicios claros, los apátridas se pueden usar primero, como los servicios para amigos.
1.2 estrategia de enrutamiento
Para los servicios con y sin estado, utilizan diferentes métodos de enrutamiento.
Para los servicios sin estado, generalmente se usa el enrutamiento aleatorio . El método de enrutamiento aleatorio tiene grandes ventajas. Si un proceso falla o la red falla, solo necesitamos eliminar este proceso del enrutamiento. No afectará las solicitudes posteriores, sino que solo afectará el proceso actual. Lógica de procesamiento.
El enrutamiento de servicios con estado necesita especificar qué proceso se procesa cada solicitud, y otros procesos no se pueden procesar porque no tienen información de estado relevante. Por ejemplo, en el servicio de batalla mencionado anteriormente, el enrutamiento puede procesar la solicitud relevante en función del ID de batalla y enviarla al proceso de batalla correspondiente. El enrutamiento generalmente usa un hash de módulo o consistente , y generalmente usa un hash consistente en lugar de un módulo para prevenir el jitter causado por fallas.
1.3 Da un ejemplo
La siguiente figura es un modelo simplificado de la arquitectura de un juego. El servidor real es mucho más complicado que esto. El propósito principal aquí es dar un ejemplo.
Los clústeres se pueden dividir en tres categorías: servicios con estado que admiten la expansión horizontal, servicios sin estado que admiten la expansión horizontal y servicios de un solo punto que no admiten la expansión horizontal.
Entre ellos, la cantidad de procesos que apoyan la expansión horizontal de servicios con estado y servicios sin estado puede representar el 90% del proyecto, y hay pocos servicios de un solo punto. Bajo este tipo de arquitectura, el cuello de botella del límite de carga de nuestro juego radica en el servicio de un solo punto, y la lógica del servicio de un solo punto es relativamente simple y el límite de carga es muy alto. Además, la anomalía del proceso de servicio que admite la expansión horizontal solo afectará a los jugadores atendidos por este proceso, que tiene alta disponibilidad.
Servicio con estado
En el grupo de servidores de nuestro juego, aproximadamente dos tercios del proceso es el proceso de procesamiento de la lógica personal del jugador (grupo de jugadores, muchos proyectos de juegos se denominan servidores de lobby). Cada proceso maneja una parte de la lógica empresarial del jugador y distribuye los jugadores a diferentes procesos de jugador a través del sombreado.
La capacidad del servidor se puede incrementar aumentando el número de procesos lógicos personales Apoyamos el continuo aumento o disminución de procesos, es decir, expansión y contracción dinámica. Estos procesos son iguales y no existe una fuerte dependencia entre los diferentes procesos. Cuando un proceso falla, no afectará a los jugadores en otros procesos.
Además de los procesos del jugador, existen procesos de batalla, procesos familiares y otros procesos similares que se pueden diseñar de esta manera.
Los mencionados anteriormente son todos servicios con estado. Necesitamos registrar en qué proceso se encuentra cada jugador / pelea / familia. Además, si el proceso es anormal, no afectará a otros jugadores / peleas / familia, sino a los jugadores / peleas en el El proceso actual / Familia no estará disponible y se perderán algunos datos.
Servicio sin estado
Usamos la implementación sin estado para algunos servicios, como inicio de sesión, pago, amigos y algunas tablas de clasificación. Dado que los servicios sin estado son más amigables con las excepciones y la expansión dinámica y los modelos de reducción más simples que los servicios con estado, priorizamos el uso de servicios sin estado para un nuevo servicio y consideramos el uso de servicios con estado si el estado es más complejo.
Punto de servicio único
Es inevitable que haya algunos servicios de un solo punto en los servicios de juego, como el administrador de jugadores, el administrador de clústeres, el administrador familiar, etc. Estos servicios no tienen escalabilidad y son el cuello de botella del servidor del juego. Además, no tiene alta disponibilidad. Si ocurre una excepción, todo el grupo de juegos no estará disponible.
La lógica del servicio de un solo punto es generalmente simple (la lógica compleja debe admitir la expansión horizontal) y la carga de rendimiento es generalmente alta. Por ejemplo, la evaluación actual de nuestro juego y la estimación conservadora en línea deberían ser 50 W. En este momento, creemos que algunos de nuestros servicios de punto único estarán completamente cargados, lo que provocará que el juego no pueda continuar expandiéndose.
Además, el número de servicios de un solo punto es pequeño y la posibilidad de anomalías es baja. Nuestro juego ha estado en línea durante casi dos años, y solo hemos encontrado dos tiempos de inactividad de la máquina, que afectaron los procesos que no son de un solo punto y no afectaron la disponibilidad general del clúster del juego.
Por supuesto, también se puede cambiar un único punto de servicio para admitir la expansión horizontal, es solo una cuestión de carga de trabajo. La teoría es que puede eliminar completamente el punto único, pero para la mayoría de los proyectos, el rendimiento de costos no es alto y tiene poca importancia.
Dos, alta concurrencia
El esquema de expansión horizontal es el medio principal para admitir una alta concurrencia (también llamada escalabilidad escalable), que se ha presentado anteriormente.
A continuación se presentan principalmente otras soluciones además de la expansión horizontal y la alta concurrencia, así como puntos que necesitan atención.
2.1 Expansión vertical y optimización del rendimiento
Para mejorar la capacidad de carga, generalmente existen dos soluciones:
- Expansión horizontal: Aumente la capacidad de carga aumentando el número de máquinas.
- Expansión vertical: aumente la capacidad de carga aumentando la configuración de la máquina. Permita que una máquina / hilo lleve más jugadores.
La expansión vertical también es útil en ciertos escenarios. En términos generales, para el punto único que mencionamos anteriormente, si no es fácil de eliminar o el costo de eliminación es alto, esta lógica se puede colocar en una máquina de alto perfil mediante expansión vertical para aumentar la carga de la lógica de un solo punto.
Además, a menudo optimizamos el rendimiento de los uniformes de combate, como la escritura de módulos de alto consumo en C ++, pero generalmente no los usamos como el medio principal para mejorar la capacidad de carga del uniforme del vestíbulo. No hablaremos de esto en profundidad. Por un lado, siempre habrá un límite superior, y es difícil cambiar cualitativamente. Por otro lado, los diferentes esquemas de optimización del juego varían mucho, todos los cuales son optimizaciones a nivel de código.
El objetivo de la optimización del lado del servidor es similar al de la expansión vertical, que es permitir que una máquina lleve más jugadores / lógica.
2.2 Eliminar los puntos únicos del sistema y los puntos únicos lógicos
La eliminación de puntos únicos introducida anteriormente es principalmente un punto único del sistema, es decir, se utilizan múltiples procesos para proporcionar servicios en lugar de un proceso.
La premisa de eliminar los puntos únicos del sistema es eliminar los puntos únicos lógicos.
Por ejemplo: cuando dejamos caer un arma, debemos generar una identificación única para el arma para identificar el arma. Este ID puede utilizar un ID autoincrementado, que crea un único punto lógico.
En este caso, si la frecuencia de generación de armas en el juego es muy baja, entonces esta solución también es posible, pero si la frecuencia de generación de armas es alta, porque toda la lógica en el juego debe ir a un lugar para solicitarla. ID, puede causar un cuello de botella. En este caso, generalmente podemos usar uuid en lugar de ID autoincrementable. (Este escenario también es común en las columnas de incremento automático en la base de datos, por lo que generalmente se recomienda usar el incremento automático menos)
2.3 Alojamiento de base de datos
Cuando la cantidad de jugadores en línea alcanza un cierto nivel, a menudo causa una gran presión en la base de datos de back-end.
En términos generales, la base de datos en sí tiene la capacidad de expandirse horizontalmente, y es más fácil mejorar la capacidad de carga con la adición de soluciones como subtablas de base de datos. Sin embargo, al diseñar la estructura de la base de datos, también es necesario considerar cuestiones como índices y shadowkeys, de lo contrario, el rendimiento de la base de datos se verá seriamente afectado. Además, considere las capacidades simultáneas de lectura y escritura de la base de datos. Por ejemplo, el motor de almacenamiento MMAPv1 en mongo es un bloqueo a nivel de documento, mientras que el motor de almacenamiento WiredTiger es un bloqueo a nivel de colección. Las capacidades de concurrencia de los dos son muy diferente.
La lógica del juego es generalmente más complicada y la cantidad de datos leídos y escritos es grande Si la base de datos se lee y escribe cada vez que cambia la información del jugador, se generará una mayor presión en la base de datos. Por lo tanto, los servicios para jugadores de juegos son generalmente servicios con estado. Los jugadores leen datos de la base de datos en la memoria cuando están en línea. La lectura y escritura de datos durante el período en línea manipulan directamente la memoria y llegan a la base de datos cuando están fuera de línea o después de un período. de tiempo. Esta solución reduce en gran medida las operaciones de lectura y escritura de la base de datos, y la presión sobre la base de datos será mucho menor.
Para algunos servicios con baja frecuencia de operaciones de lectura y escritura de datos, puede considerar convertir el servicio en sin estado y luego operar la base de datos cada vez que lea y escriba.
2.4 Multi-cluster y cross-cluster
Cuando el servidor del juego alcanza una cierta escala, a menudo es necesario implementarlo en clústeres y los escenarios deben resolverse mediante clústeres:
- La capacidad de carga de un solo clúster tiene un límite superior. Por ejemplo, skynet solo admite 256 procesos.
- Requisitos del servidor multizona, cada grupo corresponde a un servidor de zona del juego. Si el juego es compatible con servidores de varias regiones y está completamente aislado sin comunicación entre servidores, será mucho más fácil lograr una alta concurrencia.
- Servicio global, algunos clústeres esperan desplegarse en el área del jugador. Por ejemplo, los uniformes de combate utilizados por los jugadores estadounidenses se despliegan en los Estados Unidos, y los uniformes de combate utilizados por los jugadores del sudeste asiático se despliegan en el sudeste asiático, y comparten el uniforme del vestíbulo desplegado en un lugar determinado.
Un problema que debe resolverse en varios clústeres es el problema de comunicación entre clústeres. Por lo general, el clúster está completamente conectado entre los procesos, pero si los procesos están completamente conectados entre los clústeres, la topología será caótica y la cantidad de conexiones se disparará. Por lo tanto, la comunicación entre clústeres generalmente utiliza el bus de mensajes, que se comunica a través del bus de mensajes.
2.5 Alta concurrencia temporal
En el escenario del negocio del juego, el tiempo, las actividades, etc. del jugador en línea están estrechamente relacionados, y el número de en línea en diferentes momentos puede ser varias veces y decenas de veces diferente.
Para el alto tráfico esperado, se puede transportar ampliando la capacidad por adelantado. Consulte "Expansión y reducción dinámicas" en "Optimización del servidor de Ninzo".
Para una alta concurrencia momentánea inesperada, puede usar el sistema de cola para bloquear el tráfico fuera del sistema y luego ingresar lentamente al juego después de la expansión dinámica.
2.6 Alta simultaneidad en escenarios de batalla
El juego también tiene una escena especial de alta concurrencia, donde los jugadores de MMO a gran escala se reúnen en una escena determinada, como una guerra nacional.
No existe una solución perfecta para este escenario. Solo puede aumentar la capacidad de carga tanto como sea posible. Las soluciones de mejora habituales son:
- Divida una escena en celdas y coloque diferentes celdas en diferentes procesos. Como bigworld / kbengine y el último SpatialOS.
- Mejorar la capacidad de carga de un solo proceso. Por ejemplo, optimización lógica, expansión vertical, uso de C ++ para escribir la lógica del juego, etc. Hay una diferencia de orden de magnitud en el rendimiento entre C ++ y Python.
- Servicio a la baja: simplifica la lógica del juego. Por ejemplo, durante la guerra nacional, es casi lo mismo siempre que los jugadores sientan que la escena es animada. De hecho, muchas lógicas de batalla se simplifican.
- Sub-servicio / sub-línea / sub-mazmorra: Deja que los jugadores se aíslen en los negocios.
Water Wind: la realización y evolución del sistema numérico del juego
Tres, alta disponibilidad
La búsqueda de un sistema de alta disponibilidad en el proceso de ejecutar la menor cantidad posible de servicios del sistema no está disponible.
El indicador de evaluación es el tiempo disponible (SLA, Service Level Agreement) del servicio en un ciclo, y la fórmula de cálculo es disponibilidad del servicio = (minutos totales del ciclo de servicio-minutos del servicio no disponible) / minutos totales del ciclo de servicio × 100% .
Generalmente se evalúa desde dos dimensiones: 1. El sistema es completamente utilizable: todos los servicios están disponibles para todos los usuarios. 2. La disponibilidad general del sistema: algunos servicios o algunos usuarios no están disponibles, pero el sistema en su conjunto está disponible.
El objetivo de la alta disponibilidad es luchar por la disponibilidad completa del sistema y garantizar la disponibilidad general.
Excepciones en grupos grandes
Debido a la pequeña probabilidad de situaciones anormales, como fallas en la máquina, atascos de red o desconexión, el servidor también debe considerar estos problemas, especialmente en el escenario de clúster grande, donde los eventos de pequeña probabilidad se acumulan en eventos de alta probabilidad, por lo que en los clústeres grandes En el En el escenario del servidor, la alta disponibilidad es un problema que debemos considerar.
La alta disponibilidad es en realidad el aislamiento y el manejo de diversas condiciones anormales, de modo que los eventos anormales de pequeña probabilidad no afectarán el servicio general del juego.
Las excepciones comunes son las siguientes:
- Anormalidad de la máquina / proceso / red: la disponibilidad de las máquinas de Alibaba Cloud está prometida en un 99,975%, lo que significa que se garantiza que cada máquina no estará disponible en 1 hora durante un año. Si el clúster utiliza cien máquinas, el peor de los casos en teoría es que una máquina no está disponible durante una hora cada tres días. Por supuesto, la disponibilidad real es mucho mejor de lo que prometió Alibaba Cloud. Nuestro juego tiene alrededor de 100 máquinas ECS. Dos máquinas se reiniciaron automáticamente debido a fallas de la máquina en un año, y no hubo indisponibilidad continua.
- Servicio Saas / Excepción de base de datos: debido a que utilizamos una gran cantidad de servicios en la nube como mysql y redis de Alibaba Cloud, estos servicios también tienen problemas de disponibilidad, lo que lleva a la conmutación maestro-esclavo, etc. El problema más común que se encuentra en nuestros juegos es que el conmutador maestro-esclavo de redis provoca un bloqueo de la red y requiere una reconexión a la red.
- ERROR empresarial: para ERROR empresarial, intente reducir el impacto del error y evitar que un pequeño ERROR cause la indisponibilidad general del sistema.
- Hotspot de rendimiento repentino: el negocio repentino ajetreado causado por el comportamiento normal o anormal del jugador es principalmente el problema de alta concurrencia mencionado anteriormente. Además, para los comportamientos anormales de algunos jugadores (como ataques de plug-in \ DDOS), debe asegurarse que no afectará la disponibilidad general del sistema. Recuerdo que hace mucho tiempo (la era legendaria), algunos complementos podían reiniciar directamente el servidor.
3.1 Obtenga una alta disponibilidad basada en la expansión horizontal
Mencionamos anteriormente que la expansión horizontal puede aumentar la capacidad de carga concurrente y al mismo tiempo aumentar la usabilidad, pero el enfoque es diferente. Para una alta concurrencia, la expansión horizontal significa que podemos aumentar la capacidad agregando máquinas / procesos. Para alta disponibilidad, significa que cuando una máquina / proceso es anormal o falla, no afectará la disponibilidad general del clúster.
Como se mencionó en la expansión horizontal anterior, para los servicios que apoyan la expansión horizontal, el estado anormal del servicio solo afectará el servicio provisto por este proceso y el funcionamiento normal de otros procesos; para el servicio sin estado, el impacto será menor y sólo afectan al proceso que se está ejecutando.
Por supuesto, esto requiere que escribamos alguna lógica de procesamiento, que incluye:
- Monitoreo anormal: a través del monitoreo anormal, las anormalidades se pueden encontrar rápidamente, generalmente usando un mecanismo de tiempo de espera de mensajes o latidos.
- Manejo de excepciones: por ejemplo, cómo tratar un mensaje después de su tiempo de espera, si se debe prestar atención o ignorarlo. Si un proceso no está disponible, debemos expulsar este proceso del clúster.
- Recuperación del servicio: para apátridas, simplemente reinícielo. Para stateful, el estado se puede migrar a otros procesos para proporcionar servicios. Hay muchas trampas en la restauración del servicio (más servicios con estado). Esquemas de restauración habituales, como iniciar directamente a los jugadores del servicio y luego volver a iniciar sesión.
- Degradación del servicio: sistema de cola común para la degradación del servicio y el cierre de funciones designadas.
Cómo implementar la lógica anterior es bastante complicado, por lo que no lo presentaré en detalle aquí.
Aislamiento de servicio y liberación gris
En el proceso de desarrollo, debemos dividir las funciones grandes en servicios más pequeños tanto como sea posible, y cada servicio solo es responsable de una función pequeña. Skynet también ofrece un mejor modelo de servicio: se pueden colocar diferentes servicios en un proceso o en diferentes procesos.
El artículo anterior introdujo el aislamiento de servicios y la liberación en escala de grises. También es para aislar los servicios de alto riesgo para que, incluso si hay problemas, no afecten la disponibilidad general del sistema.
3.2 Replicación maestro-esclavo
Para los servicios con estado, un proceso que admite la expansión horizontal puede garantizar que una excepción en un proceso no afecte a otros procesos para proporcionar servicios, pero un bloqueo de este proceso hará que el servicio proporcionado por este proceso no esté disponible y cause problemas como los datos. pérdida de memoria.
Para resolver esto, la solución común es la replicación maestro-esclavo. La replicación maestro-esclavo es muy común en las bases de datos y es una solución común para garantizar la alta disponibilidad de la base de datos.
La replicación maestro-esclavo consiste en colgar uno o más nodos esclavos (esclavos) detrás del nodo maestro, y el nodo maestro replica el estado / datos a los nodos esclavos en tiempo real. Por lo general, el nodo principal proporciona los servicios. Cuando el nodo principal tiene un problema, el nodo esclavo se convierte en el nodo principal y continúa proporcionando los servicios. Debido a que el nodo maestro replica los datos al nodo esclavo casi de hecho, puede garantizar aproximadamente que los datos no se pierdan.
Por lo tanto, si desea mejorar aún más la disponibilidad de servicios con estado o servicios de punto único, puede utilizar el esquema de replicación maestro-esclavo.
Los servidores de juegos utilizan esta solución para escribir menos lógica empresarial, y algunos nodos de gestión de clústeres (lógica no empresarial) utilizarán esta solución.
Además, debido a que common db (mysql / mongo / redis) tiene su propia replicación maestro-esclavo, los servicios sin estado realmente permiten que db administre el estado por nosotros, a fin de obtener la capacidad de replicación maestro-esclavo de db para que los datos no se pierdan .
3.3 Manejo de excepciones de los servicios en la nube
Además de las máquinas ECS, hemos utilizado ampliamente varios servicios SAAS de Alibaba Cloud, como bases de datos como redis / Mysql / Mongo y servicios de registro similares a ELK.
La mayoría de estos servicios admiten soluciones de alta disponibilidad, como la conmutación maestro-esclavo, pero debemos considerar el impacto en nuestro sistema cuando realizan la conmutación maestro-esclavo.
En Mysql y Redis, cuando falla un switch maestro-esclavo o gateproxy, se desconecta la conexión a la red, por lo que debemos manejar la interrupción de la red y reconectarnos en la lógica. Durante la fase de desconexión y reconexión de la red, ciertas solicitudes de la base de datos fallarán inevitablemente, y también debemos solucionar este problema anormal.
En el escenario de aterrizaje de datos, es necesario determinar si cada solicitud de base de datos es exitosa, si no lo es, reintentar y asegurar la idempotencia de la solicitud para evitar que la solicitud se ejecute varias veces.
Cuarto, el objetivo de alta concurrencia y alta disponibilidad.
Para lograr una alta concurrencia y alta disponibilidad, tiene un costo de desarrollo relativamente grande y los recursos humanos no son ilimitados en la mayoría de los proyectos. Por lo tanto, cuando esté realizando un trabajo relacionado, debe diseñar en exceso, considerando de manera integral las necesidades comerciales, las expectativas y los costos de desarrollo.
De hecho, el costo de desarrollo al que me refiero no es solo que la cantidad de desarrollo del programa es mayor, sino que cuanto más complejo es el sistema, más propenso a problemas. Si no hay suficiente mano de obra para probar, mantener e iterar, es mejor utilizar una forma más sencilla de lograrlo La probabilidad de problemas es menor.
Por supuesto, si su equipo de proyecto es la gloria del rey y la élite de la paz, los requisitos de alta concurrencia y alta disponibilidad son muy altos y la mano de obra es casi ilimitada, ignore este párrafo.
Millones de simultáneos en línea
En la industria de los juegos, un millón en línea simultánea se considera generalmente como el objetivo concurrente de la arquitectura del servidor de juegos, y la magnitud de un millón es también el límite superior de la mayoría de los juegos (excepto King y Chicken).
Por lo tanto, en el diseño de la arquitectura previa al juego, la planificación y las pruebas de estrés, podemos estimar la capacidad requerida por diferentes sistemas en base a millones de online simultáneos como referencia, y es suficiente para alcanzar esta capacidad.
Por ejemplo, nuestro juego, aunque hay muchos puntos únicos y cuellos de botella en el rendimiento, según nuestra estimación, incluso si existen estos puntos únicos, podemos estar en línea al mismo tiempo agregando soporte de máquina a 100w. Entonces, estos puntos únicos y cuellos de botella están dentro de nuestras expectativas y no optimizaremos más.
Si un día necesitamos admitir decenas de millones de juegos en línea al mismo tiempo, teóricamente podemos continuar eliminando puntos únicos y optimizando los cuellos de botella de rendimiento, pero el costo aumentará significativamente.
¡Altamente disponible! = Completamente disponible
Nuestra búsqueda de alta disponibilidad de clústeres de servidores no requiere tolerancia a desastres para todas las excepciones, es imposible y poco realista.
Según el pensamiento de skynet, si un nodo no responde de manera oportuna, todas las solicitudes para acceder a él se bloquearán sin tiempo de espera. Si el nodo está inactivo, informará directamente el rastreo. Es equivalente a que Skynet considera el clúster como un todo y no tiene un mecanismo tolerante a fallas. Si un nodo principal falla, el clúster completo no debería estar disponible.
Como dije anteriormente, en general, estoy de acuerdo con la idea de skynet, que puede reducir efectivamente la carga de pensar durante el desarrollo empresarial. Sobre esta base, para algunas anomalías comunes, el impacto debe minimizarse para evitar el efecto de avalancha.
Alta simultaneidad y alta disponibilidad más allá de la tecnología
La alta concurrencia y la alta disponibilidad también tienen una mayor relación con las no tecnologías, como las capacidades de operación y mantenimiento, las condiciones del hardware, la calidad del personal y el nivel de gestión.
Para resolver la alta concurrencia, es necesario implementar clústeres a gran escala, lo que impondrá requisitos más altos en las capacidades de operación y mantenimiento. En el caso de un número pequeño de usuarios y un grupo pequeño, la operación y el mantenimiento manuales son aceptables, pero a medida que aumenta la escala y la complejidad del grupo, la operación y el mantenimiento manuales se volverán cada vez más difíciles y deben ser procesados y automatizados.
Muchos de los problemas en el sistema de juego son en realidad causados por problemas de operación y mantenimiento, procesos y especificaciones, como la entrega incorrecta de beneficios después de que Zhan Shuang se conectó.
Por lo tanto, para obtener alta concurrencia y alta disponibilidad, las herramientas de operación y mantenimiento, los procedimientos de operación y mantenimiento y las especificaciones deben realizarse bien, sin operación y mantenimiento humanos, y la operación y mantenimiento deben estar equipados y automatizados. Además, el monitoreo, la alarma y la respuesta rápida del personal también son condiciones necesarias para el funcionamiento estable de sistemas a gran escala.
Espero que pueda ser útil para todos aprender y usar una alta concurrencia. Mis amigos favoritos pueden ayudar con un clic y tres enlaces. ¡Gracias!