Cómo implementar la función de captura de tickets en PHP
Opción 1: usar colas para implementar
. Puede basarse en, por ejemplo, colas de mensajes como MemcacheQ, el plan de implementación específico se puede expresar de la siguiente manera
Anteriormente, si había 100 tickets para que los usuarios los tomaran, entonces estos 100 tickets se podían colocar en el caché, lectura y escritura No es necesario bloquear. Si hay 100 tickets en juego para un usuario, estos 100 tickets se pueden colocar en el caché sin bloquear las lecturas y escrituras. Cuando la concurrencia es alta, alrededor de 500 personas pueden conseguir entradas con éxito, de modo que las solicitudes de 500 personas posteriormente puedan dirigirse a una página estática al final del evento. No hay manera de que 400 de las 500 personas que entran obtengan los productos. Por lo tanto, solo puedes ingresar a la cola en el orden de las primeras 100 personas que compraron exitosamente. Las siguientes 400 personas irán directamente a la página final del evento. Por supuesto, la entrada de 500 personas es solo un ejemplo de cuántas personas se pueden ajustar. La página final de la actividad debe ser una página estática y no utilizar una base de datos. Esto puede reducir la presión sobre la base de datos.
Opción 2: cuando hay varios servidores, se puede implementar en forma de descarga
Supongamos que hay m tickets, n servidores de productos que reciben solicitudes y x rutas de solicitud El servidor reenvía aleatoriamente
Asigne directamente m/n tickets a cada servidor de producto
La memoria de cada servidor de producto se utiliza como contador, por ejemplo, m/n* (1+0,1) individuos son permitido entrar. 0.1) Entran individuos.
Cuando el contador de memoria está lleno:
Las personas que ingresan por detrás saltarán directamente a la página estática donde termina la actividad,
Notifique al servidor de enrutamiento que no lo haga. ruta aquí Servidor (esto es discutible).
Todos los servidores del producto vienen en m/n* (1+0.1) personas, y luego todos se reenvían al servidor de pago e ingresan el enlace de pago para ver quién es más rápido. En este momento, hay. Pocas personas y el bloqueo es sencillo.
Opción 3, si es un servidor único, puedes usar el bloqueo de Memcache para lograrlo
product_key es la clave del recibo
product_lock_key es la clave de bloqueo del recibo
Cuando product_key existe en Memcached, todos los usuarios pueden ingresar al proceso de pedido.
Al ingresar al proceso de pago, primero almacene add(product_lock_key, "1") en memcached.
Si la devolución es exitosa, se ingresará al proceso de pago.
Si no tiene éxito, significa que alguien ya ingresó al proceso de pago, luego el hilo espera N segundos y realiza la operación de agregar de forma recursiva.
Estudié tu pregunta detenidamente e imaginé tu entorno.
Quizás 100 entradas. 100.000 personas corrieron a conseguir entradas.
Puedes crear una cola de mensajes en el servidor. No importa cuántas personas obtengan boletos, ingresarán primero a la cola de mensajes. De esta manera transformamos la alta concurrencia en un único hilo unificado.
Todo está bien en este momento. La ventaja es que reduce la presión instantánea sobre MYSQL
, pero la desventaja es que si 10,000 personas hacen clic para obtener boletos en 1 segundo. Puede resultar difícil para los usuarios transitorios acceder. (Porque todo el mundo está haciendo cola)
Si cree que unos cientos de milisegundos son insoportablemente lentos, entonces debe adoptar un enfoque diferente:
Haga un bloqueo de contención para evitar múltiples tickets A. pueden acceder varios usuarios al mismo tiempo. (Emisión de billetes en MYSQL)
Almacena un indicador en la memoria para determinar si un billete todavía está disponible.
Cuando aparece la etiqueta de memoria: No hay más tickets. Todos los usuarios restantes descansan.
La ventaja de esto es que es simple para MYSQL y los usuarios.
La desventaja es que es un poco problemático. Depende de tus necesidades específicas.