Recientemente, debido al impacto de la epidemia de neumonía infectada por el nuevo coronavirus, el aumento del tráfico ha aumentado dramáticamente.
Desde el 3 de febrero, Dingding ha introducido continuamente un pico de tráfico: más de 10 millones de empresas usan Dingding para trabajar en línea, con un número total de más de 200 millones; más de 200 oficinas de educación en más de 20 provincias de todo el país han lanzado un programa de "transmisión en vivo de cursos". Involucrando a más de 12 millones de estudiantes, incluyendo más de 20,000 escuelas primarias y secundarias.
El crecimiento sostenido del negocio también ha hecho que Dingding tenga muchos momentos históricos: el 5 de febrero, Dingding saltó a la cima de las clasificaciones gratuitas de Apple en la tienda de aplicaciones, ocupando hasta la fecha
El 6 de febrero, Dingding fue puesto en CCTV, y Dingding CTO fue entrevistado
El tráfico de brotes proviene principalmente de la oficina remota y las funciones de educación en línea de DingDing. Literalmente, parece ser solo dos funciones comerciales de DingDing, pero no hay menos de 20 módulos dependientes dentro de DingDing, principalmente en mensajería / video conferencia / Transmisión en vivo / escuela en casa / tarjeta perforada de salud y otros escenarios comerciales. Cómo garantizar el rendimiento y la estabilidad de más de 20 empresas en un crecimiento tan explosivo es un gran desafío para el sistema de fondo y el sistema de base de datos de Dingding.
Este artículo presentará cómo ganamos esta "batalla" desde la perspectiva de la base de datos DBA, qué desafíos encontramos en el proceso, cómo organizamos nuestro equipo, cómo pensar, cómo usar realmente la tecnología para superarlos. Desafíe, y finalmente a través de esta batalla, qué experiencia y tecnología hemos acumulado.
1. Desafíos para el sistema de base de datos.
La base de datos es una fuerte dependencia del funcionamiento del sistema de negocios de Dingding. En este escenario similar al Doble 11, cómo planificar y desplegar la base de datos se ha convertido en la parte más importante de la estabilidad, pero esta batalla llegó demasiado repentinamente, no tenemos muchos Tiempo de preparación, por lo que enfrentamos muchas dificultades y desafíos En resumen, tenemos los siguientes tres puntos:
1. ¿Cuál es la capacidad requerida del sistema y es imposible predecir el módulo de mensajes como ejemplo? Antes del Festival de Primavera, el tráfico máximo diario de Dingding News era inferior a 10 millones. Para la primera evaluación de capacidad, todos establecieron un objetivo para el 3 de febrero. Es tres veces el pico diario. Con la llegada del pico del 10 de febrero, el objetivo del 10 de febrero se ajustará a 10 veces, y luego el objetivo se ajustará a 40 veces nuevamente debido a la llegada de la temporada escolar el 17 de febrero. . ¡Entonces la capacidad total es 40 veces mayor que el pico diario!
2. El tiempo es escaso, hay muchas demandas de expansión de capacidad y recursos insuficientes.El aumento en el tráfico epidémico ha causado al sistema tanto impacto como el doble 11 cada año. El comercio electrónico pasará medio año preparándose para el Doble 11, pero el tiempo que nos queda esta vez solo se puede medir en horas. Por otro lado, debido a consideraciones de costo, Dingding básicamente no tiene máquinas de repuesto en el grupo de recursos, y la densidad de despliegue de recursos existente también es relativamente alta. Cómo mover recursos para expandir la capacidad de Dingding cerca de 20 grupos principales en un corto período de tiempo Es un gran problema
3. Cómo garantizar la estabilidad del sistema y la experiencia del usuario en escenarios extremos ¿Qué podemos hacer cuando varios factores impiden que el clúster se expanda y el sistema haya alcanzado el cuello de botella? ¿Qué medidas de emergencia se pueden utilizar? ¿Existe un punto de equilibrio para minimizar el impacto en los usuarios?
2. Medidas de respuesta
El repentino aumento en el tráfico comercial también es una inspección exhaustiva del sistema de base de datos subyacente del equipo de Dingding. Confiando en la gestión y el control maduros subyacentes, DTS, el sistema de middleware, el equipo de base de datos y el equipo comercial de Dingding trabajan en estrecha colaboración para resolver los desafíos anteriores uno por uno a través de capacidades profesionales y productos maduros.
1. Arreglo razonable del personal
1) Durante el establecimiento del equipo de base de datos durante la epidemia, los miembros del equipo de seguridad empresarial de enclavamiento incluyeron al equipo de base de datos DBA / kernel de base de datos / CORONA / TDDL / DTS / jingwei / NOSQL estudiantes de la línea de productos.
Según la línea de negocios de Dingding, cada DBA sigue una línea de negocios, participa en el período pico de protección y transmite el estado del sistema en línea y el nivel de agua a tiempo, para que el personal de toma de decisiones de la compañía de seguros pueda mantenerse al tanto del estado del sistema. Trate con urgencia los problemas que ocurren en línea para garantizar que los problemas se reparen en poco tiempo. Optimice los escenarios empresariales irracionales para garantizar que los problemas conocidos solo ocurran una vez. Participe en la prueba de presión del sistema y encuentre los puntos de riesgo potenciales que deben corregirse a tiempo, expanda el sistema con una capacidad insuficiente en el tiempo y permita que la base de datos tenga capacidad suficiente antes del pico cuando se cumplan los recursos.
2) El equipo de la base de datos trabaja en estrecha colaboración con el equipo de estabilidad de Dingding. Debido a los recursos limitados en la etapa inicial, hay muchos sistemas que deben ampliarse. Cada propietario de la línea de negocio considera que su sistema es el más importante. Debe dar prioridad a la expansión de su propia base de datos, e incluso algunos propietarios se retiran. Su propio líder o incluso el líder del líder vino al DBA para aumentar la demanda de expansión.
Esto ejerce mucha presión sobre el DBA. Es realmente porque hay demasiados monjes y poca carne, por lo que el DBA ha sufrido muchas quejas. En este momento, el equipo de estabilidad de Dingding tomó la iniciativa de ponerse de pie y ayudar al DBA a compartir mucha presión. Priorice las necesidades de expansión de la base de datos de acuerdo con la importancia del negocio y unifique las necesidades de expansión. El DBA juzga de acuerdo con el orden de prioridad y la capacidad objetivo del negocio, y se expande sistemáticamente bajo los recursos limitados para garantizar que los recursos se utilicen primero en la hoja. Mejorando enormemente la eficiencia de expansión.
2. Coordinación de recursos de emergencia.
La epidemia estalló repentinamente, y todos esperaban que el flujo aumentara, pero nadie sabía cuánto aumentaría, y era necesario prepararse temprano. Para garantizar que los recursos no se conviertan en una resistencia a la expansión del sistema. El DBA y el equipo de recursos en la nube hicieron planes razonables. A corto plazo, al tomar prestada la máquina en la nube del grupo, al mismo tiempo que reducía el tamaño de otros grupos de bases de datos de BU, reunimos alrededor de 400 máquinas para garantizar la expansión de los sistemas de alta prioridad y coordinar la reubicación de los recursos en la nube En solo unos días, más de 300 máquinas fueron reubicadas en el grupo de recursos de clavos, lo que garantiza los requisitos de expansión de todas las bases de datos de clavos.
Una vez que los recursos estén en su lugar, es hora de verificar la resistencia de la base de datos. Confiando en la arquitectura de implementación distribuida de tres nodos PolarDB-X, podemos actualizar y expandir fácilmente el clúster original en línea, lo que tiene un bajo impacto en los usuarios y garantiza datos consistentes. Sexo En algunos escenarios, los usuarios necesitan migrar datos desde el clúster original a un nuevo clúster con más sub bases de datos y tablas. También podemos usar DTS con una plataforma de administración y control madura para completar sin problemas. Al final, siempre que haya recursos, la base de datos también puede ser extremadamente flexible para satisfacer las necesidades comerciales.
3. Emergencia y optimización
Antes de que llegue el pico del sistema, el equipo de la base de datos ya ha preparado un plan de emergencia: rebajar los parámetros, ajustar los parámetros de la base de datos para dar un juego completo a las capacidades de la base de datos, mejorar el rendimiento
Reduzca los recursos, ajuste los límites de recursos, libere el aislamiento de la CPU y aumente urgentemente el tamaño de la base de datos
Para SQL anormal, limitación de flujo de emergencia después de la confirmación del impacto o intervención de emergencia a través del perfil de ejecución del plan SQL
Se distribuye el flujo de clúster completo de la base de datos en espera, y el tráfico de lectura máximo se puede cambiar a la base de datos en espera de acuerdo con la situación de presión.
Prepare scripts consistentes con bases de datos débiles para mejorar aún más el rendimiento de la base de datos cuando sea necesario
Al mismo tiempo, combinado con el plan actual de límite / rebaja de la empresa, puede garantizar el funcionamiento estable de muchos sistemas de bases de datos cuando llega el pico de tráfico desconocido.
Sin embargo, el límite actual del servicio reduce la experiencia de muchos usuarios. El valor límite actual del servicio anterior se estableció en 30QPM / grupo, lo que significa que cada grupo solo puede enviar 30 mensajes en un minuto y, a menudo, incluso más en los primeros 20 segundos de 1 minuto. En poco tiempo, se han enviado 30 mensajes. En el tiempo restante de más de 40 segundos, la experiencia del usuario es que no se pueden usar clavos. Para esta situación, el DBA recomienda reducir la ventana de límite actual y cambiar el valor límite actual 30QPM a 30 / 20S. Reducido en un 97%, mejorando en gran medida la experiencia del usuario.
(La curva roja es el límite de flujo)
4. Estimación de capacidad de DB y análisis de desempeño
En los negocios, el nivel de agua del sistema puede analizarse aproximadamente a través de la situación de la CPU del clúster, pero para el DB, no solo la CPU, IO, red, SQL, bloqueo, etc., el cuello de botella de cualquier componente a menudo se convertirá en el cuello de botella de la capacidad final. Los diferentes modelos de negocio a menudo tienen diferentes cuellos de botella, incluso si se trata de consultas a gran escala, algunos pueden ser cuellos de botella de la CPU, algunos pueden ser causados por una relación de memoria insuficiente y otros pueden ser causados por diseños de índice irrazonables. La parte más complicada es que algunos cuellos de botella a menudo no son lineales. Puede que no sea un problema aumentar la presión 2 veces, y las capacidades del hardware todavía son excedentes, pero cuando se aumenta a 3 veces, se vincula directamente. En este escenario, ¿cómo podemos evaluar con mayor precisión la capacidad de la base de datos?
En el pasado, utilizamos nuestra experiencia y realizamos pruebas de presión de enlace completo con el lado comercial para estimar la capacidad de la base de datos (cuántas lecturas y escrituras puede admitir el clúster). Este método tiene los siguientes problemas:
El conjunto de datos de la prueba de presión es a menudo relativamente pequeño en comparación con la base de datos total, y la tasa de aciertos de la base de datos es básicamente del 100%, lo cual es un gran error para el análisis de modelos de negocio con IO
El costo es grande, y todos los enlaces ascendentes y descendentes deben conectarse, con la participación de más estudiantes.
Incluso si el enlace completo se prueba a presión, a menudo son solo unas pocas interfaces centrales las que realmente se presionan hasta el final de la base de datos, y no puede cubrir el 100% de todas las interfaces en la línea, y muchos SQL lentos a menudo provienen de estas interfaces fácilmente ignoradas.
En realidad, es muy fácil pensar en la forma de resolver este problema, siempre que todo el tráfico comercial en línea se recopile y reproduzca una vez, pero es muy complicado de implementar. Lo que realmente necesitamos es una capacidad de medición de presión de enlace único universal para DB, que no depende de los servicios aguas arriba. La capa de DB puede generar, escalar o reducir el tráfico por sí misma, e incluso cambiar la presión nuevamente después de cambiar la relación de transacción. .
A partir de 2019, con los esfuerzos conjuntos de los científicos de bases de datos del DBA y el Instituto Dharma, hemos desarrollado ClouDBench para cumplir con los requisitos anteriores, y ayudamos al DBA a evaluar la capacidad en esta batalla.
Primero muestra el efecto:
El azul es la curva de rendimiento del negocio real en un momento determinado, y el verde es la curva de rendimiento que recopilamos de la reproducción del tráfico final de la base de datos. Se puede ver que las dos curvas están muy ajustadas en series de tiempo, especialmente los indicadores dentro de InnoDB están muy cerca, incluyendo Fluctuaciones en el tráfico.
Cuando podemos reproducir la carga de trabajo de la empresa de manera más realista, podemos amplificar la presión para analizar la capacidad de la base de datos y analizar el cuello de botella de rendimiento en el escenario extremo, a fin de optimizar la base de datos y verificar el efecto de optimización.
ClouDBench se ha lanzado en el Servicio de Autonomía de la Base de Datos del Servicio Autónomo de Gray Cloud (DAS). Presentaremos la implementación de ClouDBench en detalle en un artículo de seguimiento.
3. Resultados y pensamiento
En el pico de la tercera ola el 17 de febrero, los diversos sistemas de Dingding estaban funcionando de manera constante. Desde el 18 de febrero, cambiamos del seguro completo anterior al mantenimiento diario. ¿Por qué tenemos esta confianza, porque tenemos una base de datos de todos los sistemas? Todos se han ampliado y optimizado, con la capacidad de superar con creces la capacidad actual del sistema.
En solo dos semanas, cada sistema de base de datos tiene la capacidad de varias veces a más de 40 veces, entre las cuales hay muchos grupos de bases de datos muy grandes con un espacio de almacenamiento superior a 1 PB. Todo esto demuestra plenamente la resistencia de la base de datos de Alibaba Cloud. A través de la cooperación perfecta de varios productos como control / DTS / CORONA, la base de datos de Alibaba Cloud es invencible frente al flujo máximo de la inundación epidémica.
El brote del tráfico provocado por esta epidemia no está preparado para nosotros. Después de experimentar esta campaña, hemos aprendido mucho. Si enfrentamos este tipo de problema nuevamente, podremos manejarlo. La experiencia resume los siguientes puntos:
1. Organización del personal:
En primer lugar, en la organización del personal, los negocios y el desarrollo deben tener una sensación aguda de tráfico repentino, descubrimiento oportuno y preparación temprana, y la persona responsable de la estabilidad de la parte comercial debe establecer un equipo de emergencia para clasificar el negocio dependiente y los sistemas de back-end correspondientes, y conectar a cada propietario de línea de negocio y antecedentes. El propietario del producto de la base de datos está incluido en el equipo de emergencia. El equipo de emergencia unifica la planificación de la capacidad, la asignación de mano de obra y la coordinación de recursos para lograr la vinculación entre las partes empresariales / equipos de productos de fondo / equipos de recursos.
2. Arquitectura técnica:
En términos de arquitectura técnica, por un lado, es necesario utilizar productos de bases de datos con suficiente flexibilidad para garantizar que los productos de bases de datos utilizados tengan la capacidad de expandirse y contraerse libremente, no solo para garantizar que el tráfico se pueda expandir después de llegar, sino también para garantizar que el tráfico diario se pueda reducir Abajo Cada componente de operación y mantenimiento, como la gestión y el control, necesita implementar la operación y el mantenimiento automáticos, mientras deja interruptores de emergencia para muchas operaciones clave para garantizar que en algunos escenarios extremos, puede ser más conveniente cambiar de conducción automática a modo manual para garantizar que la tarea se ejecute sin problemas y de manera eficiente .
3. Medidas de emergencia:
Cuando se enfrentan con cuellos de botella en el sistema, los productos comerciales y de base de datos deben prepararse con anticipación, y debe haber una degradación y funciones limitantes actuales en el negocio. Cuando el sistema no puede soportar la presión, algunas funciones no centrales pueden degradarse y limitarse en algunas ocasiones. Funciones básicas para garantizar el funcionamiento normal de los negocios principales. El producto de base de datos debe tener la capacidad de mejorar instantáneamente el rendimiento de la base de datos a través de algunos métodos de optimización sin expandir la capacidad y, lo que es más importante, estas capacidades deben tener una buena compatibilidad, en diferentes entornos de implementación y diferentes arquitecturas de bases de datos. Tener herramientas y planes correspondientes.
Por otro lado, necesitamos tener los medios para evaluar y detectar el efecto del plan. Ahora podemos usar ClouDBench para analizar y predecir la capacidad de la base de datos, pero el costo actual de uso sigue siendo demasiado alto. El seguimiento de ClouDBench necesita ser más automatizado, reducir el costo de uso y reducir Se transmite de forma transparente al propietario del negocio. Antes de la gran promoción, se realizan automáticamente una gran cantidad de pruebas de presión de enlace único DB para evaluar el nivel de agua del sistema, encontrar cuellos de botella en el rendimiento, optimizar los parámetros DB y verificar el efecto del plan.
Finalmente, ¡bendiga a Nail Sanduo con el apoyo de la base de datos de Alibaba Cloud para volar más alto y más lejos!
Para la nube, consulte Yunqi: más información sobre la nube, casos de la nube, mejores prácticas, introducción del producto, visite: https://yqh.aliyun.com/
Este artículo es contenido original de Alibaba Cloud y no puede reproducirse sin permiso.
