problemas de concurrencia Redis
Desde Redis es de un solo subproceso, por lo que ¿por qué tiene problemas de concurrencia. En teoría, Redis es una operación de modificación con el fin, habrá múltiples hilos simultáneamente modificación.
Pero si hay un escenario como sigue:
una cadena, clave para un valor de 1. Mientras se incrementan a dos clientes.
También adquirieron un valor de 1, mientras que la solicitud de los Redis, con el valor de un 2.
surgen tales problemas de concurrencia.
Redis sí se ejecutan en orden, que en sí no tiene problemas de concurrencia, pero para la solicitud del cliente, no es el caso.
La solución está bloqueado.
Redis Bloqueo Distribuido
En realidad muy simple, es decir, por la necesidad de modificar la configuración de una cadena, llave fija, con setNx.
Todo lo que necesita para modificar el funcionamiento del valor de la cadena tendrá que setNx éxito, de lo contrario no se puede modificar.
Después de editar, es necesario eliminar la cadena a los otros hilos.
Como se muestra a continuación
//1 加锁，设置一个只有本线程可以拿到的Redis的key-value，还要设置一下保存时间
boolean isLock = cacheUtil.setNx(LOCK + "_" + id + "_" + bpin, "1", 2, TimeUnit.HOURS);
if(!isLock){
//获取锁失败后的操作
}
Ejemplo completo de la siguiente manera:
try{
//1 加锁，设置一个只有本线程可以拿到的Redis的key-value，还要设置一下保存时间
boolean isLock = cacheUtil.setNx(LOCK + "_" + id + "_" + bpin, "1", 2, TimeUnit.HOURS);
if(!isLock){
//获取锁失败后的操作
}
//2 获取锁成功后要对某个key进行的操作
String allStr = cacheUtil.hGet(ALL + "_" + id, bpin);
cacheUtil.hSet(ALL + "_" + id, bpin, allStr + 1);
}catch (Exception e){
e.printStackTrace();
}finally {
//3 关闭Redis的锁
cacheUtil.del(LOCK + "_" + id + "_" + bpin);
}
marco redisson
Redisson Redis oficial se distribuye en el marco de la cerradura, es muy simple:
el mecanismo de bloqueo primer punto
Client 1 inicia una cerradura
- Los iniciados cliente un comando de bloqueo para "myLock" para el bloqueo: bloqueo RLock = redisson.getLock ( "myLock"); lock.lock ();
- Información comprende enviadas: duración bloqueado (30s por defecto), el ID de cliente - 8743c9c0-0795-4907-87fd-6c719a6b4586: 1
- Redis servidor recibe el mensaje, a través de "existe myLock" comando para determinar qué, si quieres cerradura que asegure no existe la clave, que será bloqueado.
- comando de bloqueo es el siguiente: HAjuste myLock 8743c9c0-0795-4907-87fd-6c719a6b4586: 1 1. Explicar, aquí es un ID de cliente clave para la tabla hash, y un valor de 1. Los datos se estructura de la siguiente manera:
- A continuación, realiza "pexpire myLock 30000" de comandos, establece el tiempo para myLock vivo la tecla de bloqueo es de 30 segundos.
- Cerradura se ha completado.
El punto 2, el mecanismo de bloqueo mutex
El cliente 2 para tratar de bloqueo:
- El cliente 2 para tratar de bloquear
- ejecuta el servidor Redis "existe myLock", que se encuentra myLock la tecla de bloqueo ha estado en existencia.
- A continuación, un segundo juicio en cuanto a lo que, las estructuras de datos de bloqueo de clave hash en myLock, contiene el ID de cliente 2, pero no significativa, porque no hay identificación 1 comprende un cliente.
- El cliente obtendrá un retorno a 2 PTTL myLock digital, esta cifra representa el myLock tiempo de vida restante de la tecla de bloqueo. Por ejemplo, 15.000 milisegundos restante vida.
- El cliente 2 entrará en un bucle while, dejar de tratar de bloqueo.
El punto 3, perro guardián mecanismo de extensión automática
cerradura Cliente bloqueado 1 vez clave por defecto fue de 30 segundos, si hay más de 30 segundos, el cliente le gustaría tener 1 mantiene el bloqueo, cómo hacerlo?
! sencilla 1 Una vez bloqueado, siempre y cuando el cliente tiene éxito, se iniciará un perro guardián del perro guardián, que es un subproceso de fondo, comprobará cada 10 segundos, si el cliente 1 también tiene la llave de bloqueo, entonces se continuará extendiendo la cerradura duración de la clave.
El punto 4, reentrante mecanismo de bloqueo
Si esta es la forma de hacerlo?
Esto implica que el mecanismo de bloqueo reentrante
- Cliente 1 de nuevo para tratar de bloqueo
- ejecuta el servidor Redis "existe myLock", que se encuentra myLock la tecla de bloqueo ha estado en existencia.
- A continuación, un segundo juicio en cuanto a lo que, de hash estructura de datos tecla de bloqueo myLock, el cliente contiene la ID 1, está obviamente incluido. El siguiente paso
- Comando: incrby myLock 8743c9c0-0795-4907-87fd-6c71a6b4586: 1 1, el número de bloqueo del cliente terminal 1, incrementa en 1. Se convierte en la siguiente:
- La estructura de datos de hash ID de cliente en myLock, que corresponde al número de bloqueado
El punto 5, liberar el mecanismo de bloqueo
- Ejecución lock.unlock (), puede liberar el bloqueo distribuido.
- Bloqueo a la estructura de datos de frecuencia myLock menos 1.
- Si encuentra un número de bloqueo es 0, lo que indica que el cliente ya no tiene el bloqueo.
- En este punto que va a utilizar: comando "del myLock", elimine la clave de Redis años.
Las deficiencias son las siguientes:
Si usted es un ejemplo principal Redis, escrita tecla de bloqueo myLock de este valor, esta vez se copiará en el maestro-esclavo asíncrono instancia correspondiente.
Sin embargo, este proceso se produce una vez redis abajo maestro, la conmutación de espera, REDIS esclavo se convierte en un maestro redis.
A continuación, dará lugar a que el cliente pruebe 2 cuando está bloqueado, el bloqueo se completa en el nuevo maestro Redis, pero también pensaba que era un cliente ha añadido correctamente un bloqueo.
En este momento, que dará lugar a más clientes para completar una cerradura de bloqueo distribuido.
A continuación, el sistema tendrá problemas en la semántica de negocio, lo que resulta en una variedad de datos sucios.
cerradura por lo que este es el grupo principal Redis, o ReDiS arquitectura maestro-esclavo de la replicación asíncrona ReDiS distribuye causó el mayor defecto: Cuando ReDiS ejemplo maestro de tiempo de inactividad podría conducir a varios clientes al mismo tiempo de bloqueo completo.
Transferencia: https: //www.cnblogs.com/daofaziran/p/11811510.html
