Nombre de la pluma: haibiscuit
Blog Park: https://www.cnblogs.com/haibiscuit/
Dirección de Git: https://github.com/haibiscuit?tab=repositories (bienvenido estrella)
La dirección del proyecto: https://github.com/haibiscuit/StudyBook
Respete los logros laborales del autor, por favor no vuelva a imprimir sin permiso
Prólogo
Acabo de tener una entrevista y, por supuesto, colgué, así que escribí este artículo para suprimirme y suavizar mi corazón agraviado.
Texto:
Uno: problemas que enfrentan las cerraduras distribuidas
1.1 La cerradura debe ser única
1.2 La cerradura debe tener un tiempo de espera para evitar un punto muerto
1.3 La creación de bloqueos y la configuración de tiempos de espera de bloqueo deben ser atómicos
1.4 Tiempo de espera de bloqueo
1.5 El problema de las cerraduras reentrantes
1.6 El problema de las cerraduras distribuidas en el clúster
1.7 Otras cuestiones a considerar para las cerraduras distribuidas redis
Dos: explicación y solución de problemas que enfrentan las cerraduras distribuidas
2.1 La cerradura debe ser única
Explicación del problema:
En primer lugar, el problema que deben resolver los bloqueos distribuidos es que múltiples procesos acceden y operan al mismo recurso en un entorno distribuido. Dado que es el mismo recurso, definitivamente debe considerar los problemas de seguridad de los datos. De hecho, el principio de bloquear y desbloquear en un solo proceso es Del mismo modo, en un solo proceso, varios subprocesos deben considerar el acceso y la modificación de la misma variable. Para garantizar que varios subprocesos no accedan a la misma variable al mismo tiempo, para modificar la variable en orden, es necesario bloquear al acceder a la variable. El bloqueo puede ser un bloqueo pesado o un bloqueo optimista basado en cas.
La solución:
Utilice el comando redis setnx (establecer si no existe), que solo puede ser ocupado por un cliente. Si una instancia de redis tiene una clave única, si desea establecer un valor en la clave, será rechazada.
2.2 La cerradura debe tener un tiempo de espera para evitar un punto muerto
Explicación del problema:
Redis necesita la operación del cliente para liberar el bloqueo. Si el cliente se cuelga repentinamente en este momento, no hay ninguna operación para liberar el bloqueo. También significa que otros clientes desean volver a bloquear, pero no pueden agregar el problema.
La solución:
Por lo tanto, para evitar el problema de que el cliente se cuelga o el cliente no puede liberar el bloqueo normalmente, es necesario agregar un tiempo de espera al bloqueo mientras se agrega el bloqueo.
Es decir, las operaciones de agregar un bloqueo y agregar un tiempo de espera al bloqueo son las siguientes:
> setnx lockkey true # Operación de bloqueo
Okay
> expire lockkey 5 # Agregue un tiempo de espera al bloqueo
... hacer algo crítico ...
> del lockkey #release lock
(entero) 1
2.3 La creación de bloqueos y la configuración de tiempos de espera de bloqueo deben ser atómicos
Explicación del problema:
A través de la configuración de 2.3 bloqueo y tiempo de espera, puede ver que setnx y caducar requieren dos comandos para completar la operación, es decir, se requieren dos operaciones RTT. Si entre los dos comandos de setnx y caducar, el cliente se cuelga repentinamente, lo que Cuando no se puede liberar el bloqueo y se devuelve el problema del punto muerto.
La solución:
Use el comando extendido establecido
Como sigue:
> establecer lockkey true ex 5 nx #Lock, tiempo de vencimiento 5s
Okay
... hacer algo crítico ...
> del lockkey
El comando set lockkey true ex 5 nx anterior puede completar las dos operaciones de setnx y caducar al mismo tiempo, que es resolver el problema de atomicidad.
2.4 Tiempo de espera de bloqueo
Explicación del problema:
Aunque el tiempo de espera se agrega al bloqueo anterior, el cliente no necesariamente puede completar la tarea programada dentro del tiempo de espera, por lo que incluso si el cliente actual no completa la tarea, otros clientes establecerán con éxito el bloqueo en este momento. El mismo recurso enfrentará el problema de que varios clientes operen simultáneamente.
La solución:
El cliente puede realizar tareas programadas después de que el bloqueo se haya configurado correctamente, use el script lua para eliminar el bloqueo y restablecer el bloqueo y el tiempo de espera antes de que el bloqueo se agote.
Por supuesto, ¿por qué usa lua para completar la operación aquí? De hecho, al igual que el problema atómico anterior, entre eliminar el bloqueo y restablecer el bloqueo y el tiempo de espera de bloqueo, puede enfrentar a otros clientes que ocupan los recursos del bloqueo, y lua tiene La característica atómica, las dos operaciones de eliminar el bloqueo y volver a bloquear se han completado o no.
2.5 El problema de las cerraduras reentrantes
Explicación del problema:
Hablamos sobre lo anterior. Para garantizar que el bloqueo sea único, necesitamos usar setnx. Más tarde, para configurarlo con el tiempo de espera, elegimos el comando set.
Durante el bloqueo que deseamos, el cliente que posee el bloqueo desea obtener el bloqueo nuevamente, que es el reingreso del bloqueo. Por supuesto, el problema aquí es similar al problema 2.5.
La solución:
Del mismo modo, podemos elegir usar el script lua para eliminar y configurar el bloqueo nuevamente.
2.6 El problema de las cerraduras distribuidas en un clúster
Explicación del problema:
Este problema ocurrirá en la solución de clúster redis. De hecho, para garantizar la alta disponibilidad y el rendimiento de acceso de redis, se configurarán el nodo maestro y el nodo esclavo de redis. Significa que todos nuestros bloqueos deben escribirse en la instancia principal del servidor redis. Si el servidor redis principal se cae, se liberan recursos (cuando no hay persistencia, si se agrega persistencia, este problema será más complicado). En ese momento, los datos del nodo maestro redis no se copian en el servidor esclavo. En este momento, otros clientes tendrán la oportunidad de adquirir el bloqueo, y el cliente que anteriormente tenía el bloqueo aún puede estar operando en el recurso. El problema del acceso a los recursos y la operación.
La solución:
Este tema está preparado para ser discutido por separado por escrito porque no está claro en una o dos oraciones.
2.7 Otros asuntos a considerar para las cerraduras distribuidas redis
Lo anterior discute los problemas que redis encontrará en la lógica empresarial, y la solución puede limitarse a la solución que discutí anteriormente.
Por supuesto, hay una lógica que debe seleccionarse de acuerdo con la propia escena del programador.
Por ejemplo:
(1) Al configurar la clave, dónde obtener el recurso clave
Entre ellos, el problema del consenso de recursos multicliente está involucrado. El análisis simple es cómo se determina que cuando varios clientes bloquean el mismo recurso, la clave debe ser coherente con varios clientes, de lo contrario, ¿cómo puedo garantizar La singularidad de la clave en múltiples clientes.
(2) Cuando se libera el bloqueo, solo puede ser liberado por el cliente que posee el recurso de bloqueo
Por supuesto, este problema se debe a la escritura incorrecta de su lógica de bloqueo y desbloqueo.De acuerdo con el análisis anterior, siempre que resuelva todos los problemas anteriores con los bloqueos distribuidos redis, generalmente no se encuentra el problema de la liberación del bloqueo del cliente.
Sin embargo, esto también es una cuestión de detalle, que debe considerarse en la lógica empresarial
Tres: resumen
El problema de redis distribuir bloqueos en el clúster, hablaré de ello en otro artículo
Espero que mi trabajo se estabilice rápidamente, vamos gallo