Transacción y monitoreo en Redis (bloqueo optimista)

Negocios

La esencia de la transacción de Redis:

Una colección de comandos. Todos los comandos de una transacción se serializarán y se ejecutarán en secuencia durante la ejecución de la transacción.

Características de la transacción de Redis:

• Una vez
• Secuencial
• Exclusividad

Las transacciones de Redis no tienen un concepto de nivel de aislamiento.

Todos los comandos no se ejecutan directamente en la transacción, Exec solo se ejecutará cuando se inicie el comando de ejecución

¡El comando único de Redis tiene atomicidad garantizada, pero las transacciones no tienen atomicidad garantizada!

Asuntos de redis

1. Iniciar transacción (múltiple)
2. Orden de unirse al equipo (....)
3. Transacción de ejecución (exec)

127.0.0.1:6379> multi    #开启事务
OK
#命令入队
127.0.0.1:6379> set k1  v1
QUEUED
127.0.0.1:6379> set k2 v2
QUEUED
127.0.0.1:6379> set k3 v3
QUEUED
127.0.0.1:6379> get k3
QUEUED
127.0.0.1:6379> exec  #执行事务
1) OK
2) OK
3) OK
4) "v3"

Rendirse

127.0.0.1:6379> multi   #开启事务
OK
127.0.0.1:6379> set k1 v1
QUEUED
127.0.0.1:6379> set k2 v2
QUEUED
127.0.0.1:6379> set k4 v4
QUEUED
127.0.0.1:6379> discard    #取消事务
OK
127.0.0.1:6379> get k4    #事务队列中的命令都不会被执行
(nil)

Dos anormalidades

1. Compilación de excepción (el comando es incorrecto), no se ejecutarán todos los comandos de la transacción

127.0.0.1:6379> multi  
OK
127.0.0.1:6379> set k1 v1
QUEUED
127.0.0.1:6379> set k2 v2
QUEUED
127.0.0.1:6379> getset k3   #错误命令
(error) ERR wrong number of arguments for 'getset' command
127.0.0.1:6379> set k4 v4
QUEUED
127.0.0.1:6379> exec  #执行是事务报错
(error) EXECABORT Transaction discarded because of previous errors.
127.0.0.1:6379> get k4   #所有的命令都不会执行
(nil) 

2. Excepción de tiempo de ejecución (1/0), si hay gramática en la cola de transacciones, cuando se ejecuta el comando, otros comandos se pueden ejecutar normalmente, el comando incorrecto arroja una excepción.

127.0.0.1:6379> set k1 "v1"
OK
127.0.0.1:6379> multi
OK
127.0.0.1:6379> incr k1  #字符串自增1 会执行失败
QUEUED
127.0.0.1:6379> set k2 v2
QUEUED
127.0.0.1:6379> set k3 v3
QUEUED
127.0.0.1:6379> exec
1) (error) ERR value is not an integer or out of range  #虽然第一条命令报错了，但是还是正常执行成功了
2) OK
3) OK
127.0.0.1:6379> get k2
"v2"

Monitor Watch (Entrevista Preguntas frecuentes)

Cerradura pesimista:

Muy pesimista, pensando que habrá problemas en cualquier momento, sin importar lo que se bloqueará

Bloqueo optimista:

Soy muy optimista y creo que no habrá problemas en ningún momento, por lo que no se bloqueará. Al actualizar los datos, juzgue si alguien ha modificado estos datos durante este período.

ver uso

• Obtener versión
• Comparar versión al actualizar
• Prueba de monitoreo de prueba de Redis

La ejecución normal es exitosa:

127.0.0.1:6379> set money 100
OK
127.0.0.1:6379> set out 0
OK
127.0.0.1:6379> watch money   #监视money对象
OK
127.0.0.1:6379> multi  #事务正常结束，数据期间没有发生改变，这个时候正常执行成功！
OK
127.0.0.1:6379> decrby money 20
QUEUED
127.0.0.1:6379> incrby out 20
QUEUED
127.0.0.1:6379> exec
1) (integer) 80
2) (integer) 20

Pruebe valores de modificación de subprocesos múltiples, use watch como operación de bloqueo optimista para redis

127.0.0.1:6379> watch money   #监视money
OK
127.0.0.1:6379> multi
OK
127.0.0.1:6379> decrby moeney 10
QUEUED
127.0.0.1:6379> incrby out 10
QUEUED
127.0.0.1:6379> exec   #执行之前，另外一个线程修改了money的值，就会导致事务执行失败！
(nil)

La modificación falló:

1. Si se descubre que la ejecución de la transacción falla, se desbloquea primero
2. Obtenga el último valor y vuelva a monitorear
3. Compruebe si el valor monitoreado ha cambiado. Si no hay cambio, se puede ejecutar. Si el cambio falla, la ejecución continuará, y continuará desbloqueando y monitoreando nuevamente.

127.0.0.1:6379> unwatch   #如果发现事务执行失败，就先解锁
OK
127.0.0.1:6379> watch money    #获取最新的值，再次监视
OK
127.0.0.1:6379> multi
OK
127.0.0.1:6379> decrby money 60
QUEUED
127.0.0.1:6379> incrby out 60
QUEUED
127.0.0.1:6379> exec  #比对监视的值是否发生变化，如果没有发生变化，可以执行，如果变化就执行失败，继续解锁再次监视。
1) (integer) 1020
2) (integer) 80