sql >> Base de Datos >  >> NoSQL >> Redis

Redis:Race Condition y Single threaded

Si Redis es de subproceso único, ¿por qué necesita un mecanismo de bloqueo?

De hecho, Redis es (principalmente) de un solo subproceso, pero se requiere bloqueo cuando varios clientes intentan hacer cosas diferentes en la proximidad temporal adyacente. El bloqueo discutido en RiA se trata exactamente de eso:garantizar que solo un cliente/subproceso realice una tarea específica, o asegurarse de que las actualizaciones no salgan mal.

Aquí hay un ejemplo de por qué necesitaría el bloqueo a pesar del subproceso único de Redis:suponga que tiene un valor en Redis, un número, por ejemplo, almacenado bajo una clave llamada foo . El código de tu aplicación lee ese número (GET foo ), hace algo (es decir, agrega 1) y lo vuelve a escribir (SET ). Cuando ejecuta su código en un solo hilo, así es como se vería:

App               Redis
 |---- GET foo ---->|
 |<------ 1 --------|
 |                  |
 | thinking...      |
 |                  |
 |--- SET foo 2 --->|
 |<----- OK --------|

Ahora veamos qué sucede cuando dos clientes de aplicaciones intentan hacer esto:

App 1             Redis              App 2
 |---- GET foo ---->|                  |
 |<------ 1 --------|<--- GET foo -----|
 |                  |------- 1 ------->|
 | thinking...      |                  |
 |                  |       thinking...|
 |--- SET foo 2 --->|                  |
 |<----- OK --------|<--- SET foo 2 ---|
 |                  |------ OK ------->|

Aquí puede ver de inmediato lo que sucedió sin bloquear, a pesar de que el servidor (en su mayoría) tiene un solo subproceso, en lugar de 3, foo El valor de es 2. A medida que agrega más subprocesos/clientes/aplicaciones, las cosas pueden salir terriblemente mal cuando varios escritores intentan modificar los datos sin coordinación (es decir, bloqueo).

El bloqueo optimista es solo una de las formas de hacerlo, que Redis ofrece integrado a través de WATCH mecanismo. A veces, sin embargo, el optimismo, a pesar de su naturaleza tranquila y feliz, no es la solución adecuada, por lo que deberá implementar mecanismos mejores/avanzados/diferentes para evitar condiciones de carrera. Podría decirse que tales bloqueos podrían implementarse incluso fuera de Redis, pero si ya lo está utilizando, tiene sentido administrar sus bloqueos también.