(1) El caché acaba de expirar (2) Solicite A que consulte la base de datos y obtenga un valor anterior (3) Solicite a B que escriba el nuevo valor en la base de datos (4) Solicite a B que elimine el caché (5) Solicite a A que escriba el valor antiguo encontrado en el caché

Pero solo si 3 entre 2 y 3 es más rápido que 2, B eliminará el caché primero y A escribirá el caché con el valor anterior.

De hecho, escribir en la base de datos es mucho más lento que leer, así que evite SQL lento.

(1) Primero elimine el caché (2) Escriba la base de datos nuevamente (estos dos pasos son los mismos que antes) (3) Duerma durante 1 segundo y elimine el caché nuevamente

Utilice doble eliminación asincrónica

Comprueba el número y la longitud.

Si existe, contiene, agrega, aumenta o disminuye la clave o un determinado campo debajo de la clave

Eliminar, eliminar la ubicación especificada, eliminar y obtener

tema libre

Llave

Colocar

Lista

recogida ordenada

Transacción

Picadillo

tema libre

Cuando es necesario ampliar el tamaño de la cadena, si es inferior a 1 M, se duplicará. Si es superior a 1 M, solo se ampliará en 1 M cada vez. La longitud máxima es 512 M.

Si el valor de autoincremento excede el valor máximo, se informará un error.

Para estructuras de datos de tipo contenedor, si el contenedor no existe, créelo; si el elemento ya no existe, elimine el contenedor.

obtener bloqueo

desbloquear

a) Una vez que se produce un cambio maestro-esclavo en redis, es posible que se pierdan algunos bloqueos.

El bloqueo distribuido implementado por Zookeeper en realidad tiene una desventaja, es decir, el rendimiento puede no ser tan alto como el del servicio de caché. Porque cada vez durante el proceso de creación y liberación de un bloqueo, los nodos transitorios deben crearse y destruirse dinámicamente para implementar la función de bloqueo. La creación y eliminación de nodos en ZK solo se puede realizar a través del servidor Leader y luego los datos no se comparten con todas las máquinas Follower. Los problemas de concurrencia pueden incluir fluctuaciones en la red y la conexión de la sesión entre el cliente y el clúster ZK está interrumpida. El clúster ZK cree que el cliente está inactivo y eliminará el nodo temporal. En este momento, otros clientes pueden obtener el bloqueo distribuido.

Redis es difícil de lograr la equidad

En la versión distribuida del algoritmo, asumimos que tenemos N hosts Redis. Los nodos son completamente independientes, por lo que no utilizamos replicación ni ningún otro sistema de coordinación implícito. Hemos descrito cómo adquirir y liberar bloqueos de forma segura en una sola instancia. Damos por sentado que el algoritmo utilizará este método para adquirir y liberar bloqueos en una sola instancia. En nuestro ejemplo, configuramos N = 5, que es un valor razonable, por lo que necesitamos ejecutar 5 servidores maestros Redis en diferentes computadoras o máquinas virtuales para asegurarnos de que fallen de manera mayoritariamente independiente. Para adquirir el candado, el cliente realiza las siguientes operaciones: 1. Obtiene la hora actual en milisegundos. 2. Intenta adquirir el bloqueo en todas las N instancias en orden, utilizando el mismo nombre de clave y valor aleatorio en todas las instancias. Durante el paso 2, cuando se establece el bloqueo en cada instancia, el cliente utiliza un pequeño tiempo de espera en comparación con el tiempo total de liberación automática del bloqueo para adquirirlo. Por ejemplo, si el tiempo de liberación automática es de 10 segundos, el tiempo de espera puede estar en el rango de ~5-50 ms. Esto evita que los clientes permanezcan bloqueados durante largos períodos de tiempo, intentando y sin éxito comunicarse con un nodo de Redis: si una instancia no está disponible, debemos intentar hablar con la siguiente instancia lo más rápido posible. 3. El cliente calcula el tiempo necesario para adquirir el bloqueo restando la marca de tiempo obtenida en el paso 1 de la hora actual. Un candado se considera adquirido si y sólo si el cliente puede adquirir el candado en la mayoría de los casos (al menos 3) y el tiempo total transcurrido para adquirir el candado es menor que el tiempo de validez del candado. 4. Si se adquiere un candado, se considera que su tiempo de validez es el tiempo de validez inicial menos el tiempo transcurrido, según se calcula en el paso 3. 5. Si el cliente no logra adquirir el bloqueo por algún motivo (no puede bloquear N/2 1 instancias o tiempo de validez negativo), intentará desbloquear todas las instancias (incluso si cree que no puede bloquear).

Cuando se cuelga un nodo, no hay riesgo de que se anule el bloqueo.

Establezca un valor aleatorio para el tiempo de falla para evitar fallas colectivas

Registre la lista de identificación de publicaciones de usuarios.

Registre la lista de ID de publicaciones de la lista activa Lista activa general, lista activa de categorías.

Se utiliza para grabar uno a muchos y la fiesta con muchos no se puede repetir estrictamente.

Registre una determinada colección, que puede estar relacionada con el usuario o con el sistema en general.

Registre la cantidad de me gusta, comentarios y clics en una publicación.

Registre el título de la publicación, el resumen, el autor, la información de la portada, etc.

Almacenar en caché el contenido de las publicaciones recientes (el contenido de la publicación es muy grande y no es adecuado para recuperarlo desde la base de datos).

Registre la lista de artículos relacionados de la publicación. Recomiende publicaciones relacionadas según el contenido.

Se utiliza como matriz bool o matriz de bits personalizada, principalmente para ahorrar memoria

Se utiliza para calcular aproximadamente valores estadísticos después de la deduplicación.

Solo puede sumar y obtener el número total, pero no puede obtener si existe un determinado valor o todos los elementos.

Se utiliza para eliminar duplicados. Obtener si un elemento existe en la lista.

Si el proyecto no es grande y el costo de mantenimiento no es alto, puede usar redsi-cell directamente. De lo contrario, puede considerar un control detallado de cada nodo de servicio para limitar el flujo e implementarlo con la estrategia de equilibrio de carga correspondiente.

Utilice zset y puntuación para rodear la ventana de tiempo y contar la cantidad de veces que ocurre el mismo comportamiento para el mismo usuario dentro de la ventana de tiempo. Si la cantidad de límites actuales es demasiado grande, es posible que no sea aplicable, como 1000 veces por segundo. .

Prueba CL.THROTTLE 100 400 60 3

1: Si fue exitoso, 0: Éxito, 1: Rechazado 2: La capacidad del depósito de tokens, el tamaño es el valor inicial 1 3: Tokens disponibles en el depósito de tokens actual 4: Si se rechaza la solicitud, este valor indica cuánto tiempo pasará antes de que el token se vuelva a agregar al depósito de embudo. Unidad: segundos, que se puede usar como tiempo de reintento. 5: Indica cuánto tiempo tardarán en llenarse los tokens del depósito de tokens.

algoritmo de embudo

Se compone de listas o matrices enlazadas comprimidas, para evitar la sobrecarga de memoria adicional de las listas enlazadas ordinarias.

Una lista doblemente enlazada diseñada para ahorrar la mayor cantidad de memoria posible

Almacenar cadena o número entero

Guarde la memoria en detalle mediante codificación de longitud variable para el almacenamiento de valores.

Implementación de estructuras de datos subyacentes de hash, list y zset

Características

1) Cuando se utiliza ziplist para escenarios con requisitos de alto rendimiento, se recomienda que la longitud no supere los 1000 y que el tamaño de cada elemento se controle dentro de los 512 bytes.

La lista de omisión admite la búsqueda promedio O(logN) y la búsqueda de complejidad O(N) en el peor de los casos.

¿Por qué no utilizar árboles o árboles equilibrados en lugar de mesas de salto?

La lista vinculada comprimida se vincula mediante punteros para convertirse en una lista vinculada

El valor predeterminado de cada ziplist es 8k (configurable).

2) Utilice el comando info Commandstats para obtener el tiempo promedio de comando, incluido el número de llamadas para cada comando. , el tiempo total empleado, el tiempo medio empleado, en microsegundos.

La función de replicación de Redis se divide en dos operaciones: sincronización (sync) y propagación de comandos (propagación de comandos):

La separación de lectura y escritura es adecuada para un acceso grande (tan grande que una sola máquina Redis se siente muy lenta), y la operación de escritura es mucho más pequeña que la operación de lectura.

Si la cantidad de solicitudes de lectura excede con creces las solicitudes de escritura, el costo de la copia de datos del clúster será mucho menor que el costo de la solicitud de lectura. Al mismo tiempo, si podemos aceptar la inconsistencia de los datos hasta cierto punto, podemos separar la lectura y la escritura.

1. Todos los nodos de Redis están interconectados entre sí (mecanismo PING-PONG) y se utiliza internamente un protocolo binario para optimizar la velocidad de transmisión y el ancho de banda.

2. La falla de un nodo surte efecto solo cuando más de la mitad de los nodos del clúster detectan fallas.

3. El cliente está conectado directamente al nodo redis, sin necesidad de una capa de proxy intermedia. El cliente no necesita conectarse a todos los nodos del clúster, simplemente se conecta a cualquier nodo disponible en el clúster.

4. redis-cluster asigna todos los nodos físicos a la ranura [0-16383] (no necesariamente distribuida uniformemente), y el clúster es responsable de mantener el valor del nodo <-> ranura <->.

5. El clúster de Redis está predividido en 16384 depósitos. Cuando es necesario colocar un valor-clave en el clúster de Redis, se decide de acuerdo con el valor de CRC16(key) mod 16384 en qué depósito se debe colocar una clave.

Cada instancia de Redis es consciente de la existencia de otros nodos.

1. Su cliente escribe en el nodo B del servidor principal. 2. El nodo B del servidor principal responde a su cliente para confirmar. 3. El nodo del servidor maestro B propaga la escritura a sus servidores esclavos B1, B2 y B3.

Si después del paso 2, no se envían datos desde el servidor esclavo y B cuelga, la clave se perderá (la clave definitivamente se perderá durante la falla)

El proceso de elección implica la participación de todos los nodos maestros del clúster. Si más de la mitad de los nodos maestros se comunican con el nodo fallido durante más de (tiempo de espera del nodo del clúster), el nodo se considera defectuoso y la operación de conmutación por error se realiza automáticamente. motivado.

(2): ¿Cuándo deja de estar disponible todo el clúster (cluster_state:fail)? a: Si algún maestro en el clúster muere y el maestro actual no tiene esclavo, el clúster ingresa al estado de falla, lo que también puede entenderse como ingresar al estado de falla cuando la asignación de ranuras del clúster [0-16383] no se completa. b: Si más de la mitad de los maestros en el clúster mueren, no importa si hay un clúster esclavo que ingresa al estado de falla.

Cuando el clúster no está disponible, todas las operaciones en el clúster no están disponibles y se recibe un error ((error) CLUSTERDOWN El clúster está inactivo).

1. Todos los nodos esclavos del nodo maestro fuera de línea serán elegidos para elegir un nuevo nodo maestro. 2. El nodo esclavo seleccionado ejecutará el comando esclavo nadie y se convertirá en el nuevo nodo maestro. 3. El nuevo nodo maestro revocará todas las asignaciones de espacios al nodo maestro fuera de línea y se asignará estos espacios a sí mismo. 4. El nuevo nodo maestro transmite un mensaje pong al clúster. Este mensaje pong permite que otros nodos del clúster sepan inmediatamente que el nodo ha cambiado de nodo esclavo a nodo maestro y que el nodo maestro se ha hecho cargo del servidor. que originalmente estaba fuera de línea. La ranura que maneja el nodo. 5. El nuevo nodo maestro comienza a aceptar solicitudes de comando relacionadas con la ranura que es responsable de procesar y se completa la operación de conmutación por error.

1. Cuando el nodo esclavo descubre que el nodo maestro que replica se ha desconectado, el nodo esclavo (puede haber varios nodos esclavos realizando solicitudes aquí) transmitirá un mensaje cluster_type_failover_auth_request al clúster, requiriendo derechos de voto (responsable de procesar los espacios). El nodo maestro vota a este nodo. 2. El nodo maestro que recibe el mensaje cluster_type_failover_auth_request juzgará si está de acuerdo con el nodo esclavo para convertirse en el nuevo nodo maestro en función de sus propias condiciones (la época actual del nodo de votación que inicia no es inferior a la época actual del nodo de votación). ). Si está de acuerdo, devolverá un mensaje cluster_type_failover_auth_ack. 3. Cuando se recibe el mensaje cluster_type_failover_auth_ack del nodo, el número de votos aumentará en 1. 4. Si los votos de un nodo esclavo son mayores o iguales a la mitad de los nodos maestros en el clúster (mayores o iguales a N/2 1), este nodo se convertirá en el nuevo nodo maestro. Si ningún nodo esclavo recibe suficientes votos durante un ciclo de configuración, el clúster ingresará a un nuevo ciclo de configuración y se llevarán a cabo elecciones aquí hasta que se elija un nuevo nodo maestro.

Todos los nodos esclavos pueden buscar opiniones sobre si pueden convertirse en maestros (aquellos que voten solo votarán por sus propios nodos más grandes), y más de la mitad de ellos pueden ser (n 1)/2

Tal vez no puedo elegir

1. Actualmente, solo se admiten operaciones por lotes de claves en la misma ranura; 2. Actualmente, solo se admiten transacciones clave en la misma ranura; 3. Solo se puede utilizar la base de datos 0 (cada instancia de Redis tiene 16 bases de datos, que se pueden cambiar mediante el comando select {index}); 4. Una clave grande (como hash, lista) no se puede asignar a diferentes nodos; 5. Actualmente, la replicación maestro-esclavo del clúster solo admite un nivel y no admite estructuras de árbol anidadas;

paso

Cada nodo conoce el nodo del clúster correspondiente a cada ranura.

Cuando el nodo recibe la solicitud de comando, pregunta si puede manejarla por sí mismo. Si es así, la maneja. De lo contrario, devuelve un error de movimiento. El error de movimiento lleva la IP del nodo y el número de puerto correctos. cliente para guiarlo para su ejecución. Y cada operación posterior del cliente. Una vez que se ejecuta la clave, irá al nodo proporcionado por el error movido.

Cuando el Codis Dashbord de Codis cambia la información de las ranuras, otros nodos de Codis monitorearán los cambios de las ranuras de ZooKeeper y los sincronizarán a tiempo. Como se muestra en la imagen:

zk es responsable de sincronizar la información de las ranuras.

Utilice varias colas para implementar colas prioritarias. Diferentes tareas prioritarias ingresan a diferentes colas.

Al mismo tiempo, cuando los consumidores obtienen datos de la cola, admiten la recuperación de datos de varias colas, con orden de prioridad.

Iniciar varios consumidores significa iniciar varios clientes para recuperar datos.

usar

riesgo

1. Cuando no hay ningún elemento en la lista dada para extraer, el comando BRPOP bloqueará la conexión hasta que se agote el tiempo de espera o se encuentre un elemento emergente. 2. Cuando se proporcionan varios parámetros clave, cada lista se verifica en secuencia de acuerdo con la clave del parámetro y aparece el elemento final de la primera lista que no está vacía. Además, BRPOP se comporta igual que BLPOP excepto por la posición del elemento emergente.

Si no hay tareas en la lista, la conexión se bloqueará Hay un tiempo de espera para el bloqueo de la conexión. Cuando el tiempo de espera se establece en 0, puede esperar de forma inalámbrica hasta que aparezca un mensaje.

Es adecuado para suscripción y publicación entre dos empresas entre A y B. Es más difícil cuando varias líneas comerciales significan diferentes consumidores.

implementación de confirmación