Cómo utilizar un cronómetro de alta concurrencia para resolver problemas de overbooking

Problemas causados ​​por ventas flash

Supongamos que solo queda un producto num = 1 en la base de datos

Pero 100 hilos leen este mensaje num al mismo tiempo; time = 1, por lo que los 100 subprocesos comienzan a reducir existencias.

Pero al final descubres que sólo un subproceso reduce con éxito el inventario y los otros 99 subprocesos fallan.

¿Por qué?

Aquí es donde entran en juego los bloqueos exclusivos de MySQL.

Los bloqueos exclusivos también se denominan bloqueos de escritura o, para abreviar, bloqueos X. Como su nombre lo indica, los bloqueos exclusivos no pueden coexistir con otros bloqueos. Por ejemplo, cuando una transacción obtiene un bloqueo exclusivo en una determinada fila de datos, otras transacciones no pueden obtener otros bloqueos en la fila, incluidos los bloqueos de disfrute *** y los bloqueos exclusivos.

Esto es similar a lo que sucede cuando hago una actualización, donde la fila es una transacción (con un bloqueo exclusivo por defecto). La fila no puede ser modificada, leída o escrita por ningún otro hilo.

Este método utiliza el método de numeración de versiones, que en realidad es el principio de CAS.

Supongamos que versión = 100, num = 1; ingresan 100 subprocesos y todos los subprocesos seleccionan la versión = 100.

Luego, cuando actualiza directamente, solo uno de los subprocesos se actualiza primero y actualiza el número de versión al mismo tiempo.

Luego, cuando los otros 99 subprocesos se actualizan, descubren que la versión no es igual a la última versión seleccionada, lo que significa que esa versión ha sido cambiada por otro subproceso. Entonces abandonaré esta actualización.

Utilice el preámbulo estándar de un solo subproceso de redis. Supongamos que hay 100 artículos.

Cada vez que ingresa un hilo de usuario, el valor de la clave se reduce en 1, y cuando el valor de la clave es 0, todas las solicitudes restantes se rechazan.

Entonces esto significa que solo 100 subprocesos realizarán operaciones posteriores. Por lo tanto, no debe haber ningún fenómeno de sobreventa.

Se puede ver que el segundo CAS es un reintento fallido y no está bloqueado. Debería ser mucho más eficiente que el primer bloqueo. Similar a la sincronización y CAS en Java.