El último artículo habló sobre la función de canalización de redis, y extendió algunas de las operaciones básicas de Linux en su interior. Este artículo completará varias funciones avanzadas mencionadas al principio del artículo anterior. El artículo anterior decía que las funciones avanzadas que se registrarán son:
Pipeline
Transaction
Publish / Subscribe
Expiration
Bloom filter
asuntos
Además de los pipelines, redis también tiene transacciones, que pueden garantizar la atomicidad de un conjunto de operaciones hasta cierto punto. El uso principal multi, exec, watchy unwatchestas palabras clave.
Una transacción comienza con multi, y luego se pueden realizar muchas instrucciones de operación hasta que se ejecute oficialmente después de ingresar exec.
Si hay dos clientes, el cliente A ingresa primero a múltiples, luego ingresa una serie de operaciones de redis, luego el cliente B ingresa a múltiples y luego ingresa una serie de operaciones, pero el cliente B ejecuta primero exec, el cliente A Después de ejecutar exec, la operación de B se ejecutará primero.
Por supuesto, una afirmación más precisa es que la secuencia anterior se refiere a la hora recibida por el servidor. Debido a la red y otras razones, ingresar primero no significa recibir primero.
Un ejemplo de una operación de transacción es el siguiente:
multi
set k1 111
get k1
exec
Además de las operaciones anteriores, las transacciones también se pueden usar con watch. Watch se usa para monitorear los cambios de una o más claves. Si el valor de clave correspondiente cambia durante el proceso de monitoreo, la ejecución posterior de la transacción fallará, por ejemplo:
client1 escucha una clave primero, luego inicia la transacción y luego realiza algunas operaciones, pero no ejecuta exec
watch k1
multi
set k1 111
get k1
Entonces client2 cambia el valor de la clave
set k1 222
Luego, regrese a client1 y ejecute exec, encontrará que el resultado devuelto es nulo, que en realidad es que los datos monitoreados por el reloj han cambiado, lo que hace que toda la transacción falle.
Publicar / suscribirse
Cuando se habla de la estructura básica de datos de redis, hay una función de bloqueo asincrónico en la lista, el uso blpopy los brpopcomandos pueden bloquear al cliente hasta obtener el resultado.
Esta función puede lograr un seguimiento y consumo de mensajes similares hasta cierto punto, pero finaliza tan pronto como se recuperan los datos.
Y la propia redis implementa la función real de publicación de noticias y suscripción, usando publishy subscribeordenando operaciones, por ejemplo: el
consumidor usa suscribirse para monitorear un canal de canal:
subscribe channel1
Vuelva a abrir una ventana de línea de comando y use publicar para publicar mensajes en el canal superior:
publish channel1 hello
Después de la publicación, la primera ventana de arriba recibirá inmediatamente el mensaje y lo imprimirá.
Aunque redis tiene una función de publicación y suscripción, pero existe otro problema, es decir, después de que el consumidor final se suscribe, o cuando la suscripción está activada, se recibirá el mensaje. Si el cliente se desconecta, solo puede Después de recibir el mensaje de re-suscripción después de la reconexión, el mensaje durante el proceso de desconexión aún se perderá.
Caducado
Aunque redis se puede almacenar de forma persistente, en realidad se utiliza como caché en la mayoría de los casos. El caché también es un almacenamiento temporal. En este sentido, redis proporciona una función muy conveniente, que es establecer un tiempo de espera.
Hay dos formas de establecer el tiempo de espera. Una es establecer el tiempo de espera cuando se establece el valor. Este método solo se aplica al tipo de cadena. No existe tal opción para otros tipos de operaciones.
La otra es usar la función de expiración para establecer un tiempo de espera para la clave que debe configurarse en tiempo de espera. Esto es universal y se puede configurar para cualquier tipo compatible con redis.
Para que los datos del tipo de cadena establezcan directamente el tiempo de espera, habrá dos parámetros opcionales, uno es el exotro px, donde ex representa segundos y px representa milisegundos, por ejemplo:
set k1 111 ex 2000
La operación anterior guardará k1 en redis durante 2000 segundos, mientras que la operación siguiente solo ahorrará 2 segundos:
set k2 111 px 2000
Pero para el vencimiento general, el parámetro de milisegundos no es compatible, y este último solo puede ser en segundos, por ejemplo:
expire k1 2000
Aquí 2000 representa 2000 segundos, no 2000 milisegundos.
Cabe señalar que una función importante del tiempo de espera de redis es reducir la operación de E / S de la base de datos y, debido a problemas de recursos de memoria, la caché normal debe ser datos activos y los datos utilizados con frecuencia son datos activos.
Por lo tanto, algunas personas pueden pensar que los datos que se leen con frecuencia extenderán automáticamente el período de tiempo de espera, pero la lectura de los datos no extenderá el tiempo de vencimiento del cambio.
Cuando se reescriban los datos, se cambiará el tiempo de vencimiento. Si se vuelve a dar el tiempo de vencimiento, se convertirá en el nuevo tiempo de vencimiento. Si no se da el nuevo tiempo de vencimiento, se volverá permanente hasta que el servicio redis deje de funcionar. Además, para los datos El cálculo no cambiará el tiempo de vencimiento.
Filtro de floración
Como se mencionó anteriormente, una función importante de redis es almacenar en caché los datos en caliente, lo que reduce la IO frecuente de la base de datos, lo que equivale a una barrera antes de la base de datos, mejorando así el rendimiento general y la disponibilidad del sistema.
Entonces, en muchas empresas reales, será lógico verificar la base de datos si no se puede encontrar el caché para garantizar la integridad y confiabilidad de la empresa.
Pero de esta manera, no habrá caché de redis ni base de datos real. Este escenario se llama penetración de caché de redis. Si hay una gran cantidad de solicitudes de este tipo, es concebible que la base de datos sea propensa a problemas. El filtro Bloom simplemente puede resolver el problema de la penetración de la caché hasta cierto punto.
El filtro Bloom no es una función básica de redis, sino un módulo adicional. Si desea usarlo, primero debe descargarlo y colgarlo. Los pasos generales son los siguientes
wget https://github.com/RedisBloom/RedisBloom/archive/master.zip
unzip master.zip
make
redis-server --loadmodule /opt/soft/rdisbloom.so
No hace falta decir que la primera línea mencionada anteriormente es la descarga básica de wget de Linux. El segundo paso para descomprimir el archivo zip no debería ser necesario decirlo. El tercer paso es compilar el código fuente.
El cuarto paso es la clave, aquí está el filtro bloom al iniciar el servicio redis. Cabe señalar que el archivo so detrás es generado por make. La ruta específica depende de la situación, y la ruta absoluta debe escribirse .
Por supuesto, este contenido también se puede configurar en el archivo de configuración de redis, por lo que no es necesario configurarlo manualmente cada vez que lo inicie.
Con las operaciones anteriores, puede usar el filtro Bloom. Hay tres operaciones clave, a saber bf.add, bf.existsy bf.reserve. La función de agregar es agregar contenido al filtro. Existe se usa para determinar si existe y la reserva puede establecer la tasa de error. Y la capacidad estimada se maneja de forma personalizada, el ejemplo es el siguiente:
bf.add filter1 111
bf.exists filter1 111
bf.reserve filter2 0.01 100
El filtro1 y el filtro2 anteriores pueden entenderse como el nombre del filtro. Cuando se usa existe para determinar, algunos de los filtros devolverán 1, y si no hay ninguno, devolverán 0.
Para la reserva, además del nombre del filtro, también se requiere una tasa de error. , Una capacidad estimada, cuanto menor sea la tasa de error, mayor será el espacio de almacenamiento consumido y los datos reales exceden la capacidad estimada, la tasa de falsos positivos aumentará.
Al mismo tiempo, debe tenerse en cuenta que la reserva solo se puede usar en filtros que aún no existen. Realizar esta operación en filtros existentes arrojará una excepción.
El almacenamiento subyacente del filtro Bloom utiliza un almacenamiento de bytes de bits como un mapa de bits. Puede haber varios datos que ocupan el mismo bit, lo que también conduce a una cierta tasa de errores de cálculo. El resultado del error de cálculo es: el filtro de Bloom devuelve un cierto número que no existe. Si no existe, el filtro Bloom vuelve a la existencia que no necesariamente existe.
El almacenamiento de datos del filtro Bloom hace que el espacio sea común, lo que ahorra en gran medida el espacio de almacenamiento. Sin embargo, también se comparte, lo que conduce a la prohibición de eliminar elementos en el filtro. Por lo tanto, el preocupante Bloom no puede encontrar la operación de eliminar elemento. Según la línea Se dice que el filtro de cuco puede manejar este tipo de problemas, por lo que aquí detendremos temporalmente la expansión.
Artículos relacionados
Almacenamiento en caché y conocimientos básicos relacionados con
redis Instalación de Linux redis e instalación de software puntos de conocimiento relacionados con Linux
tipo de datos de redis conocimientos clave y escenarios de aplicación
canalización de redis, transacción, publicación y suscripción, vencimiento, filtrado y otras funciones avanzadas comunes (parte 1)
canalización de redis, Una pequeña nota de las funciones avanzadas de uso común, como transacciones, publicación y suscripción, vencimiento, filtros, etc. (Parte 2)
Integración de Springboot y uso de funciones comunes de redis.