Condivisione della tecnologia

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

7.11 Check-in del giorno di studio

1. transazione redis

Il concetto di transazioni e proprietà ACID

Transazioni a livello di database

A livello di database, una transazione è un insieme di operazioni che vengono eseguite tutte con successo oppure nessuna viene eseguita.

Quattro caratteristiche principali delle transazioni di database

• R: Atomic, atomicity, esegue tutti gli SQL come unità di lavoro atomiche, vengono eseguiti tutti o nessuno di essi;
• C: Coerente, una volta completata la transazione, lo stato di tutti i dati è coerente, ovvero finché 100 viene sottratto dal conto A, 100 verrà aggiunto al conto B;
• I: Isolamento, se vengono eseguite più transazioni contemporaneamente, le modifiche apportate da ciascuna transazione devono essere isolate dalle altre transazioni;
• D: Durata, persistenza, ovvero, una volta completata la transazione, le modifiche ai dati del database vengono archiviate in modo persistente.

Transazione Redis

Una transazione Redis è un insieme di comandi Tutti i comandi in una transazione verranno serializzati e una serie di comandi verrà eseguita in modo unico, sequenziale ed esclusivo.

Tre caratteristiche principali delle transazioni Redis

• operazioni di quarantena separate : tutti i comandi nella transazione verranno serializzati ed eseguiti in ordine. Durante l'esecuzione della transazione, questa non verrà interrotta dalle richieste di comandi inviate da altri client;
• Nessun concetto di livello di isolamento: I comandi nella coda non verranno effettivamente eseguiti finché non verranno inviati, poiché nessuna istruzione verrà effettivamente eseguita prima dell'invio della transazione, quindi non esiste alcuna "query all'interno della transazione per vedere gli aggiornamenti nella transazione e query all'esterno della transazione" transazione"Non riesco a vedere".
• Nessuna garanzia di atomicità: se un comando non viene eseguito nella stessa transazione Redis, i comandi successivi verranno comunque eseguiti senza rollback;

Tre fasi di esecuzione della transazione Redis

• accendere:diMULTIAvviare una transazione;
• Unisciti alla squadra: Accoda più comandi in una transazione Questi comandi non verranno eseguiti immediatamente dopo averli ricevuti, ma verranno inseriti nella coda delle transazioni in attesa di esecuzione;
• strumento:Dipende daEXECIl comando attiva la transazione;

Operazioni di base delle transazioni Redis

Multi、Esegui、Scarta

input della transazione daMultiAll'avvio del comando, i comandi immessi verranno inseriti nella coda del buffer dei comandi uno per uno e non verranno eseguiti fino alExec Successivamente, Redis eseguirà in sequenza i comandi nella coda del buffer dei comandi precedente.Durante il processo di formazione della squadra, puoi passarediscardVieni a rinunciare alla squadra.

esempio

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

abbandonare la transazione

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

Tutti seduti insieme

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

Avviso：
Il set di comandi contiene istruzioni errate (nota che si tratta di errori di sintassi). Sono tutti collegati e tutti falliscono.

Ogni ingiustizia ha il suo padrone, ogni debito ha il suo padrone

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

Avviso：
Per gli errori di runtime, ovvero gli errori non grammaticali, verranno eseguiti i comandi corretti e i comandi errati restituiranno un errore.

2. cluster Redis

replica master-slave

Panoramica
Tra le imprese esistenti, l’80% delle aziende utilizza principalmente servizi Redis stand-alone. Negli scenari reali, Redis su un singolo nodo è soggetto a rischi.

affrontare problemi:

• malfunzionamento della macchina. Distribuiamo su un server Redis Quando si verifica un guasto della macchina, dobbiamo migrare su un altro server e garantire che i dati siano sincronizzati.
• Collo di bottiglia in termini di capacità. Quando avremo bisogno di espandere la memoria Redis, da 16G di memoria a 64G, una sola macchina sicuramente non sarà in grado di soddisfarla. Naturalmente puoi acquistare una nuova macchina da 128G.

Soluzione

Per ottenere una maggiore capacità di archiviazione del database distribuito e per resistere ad un elevato accesso simultaneo, memorizzeremo i dati del database centralizzato originale su più altri nodi di rete.

Avviso：
Per risolvere questo problema del nodo singolo, Redis distribuirà anche più copie dei dati su altri nodi per la replica per ottenere un'elevata disponibilità di Redis e un backup ridondante dei dati per garantire un'elevata disponibilità di dati e servizi.

Cos'è la replica master-slave

La replica master-slave si riferisce alla copia dei dati da un server Redis ad altri server Redis. Il primo è chiamato nodo master e il secondo è chiamato nodo slave. La replica dei dati è unidirezionale e può avvenire solo dal nodo master al nodo slave.

Il ruolo della replica master-slave

• Ridondanza dei dati: La replica master-slave implementa il backup a caldo dei dati, che è un metodo di ridondanza dei dati oltre alla persistenza.
• Recupero: Quando si verifica un problema sul nodo master, il nodo slave può fornire servizi per ottenere un rapido ripristino dagli errori: in realtà si tratta di una sorta di ridondanza del servizio.
• bilancio del carico: Sulla base della replica master-slave, con la separazione tra lettura e scrittura, il nodo master può fornire servizi di scrittura e i nodi slave possono fornire servizi di lettura (ovvero, durante la scrittura dei dati Redis, l'applicazione dovrebbe connettersi al nodo master , e durante la lettura dei dati Redis, l'applicazione deve connettersi al nodo slave), condividendo il carico del server, soprattutto negli scenari in cui c'è meno scrittura e più lettura, la condivisione del carico di lettura attraverso più nodi slave può aumentare notevolmente la concorrenza del server Redis; .
• Pietra miliare dell'alta disponibilità: Oltre alle funzioni di cui sopra, la replica master-slave è anche la base per l'implementazione di sentinelle e cluster. Pertanto, la replica master-slave è la base per l'elevata disponibilità di Redis.

Configurazione dell'ambiente di replica master-slave

Scrivi il file di configurazione
Crea un nuovo 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

Crea un nuovo 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

Crea un nuovo 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

Avvia tre server Redis

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

Visualizza i processi di 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

Controlla lo stato di funzionamento di tre host

#打印主从复制的相关信息
./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

Dotato di database slave ma non di database master

Formato della sintassi:

slaveof  <ip> <port>
1

Esempio:

Eseguito su 6380 e 6381.

127.0.0.1:6380> SLAVEOF 127.0.0.1 6379
OK
1
2

Scrivi sull'host e leggi i dati sullo slave

set k1 v1
1

Analisi del principio di replica master-slave

La replica master-slave può essere suddivisa in 3 fasi

• Fase di realizzazione della connessione (ovvero fase di preparazione)
• Fase di sincronizzazione dei dati
• fase di propagazione dei comandi

Il processo di copia è approssimativamente suddiviso in 6 processi

1. Salva le informazioni sul nodo principale (master).
   Visualizza le informazioni sullo stato dopo aver eseguito slaveof

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. Il nodo slave (slave) mantiene la logica relativa alla replica attraverso attività pianificate che vengono eseguite ogni secondo. Quando l'attività pianificata rileva la presenza di un nuovo nodo master, tenterà di stabilire una connessione di rete con il nodo.
   
3. Stabilire una connessione di rete tra il nodo slave e il nodo master
   Il nodo slave stabilirà un socket. Il nodo slave stabilisce un socket con la porta 51234, che viene utilizzata specificamente per accettare comandi di replica inviati dal nodo master.

4. Invia il comando ping

Dopo che la connessione è stata stabilita con successo, il nodo slave invia una richiesta ping per la prima comunicazione.

effetto:

• Rileva se la presa di rete tra master e slave è disponibile.
• Rileva se il nodo master può attualmente accettare comandi

5. ASD.
   Se il parametro requirepass è impostato sul nodo master, è richiesta la verifica della password. Il nodo slave deve configurare il parametro masterauth per garantire che la password sia la stessa del nodo master per superare la verifica, se la verifica fallisce, verrà eseguita la replica terminato e il nodo slave avvierà nuovamente il processo di replica.

6. Sincronizza i set di dati.
   Dopo che la connessione di replica master-slave comunica normalmente, quando la replica viene stabilita per la prima volta, il nodo master invierà tutti i dati in suo possesso al nodo slave. Questa parte dell'operazione è il passaggio più lungo.
   

Strategia di sincronizzazione master-slave

Quando il master e lo slave sono appena collegati, viene eseguita la sincronizzazione completa; una volta completata la sincronizzazione completa, viene eseguita la sincronizzazione incrementale. Naturalmente, se necessario, lo slave può avviare in qualsiasi momento la sincronizzazione completa. La strategia Redis prevede che, indipendentemente da ciò, verrà tentata prima la sincronizzazione incrementale e, in caso di insuccesso, la macchina slave dovrà eseguire la sincronizzazione completa.

Per esempio

salvare una cache

set name jjy
1

Il comando di registrazione è

$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. Il comando viene copiato continuamente.
Quando il nodo master sincronizza i dati correnti con il nodo slave, il processo di creazione della replica viene completato. Successivamente, il nodo master invierà continuamente comandi di scrittura ai nodi slave per garantire la coerenza dei dati master-slave.

Monitoraggio sentinella

Svantaggi della replica master-slave di Redis

Quando il Master host si interrompe, dobbiamo risolvere manualmente il passaggio.

Problemi di esposizione:
Una volta che il nodo master non funziona e il servizio di scrittura non può essere utilizzato, è necessario cambiare manualmente, selezionare nuovamente il nodo master e impostare manualmente la relazione master-slave.

Tecnologia di commutazione master-slave

Quando il server master non funziona, è necessario passare manualmente da un server slave al server master, il che richiede un intervento manuale, richiede molto tempo e manodopera e causa anche la non disponibilità del servizio per un periodo di tempo.Questo non è un approccio consigliato, più spesso diamo la prioritàModalità sentinella。

Panoramica della sentinella

La modalità Sentinel è una modalità speciale Innanzitutto, Redis fornisce i comandi Sentinel è un processo indipendente, verrà eseguito in modo indipendente. Il principio è che la sentinella monitora più istanze Redis in esecuzione inviando comandi e aspettando la risposta del server Redis.

Ruolo di sentinella

• Monitoraggio dei cluster: responsabile del monitoraggio del corretto funzionamento dei processi redis master e slave
• notifica: Se un'istanza Redis fallisce, la sentinella è responsabile dell'invio di messaggi come notifiche di allarme all'amministratore.
• failover: Se il nodo master riaggancia, verrà automaticamente trasferito al nodo slave.
• Centro di configurazione: Se si verifica un failover, notificare al client il nuovo indirizzo master

Costruzione dell'ambiente di monitoraggio Sentinel

Crea un nuovo file sentinel-26379.conf

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

parametro:
monitor sentinella mymaster 192.168.92.128 6379 2 Il significato della configurazione è: il nodo sentinella monitora il nodo master 192.168.92.128:6379 Il nome del nodo master è mymaster Il significato degli ultimi 2 è legato alla determinazione dell'errore il nodo master: ne sono necessari almeno 2. Solo quando due nodi sentinella concordano è possibile determinare il guasto del nodo master ed eseguire il failover.

Crea un nuovo file sentinel-26380.conf

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

Crea un nuovo file sentinel-26381.conf

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

Avvio del nodo sentinella

redis-sentinel sentinel-26379.conf
1

Visualizza lo stato del nodo sentinella

[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

Analisi del principio di funzionamento di Sentinel

fase di monitoraggio

Avviso:

• sentinel (sentinel 1)----->Invia informazioni al master (master) e allo slave (slave) e ottieni le informazioni complete.
• sentinella (sentinella 2)----->Invia informazioni al master (master), conoscerai le informazioni della sentinella esistente (sentinella 1) e ti connetterai allo slave (slave).
• sentinel (sentinel 2)----->Avvia una sottoscrizione a sentinel (sentinel 1).

Fase di notifica

Sentinel invia continuamente notifiche al master e allo slave per raccogliere informazioni.

fase di failover

Nella fase di notifica, se la notifica inviata dalla sentinella non riceve risposta dal master, contrassegnerà il master come SRI_S_DOWN e invierà lo stato del master a ciascuna sentinella. Quando le altre sentinelle sentono che il master è morto, dicono Non ci credo Lo controllerò e lo invierò I risultati vengono condivisi con ciascuna sentinella Quando metà delle sentinelle pensa che il master sia a terra, lo contrassegneranno come SRI_0_DOWN.

Ecco la domanda:

In questo momento il maestro deve essere sostituito. Chi sarà il padrone?

Come votare

Modo:

Voterò per la sentinella a cui riceverò per prima la notifica elettorale.

Elimina alcuni casi:

• Non online
• Risposta lenta
• Disconnesso dal master originale per molto tempo
• principio di priorità

failover

Panoramica
Dimostra le funzionalità di monitoraggio e failover automatico di Sentinel in caso di guasto del nodo master.

Dimostrare il failover
Usa il comando kill per uccidere il nodo master

ps aux |grep redis
kill -9 pid
1
2

Visualizza le informazioni sul nodo sentinella

Se utilizzi immediatamente il comando info Sentinel sul nodo sentinella per visualizzarlo.

[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

Avviso：
Scoprirai che il nodo master non è stato commutato, perché ci vorrà del tempo prima che la sentinella rilevi il guasto del nodo master e lo trasferisca.

Riavviare il 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

I file di configurazione verranno riscritti
Durante la fase di failover verranno riscritti i file di configurazione dei nodi sentinella e master-slave.

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

Insomma

• I nodi master-slave nel sistema Sentinel non sono diversi dai normali nodi master-slave. Il rilevamento e il trasferimento dei guasti sono controllati e completati da Sentinel.
• I nodi sentinella sono essenzialmente nodi Redis.
• Ogni nodo sentinella deve solo configurare il nodo master di monitoraggio per rilevare automaticamente altri nodi sentinella e nodi slave.
• Durante le fasi di avvio e failover del nodo sentinella, i file di configurazione di ciascun nodo verranno riscritti (config rewrite).

Modalità cluster

Redis ha tre modalità cluster

• modalità master-slave
• Modalità sentinella
• Modalità cluster

Svantaggi della modalità sentinella

discordanza：

• Quando il master riattacca, la sentinella eleggerà un master. Durante l'elezione non sarà possibile accedere a Redis e ci sarà un'interruzione temporanea dell'accesso;
• In modalità sentinella, solo il nodo master può essere scritto esternamente e il nodo slave può essere utilizzato solo per la lettura. Sebbene un singolo nodo Redis supporti fino a 10 W QPS, durante le promozioni e-commerce, tutta la pressione della scrittura dei dati ricade sul master.
• La memoria del singolo nodo di Redis non può essere impostata su un valore troppo grande. Se i dati sono troppo grandi, la sincronizzazione master-slave sarà molto lenta all'avvio del nodo e richiederà molto tempo;

Panoramica della modalità cluster

Il cluster Redis è un cluster di servizi distribuiti composto da più gruppi di nodi master-slave con funzionalità di replica, disponibilità elevata e partizionamento orizzontale.

Vantaggi del cluster Redis

• Il cluster Redis ha più master, il che può ridurre l'impatto dei problemi di accesso transitorio.
• Il cluster Redis ha più master, che possono fornire una maggiore concorrenza
• Il cluster Redis può essere archiviato in frammenti in modo da poter archiviare più dati

Costruzione in modalità cluster

La costruzione del cluster Redis richiede almeno 3 nodi master Qui creiamo 3 master, ciascuno con un nodo slave, per un totale di 6 nodi Redis;

Costruzione di cluster

Crea 6 diversi nodi Redis con numeri di porta rispettivamente 6379, 6380, 6381, 6382, 6383 e 6384.

Avviso: I file dump.rdb e appendonly.aof devono essere eliminati prima della copia.

1. Creare un nuovo file di configurazione
Creare file redis6379.config, redis6380.config, redis6381.config, redis6382.config, redis6383.config, redis6384.config Modificare il numero di porta nel file di configurazione in modo che corrisponda al numero di porta del file.

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

parametro：

• cluster-config-file: il file di configurazione della persistenza del cluster, che contiene lo stato di altri nodi, variabili di persistenza, ecc., verrà generato automaticamente nella directory dir configurata sopra. Ogni nodo manterrà un file di configurazione del cluster durante il funzionamento; ogni volta che le informazioni sul cluster cambiano (come l'aggiunta o la rimozione di nodi), tutti i nodi nel cluster aggiorneranno le informazioni più recenti nel file di configurazione, che verrà riletto il file di configurazione per ottenere informazioni sul cluster ed è possibile ricongiungersi facilmente al cluster. Il file di configurazione del cluster viene gestito da Redis e non richiede modifiche manuali.
• cluster-enabled: abilita il cluster

Creare una cartella

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

Inizia sei nodi

[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

Controlla se ciascun nodo viene avviato correttamente

[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

Configura il cluster

Formato del comando: --cluster-replicas 1 significa creare un nodo slave per ciascun master

Avviso: L'IP qui è l'IP reale della macchina su cui si trova ciascun 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

Verifica gruppo

Connettiti a qualsiasi client

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

parametro:

‐h: indirizzo dell'host
-p: numero di porta
‐c: indica la modalità cluster

Prova di scrittura dei dati

[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

Analisi dei principi dei modelli di cluster

Cluster Redis Tutti i dati sono suddivisi in 16384 slot (slot) e ciascun nodo è responsabile di una parte degli slot. Le informazioni sugli slot vengono archiviate in ciascun nodo. Solo al nodo master verranno assegnati gli slot e al nodo slave non verranno assegnati gli slot.

Algoritmo di posizionamento degli slot： k1 = 127001

Per impostazione predefinita, Cluster utilizzerà l'algoritmo crc16 per eseguire l'hashing del valore della chiave per ottenere un valore intero, quindi utilizzerà questo valore intero nel modulo 16384 per ottenere lo slot specifico.

HASH_SLOT = CRC16(chiave) % 16384

Recupero
Visualizza i nodi

192.168.66.103:8001> cluster nodes
1

Uccidi il nodo principale

lsof -i:8001
kill -9 pid
1
2

Osservare le informazioni sul nodo

Cluster Redis operativo Java

Modifica file di configurazione

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

Avviso
1. Il cluster Redis richiede almeno 3 nodi per garantire un'elevata disponibilità.
2. Dovresti cercare di evitare di aggiungere o eliminare nodi mentre il cluster Redis è in esecuzione, poiché ciò potrebbe causare la migrazione dei dati e quindi influire sulle prestazioni generali del cluster Redis.

Codice scritto in 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

Se i miei contenuti ti sono utili, per favoreMetti mi piace, commenta, aggiungi ai preferiti .Creare non è facile, il sostegno di tutti è ciò che mi fa andare avanti