Construcción de caché distribuida de Redis
El autor pasó dos días clasificando la construcción y el uso registrados previamente del modo único y el modo centinela de Redis, y luego compensó el uso y la experiencia de construcción del modo de clúster y comprendió algunos principios de los clústeres.
Algunos problemas encontrados por el autor durante la instalación:
Si make informa un error, puede ser que el editor gcc o gcc-c++ no esté instalado Instale yum -y install gcc gcc. -c++ kernel-devel, también puede indicar que algunos archivos c no se pueden compilar. Use gcc -v para verificar la siguiente versión. Si es inferior a 5.3, actualice gcc:
En /etc/. fuente del perfil /opt/rh/devtoolset-9/enable Agregar una línea
scl enable devtoolset-9 bash
Vuelva a hacerlo limpiamente, haga
Esto tiempo que pasó la compilación, solicitándole que haga la prueba/
Ejecute make test, si se le solicita que necesita tcl 8.5 o posterior para ejecutar la prueba de Redis
Actualice tcl, yum instale tcl
Vuelva a realizar la prueba, si aún hay errores, elimine el directorio, descomprima el paquete tar y luego realice nuevamente la prueba
\o/ ¡Todas las pruebas pasaron sin problemas!
Luego realiza la instalación.
Ejecute el comando: ./redis-server /usr/redis-6.0.3/redis.conf &
En el archivo de configuración redis.conf, se utiliza bind 0.0.0.0 para configurar Para acceso externo, requirepass xxxx se utiliza para configurar la contraseña.
Hay dos escenarios de aplicación de alta disponibilidad de Redis:
Los escenarios de aplicación más comunes son 1 maestro 1 esclavo o 1 maestro 2 esclavos + 3 nodos maestros de monitoreo centinela y 3 maestros 3 esclavos. Clúster de 6 nodos.
(1) Centinela
/usr/redis-6.0.3/src/redis-sentinel /usr/redis-6.0.3/sentinel2.conf &
Configuración de sentinel2.conf:
Pozo 1: el nodo maestro también se convertirá en un nodo esclavo después de la conmutación por error, y es necesario configurar masterauth
Después de finalizar el proceso maestro, vaya. a través de la elección centinela, el nodo esclavo se convierte en el nuevo nodo maestro. Cuando se reinicie el nodo maestro original, aparecerá el siguiente error:
El motivo es que la estación maestra ya es una estación esclava. se inicia nuevamente y ahora es necesario ingresar la contraseña de la nueva estación maestra, por lo que debe configurarse en la maestra. conf
Pozo 2: archivo de configuración de Sentinel, que expone la dirección maestra accesible al cliente
Monitor de Sentinel mymaster 122.xx.xxx.xxx en el archivo de configuración sentinel.conf En 6379 2 , configure el nombre de la estación maestra, la dirección de la estación maestra y el puerto correspondiente a este centinela, y cuántas veces pasa la elección del centinela antes de que la estación maestra se considere colgada. La dirección maestra debe ser desde la perspectiva del visitante de Redis (es decir, el cliente) y configurar la dirección a la que el visitante puede acceder. Por ejemplo, si Sentinel y el maestro están en el mismo servidor (122.xx.xxx.xxx), entonces. relativo a Sentinel y el maestro está en la máquina local, es decir, en 127.0.0.1, por lo que tanto el centinela como su maestro son locales.
0.0.0.1, por lo que sentinel monitorea mymaster 127.0.0.1 6379 2. Lógicamente no hay problema, pero si springboot de otro servidor accede a este redis sentinel a través de lechuga, la dirección maestra obtenida es 127.0.0.1, es decir, springboot se encuentra localmente en el servidor. , esto es obviamente un problema.
Se adjunta la configuración de springboot2.1 redis sentinel:
Pit 3: tenga en cuenta que el archivo de configuración .conf puede ser modificado por sentinel
redis-cli -h localhost - p 26379, puede iniciar sesión en Sentinel y utilizar el comando info para ver información relacionada con Sentinel.
Me he encontrado con un problema de este tipo, la información general es la siguiente
De alguna manera hay un dispositivo esclavo más y la dirección del dispositivo maestro obviamente se ha cambiado a una externa real. dirección, aquí ¡Se convirtió en 127.0.0.1!
Finalmente, detuve los 5 procesos de Redis y revisé los archivos de configuración uno por uno. Descubrí que en el modo centinela maestro-esclavo, el archivo de configuración de Redis se modificará y hay una línea inexplicable en. Al final del archivo de configuración de la estación maestra, réplica de 127.0.0.1 7001, sospecho que esto debería agregarse dinámicamente cuando Sentinel se configuró incorrectamente (ver Pozo 2). ¡Sospecho que Sentinel debería haber agregado esto dinámicamente durante una mala configuración anterior (ver Pozo 2)! De todos modos, en la práctica siempre debes prestar más atención a los cambios en los archivos de configuración.
(2) Clúster
Cuando la cantidad de datos alcanza un cierto nivel, como decenas o cientos de gigabytes, el modo Sentinel no es suficiente para lograr la fragmentación en los primeros años. , se utiliza middleware de terceros como codis y twemproxy para fragmentar, es decir, el modo cliente-> middleware-> servidor Redis. El middleware utiliza un algoritmo hash consistente para determinar qué clave fragmentar. Más tarde, Redis lanzó oficialmente el programa y todos utilizaron el programa oficial de Redis Cluster.
Redis Cluster se divide lógicamente en 16384 ranuras hash. El algoritmo de corte utiliza CRC16 (clave) mod 16384 para obtener a qué ranura corresponde la clave y determinar a qué nodo pertenece la ranura.
Cada nodo se puede configurar con uno o más nodos esclavos. La solución comúnmente utilizada es 3 nodos maestros y 3 nodos esclavos.
Resharding (resharding), la resharding le permite especificar qué nodo mover ciertas ranuras hash a otro nodo. El proceso de repartición es transparente para el cliente y no afectará los servicios en línea.
Cree un clúster de Redis
Algunas configuraciones clave en el archivo redis.conf:
Inicie 6 nodos del clúster
[root@VM_0_11_centos redis-6.0.3]# ps -ef|grep redis
root 5508 1 0 21:25 00:00:00 /usr/redis-6.0.3/src/redis-server 0.0.0.0 :7001 [clúster]
raíz 6903 1 0 21:32 00:00:00 /usr/redis-6.0.3/src/redis-server 0.0.0.0:7002 [clúster]
raíz 6939 1 0 21:33 ? 00:00:00 /usr/redis-6.0.3/src/redis-server 0.0.0.0:7003 [clúster]
raíz 6966 1 0 21:33 00:00:00 /usr/redis-6.0.3/src/redis-server 0.0.0.0:7004 [clúster]
raíz 6993 1 0 21:33 ? 00 /usr/redis-6.0.3/src/redis-server 0.0.0.0:7005 [clúster]
raíz 7015 1 0 21:33 00:00:00 /usr/redis-6.0. 3/src/redis-server 0.0.0.0:7006 [clúster]
En este momento, estos 6 nodos todavía son independientes y deben configurarse como un clúster:
Nota. : -a xxxx se debe a que el autor configuró la contraseña requirepass xxxx, y luego el 1 en --cluster-replicas 1 significa que cada nodo maestro tiene 1 nodo esclavo.
Después de ejecutar el comando anterior, aparecerá una consulta: ¿Puedo establecer la configuración anterior? Sí, acepta la fragmentación automática.
Finalmente, se cubren las 16384 plazas. Esto significa que cada una de las 16384 ranuras del clúster tiene al menos un nodo maestro funcionando y el clúster se ha iniciado correctamente.
Verifique el estado del clúster:
Trampa 1: exponer la dirección de nodo incorrecta al cliente
Al conectarnos usando lechuga, descubrimos que no podíamos conectarnos. entonces verificamos los registros. Conexión rechazada: No hay más información: /127.0.0.1:7002 Este es el mismo error cometido al configurar la dirección principal en el archivo de configuración de Sentinel sentinel.conf. La dirección inicial del clúster debe ser la dirección proporcionada a los clientes para que accedan.
Necesitamos reconstruir el clúster: primero detener los seis procesos de Redis, luego eliminar el archivo de configuración del nodo nodes-7001.conf, eliminar los archivos persistentes dump.rdb y appendonly.aof, reiniciar los seis procesos. y luego restablecer el clúster:
Luego, todavía no pudimos conectarnos, esta vez recibimos un mensaje de error de tiempo de espera de conexión: /172.xx.0.xx:7004, encontramos la dirección de intranet conectada a ¡El servidor en la nube de Penguin!
La solución es modificar el archivo de configuración redis.conf de cada nodo y encontrar las siguientes instrucciones:
Entonces agregue la configuración:
Luego reconstruya el clúster y detenga el proceso. Cambie la configuración, elimine los archivos de nodo y los archivos de persistencia, inicie los procesos y configure el clúster.
Otro conjunto (agotado)
Usa Lettuce para probar nuevamente, ¡esta vez la conexión finalmente está conectada!
Pozo 2: cuando el nodo maestro falla, el cliente Lettuce no cambiará automáticamente al nodo esclavo
La clave de nombre se encuentra en 7002, finalice el proceso para simular el nodo maestro estar desconectado y luego Lettuce seguirá reconectándose. Queremos que cambie automáticamente al esclavo 7006, de la siguiente manera:
Reinicie el proceso 7002,
7006 se convierte en el nuevo maestro, 7002 se convierte en esclavo y luego Lettuce puede conectarse.
Solución, modifique la configuración de Lettuce:
Estoy usando el cliente Lettuce predeterminado springboot 2.1 spring-boot-starter-data-redis. Cuando uso el modo de clúster Redis, necesito Configurar. RedisConnectionFactory para habilitar la actualización adaptativa para cambiar automáticamente los nodos esclavos para las conexiones en caso de una conmutación por error.
Nueva prueba: detenga el nodo maestro 7006. En este momento, Lettuce puede cambiar al nodo esclavo 7002 normalmente. (Los errores de conexión seguirán apareciendo constantemente en los registros debido a la necesidad de intentar volver a conectar 7006 constantemente, pero como el nodo esclavo 7002 está en la parte superior, la aplicación puede ejecutarse normalmente)
Redis no garantiza una solidez consistencia
Redis no garantiza una consistencia sólida, lo que significa que requiere el teorema CAP AP
Para algoritmos hash consistentes, consulte Algoritmos Hash consistentes - (jianshu.
El clúster de Redis utiliza un algoritmo de ranura hash, que no es lo mismo que el algoritmo hash consistente. Fija 16,384 ranuras hash y luego calcula dentro de la clave a qué ranura pertenece la clave (calcula el valor CRC16 de la clave y luego toma el modo de). 16384), la clave busca ranuras en lugar de nodos, la relación correspondiente entre ranuras y nodos se puede cambiar resharding y propagarse a cada nodo en el clúster a través del protocolo de rumor. El cliente puede saber esto, de modo que la dirección de nodo de la clave es independiente del número específico de nodos. Esto también resuelve un problema en los algoritmos de hash ordinarios cuando el número de nodos cambia, lo que provoca la invalidación del caché.
Por ejemplo, si el clúster se agrega. 1 nodo, entonces, si no se hace nada, no habrá ranuras en el nodo recién agregado y todas las ranuras estarán vacías en el nodo original y la relación correspondiente permanecerá sin cambios, por lo que el caché no se invalidará debido a cambios en. el número de nodos Después de volver a fragmentar algunas ranuras en nuevos nodos, el cliente obtendrá la relación y dirección correspondientes del nuevo nodo y la invalidación de la caché. Cuando se cambia el tamaño de una ranura a un nuevo nodo, el cliente obtendrá la correspondencia entre ellos. la nueva ranura migrada y el nuevo nodo y la dirección del nuevo nodo, mientras que la ranura no migrada seguirá siendo el Nodo direccionado
En cuanto a la migración en vivo, se supone que la migración debe copiarse internamente y luego la. La relación correspondiente entre la ranura y el nodo se cambia después de que se completa la migración. Antes de que se complete la copia, todavía se accede a la ranura original en el nodo original. los nodos fallan, el nodo defectuoso se cerrará objetivamente. A continuación, todos los nodos maestros seleccionarán un nuevo nodo esclavo del nodo maestro. En este momento, si más de la mitad de todos los nodos maestros votan por el nodo esclavo. el nodo fallido, el nodo esclavo será seleccionado como el nuevo nodo maestro.
Todos los nodos admitirán el nodo esclavo. Hay metadatos y los nodos se comunican a través de un protocolo binario llamado gossip, enviando información de metadatos, falla. detección, actualizaciones de configuración del clúster, autorización de conmutación por error, etc. a otros nodos
Este tipo de comunicación entre nodos El núcleo de la coordinación distribuida descentralizada (incluida la identificación de fallas, la conmutación por error, la selección del nodo maestro, etc.) radica en el protocolo de difusión de chismes, que puede admitir dicho protocolo de transmisión en el que todos los nodos tengan una copia completa de los metadatos del clúster, es decir, todos los nodos conocen la situación global actual del clúster.
Alta disponibilidad de Redis - (jianshu.com)
Pregunta de la entrevista: ¿Cómo funciona el modo de clúster de Redis - Nube + Comunidad - Tencent (tencent.com)
Redis Ilustración detallada de los principios del clúster - detectiveHLH - Blogspot (cnblogs.com)
Ilustración detallada de los principios del clúster Redis - detectiveHLH - Blogspot (cnblogs.com)
Clúster de Redis reinicie las notas de estudio y los problemas encontrados Trampas - Alibaba Cloud Developer Community (aliyun.com)
Implementación del clúster Redis del servidor en la nube y problemas de conexión del cliente a través de IP pública