Compartir tecnología

한어Русский языкEnglishFrançaisIndonesianSanskrit日本語DeutschPortuguêsΕλληνικάespañolItalianoSuomalainenLatina

Registro del estudio del día 7.11

1. transacción redis

El concepto de transacciones y propiedades ACID.

Transacciones a nivel de base de datos

A nivel de base de datos, una transacción es un conjunto de operaciones que se ejecutan todas con éxito o ninguna.

Cuatro características principales de las transacciones de bases de datos

• R: Atómico, atomicidad, ejecuta todo SQL como unidad de trabajo atómico, o se ejecutan todos o no se ejecuta ninguno;
• C: Consistente, una vez completada la transacción, el estado de todos los datos es consistente, es decir, siempre que se resten 100 de la cuenta A, se agregarán 100 a la cuenta B;
• I: Aislamiento, si se ejecutan múltiples transacciones al mismo tiempo, las modificaciones realizadas por cada transacción deben aislarse de otras transacciones;
• D: Duración, persistencia, es decir, una vez completada la transacción, las modificaciones en los datos de la base de datos se almacenan de forma persistente.

transacción redis

Una transacción de Redis es un conjunto de comandos. Todos los comandos de una transacción se serializarán y una serie de comandos se ejecutarán de forma única, secuencial y exclusiva.

Tres características principales de las transacciones de Redis

• operaciones de cuarentena separadas : Todos los comandos de la transacción se serializarán y ejecutarán en orden. Durante la ejecución de la transacción, ésta no será interrumpida por solicitudes de comando enviadas por otros clientes;
• Sin concepto de nivel de aislamiento.: Los comandos en la cola no se ejecutarán realmente hasta que se envíen, porque no se ejecutarán instrucciones antes de enviar la transacción, por lo que no hay una "consulta dentro de la transacción para ver las actualizaciones en la transacción y una consulta fuera del transacción "No puedo ver".
• No hay garantía de atomicidad: Si un comando no se ejecuta en la misma transacción de Redis, los comandos posteriores se seguirán ejecutando sin reversión;

Tres etapas de ejecución de transacciones de Redis

• encender:porMULTIIniciar una transacción;
• Únete al equipo: Ponga en cola varios comandos en una transacción. Estos comandos no se ejecutarán inmediatamente después de recibirlos, sino que se colocarán en la cola de transacciones esperando su ejecución;
• implementar:Depender deEXECEl comando desencadena la transacción;

Operaciones básicas de transacciones de Redis.

Multi, Ejecución, Descartar

entrada de transacción deMultiCuando se inicia el comando, los comandos ingresados ​​se enviarán a la cola del búfer de comandos uno por uno y no se ejecutarán hasta que finalice el comando.Exec Luego, Redis ejecutará los comandos en la cola del búfer de comandos anterior en secuencia.Durante el proceso de formación del equipo, puedes pasardiscardVen a renunciar al equipo.

ejemplo

127.0.0.1:6379> set t1 1
OK
127.0.0.1:6379> MULTI
OK
127.0.0.1:6379(TX)> set id 12
QUEUED
127.0.0.1:6379(TX)> get id
QUEUED
127.0.0.1:6379(TX)> incr t1
QUEUED
127.0.0.1:6379(TX)> incr t1
QUEUED
127.0.0.1:6379(TX)> get t1
QUEUED
127.0.0.1:6379(TX)> EXEC
1) OK
2) "12"
3) (integer) 2
4) (integer) 3
5) "3"
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20

abandonar la transacción

127.0.0.1:6379> MULTI
OK
127.0.0.1:6379(TX)> set name z3
QUEUED
127.0.0.1:6379(TX)> set age 29
QUEUED
127.0.0.1:6379(TX)> incr t1
QUEUED
127.0.0.1:6379(TX)> DISCARD
OK
1
2
3
4
5
6
7
8
9
10

todos sentados juntos

127.0.0.1:6379> MULTI
OK
127.0.0.1:6379(TX)> set name z3
QUEUED
127.0.0.1:6379(TX)> get name
QUEUED
127.0.0.1:6379(TX)> incr t1
QUEUED
127.0.0.1:6379(TX)> get t1
QUEUED
127.0.0.1:6379(TX)> set email
(error) ERR wrong number of arguments for 'set' command
127.0.0.1:6379(TX)> exec
(error) EXECABORT Transaction discarded because of previous errors.
1
2
3
4
5
6
7
8
9
10
11
12
13
14

Aviso：
El conjunto de comandos contiene instrucciones incorrectas (tenga en cuenta que son errores de sintaxis). Todos están conectados y todos fallan.

Cada injusticia tiene su dueño, cada deuda tiene su dueño.

127.0.0.1:6379> MULTI
OK
127.0.0.1:6379(TX)> set age 11
QUEUED
127.0.0.1:6379(TX)> incr t1
QUEUED
127.0.0.1:6379(TX)> set email [email protected]
QUEUED
127.0.0.1:6379(TX)> incr email
QUEUED
127.0.0.1:6379(TX)> get age
QUEUED
127.0.0.1:6379(TX)> exec
1) OK
2) (integer) 5
3) OK
4) (error) ERR value is not an integer or out of range
5) "11"
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18

Aviso：
Para errores de tiempo de ejecución, es decir, errores no gramaticales, se ejecutarán los comandos correctos y los comandos incorrectos devolverán un error.

2. clúster de redis

replicación maestro-esclavo

Descripción general
Entre las empresas existentes, el 80% de las empresas utilizan principalmente el servicio independiente de Redis. En escenarios reales, Redis en un solo nodo es propenso a riesgos.

enfrentando problemas:

• mal funcionamiento de la máquina. Implementamos en un servidor Redis. Cuando ocurre una falla en la máquina, debemos migrar a otro servidor y asegurarnos de que los datos estén sincronizados.
• Cuello de botella de capacidad. Cuando necesitamos expandir la memoria de Redis, de 16G a 64G, una sola máquina definitivamente no podrá satisfacerla. Por supuesto, puedes comprar una nueva máquina de 128G.

Solución

Para lograr una mayor capacidad de almacenamiento de la base de datos distribuida y soportar un alto acceso concurrente, almacenaremos los datos de la base de datos centralizada original en muchos otros nodos de red.

Aviso：
Para resolver este problema de un solo nodo, Redis también implementará múltiples copias de datos en otros nodos para su replicación para lograr una alta disponibilidad de Redis y una copia de seguridad redundante de datos para garantizar la alta disponibilidad de datos y servicios.

¿Qué es la replicación maestro-esclavo?

La replicación maestro-esclavo se refiere a copiar datos de un servidor Redis a otros servidores Redis. El primero se denomina nodo maestro y el segundo se denomina nodo esclavo. La replicación de datos es unidireccional y solo puede ser del nodo maestro al nodo esclavo.

El papel de la replicación maestro-esclavo

• Redundancia de datos: La replicación maestro-esclavo implementa una copia de seguridad en caliente de los datos, que es un método de redundancia de datos además de la persistencia.
• Recuperación: Cuando ocurre un problema en el nodo maestro, el nodo esclavo puede proporcionar servicios para lograr una rápida recuperación de fallas; en realidad, es un tipo de redundancia de servicio;
• balanceo de carga: Sobre la base de la replicación maestro-esclavo, con la separación de lectura y escritura, el nodo maestro puede proporcionar servicios de escritura y los nodos esclavos pueden proporcionar servicios de lectura (es decir, al escribir datos de Redis, la aplicación debe conectarse al nodo maestro , y al leer datos de Redis, la aplicación debe conectarse al nodo esclavo), compartir la carga del servidor, especialmente en escenarios donde hay menos escritura y más lectura, compartir la carga de lectura a través de múltiples nodos esclavos puede aumentar en gran medida la concurrencia del servidor Redis; .
• Piedra angular de la alta disponibilidad: Además de las funciones anteriores, la replicación maestro-esclavo también es la base para la implementación de centinelas y clústeres. Por lo tanto, la replicación maestro-esclavo es la base de la alta disponibilidad de Redis.

Configuración del entorno de replicación maestro-esclavo

Escribir archivo de configuración
Crear nuevo redis6379.conf

include /usr/local/redis-7.2.4/redis.config
pidfile /var/run/redis_6379.pid
port 6379
dbfilename dump6379.rdb
1
2
3
4

Crear nuevo redis6380.conf

include /usr/local/redis-7.2.4/redis.config
pidfile /var/run/redis_6380.pid
port 6380
dbfilename dump6380.rdb
1
2
3
4

Crear nuevo redis6381.conf

include /usr/local/redis-7.2.4/redis.config
pidfile /var/run/redis_6381.pid
port 6381
dbfilename dump6381.rdb
1
2
3
4

Inicie tres servidores redis

./redis-server ../redis6379.conf
./redis-server ../redis6380.conf
./redis-server ../redis6381.conf
1
2
3

Ver procesos del sistema

[root@localhost src]# ps -ef |grep redis
root    40737    1  0 22:05 ?     00:00:00 ./redis-server *:6379
root    40743    1  0 22:05 ?     00:00:00 ./redis-server *:6380
root    40750    1  0 22:05 ?     00:00:00 ./redis-server *:6381
root    40758  40631  0 22:05 pts/0   00:00:00 grep --color=auto redis
1
2
3
4
5

Verifique el estado de ejecución de tres hosts

#打印主从复制的相关信息
./redis-cli -p 6379
./redis-cli -p 6380
./redis-cli -p 6381
127.0.0.1:6379> info replication
127.0.0.1:6380> info replication
127.0.0.1:6381> info replication
1
2
3
4
5
6
7

Equipado con base de datos esclava pero no con base de datos maestra

Formato de sintaxis:

slaveof  <ip> <port>
1

Ejemplo:

Ejecutado en 6380 y 6381.

127.0.0.1:6380> SLAVEOF 127.0.0.1 6379
OK
1
2

Escribe en el host y lee datos en el esclavo.

set k1 v1
1

Análisis del principio de replicación maestro-esclavo.

La replicación maestro-esclavo se puede dividir en 3 etapas

• Fase de establecimiento de conexión (es decir, fase de preparación)
• Fase de sincronización de datos
• etapa de propagación del comando

El proceso de copia se divide aproximadamente en 6 procesos.

1. Guarde la información del nodo maestro (maestro).
   Ver información de estado después de ejecutar esclavode

info replication
# Replication
role:slave
master_host:127.0.0.1
master_port:6379
master_link_status:up
1
2
3
4
5
6

2. El nodo esclavo (esclavo) mantiene la lógica relacionada con la replicación a través de tareas programadas que se ejecutan cada segundo. Cuando la tarea programada descubre que hay un nuevo nodo maestro, intentará establecer una conexión de red con el nodo.
   
3. Establecer una conexión de red entre el nodo esclavo y el nodo maestro
   El nodo esclavo establecerá un socket. El nodo esclavo establece un socket con el puerto 51234, que se utiliza específicamente para aceptar comandos de replicación enviados por el nodo maestro.

4. Envía el comando ping

Una vez que la conexión se establece exitosamente, el nodo esclavo envía una solicitud de ping para la primera comunicación.

efecto:

• Detecta si el socket de red entre maestro y esclavo está disponible.
• Detectar si el nodo maestro puede aceptar comandos actualmente

5. TEA.
   Si el parámetro requirepass está configurado en el nodo maestro, se requiere la verificación de la contraseña. El nodo esclavo debe configurar el parámetro masterauth para garantizar que la contraseña sea la misma que la del nodo maestro para pasar la verificación; si la verificación falla, la replicación será; terminará y el nodo esclavo reiniciará el proceso de replicación.

6. Sincronizar conjuntos de datos.
   Después de que la conexión de replicación maestro-esclavo se comunique normalmente, cuando se establece la replicación por primera vez, el nodo maestro enviará todos los datos que contiene al nodo esclavo. Esta parte de la operación es el paso más largo.
   

Estrategia de sincronización maestro-esclavo

Cuando el maestro y el esclavo recién están conectados, se realiza una sincronización completa; una vez completada la sincronización completa, se realiza una sincronización incremental. Por supuesto, si es necesario, el esclavo puede iniciar la sincronización completa en cualquier momento. La estrategia de Redis es que, pase lo que pase, primero se intentará la sincronización incremental y, si no tiene éxito, se requerirá que la máquina esclava realice una sincronización completa.

Por ejemplo

guardar un caché

set name jjy
1

El comando de grabación es

$3 r n
set r n
$4 r n
name r n
$5  r n
jjy r n
1
2
3
4
5
6

7. El comando se copia continuamente.
Cuando el nodo maestro sincroniza los datos actuales con el nodo esclavo, se completa el proceso de establecimiento de replicación. A continuación, el nodo maestro enviará continuamente comandos de escritura a los nodos esclavos para garantizar la coherencia de los datos maestro-esclavo.

Monitoreo centinela

Desventajas de la replicación maestro-esclavo de Redis

Cuando el host Master deja de funcionar, debemos resolver manualmente el cambio.

Problemas de exposición:
Una vez que el nodo maestro deja de funcionar y no se puede utilizar el servicio de escritura, debe cambiar manualmente, volver a seleccionar el nodo maestro y configurar manualmente la relación maestro-esclavo.

Tecnología de conmutación maestro-esclavo

Cuando el servidor maestro deja de funcionar, es necesario cambiar manualmente un servidor esclavo al servidor maestro, lo que requiere intervención manual, requiere mucho tiempo y mano de obra y también hará que el servicio no esté disponible durante un período de tiempo.Este no es un enfoque recomendado, más a menudo damos prioridad aModo centinela。

Descripción general del centinela

El modo Sentinel es un modo especial. Primero, Redis proporciona comandos Sentinel. Como proceso, se ejecutará de forma independiente. El principio es que Sentinel monitorea varias instancias de Redis en ejecución enviando comandos y esperando que el servidor de Redis responda.

Papel centinela

• Monitoreo de clústeres: Responsable de monitorear si los procesos maestro y esclavo de Redis están funcionando correctamente.
• notificación: Si falla una instancia de Redis, el centinela es responsable de enviar mensajes como notificaciones de alarma al administrador.
• conmutación por error: Si el nodo maestro cuelga, se transferirá automáticamente al nodo esclavo.
• Centro de configuración: Si se produce una conmutación por error, notifique al cliente la nueva dirección maestra

Construcción del entorno de monitoreo centinela

Cree un nuevo archivo sentinel-26379.conf

#端口
port 26379
#守护进程运行
daemonize yes
#日志文件
logfile "26379.log"
sentinel monitor mymaster localhost 6379 2
1
2
3
4
5
6
7

parámetro:
monitor centinela mymaster 192.168.92.128 6379 2 El significado de la configuración es: el nodo centinela monitorea el nodo maestro 192.168.92.128:6379 El nombre del nodo maestro es mymaster El significado de los 2 últimos está relacionado con la determinación de fallas. el nodo maestro: se requieren al menos 2. Solo cuando dos nodos centinela están de acuerdo se puede determinar la falla del nodo maestro y realizar la conmutación por error.

Cree un nuevo archivo sentinel-26380.conf

#端口
port 26380
#守护进程运行
daemonize yes
#日志文件
logfile "26380.log"
sentinel monitor mymaster localhost 6379 2
1
2
3
4
5
6
7

Cree un nuevo archivo sentinel-26381.conf

#端口
port 26381
#守护进程运行
daemonize yes
#日志文件
logfile "26381.log"
sentinel monitor mymaster localhost 6379 2
1
2
3
4
5
6
7

Iniciando el ganglio centinela

redis-sentinel sentinel-26379.conf
1

Ver el estado del ganglio centinela

[root@localhost src]# ./redis-cli -p 26379
127.0.0.1:26379> 
127.0.0.1:26379> 
127.0.0.1:26379> info sentinel
# Sentinel
sentinel_masters:1
sentinel_tilt:0
sentinel_running_scripts:0
sentinel_scripts_queue_length:0
sentinel_simulate_failure_flags:0
master0:name=mymaster,status=ok,address=192.168.66.100:6379,slaves=2,sentinels=3
1
2
3
4
5
6
7
8
9
10
11

Análisis del principio de funcionamiento de Sentinel.

fase de seguimiento

Aviso:

• centinela (centinela 1)----->Iniciar información al maestro (maestro) y al esclavo (esclavo) y obtener la información completa.
• centinela (centinela 2) -----> Inicie información al maestro (maestro), conocerá la información del centinela existente (centinela 1) y se conectará al esclavo (esclavo).
• centinela (centinela 2)----->Iniciar una suscripción a centinela (centinela 1).

Etapa de notificación

Sentinel envía continuamente notificaciones al maestro y al esclavo para recopilar información.

fase de conmutación por error

En la fase de notificación, si la notificación enviada por el centinela no recibe una respuesta del maestro, marcará al maestro como SRI_S_DOWN y enviará el estado del maestro a cada centinela. Cuando otros centinelas se enteren de que el maestro ha muerto, dirán. No lo creo. También lo comprobaré y lo enviaré. Los resultados se comparten con cada centinela. Cuando la mitad de los centinelas piensen que el maestro está caído, lo marcarán como SRI_0_DOWN.

Aquí viene la pregunta:

En este momento, el maestro debe ser reemplazado. ¿Quién será el maestro?

como votar

Forma:

El centinela que reciba primero el aviso electoral votará a favor.

Elimina algunos casos:

• Fuera de linea
• Respuesta lenta
• Desconectado del master original durante mucho tiempo
• principio de prioridad

conmutación por error

Descripción general
Demuestra las capacidades de monitoreo y conmutación por error automática de Sentinel cuando falla el nodo maestro.

Demostrar conmutación por error
Utilice el comando kill para matar el nodo maestro

ps aux |grep redis
kill -9 pid
1
2

Ver información del ganglio centinela

Si usa inmediatamente el comando info Sentinel en el nodo centinela para verlo.

[root@localhost src]# ./redis-cli -p 26379
127.0.0.1:26379> info sentinel
# Sentinel
sentinel_masters:1
sentinel_tilt:0
sentinel_running_scripts:0
sentinel_scripts_queue_length:0
sentinel_simulate_failure_flags:0
master0:name=mymaster,status=ok,address=127.0.0.1:6381,slaves=5,sentinels=3
1
2
3
4
5
6
7
8
9

Aviso：
Descubrirá que el nodo maestro no se ha cambiado, porque el centinela tardará algún tiempo en detectar la falla del nodo maestro y transferirlo.

Reiniciar el nodo 6379

[root@localhost src]# ./redis-cli info replication
# Replication
role:slave
master_host:127.0.0.1
master_port:6381
master_link_status:down
1
2
3
4
5
6

Los archivos de configuración se reescribirán
Durante la fase de conmutación por error, se reescribirán los archivos de configuración de los nodos centinela y maestro-esclavo.

include /usr/local/redis/redis.conf
pidfile "/var/run/redis_6379.pid"
port 6379
dbfilename "dump6379.rdb"
# Generated by CONFIG REWRITE
daemonize yes
protected-mode no
appendonly yes
slowlog-max-len 1200
slowlog-log-slower-than 1000
save 5 1
user default on nopass ~* &* +@all
dir "/usr/local/redis"
replicaof 127.0.0.1 6381
1
2
3
4
5
6
7
8
9
10
11
12
13
14

en conclusión

• Los nodos maestro-esclavo del sistema Sentinel no son diferentes de los nodos maestro-esclavo ordinarios. Sentinel controla y completa el descubrimiento y la transferencia de fallas.
• Los ganglios centinela son esencialmente nodos redis.
• Cada nodo centinela solo necesita configurar el nodo maestro de monitoreo para descubrir automáticamente otros nodos centinela y nodos esclavos.
• Durante las fases de inicio y conmutación por error del nodo centinela, los archivos de configuración de cada nodo se reescribirán (reescritura de configuración).

Modo de clúster

Redis tiene tres modos de clúster

• modo maestro-esclavo
• Modo centinela
• Modo de clúster

Desventajas del modo centinela

defecto：

• Cuando el maestro cuelga, el centinela elegirá un maestro. Durante la elección, no hay forma de acceder a Redis y habrá una interrupción temporal del acceso;
• En el modo centinela, solo el nodo maestro se puede escribir externamente y el nodo esclavo solo se puede usar para lectura. Aunque un solo nodo de Redis admite hasta 10 W QPS, durante las promociones de comercio electrónico, toda la presión de escribir datos recae sobre el maestro.
• La memoria de un solo nodo de Redis no se puede configurar demasiado grande. Si los datos son demasiado grandes, la sincronización maestro-esclavo será muy lenta cuando se inicie el nodo y llevará mucho tiempo;

Descripción general del modo de clúster

El clúster Redis es un clúster de servicios distribuidos compuesto por múltiples grupos de nodos maestro-esclavo. Tiene funciones de replicación, alta disponibilidad y fragmentación.

Ventajas del clúster Redis

• El clúster de Redis tiene varios maestros, lo que puede reducir el impacto de los problemas de acceso transitorio.
• El clúster de Redis tiene varios maestros, lo que puede proporcionar una mayor concurrencia
• El clúster de Redis se puede almacenar en fragmentos para poder almacenar más datos

Construcción en modo clúster

La construcción del clúster de Redis requiere al menos 3 nodos maestros. Aquí construimos 3 maestros, cada uno con un nodo esclavo, para un total de 6 nodos de Redis;

Construcción de clusters

Cree 6 nodos de Redis diferentes con los números de puerto 6379, 6380, 6381, 6382, 6383 y 6384 respectivamente.

Aviso: Los archivos dump.rdb y appendonly.aof deben eliminarse antes de copiarlos.

1. Cree un nuevo archivo de configuración
Cree los archivos redis6379.config, redis6380.config, redis6381.config, redis6382.config, redis6383.config, redis6384.config. Modifique el número de puerto en el archivo de configuración para que corresponda al número de puerto del archivo.

daemonize yes
dir /usr/local/redis-7.2.4/redis-cluster/6382/
bind 192.168.47.100
port 6382
dbfilename dump6382.rdb
cluster-enabled yes
cluster-config-file nodes-6382.conf
cluster-node-timeout 5000
appendonly yes
protected-mode no
1
2
3
4
5
6
7
8
9
10

parámetro：

• cluster-config-file: el archivo de configuración de persistencia del clúster, que contiene el estado de otros nodos, variables de persistencia, etc., se generará automáticamente en el directorio dir configurado anteriormente. Cada nodo mantendrá un archivo de configuración del clúster durante la operación; cada vez que cambie la información del clúster (como agregar o eliminar nodos), todos los nodos del clúster actualizarán la información más reciente en el archivo de configuración cuando el nodo se reinicie. el archivo de configuración para obtener información del clúster y podrá volver a unirse fácilmente al clúster. Redis mantiene el archivo de configuración del clúster y no requiere modificación manual.
• habilitado para clúster: habilita el clúster

Crear carpeta

mkdir -p /usr/local/redis-7.2.4/redis-cluster/6379/
mkdir -p /usr/local/redis-7.2.4/redis-cluster/6380/
mkdir -p /usr/local/redis-7.2.4/redis-cluster/6381/
mkdir -p /usr/local/redis-7.2.4/redis-cluster/6382/
mkdir -p /usr/local/redis-7.2.4/redis-cluster/6383/
mkdir -p /usr/local/redis-7.2.4/redis-cluster/6384/
1
2
3
4
5
6

Iniciar seis nodos

[root@bogon src]# ./redis-server ../redis6379.config
[root@bogon src]# ./redis-server ../redis6380.config
[root@bogon src]# ./redis-server ../redis6381.config
[root@bogon src]# ./redis-server ../redis6382.config
[root@bogon src]# ./redis-server ../redis6383.config
[root@bogon src]# ./redis-server ../redis6384.config
1
2
3
4
5
6

Compruebe si cada nodo se inicia correctamente

[root@bogon src]# ps -ef | grep redis
root    3889    1 0 09:56 ?    00:00:03 ./redis-server 0.0.0.0:6379 [cluster]
root    3895    1 0 09:56 ?    00:00:03 ./redis-server 0.0.0.0:6380 [cluster]
root    3901    1 0 09:57 ?    00:00:03 ./redis-server 0.0.0.0:6381 [cluster]
root    3907    1 0 09:57 ?    00:00:02 ./redis-server *:6382 [cluster]
root    3913    1 0 09:57 ?    00:00:02 ./redis-server 0.0.0.0:6383 [cluster]
root    3919    1 0 09:57 ?    00:00:02 ./redis-server 0.0.0.0:6384 [cluster]
root    4247  2418 0 10:22 pts/0  00:00:00 grep --color=auto redis
1
2
3
4
5
6
7
8

Configurar el clúster

Formato de comando: --cluster-replicas 1 significa crear un nodo esclavo para cada maestro

Aviso: La IP aquí es la IP real de la máquina donde se encuentra cada nodo.

[root@localhost src]# ./redis-cli --cluster create 192.168.47.100:6379 192.168.47.100:6380 192.168.47.100:6381 192.168.47.100:6382 192.168.47.100:6383 192.168.47.100:6384 --cluster-replicas 1
1

Verificar clúster

Conéctate a cualquier cliente

./redis-cli -h 192.168.47.100  -p 6379 -c
1

parámetro:

‐h: dirección de host
-p: número de puerto
‐c: indica modo de clúster

prueba de escritura de datos

[root@bogon src]# ./redis-cli -p 6379 -c
127.0.0.1:6379> set name zhangsan
-> Redirected to slot [5798] located at 192.168.47.100:6380
OK
192.168.47.100:6380> get name
"zhangsan"
192.168.47.100:6380>
[root@bogon src]# ./redis-cli -p 6383 -c
127.0.0.1:6383> get name
-> Redirected to slot [5798] located at 192.168.47.100:6380
"zhangsan"
192.168.47.100:6380>
[root@bogon src]# ./redis-cli -p 6383 -c
127.0.0.1:6383> readonly
OK
127.0.0.1:6383> get name
"zhangsan"
127.0.0.1:6383>
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18

Análisis del principio del patrón de conglomerados

Clúster Redis Todos los datos se dividen en 16384 ranuras (slots) y cada nodo es responsable de una parte de las ranuras. La información de las ranuras se almacena en cada nodo. Solo se asignarán ranuras al nodo maestro y no se asignarán ranuras al nodo esclavo.

Algoritmo de posicionamiento de ranura：k1 = 127001

De forma predeterminada, Cluster usará el algoritmo crc16 para codificar el valor de la clave para obtener un valor entero, y luego usará este valor entero hasta el módulo 16384 para obtener la ranura específica.

HASH_SLOT = CRC16(clave) % 16384

Recuperación
Ver nodos

192.168.66.103:8001> cluster nodes
1

Mata el nodo maestro

lsof -i:8001
kill -9 pid
1
2

Observar la información del nodo

Clúster de Redis operativo Java

Modificar archivo de configuración

spring.data.redis.cluster.nodes=192.168.47.100:6381,192.168.47.100:6383,192.168.47.100:6380
1

Aviso
1. El clúster de Redis requiere al menos 3 nodos para garantizar una alta disponibilidad.
2. Debe intentar evitar agregar o eliminar nodos mientras el clúster de Redis se está ejecutando, ya que esto puede provocar una migración de datos y, por lo tanto, afectar el rendimiento general del clúster de Redis.

Código escrito en Java

@SpringBootTest
public class CluseterTest {

  @Autowired
  private RedisTemplate<String,Object> redisTemplate;

  @Test
  void string() {
    //  保存字符串
    redisTemplate.opsForValue().set("itbaizhan","itbaizhan123");

    System.out.println(redisTemplate.opsForValue().get("itbaizhan"));

   }
}
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15

Si mi contenido te resulta útil, por favorMe gusta, comenta, favorito .Crear no es fácil, el apoyo de todos es lo que me mantiene adelante