7 dimensiones diferentes, explicando el diseño de la arquitectura del sistema seckill en detalle

Hoy hablaré sobre el diseño de la arquitectura del sistema seckill desde 7 dimensiones diferentes, los principales puntos de conocimiento son los siguientes:

  • Nginx + separación de front-end y back-end + caché de CDN + puerta de enlace (limitación de corriente + disyuntor)

  • Capa de enrutamiento de clúster + Redis (datos de punto de acceso de caché, bloqueos distribuidos)

  • Clúster MQ

  • capa de procesamiento empresarial

  • Capa de base de datos (separación de lectura y escritura, aislamiento de puntos de acceso)

1. Características de las ofertas relámpago

  • Una gran cantidad de operaciones para actualizar la página en un instante.

  • Una gran cantidad de operaciones de captura de tesoros en un instante.

  • Puede haber una competencia feroz con los flash killers

2. Idea general

2.1 Afeitado de picos y limitación de corriente

  • Front-end + intercepción de Redis, solo las solicitudes con deducciones de redis exitosas pueden ingresar al flujo descendente

  • MQ acumula pedidos para proteger la carga de la capa de procesamiento de pedidos. Los consumidores toman las tareas de acuerdo con sus propias capacidades de consumo. De hecho, la presión aguas abajo es controlable. Concéntrese en la seguridad de la capa de enrutamiento y MQ

  • Introducir medidas como códigos de verificación de respuesta y latencia aleatoria de solicitudes para cortar picos y llenar valles.

Medida de seguridad

  • Los juicios deben hacerse en la página y en la interfaz para evitar la captura de pedidos antes de que comience el evento, y para evitar clics repetidos en el botón para tomar pedidos continuamente.

  • Evite el robo malicioso de pedidos por parte de flash killers, limite el flujo de IP, limite la compra de ID de usuario, introduzca preguntas de respuesta para interferir con el clicker y haga inferencias de sentido común sobre el tiempo de respuesta del clicker

  • Lista negra de IP, función de lista negra de ID de usuario

  • Descarte de sobrecarga: cuando los indicadores principales, como QPS o CPU, superan un cierto límite, la solicitud se descarta para evitar que el servidor cuelgue y garantizar que la mayoría de los usuarios estén disponibles.

Optimización de página, separación dinámica y estática

  • El contenido de la página web de los productos seckill debe ser lo más simple posible: imágenes pequeñas, js css, pequeño volumen y cantidad, el contenido debe estar separado de lo estático y dinámico tanto como sea posible.

  • En el proceso de obtención de tesoros en seckill, se realiza una actualización asincrónica para obtener tesoros, sin necesidad de que los usuarios actualicen la página para obtener tesoros, lo que reduce la presión de la interacción del servidor.

  • Puede usar la separación dinámica y estática de Nginx y no obtener recursos estáticos a través de los navegadores web tradicionales

  • nginx habilita la compresión gzip, comprime los recursos estáticos, reduce el ancho de banda de transmisión y mejora la velocidad de transmisión

  • O use Varnish para almacenar en caché recursos estáticos en la memoria para evitar la presión en el servidor causada por la adquisición de recursos estáticos

procesamiento asíncrono

  • Después de que redis obtiene el pedido con éxito, lanza el negocio de seguimiento al grupo de subprocesos para el procesamiento asíncrono, lo que mejora la velocidad de respuesta para obtener el pedido.

  • Cuando el grupo de subprocesos se está procesando, la tarea se lanza a MQ y espera de forma asíncrona a que cada subsistema procese (sistema de pedidos, sistema de inventario, sistema de pago, sistema de cupones).Las operaciones asíncronas tienen problemas de transacción, transacciones locales y transacciones distribuidas, pero en
    orden para mejorar el grado de concurrencia, es mejor sacrificar la consistencia. Al escanear regularmente los registros estadísticos, los pedidos problemáticos se encuentran y procesan de manera oportuna

separación de puntos calientes

Trate de evitar el impacto de la función seckill en las funciones normales, por ejemplo, seckill arrastrará hacia abajo una determinada función del servidor.

La separación puede mejorar la tolerancia a desastres del sistema, pero el costo de transformación del aislamiento completo es demasiado alto. Intente usar la configuración de middleware para realizar la separación de calor y frío.

  • Separación de los nodos del clúster: la configuración de nginx hace que los nodos del clúster para negocios seckill sean diferentes del clúster para negocios ordinarios.

  • Separación de MQ: para evitar que el negocio de picos llene la cola de mensajes, y el retraso de las transacciones de los negocios ordinarios también es particularmente grave.

  • Separación de bases de datos: elija de acuerdo con el QPS real de la segunda muerte. Después de que los datos activos se dividan en bases de datos, se agregará el problema de las transacciones distribuidas y el rendimiento de las consultas entre bases de datos será peor al consultar (ShardingJDBC tiene esto función), por lo que debe pesarse en el futuro. Luego, decida si necesita una sub-biblioteca

  • Evite un solo punto: cada enlace debe tratar de evitar

  • Degradación: cierre temporalmente algunas funciones menos importantes, como la función de transferencia de los productos seckill y la función de retiro de efectivo de los sobres rojos. Después de que haya pasado el valor máximo de seckill, configure el interruptor y luego abra dinámicamente estas funciones secundarias

Recomendación de videotutorial relacionado: diseño del sistema de picos

2.2 Detalles de diseño de Nginx

  • Separación dinámica y estática, no use tomcat para obtener recursos estáticos

 server {
        listen       8088;
    location ~ \.(gif|jpg|jpeg|png|bmp|swf)$ {  
        root    C:/Users/502764158/Desktop/test;  
    } 

    location ~ \.(jsp|do)$ {
            proxy_pass http://localhost:8082;
        }
    }
 }

  • La compresión Gzip reduce el volumen de transferencias de archivos estáticos, ahorra ancho de banda y mejora la velocidad de procesamiento

    gzip on;
    gzip_min_length 1k;
    gzip_buffers 4 16k;
    gzip_comp_level 3;
    gzip_disable "MSIE [1-6]\.";
    gzip_types   text/plain application/x-javascript text/css application/xml text/javascript image/jpeg image/gif image/png;

Configure la carga del clúster y la recuperación ante desastres, configure el tiempo para la reconexión después de una falla, después de una falla, el nodo que cuelga no se volverá a intentar de forma regular, parámetros:

  • fail_timeout por defecto es 10s

  • max_fails por defecto es 1. Es decir, siempre que un servidor falle una vez, la solicitud no se distribuirá al servidor en los próximos 10 segundos.

  • proxy_connect_timeout tiempo de espera de conexión del servidor backend_initiate apretón de manos esperando el tiempo de espera de respuesta

    upstream  netitcast.com {  #服务器集群名字   
    server    127.0.0.1:8080;
    server    127.0.0.1:38083;
    server    127.0.0.1:8083;
    } 

 server {
        listen       88;
        server_name  localhost;
    location / {  
            proxy_pass http://netitcast.com;  
            proxy_connect_timeout       1;
            fail_timeout 5;
        } 
    }

  1. Integre Varnish para el almacenamiento en caché de recursos estáticos

  2. Protección integrada contra sobrecarga del motor

2.3 Detalles de optimización de página

reducir el estrés de la interacción

  • Intente poner archivos js y css en algunos para reducir la cantidad de veces que el navegador interactúa con el backend para obtener recursos estáticos

  • Trate de evitar el uso de imágenes grandes o el uso de demasiadas imágenes en la página del producto seckill

controlar con seguridad

  • Verificación de validez de tiempo: la captura de pedidos no se puede realizar antes de que se alcance el tiempo de seguridad y, al mismo tiempo, el backend del programa también necesita verificar la validez de tiempo, porque el tiempo de la página web está determinado por el tiempo del sistema respectivo, y el seckiller puede llamar directamente a la captura sin pasar por la verificación

  • Acaparamiento de pedidos asincrónico: haga clic en el botón para actualizar el acaparamiento de tesoros en lugar de actualizar la página (el código de verificación para responder preguntas, etc. también es interacción ajax)

  • Además, si busca en la cuenta oficial de Linux, debe aprender a responder "mono" en segundo plano y obtener un paquete de regalo sorpresa.

  • Redis limita la corriente IP

  • redis como limitación actual de ID de usuario

2.4 Aplicación del clúster de Redis

  1. Bloqueo distribuido (bloqueo pesimista)

  2. Caché de datos calientes (inventario): si el QPS es demasiado alto, otra solución es usar localcache, y la base de datos controla la consistencia del estado distribuido

Bloqueo pesimista distribuido (consulte el código de bloqueo pesimista redis)

  • Bloqueo pesimista (porque la afirmación debe ser seria)

  • Tiempo de caducidad (después de agarrar el candado, configure el tiempo de caducidad inmediatamente para evitar el cierre anormal de un determinado subproceso, lo que resulta en el cierre de todo el negocio)

  • Bucle de tiempo y retroalimentación rápida (el caché for tiene una configuración de tiempo de espera. Después de cada tiempo de espera, el inventario se lee nuevamente y la segunda ronda de competencia de bucle for se lleva a cabo si todavía hay existencias, para lograr una retroalimentación rápida y evitar continuo bloqueo de agarre cuando no hay stock)

Procesar pedidos de forma asíncrona

  • Después de que Redis agarra con éxito el candado, después de registrar la información del usuario que agarra el candado, el candado se puede liberar directamente y el usuario puede retroalimentarse para procesar el pedido de manera asíncrona, a fin de mejorar la eficiencia de seckill y reducir hilo sin sentido esperando

  • Para evitar datos asincrónicos fuera de sincronización, cuando es necesario tomar el bloqueo, la lista de información del usuario se almacena en caché en redis.Después de que se completa el caché, la información del usuario se activa para persistir después de la toma exitosa del pedido, y la consistencia es comparado regularmente.

2.5 Limitación de corriente de la cola de mensajes

Afeitado de picos de cola de mensajes y limitación de corriente (el Consumidor integrado de RocketMQ tiene su propio grupo de subprocesos y medidas de limitación de corriente), clúster. Generalmente, son microservicios, como el centro de pedidos, el centro de inventario, el centro de puntos y el centro de productos del usuario.

2.6 Diseño de base de datos

  • Dividir transacciones para mejorar la concurrencia

  • Considere las subbases de datos de acuerdo con las necesidades comerciales: separación de lectura y escritura, aislamiento de puntos de acceso y división, pero presentará problemas de transacciones distribuidas y la dificultad de las operaciones entre bases de datos.

Acciones a realizar: deducción de inventario, generación de nuevos pedidos, generación de pedidos pendientes, deducción de cupones, cambios de puntos

La tabla de inventario es el cuello de botella de la concurrencia de la base de datos, y se debe realizar una compensación en el control de transacciones: puede establecer la deducción del inventario como una transacción independiente y otras operaciones como una transacción grande (pedidos, cupones, operaciones de puntos) , mejora la concurrencia, pero haz una verificación adicional

actualizar la tabla de inventario establecer inventario = inventario-1 donde id = ** e inventario> 1

2.7 Diseño de código de verificación de respuesta

  • Puede prevenir la interferencia de flash killers, para que más usuarios tengan la oportunidad de agarrar

  • Al retrasar la solicitud, el tiempo de respuesta de todos es diferente, lo que distribuye el tráfico instantáneo

El diseño del código de verificación se puede dividir en dos tipos:

  • Vuelva a actualizar la respuesta cuando falle la verificación (12306): el servidor tiene una gran cantidad de interacción, y cada vez que hay una interacción incorrecta, puede reducir en gran medida la posibilidad de que el secker responda la pregunta, porque no hay prueba y función de error, y la respuesta sigue cambiando

  • Si la verificación falla, indica una falla, pero no actualiza el algoritmo de la respuesta: la respuesta es exitosa, ingresa a la interfaz de pedido o solicita el tipo incorrecto y continúa respondiendo la pregunta (no actualice la respuesta, sin interacción, use js para verificar el resultado).
    Esta solución puede cargar la respuesta encriptada MD5 al cargar la pregunta y luego verificarla nuevamente en segundo plano para lograr un efecto similar de prevención de trampas. El beneficio es que no se requiere interacción adicional con el servidor.
    Deben introducirse factores como el ID de usuario y PK en el algoritmo de respuestas encriptadas MD para garantizar que cada respuesta sea diferente e irregular, y evitar el conjunto de resultados estadísticos del atacante.

Verificación de la respuesta: Además de verificar la corrección de la respuesta, también es necesario contar el tiempo de reacción, por ejemplo, el problema 12306, la velocidad de respuesta más rápida de un ser humano normal es de 1,5 s, luego la verificación de menos de 1s puede ser juzgado como verificación de máquina

3. Precauciones

Para mejorar la concurrencia, debe comprometer las transacciones:

  • División de transacciones en una sola máquina: por ejemplo, la deducción de la tabla de inventario + (generación de pedidos a pagar + deducción de cupón + cambio de puntos) es una transacción grande. Para mejorar la concurrencia, se puede dividir en 2 transacciones

  • Para garantizar la experiencia del usuario, es mejor mantener manualmente a través del análisis de registros, de lo contrario, el bloqueo será demasiado grave y la concurrencia será deficiente.

     

Supongo que te gusta

Origin blog.csdn.net/Javatutouhouduan/article/details/130025189
Recomendado
Clasificación