Discusión sobre cómo resolver problemas de rendimiento de ventas flash y sobreventa
PD: Antes de ingresar al texto, déjame contarte algunos sentimientos personales. Solía mirar el PPT de Taobao y sentí que no podía entenderlo. Cuando lo resolví yo mismo, descubrí que había. Todavía hay muchas cosas inesperadas que no entendí. Lo verifiqué nuevamente. Teoría "El diablo está en los detalles". Y la capacidad de una persona es limitada. Sólo discutiendo juntos podemos pensar de manera más integral y detallada. Bien, sin más preámbulos, entremos en el texto principal.
1. ¿Qué aporta la venta flash?
Las actividades de venta flash o venta urgente generalmente pasan por tres enlaces principales: reserva, obtención de pedidos y pago. Entre ellos, el vínculo de obtención de pedidos y pago es la prueba más importante de la capacidad del proveedor comercial para resistir la presión.
El proceso de obtención de pedidos generalmente genera dos problemas:
1. Alta concurrencia
La venta flash más popular tiene un número tan alto de 100.000 personas. de personas en línea La arquitectura del sitio web es una prueba de adelante hacia atrás.
2. Sobreventa
Cualquier producto tendrá un límite superior de cantidad. ¿Cómo evitar realizar un pedido para comprar productos con éxito sin exceder el límite de cantidad del producto? enfrentar en cada evento de compra urgente.
En segundo lugar, ¿cómo solucionarlo?
En primer lugar, no analizamos soluciones de productos. Solo discutimos soluciones técnicas
1. Front-end
Ante las actividades de captura de pedidos de alta concurrencia, las tres herramientas comunes utilizadas por el front-end son expandir la corriente estática. limitante
A: expansión de capacidad
Agregar máquinas Este es el método más simple para aumentar la resistencia máxima general del grupo frontal.
B: Estatización
Estatiza todos los elementos que se pueden estatizar en la página activa y minimiza los elementos dinámicos. Anti-peaking vía CDN.
C: Limitación de tráfico
Se suele utilizar la limitación de tráfico a nivel de IP, es decir, para una determinada IP, el número de solicitudes iniciadas por unidad de tiempo es limitado.
O agregue juegos o sesiones de preguntas durante el horario de entrada al evento para eliminar las operaciones pico.
D: Pérdida de servicio
El último recurso es rechazar aleatoriamente algunas solicitudes cuando se acerca al límite superior de la capacidad de carga del grupo frontal para garantizar la disponibilidad general de la actividad.
2. Backend
Entonces, ¿qué problemas encontrará la base de datos de backend en caso de alta concurrencia y condiciones de sobreventa? Hay principalmente tres problemas: (se trata principalmente de problemas de escritura, los problemas de lectura se pueden resolver fácilmente agregando caché)
1: Primero, MySQL en sí tiene problemas con el alto rendimiento del procesamiento concurrente. En términos generales, el rendimiento de procesamiento de MySQL aumentará a medida que aumente el número de subprocesos concurrentes, pero después de que la concurrencia alcance un cierto nivel, habrá un punto de inflexión obvio.
Dos: en segundo lugar, la causa principal de la sobreventa es que la operación de reducción de inventario es una operación transaccional, que requiere primero seleccionar, luego insertar y finalmente actualizar -1. Esta última operación -1 no puede ser un número negativo, pero cuando varios usuarios operan el inventario al mismo tiempo, los números negativos son inevitables.
Tres: finalmente, cuando la reducción de inventario y la alta concurrencia ocurren juntas, debido a la gran cantidad de operaciones de inventario en la misma fila, se producirá competencia por los bloqueos de fila de InnoDB, lo que provocará esperas mutuas o incluso bloqueos, por lo que Reduce enormemente el rendimiento de procesamiento de MySQL y, finalmente, provoca una excepción de tiempo de espera en la página de inicio.
¿Cómo solucionar los problemas anteriores? Echemos un vistazo a los ingeniosos trucos de Taobao:
Uno: desactive la detección de interbloqueos para mejorar el rendimiento del procesamiento concurrente.
Dos: modificar el código fuente y mencionar la cola antes de ingresar a la capa del motor para reducir la concurrencia de la capa del motor.
Tres: envíos grupales para reducir la cantidad de interacciones entre el servidor y el motor y reducir el consumo de IO.
Para conocer el contenido anterior, consulte el artículo "La ineficiencia de MySQL en el escenario de venta flash" compartido por Ding Qi en DTCC 2013.
Después de utilizar todas las medidas de optimización del artículo, el TPS en alta concurrencia se disparó de los 150 originales a 8,5 w, un aumento de casi 566 veces, ¡lo cual da mucho miedo!
Pero basándonos en nuestra situación actual, la elevada solución de cambiar el código fuente es obviamente un poco irreal. Por tanto, es necesario que todos debatan una solución que se adapte a nuestra situación actual. Las siguientes son las soluciones que discutimos:
En primer lugar, establezca la premisa de que para evitar fenómenos de sobreventa, todas las operaciones de reducción de inventario deben realizar controles de reducción para garantizar que la reducción no pueda ser igual a un valor negativo. número. (Debido a las características de las transacciones MySQL, este método solo puede reducir la cantidad de sobreventa, pero es imposible evitarla por completo)
Actualizar cantidad establecida x=x-1 donde (x -1) gt; = 0; Solución 1:
El inventario avanza de MySQL a Redis y todas las escrituras se colocan en la memoria. No hay bloqueos en Redis, por lo que no habrá que esperarse unos a otros, y dado que el rendimiento de escritura y lectura de Redis es mucho mayor que el de MySQL, esto resuelve el problema del alto rendimiento de concurrencia. Luego, los datos modificados se escriben de forma asincrónica en la base de datos mediante métodos asincrónicos como colas.
Ventajas: resuelve el problema de rendimiento
Desventajas: no resuelve el problema de sobreventa. Al mismo tiempo, debido a la escritura asincrónica en la base de datos, existe el riesgo de que los datos en. la base de datos y Redis serán inconsistentes en un momento determinado.
Solución 2:
Introduzca colas y luego ponga en cola todas las operaciones de escritura de base de datos en una sola cola para un procesamiento completamente en serie. Cuando se alcanza el umbral de inventario, ya no está en la cola de consumo y la función de compra se desactiva. Esto resuelve el problema de sobreventa.
Ventajas: Se soluciona el problema de sobreventa y se mejora ligeramente el rendimiento.
Desventajas: el rendimiento está limitado por el rendimiento de procesamiento más corto del procesador de cola y el rendimiento de escritura de la base de datos. Además, se deben preparar varias colas cuando se compran varios productos al mismo tiempo.
Solución 3:
Reenviar operaciones de escritura a MC mientras se utiliza el mecanismo de bloqueo liviano CAS de MC para implementar operaciones de reducción de inventario.
Ventajas: lectura y escritura en la memoria, el rendimiento de la operación es rápido, la introducción de bloqueos livianos puede garantizar que solo una escritura sea exitosa al mismo tiempo, resolviendo el problema de reducir el inventario.
Desventajas: no existe una prueba real según las características de CAS, no sé si se producirá una gran cantidad de fallas de actualización en condiciones de alta concurrencia. Sin embargo, agregar bloqueos definitivamente tendrá un impacto en el rendimiento de la concurrencia.
Solución 4:
Convierta la operación de envío en un proceso de dos etapas: primero aplique y luego confirme. Luego use la operación de incremento atómico de Redis (no hay nulo en comparación con el incremento automático de MySQL) y use la función de transacción de Redis para emitir el número para garantizar que cualquiera que obtenga un número menor o igual al umbral de inventario pueda enviar un pedido con éxito. Luego, los datos se actualizan de forma asincrónica en la base de datos.
Ventajas: Se soluciona el problema de sobreventa. La lectura y escritura del inventario se realiza en la memoria, por lo que se soluciona el problema de rendimiento al mismo tiempo.
Desventajas: debido a la escritura asincrónica en la base de datos, pueden producirse inconsistencias en los datos. También es posible realizar una compra insuficiente, es decir, si la persona que obtuvo el número en realidad no realizó un pedido, el inventario puede reducirse a 0, pero la cantidad del pedido no alcanzó el umbral del inventario.
3. Resumen
1. Expansión de la capacidad del front-end y limitación de corriente estática
2. p>4. Pensamiento no técnico
1. El poder del equipo es infinito y los amigos discuten varias soluciones (dejando de lado la viabilidad). Queremos que todos hagan oír su voz y no se apresuren a negarlo.
2. La optimización requiere pensar desde un nivel general. No te concentres solo en la parte de la que eres responsable. Si solo te concentras en un punto y piensas en él, probablemente terminarás muerto. fin.
3. Hay muchas cosas que entenderás después de leerlas detenidamente, pero este no es el caso.
Aún necesitas practicar, de lo contrario el conocimiento de los demás nunca será tuyo.
4. Piensa más en por qué y qué sucederá, y no lo des por sentado. Sólo así podremos profundizar y no quedarnos en la superficie.