Hola a todos~ Este es el último artículo de la serie de artículos de redis "[Fundamentos de redis] Transacción|Pipeline|Publicar suscripción": Persistencia de Redis [RDB+AOF] Héroes duales de persistencia_Trabaja duro y trabaja duro blog de mlx-CSDN Blog
Tabla de contenido
Transacciones de base de datos vs transacciones redis
Caso 2: Abandono de la transacción
Situación 3: Todos sentados juntos
Introducción de las preguntas de la entrevista y origen de las preguntas.
asuntos
concepto
La llamada transacción significa que varias instrucciones se ejecutan todas o no se ejecutan en absoluto. Una transacción puede ejecutar varios comandos a la vez, que es esencialmente un conjunto de comandos. Todos los comandos de una transacción se serializarán y ejecutarán en secuencia . no se permite la inserción de otros comandos, y no se permite la detención.
efecto
Almacene muchas instrucciones en una cola y ejecute una serie de instrucciones una sola vez, secuencial y exclusivamente
Transacciones de base de datos vs transacciones redis
comando común
Los comandos comúnmente utilizados para las transacciones son los siguientes:
Introducimos y usamos instrucciones específicas en detalle:
Caso 1: Ejecución normal
MULTI //
conjunto de inicio de transacción ...
EXEC // ejecutar
Caso 2: Abandono de la transacción
MULTI //
conjunto de inicio de transacción ...
DISCARD // abandono de transacción
Situación 3: Todos sentados juntos
Si una de las instrucciones de la transacción tiene un error de sintaxis, no se ejecutarán todas las instrucciones.
MULTI // inicio de transacción
establecido k1 // compilación de sintaxis fallida
EXEC // ejecutar
Situación 4: Acreedor malo
En un grupo de transacciones, la sintaxis de la instrucción en sí no tiene errores, pero no se ajusta a la especificación específica de la sintaxis de la instrucción, y luego se informa un error en la última ejecución. En este momento, solo la instrucción que informó el error no se ejecuta, y todas las demás instrucciones se ejecutan.
MULTI // inicio de transacción
incr k1 // la sintaxis se compila correctamente, pero la ejecución falla
EXEC // ejecutar
Caso 5: vigilancia del reloj
Primero aclarar algunos conceptos:
Bloqueo optimista: El bloqueo optimista (Optimistic Lock), como su nombre lo indica, es muy optimista, cada vez que vas a obtener los datos, piensas que los demás no lo modificarán, por lo que no lo bloquearás, pero al actualizar, lo harás . juzgar si otros lo tienen durante este período para actualizar estos datos. Estrategia de bloqueo optimista: la versión enviada debe ser mayor que la versión actual del registro para realizar la actualización
Bloqueo pesimista: El bloqueo pesimista (Pessimistic Lock), como su nombre lo indica, es muy pesimista. Cada vez que vas a obtener los datos, piensas que otros los modificarán, por lo que cada vez que obtienes los datos, los bloquearás, por lo que que otros bloquearán si quieren obtener los datos hasta que obtenga el bloqueo.
CAS: Similar al CAS de JUC
En redis, el reloj proporciona la función de CAS, y sus instrucciones detalladas son las siguientes:
mirar
circunstancias normales:
-
Inicialice los valores clave (k1 y claves de saldo), primero monitoree y luego habilite multi para asegurarse de que los dos cambios clave estén dentro de la misma transacción
-
ver k1 // bloquear
multi //transacción abierta
set k1 ninini //Modifica el valor de k1 por primera vez
set k1 owowowo //Modifica el valor de k1 por segunda vez
Dado que k1 se modifica dentro de una transacción, incluso si k1 tiene un bloqueo de vigilancia, la operación sigue siendo exitosa
Situación de atasco:
El comando watch es una implementación del bloqueo optimista. Redis detectará si los datos han cambiado cuando se modifican. Si se cambia, la ejecución fallará.
desvelar
dejar de monitorear
resumen:
- Una vez que se haya agregado el bloqueo de monitoreo del reloj antes de ejecutar exec, se cancelará.
- Cuando se pierde la conexión del cliente (como al salir de la conexión), no se supervisa todo
Resumir
Abrir Iniciar
una transacción con MULTI
Poner en cola
Poner en cola múltiples comandos en la transacción, estos comandos no se ejecutarán inmediatamente, sino que se colocarán en la cola de transacciones esperando a ser ejecutados
Ejecutar
la transacción es desencadenada por el comando EXEC
tubería
Introducción de las preguntas de la entrevista y origen de las preguntas.
Origen del problema
Redis es un servicio TCP basado en un modelo cliente-servidor y un protocolo de solicitud/respuesta. Una solicitud sigue estos pasos:
1. El cliente envía comandos al servidor en cuatro pasos (envío de comandos→posición en cola de comandos→ejecución de comandos→resultados de retorno) y monitorea el retorno del Socket, generalmente en modo de bloqueo para esperar que el servidor responda.2 El servidor procesa el comando y devuelve el resultado al cliente.Los dos pasos anteriores se denominan: Tiempo de ida y vuelta (conocido como RTT, el tiempo para los paquetes de datos hacia y desde ambos extremos), en la parte inferior de la nota de pregunta
Si necesita ejecutar una gran cantidad de comandos al mismo tiempo, debe esperar la respuesta del comando anterior antes de ejecutarlo, no solo hay más RTT (Round Time Trip), sino que también llama con frecuencia al sistema IO, envía solicitudes de red y requiere que redis llame varias veces Los métodos del sistema read() y write(), el método del sistema transferirá los datos del estado del usuario al estado del kernel, lo que tendrá un impacto relativamente grande en el contexto del proceso, y el rendimiento no es muy bueno, o(╥﹏╥)o
concepto
La tubería (tubería) puede enviar múltiples comandos al servidor a la vez. Después de que el servidor termine de procesar en secuencia, devolverá los resultados a la vez a través de una respuesta y reducirá el tiempo de demora de ida y vuelta al reducir la cantidad de comunicaciones. entre el cliente y redis . El principio de la implementación de la canalización es la cola, y la función de primero en entrar, primero en salir garantiza el orden de los datos. La tubería es para resolver el retorno de RTT, solo empaque el comando una vez y envíelo, sin ningún impacto en toda la ejecución de Redis (en una palabra, la tubería es una medida de optimización para el procesamiento por lotes, similar al comando de procesamiento por lotes nativo de Redis (mset / mgget) )
Presentación del caso
Resumir
Pipeline y lote nativo
- Los comandos por lotes nativos son atómicos (como: mset, mget) y la canalización no es atómica
- Los comandos por lotes nativos solo pueden ejecutar un tipo de comando a la vez, y la canalización admite la ejecución por lotes de diferentes comandos
- El servidor implementa el comando de lote nativo, mientras que el servidor y el cliente deben completar la canalización
Pipeline vs. Transacción
- Las transacciones son atómicas, los pipelines no lo son
- La tubería envía múltiples comandos al servidor a la vez, y la transacción se envía una por una. La transacción solo se ejecutará después de recibir el comando exec, y la tubería no
- La ejecución de una transacción bloqueará la ejecución de otros comandos, mientras que la ejecución de comandos en una canalización no lo hará.
Consideraciones de tubería
- Las instrucciones almacenadas en el búfer de la canalización solo se ejecutarán de forma secuencial y no se garantiza la atomicidad. Si se produce una excepción durante la ejecución, las instrucciones posteriores seguirán ejecutándose.
- La cantidad de comandos ensamblados mediante la canalización no debe ser demasiado grande, de lo contrario, el cliente puede bloquearse durante demasiado tiempo cuando la cantidad de datos es demasiado grande, y el servidor también se ve obligado a responder a una respuesta en cola, lo que requiere mucho tiempo. de la memoria
publicar suscribir
concepto
- es un patrón de comunicación de mensajes:
- El remitente (PUBLISH) envía el mensaje
- Los suscriptores (SUBSCRIBE) reciben mensajes y pueden implementar la entrega de mensajes entre procesos
- Redis puede implementar la función de middleware de mensajes MQ y realizar la guía y distribución de mensajes a través de la publicación y suscripción.
- Función
- El cliente de Redis puede suscribirse a cualquier número de canales, similar a nuestro WeChat, seguir múltiples cuentas públicas
La publicación/suscripción es en realidad una cola liviana, pero los datos no se conservarán y, por lo general, se usa para procesar mensajes asincrónicos con un alto rendimiento en tiempo real.
Comandos comunes
SUBSCRIBE channel [canal] // Suscríbete a varios canales
PUBLISH channel message // Publica información en un canal
PSUBSCRIBE pattern [pattern...] // Suscríbete en lotes según el patrón, suscríbete a uno o más que coincidan con el patrón dado ( support * number?
PUSUB CHANNELS // Una lista de canales activos
NUMSUB channel [channel...] // Cuántos suscriptores tiene un determinado canal
PUBSUB NUMPAT // Solo cuenta los ejecutados por el comando PUBSCRIBE, y regresa a el cliente El número de patrones únicos a los que está suscrito el cliente
UNSUBSCRIBE channel [channel...] // cancela la suscripción del
patrón PUNSUBSCRIBE [patrón...] // cancela la suscripción de todos los canales con el patrón dado
Resumir
ventaja
- Redis puede implementar la función de middleware de mensajes MQ y realizar la guía y distribución de mensajes a través de publicación y suscripción. (Pero no se recomienda su uso, las cosas profesionales se dejan a las herramientas profesionales MQ, kafka, RabbitMQ)
defecto
- Los mensajes publicados no se pueden persistir en el sistema Redis, por lo tanto, primero se debe realizar la suscripción y luego esperar a que se publique el mensaje. Si el mensaje se publica primero, el mensaje se descartará directamente porque no hay suscriptores.
- Siempre que se envíe el mensaje, el mensaje se envía y se pierde inmediatamente para el editor. No importa si se recibe, no hay un mecanismo ACK y no se puede garantizar el consumo exitoso del mensaje.
- Las deficiencias anteriores hacen que el modo Pub/Sub de Redis sea como un pequeño juguete, que es casi inútil en el entorno de producción. Por esta razón, la versión Redis 5.0 agrega una estructura de flujo de datos, que no solo admite multidifusión, sino que también admite la persistencia de datos. Más potente que Pub/Sub