Transacción y bloqueo distribuido
Transacción: un conjunto de comandos
Los principales comandos multi y exec
multi set a 1 sadd s1 a ...... exec
Manejo de errores
- (1) Error de sintaxis
127.0.0.1:6379> multi OK 127.0.0.1:6379> set a 1 QUEUED 127.0.0.1:6379> set b (error) ERR número incorrecto de argumentos para el comando 'set' 127.0.0.1:6379> seta c (error) ERR comando desconocido 'seta' 127.0.0.1:6379> exec (error) EXECABORT Transacción descartada debido a errores anteriores. 127.0.0.1:6379> obtener un (nulo) 127.0.0.1:6379>
Mientras exista algún error gramatical, no se ejecutará el correcto
- (2) Error de operación Por
ejemplo, a es un tipo de cadena, y luego sigue la operación hash hset a k1 v1
127.0.0.1:6379> teclas * (lista vacía o conjunto) 127.0.0.1:6379> establecer un 1 OK 127.0.0.1:6379> escribir una cadena 127.0.0.1:6379> multi OK 127.0.0.1:6379> establecer n 1 QUEUED 127.0.0.1:6379> hset a k1 v1 QUEUED 127.0.0.1:6379> set m 2 QUEUED 127.0.0.1:6379> exec 1) OK 2) (error) WRONGTYPE Operación contra una clave que contiene el tipo de valor incorrecto 3) OK 127.0.0.1:6379> mget n m 1) "1" 2) "2" 127.0.0.1:6379> escriba una cadena
Se ejecuta la instrucción correcta, la transacción de redis no admite la reversión, por lo que el desarrollador debe lidiar
con el nombre de la clave estandarizada en el desarrollo por sí mismo , y este problema generalmente no ocurre
DESCARTAR cancelar transacción
Cerradura distribuida
setnx a: lock 1 expire a: lock 5 del a: lock
Para permitir que setnx y expire se ejecuten juntos, y la ejecución de expire depende del éxito de setnx, obviamente no es cierto poner en la transacción
Instrucciones atómicas combinadas con setnx y expire
establecer a: bloqueo 1 ex 10 nx
Lo anterior es esta operación atómica con un bloqueo de 1 y una validez de 10 s
Problema de tiempo de espera
Los bloqueos distribuidos de Redis no pueden resolver el problema del tiempo de espera. Si la lógica entre el bloqueo y la liberación del bloqueo se ejecuta demasiado tiempo para exceder el límite de tiempo de espera del bloqueo, se producirán problemas. Debido a que el bloqueo retenido por el primer subproceso expira en este momento, la lógica de la sección crítica aún no se ha ejecutado, en este momento el segundo subproceso retiene el bloqueo por adelantado, lo que hace que el código de la sección crítica no se pueda ejecutar estrictamente en serie. .
Para evitar este problema, los bloqueos distribuidos de Redis no deben usarse para tareas a largo plazo. Si ocurre ocasionalmente, el desorden de la ondícula en los datos puede necesitar una intervención manual para resolverlo.