Tabla de contenido
1. Introducción a la transacción de Redis
Tres, cerradura optimista y cerradura pesimista
Xiaobai aprende el segundo registro de Redis. El último es principalmente para conocer Redis y comprender sus tipos de datos y la estructura de datos subyacente. Para obtener más detalles, consulte " Introducción a Redis, comenzando por la estructura de datos subyacente y los principios de la aplicación ". Luego, quiero registrar la parte de la transacción de Redis en este artículo. Siento que también es un contenido más importante. La función ACID de la transacción no es exclusiva de Redis. La base de datos Mysql también la tiene. Así que creo que esta función general es la punto central de la base de datos, y necesito entender el principio.
La base de datos es un sistema de gestión compartida orientado a múltiples usuarios con control de concurrencia y mecanismos de bloqueo para garantizar la integridad y el funcionamiento normal de la base de datos. Una transacción es una unidad que garantiza la integridad, el control de concurrencia y un mecanismo de bloqueo y consta de una serie de comandos de la base de datos como una unidad colectiva. Hay transacciones en bases de datos tanto relacionales como no relacionales. Echemos un vistazo al contenido relevante de las transacciones de Redis.
1. Introducción a la transacción de Redis
Comandos básicos implementados por transacciones de Redis: MULTI, EXEC, DISCARD, WATCH .
- MULTI: Inicie la transacción de Redis y configure el cliente en el estado de transacción.
- EXEC: envíe la transacción, ejecute el comando MULTI en la cola de comandos entre EXEC y el cliente se encuentra en un estado no transaccional en este momento.
- DESCARTAR: Cancela la transacción, borra todos los comandos en la cola de transacciones y el cliente sale del estado de transacción.
- OBSERVAR: Monitorear pares clave-valor Cuando no se hayan modificado todos los pares clave-valor monitoreados, la transacción se ejecuta normalmente, de lo contrario, la transacción no se ejecutará.
Actualmente, las transacciones de Redis garantizan que los comandos en una transacción solicitada por un cliente se puedan ejecutar de forma continua, y no se enviarán solicitudes de comando enviadas por otros clientes durante este proceso. Al recibir el comando MULTI , se abre un contexto de transacción y los comandos subsiguientes se colocarán en una cola, estos comandos se ejecutarán después de que el servidor reciba el comando EXEC .
Dos, características ACID
1. Atomicidad
La atomicidad de la transacción significa que después de que se inicia el estado de la transacción, los comandos en la cola se consideran como un todo, y Redis ejecuta todas las colas de comandos correctamente o no las ejecuta todas.
127.0.0.1:6379> set name "xiaochen"
OK
127.0.0.1:6379> set age 20
OK
127.0.0.1:6379> multi
OK
127.0.0.1:6379> set name "charzous"
QUEUED
127.0.0.1:6379> set age 21
QUEUED
127.0.0.1:6379> incrby age 3
QUEUED
127.0.0.1:6379> exec
1) OK
2) OK
3) (integer) 24
127.0.0.1:6379> get name
"charzous"
127.0.0.1:6379> get age
"24"
127.0.0.1:6379>Se puede ver que si el estado de la transacción no está activado, el comando de entrada regresará con " OK " después de que se complete la ejecución ; después de que se encienda el múltiple , el comando de entrada regresará con " QUEUE ", lo que indica que el comando ha entrado en la cola. Finalmente, después de que el comando exec ejecuta los comandos en la cola, devuelve todos los resultados de ejecución en una matriz.
A continuación, verifique la atomicidad de la transacción e ingrese deliberadamente el formato de comando incorrecto : establecer (sin clave-valor)
127.0.0.1:6379> multi
OK
127.0.0.1:6379> set name "test"
QUEUED
127.0.0.1:6379> set age 18
QUEUED
127.0.0.1:6379> set
(error) ERR wrong number of arguments for 'set' command
127.0.0.1:6379> set sex "male"
QUEUED
127.0.0.1:6379> exec
(error) EXECABORT Transaction discarded because of previous errors.
127.0.0.1:6379>(error) EXECABORT Transacción descartada debido a errores anteriores.
Se devuelve información de error. Redis descubrió que había una entrada de comando incorrecta en el proceso de la cola de ejecución, por lo que la ejecución de la transacción falló y la información recién verificada no se actualizó ni aumentó.
127.0.0.1:6379> get age
"24"
127.0.0.1:6379> get name
"charzous"
127.0.0.1:6379> get sex
(nil)
127.0.0.1:6379>Hay otra situación aquí, el tipo de comando ingresado es incorrecto, por ejemplo , si agrega 5 al campo de nombre en este momento: incrby name 5, ocurrirá la siguiente situación:
127.0.0.1:6379> multi
OK
127.0.0.1:6379> set name "test"
QUEUED
127.0.0.1:6379> set age 18
QUEUED
127.0.0.1:6379> incrby name 5
QUEUED
127.0.0.1:6379> set sex "male"
QUEUED
127.0.0.1:6379> exec
1) OK
2) OK
3) (error) ERR value is not an integer or out of range
4) OK
127.0.0.1:6379>En este momento, solo el comando con el tipo incorrecto no se ejecutará y los demás comandos no se verán afectados.
127.0.0.1:6379> get name
"test"
127.0.0.1:6379> get age
"18"
127.0.0.1:6379> get sex
"male"2. Coherencia
La coherencia de la transacción significa que los datos de la base de datos son coherentes antes y después de que se ejecute la transacción. Al principio, no creo que sea fácil de entender. La consistencia aquí es que la base de datos cambia del estado actual a un nuevo estado, y los datos aún cumplen con la definición y los requisitos de los datos antes y después, y no no contener datos sucios ilegales o inválidos . El significado literal debería ser: la definición de los datos en sí son las características del tipo de datos y las restricciones sobre el tipo de datos permanecen sin cambios.
Así como la atomicidad de la transacción se verifica arriba, si se ingresa el comando incorrecto, la ejecución de la transacción falla, lo que asegura la atomicidad y consistencia.
3. Aislamiento
El aislamiento de transacciones significa que varios usuarios acceden a la base de datos simultáneamente, y la base de datos abrirá una transacción para cada usuario por separado. No interfieren entre sí y están aislados entre sí, lo que logra el efecto de ejecutar transacciones en un estado concurrente y en serie. ejecución. Exactamente lo mismo.
Debido a que Redis tiene sus propias características, utiliza un modelo de un solo proceso y un solo subproceso para lograr el almacenamiento de pares clave-valor. Al ejecutar los comandos de la base de datos, utiliza un método de un solo subproceso. Los demás comandos no se ejecutarán hasta que se realice la última transacción ejecutado.
4, resistencia
La durabilidad de la transacción significa que después de que una transacción se ejecuta correctamente, los cambios en la base de datos son permanentes. Incluso si la base de datos encuentra una falla, la operación no desaparecerá después de que se ejecute la transacción.
La persistencia de Redis proviene de su método de persistencia único. En Redis, incluidos los métodos de persistencia AOF y RDB, ejecución asincrónica.
Los dos métodos de persistencia tienen sus propias ventajas y desventajas, y se pueden combinar con ventajas y escenarios.
Tres, cerradura optimista y cerradura pesimista
En esta parte, el bloqueo optimista y el bloqueo pesimista son exactamente el mecanismo de datos de lectura y escritura que se usa en las transacciones de Redis, y el comando WATCH usa este principio.
- Cerradura optimista
Como su nombre indica, este tipo de bloqueo tiene una personalidad optimista, cada vez que voy a la base de datos para leer datos, creo que otros no modificarán los datos y no bloquearán los datos. Pero también es tosco y detallado: al actualizar los datos, juzgará si los datos han sido modificados por otros durante el período. Si se ha modificado, la actualización se abandona; en caso contrario, se realiza la operación de actualización. Escenario de uso: lea más y escriba menos, mejore el rendimiento.
Estrategia de implementación: mecanismo de número de versión.
Hay un campo de "versión" en la tabla de datos, que registra el número de versión de los datos. Se leerá al leer datos y el número de versión es +1 al escribir datos. Compare el número de versión en su mano con el de la tabla de datos. Si es mayor que el número de versión en la tabla, actualice los datos; de lo contrario, significa que los datos no están actualizados y no se actualizan.
- Bloqueo pesimista
De igual forma, como su nombre indica, este candado tiene una personalidad pesimista, cada vez que busques datos, pensarás que ha sido modificado por otros, por lo que lo bloquearás cada vez para restringir el uso de otros. En las bases de datos relacionales tradicionales, hay una gran cantidad de bloqueos pesimistas: bloqueos de fila, bloqueos de tabla, bloqueos de lectura y bloqueos de escritura. Puede verse que la eficiencia es obviamente limitada.
Cuatro, comando WATCH
El comando WATCH en la transacción es un bloqueo optimista . Se usa para monitorear los comandos en la transacción, por lo que el comando EXEC debe ejecutarse condicionalmente.
Solo bajo la premisa de que todas las claves monitoreadas por el comando WATCH no han sido modificadas, la transacción se puede ejecutar con éxito. De lo contrario, el servidor se niega a ejecutar y devuelve una respuesta vacía de que la ejecución falló al cliente.
Estrategia de implementacion:
Cuando la clave monitoreada ejecuta comandos relacionados con la base de datos, llamará a la función touchWatchKey para abrir el logotipo REDIS_DIRTY_CAS del cliente que monitorea la clave de la base de datos modificada . Cuando el servidor recibe el comando EXEC, determinará si el cliente abre este logotipo para decidir si ejecutar la transacción.
Verifique el efecto del comando WATCH.
Si cree que es bueno, bienvenido a "un clic, tres enlaces", haga clic en Me gusta, marque, siga, comente directamente si tiene alguna pregunta, intercambie y aprenda.
Mi blog de CSDN: https://blog.csdn.net/Charzous/article/details/114546348