Teknologian jakaminen

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

7.11 Opintopäivän sisäänkirjautuminen

1. redis-tapahtuma

Tapahtuman käsite ja ACID-ominaisuudet

Tietokantatason tapahtumat

Tietokantatasolla tapahtuma on joukko toimintoja, jotka joko kaikki suoritetaan onnistuneesti tai eivät suorita yhtään.

Tietokantatapahtumien neljä pääpiirrettä

• V: Atomic, atomicity, suorittaa kaikki SQL:t atomisina työyksiköinä, joko ne kaikki suoritetaan tai niitä ei suoriteta;
• C: Johdonmukainen, kun tapahtuma on suoritettu, kaikkien tietojen tila on johdonmukainen, eli niin kauan kuin tilistä A vähennetään 100, tilille B lisätään 100;
• I: Eristäminen, jos useita tapahtumia suoritetaan samanaikaisesti, kunkin tapahtuman tekemät muutokset on eristettävä muista tapahtumista;
• D: Kesto, pysyvyys, eli sen jälkeen, kun tapahtuma on suoritettu, tietokantatietojen muutokset tallennetaan jatkuvasti.

Redis-kauppa

Redis-tapahtuma on joukko komentoja. Kaikki tapahtuman komennot sarjoitetaan ja joukko komentoja suoritetaan kertaluonteisesti, peräkkäin ja yksinomaisesti.

Kolme Redis-tapahtumien pääpiirrettä

• erilliset karanteenitoiminnot : Kaikki tapahtuman komennot sarjoidaan ja suoritetaan järjestyksessä. Tapahtuman suorittamisen aikana muiden asiakkaiden lähettämät komentopyynnöt eivät keskeydy sitä;
• Ei käsitettä eristystasosta: Jonossa olevia komentoja ei suoriteta ennen kuin ne on lähetetty, koska mitään ohjeita ei suoriteta ennen tapahtuman lähettämistä, joten tapahtuman sisällä ei ole "kyselyä tapahtuman päivitysten näkemiseksi, eikä kyselyä tapahtuman ulkopuolella. kauppa "Ei näe".
• Ei takuita atomisuudesta: Jos komento epäonnistuu samassa redis-tapahtumassa, seuraavat komennot suoritetaan silti ilman palautusta;

Redis-tapahtuman suorittamisen kolme vaihetta

• kiihottua: kirjoittajaMULTIAloita tapahtuma;
• Liity joukkueeseen: Järjestä tapahtumaan useita komentoja. Näitä komentoja ei suoriteta heti niiden vastaanottamisen jälkeen, vaan ne sijoitetaan tapahtumajonoon odottamaan suoritusta.
• toteuttaa:RiippuaEXECKomento käynnistää tapahtuman;

Redis-tapahtumien perustoiminnot

Multi, Exec, hylkää

tapahtuman syöttö osoitteestaMultiKun komento käynnistyy, syötetyt komennot työnnetään komentopuskurijonoon yksitellen ja niitä ei suoriteta ennen kuinExec Tämän jälkeen Redis suorittaa edellisen komentopuskurijonon komennot peräkkäin.Joukkueenmuodostusprosessin aikana voit läpäistädiscardTule luopumaan joukkueesta.

esimerkki

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

hylätä kauppa

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

Kaikki istuvat yhdessä

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

Ilmoitus：
Komentosarja sisältää virheellisiä ohjeita (huomaa, että ne ovat syntaksivirheitä Ne ovat kaikki yhteydessä ja kaikki epäonnistuvat).

Jokaisella epäoikeudenmukaisuudella on omistajansa, jokaisella velalla on omistajansa

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

Ilmoitus：
Suorituksenaikaisissa virheissä eli ei-kielioppivirheissä suoritetaan oikeat komennot ja väärät komennot palauttavat virheilmoituksen.

2. redis-klusteri

master-slave replikointi

Yleiskatsaus
Olemassa olevista yrityksistä 80 % yrityksistä käyttää enimmäkseen Redis-erillistä palvelua Todellisissa skenaarioissa Redis on alttiina riskeille.

kohtaamaan ongelmia:

• koneen toimintahäiriö. Otamme käyttöön Redis-palvelimen Kun konevika tapahtuu, meidän on siirryttävä toiselle palvelimelle ja varmistettava, että tiedot synkronoidaan.
• Kapasiteetin pullonkaula. Kun meidän on laajennettava Redis-muistia 16G-muistista 64G-muistiin, yksi kone ei varmasti pysty tyydyttämään sitä. Tietysti voit ostaa uuden 128G koneen.

Ratkaisu

Hajautetun tietokannan suuremman tallennuskapasiteetin saavuttamiseksi ja korkean samanaikaisen käytön kestämiseksi tallennamme alkuperäisen keskitetyn tietokannan tiedot useisiin muihin verkon solmuihin.

Ilmoitus：
Ratkaisekseen tämän yhden solmun ongelman Redis ottaa käyttöön useita kopioita tiedoista myös muihin solmuihin replikoitaviksi, jotta Rediksen korkea käytettävyys ja redundantti tietojen varmuuskopiointi voidaan varmistaa tietojen ja palveluiden korkean käytettävyyden varmistamiseksi.

Mikä on master-slave -replikointi

Master-slave-replikointi tarkoittaa tietojen kopioimista yhdeltä Redis-palvelimelta toisiin Redis-palvelimiin. Ensin mainittua kutsutaan isäntäsolmuksi ja jälkimmäistä orjasolmuksi. Tietojen replikointi on yksisuuntaista, ja se voi tapahtua vain pääsolmusta orjasolmuun.

Isäntä-orja-replikoinnin rooli

• Datan redundanssi: Master-slave-replikointi toteuttaa tietojen kuuman varmuuskopioinnin, joka on pysyvyyden lisäksi tietojen redundanssimenetelmä.
• Elpyminen: Kun pääsolmussa ilmenee ongelma, orjasolmu voi tarjota palveluja nopean vianpalautuksen saavuttamiseksi, se on itse asiassa eräänlainen palvelun redundanssi.
• kuormituksen tasapainoittaminen: Isäntä-orja-replikoinnin perusteella, erottamalla luku ja kirjoittaminen, isäntäsolmu voi tarjota kirjoituspalveluita ja orjasolmut voivat tarjota lukupalveluita (eli Redis-tietoja kirjoitettaessa sovelluksen tulee muodostaa yhteys isäntäsolmuun , ja kun luet Redis-tietoja, sovelluksen tulisi muodostaa yhteys orjasolmuun), jakamalla palvelimen kuormitus erityisesti sellaisissa tilanteissa, joissa on vähemmän kirjoitusta ja enemmän lukemista, lukukuorman jakaminen useiden orjasolmujen kautta voi lisätä huomattavasti Redis-palvelimen samanaikaisuutta; .
• Korkean saatavuuden kulmakivi: Yllä mainittujen toimintojen lisäksi isäntä-orja-replikointi on myös vartioiden ja klustereiden toteuttamisen perusta. Siksi isäntä-orja-replikointi on Redin korkean käytettävyyden perusta.

Master-slave replikointiympäristön asetukset

Kirjoita asetustiedosto
Luo uusi 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

Luo uusi 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

Luo uusi 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

Käynnistä kolme redis-palvelinta

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

Tarkastele järjestelmäprosesseja

[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

Tarkista kolmen isännän toimintatila

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

Varustettu orjatietokannalla, mutta ei päätietokannalla

Syntaksimuoto:

slaveof  <ip> <port>
1

Esimerkki:

Toteutettu numeroilla 6380 ja 6381.

127.0.0.1:6380> SLAVEOF 127.0.0.1 6379
OK
1
2

Kirjoita isäntään ja lue tietoja orjasta

set k1 v1
1

Isäntä-orja-replikoinnin periaatteen analyysi

Master-slave replikointi voidaan jakaa 3 vaiheeseen

• Yhteyden muodostusvaihe (eli valmisteluvaihe)
• Tietojen synkronointivaihe
• komennon levitysvaihe

Kopiointiprosessi on karkeasti jaettu 6 prosessiin

1. Tallenna pääsolmun (isäntä) tiedot.
   Näytä tilatiedot, kun slaveof on suoritettu

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. Orjasolmu (orja) ylläpitää replikointiin liittyvää logiikkaa ajoitettujen tehtävien avulla, jotka suoritetaan joka sekunti. Kun ajoitettu tehtävä havaitsee, että on olemassa uusi pääsolmu, se yrittää muodostaa verkkoyhteyden solmun kanssa.
   
3. Muodosta verkkoyhteys orjasolmun ja pääsolmun välille
   Orjasolmu perustaa socketin, jonka portti on 51234, jota käytetään erityisesti pääsolmun lähettämien replikointikomentojen hyväksymiseen.

4. Lähetä ping-komento

Kun yhteys on muodostettu onnistuneesti, orjasolmu lähettää ping-pyynnön ensimmäistä viestintää varten.

vaikutus:

• Tunnista, onko isäntä- ja orjaverkkoliitäntä käytettävissä.
• Tunnista, voiko pääsolmu tällä hetkellä hyväksyä komentoja

5. ASD.
   Jos master-solmussa on asetettu parametri, salasanan vahvistus vaaditaan. Orjasolmun on määritettävä masterauth-parametri varmistaakseen, että salasana on sama kuin pääsolmun, jotta varmennus epäonnistuu lopetetaan ja orjasolmu aloittaa replikointiprosessin uudelleen.

6. Synkronoi tietojoukot.
   Kun isäntä-orja-replikointiyhteys kommunikoi normaalisti, kun replikointi muodostetaan ensimmäistä kertaa, pääsolmu lähettää kaikki sen hallussa olevat tiedot orjasolmulle. Tämä osa on toiminnan pisin vaihe.
   

Master-slave-synkronointistrategia

Kun isäntä ja orja on juuri yhdistetty, suoritetaan täysi synkronointi, kun täydellinen synkronointi on suoritettu, inkrementaalinen synkronointi suoritetaan. Tietysti orja voi tarvittaessa aloittaa täyden synkronoinnin milloin tahansa. Redis-strategiana on, että riippumatta siitä, mitä, inkrementaalinen synkronointi yritetään ensin, ja jos se ei onnistu, orjakoneen on suoritettava täydellinen synkronointi.

Esimerkiksi

tallenna välimuisti

set name jjy
1

Tallennuskomento on

$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. Komentoa kopioidaan jatkuvasti.
Kun isäntäsolmu synkronoi nykyiset tiedot orjasolmuun, toisinnusprosessi on valmis. Seuraavaksi isäntäsolmu lähettää jatkuvasti kirjoituskomentoja orjasolmuille varmistaakseen isäntä-orjan datan yhdenmukaisuuden.

Sentinel-seuranta

Redisin isäntä-orja-replikaation haitat

Kun isäntäpääkone kaatuu, meidän on ratkaistava kytkin manuaalisesti.

Altistumisongelmat:
Kun pääsolmu menee alas ja kirjoituspalvelua ei voi käyttää, sinun on vaihdettava manuaalisesti, valittava uudelleen pääsolmu ja asetettava isäntä-orja-suhde manuaalisesti.

Master-slave-kytkentätekniikka

Kun pääpalvelin kaatuu, orjapalvelin on vaihdettava manuaalisesti isäntäpalvelimeen, mikä vaatii manuaalista toimenpiteitä, on aikaa vievää ja työlästä ja aiheuttaa myös sen, että palvelu on poissa käytöstä jonkin aikaa.Tämä ei ole suositeltava lähestymistapa, useammin asetamme sen etusijalleSentry-tila。

Sentinel Yleiskatsaus

Sentinel-tila on erityinen tila. Ensinnäkin Redis on itsenäinen prosessi. Periaate on, että vartija valvoo useita käynnissä olevia Redis-ilmentymiä lähettämällä komentoja ja odottamalla Redis-palvelimen vastausta.

Sentinellin rooli

• Klusterin seuranta: Vastaa siitä, että redis-isäntä- ja orjaprosessit toimivat oikein
• ilmoitus: Jos redis-instanssi epäonnistuu, vartija on vastuussa viestien lähettämisestä hälytysilmoituksina järjestelmänvalvojalle.
• epäonnistuminen: Jos isäntäsolmu katkaisee puhelun, se siirretään automaattisesti orjasolmuun.
• Konfigurointikeskus: Jos vikasiirtymä tapahtuu, ilmoita asiakkaalle uusi pääosoite

Sentinel-seurantaympäristön rakentaminen

Luo uusi sentinel-26379.conf-tiedosto

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

parametri:
sentinel monitor mymaster 192.168.92.128 6379 2 Konfiguroinnin merkitys on: Sentinel-solmu valvoo pääsolmua 192.168.92.128:6379 Pääsolmun nimi on mymaster. Viimeisen 2:n merkitys liittyy determinaatioon pääsolmu: vähintään 2 vaaditaan vain, kun kaksi vartiosolmua ovat yhtä mieltä, voidaan määrittää pääsolmun vika ja suorittaa vika.

Luo uusi sentinel-26380.conf-tiedosto

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

Luo uusi sentinel-26381.conf-tiedosto

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

Sentinel-solmun käynnistäminen

redis-sentinel sentinel-26379.conf
1

Näytä vartiosolmun tila

[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

Sentinelin toimintaperiaatteen analyysi

seurantavaihe

Ilmoitus:

• sentinel (sentinel 1)----->Aloita tiedot isännälle (isäntä) ja orjalle (slave) ja saat täydelliset tiedot.
• sentinel (sentinel 2)----->Aloita tiedot isännälle (master), tiedät olemassa olevan vartijan tiedot (sentinel 1) ja muodostat yhteyden orjaan (slave).
• sentinel (sentinel 2)----->Aloita sentinel (sentinel 1) tilaus.

Ilmoitusvaihe

Sentinel lähettää jatkuvasti ilmoituksia isännälle ja orjalle tiedon keräämiseksi.

vikasietovaihe

Ilmoitusvaiheessa, jos vartijan lähettämä ilmoitus ei saa vastausta isännältä, se merkitsee isännäksi SRI_S_DOWN ja lähettää isännän tilan jokaiselle vartijalle, kun muut vartijat kuulevat, että isäntä on kuollut En usko, että tarkistan sen ja lähetän sen.

Tässä tulee kysymys:

Tällä hetkellä mestari on vaihdettava. Kuka on mestari?

Kuinka äänestää

Tapa:

Kumpi vartija saan vaaliilmoituksen ensin, äänestää sitä.

Poista jotkin tapaukset:

• Ei verkossa
• Hidas vastaus
• Irrotettu alkuperäisestä isännästä pitkäksi aikaa
• prioriteettiperiaate

epäonnistuminen

Yleiskatsaus
Osoittaa Sentinelin valvonta- ja automaattiset vikasietoominaisuudet, kun pääsolmu epäonnistuu.

Osoita vikasietoa
Käytä kill-komentoa tappaaksesi pääsolmun

ps aux |grep redis
kill -9 pid
1
2

Näytä vartiosolmun tiedot

Jos käytät heti sentinel-solmun info Sentinel -komentoa nähdäksesi sen.

[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

Ilmoitus：
Tulet huomaamaan, että pääsolmua ei ole vaihdettu, koska kestää jonkin aikaa, ennen kuin vartija havaitsee pääsolmun vian ja siirtää sen.

Käynnistä solmu 6379 uudelleen

[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

Asetustiedostot kirjoitetaan uudelleen
Vikasiirtovaiheen aikana sentinel- ja master-slave-solmun konfiguraatiotiedostot kirjoitetaan uudelleen.

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

tiivistettynä

• Sentinel-järjestelmän isäntä-slave-solmut eivät eroa tavallisista isäntä-orja-solmuista.
• Sentinel-solmut ovat pohjimmiltaan redis-solmuja.
• Jokaisen sentinel-solmun tarvitsee vain määrittää valvontapääsolmu etsimään automaattisesti muut vartiosolmut ja orjasolmut.
• Sentinel-solmun käynnistys- ja vikasietovaiheiden aikana kunkin solmun konfiguraatiotiedostot kirjoitetaan uudelleen (config rewrite).

Klusteritila

Redisillä on kolme klusteritilaa

• isäntä-orja-tila
• Sentinel-tila
• Klusteritila

Sentry-tilan haitat

puute：

• Kun päällikkö katkaisee puhelun, vartija valitsee mestarin Vaalien aikana Redikseen ei pääse käsiksi, ja pääsy keskeytyy väliaikaisesti.
• Vartiotilassa vain pääsolmu voidaan kirjoittaa ulkoisesti ja orjasolmua voidaan käyttää vain lukemiseen. Vaikka yksi Redis-solmu tukee jopa 10 W QPS:ää, verkkokaupan kampanjoiden aikana kaikki tietojen kirjoittamisen paine on isännällä.
• Redisin yksittäisen solmun muistia ei voi asettaa liian suureksi.

Klusteritilan yleiskatsaus

Redis-klusteri on hajautettu palveluklusteri, joka koostuu useista isäntä-orjasolmuryhmistä. Siinä on replikointi, korkea saatavuus ja jakoominaisuudet.

Redis-klusterin edut

• Redis-klusterissa on useita isäntiä, mikä voi vähentää ohimenevien käyttöongelmien vaikutusta.
• Redis-klusterissa on useita isäntiä, jotka voivat tarjota korkeamman samanaikaisuuden
• Redis-klusteri voidaan tallentaa sirpaleiksi, jotta lisää tietoa voidaan tallentaa

Klusteritilan rakentaminen

Redis-klusterin rakentamiseen tarvitaan vähintään 3 isäntäsolmua, joista jokaisessa on orjasolmu, yhteensä 6 Redis-solmua.

Klusterin rakentaminen

Luo kuusi erilaista redis-solmua porttinumeroilla 6379, 6380, 6381, 6382, 6383 ja 6384.

Ilmoitus: Dump.rdb- ja appendonly.aof-tiedostot on poistettava ennen kopioimista.

1. Luo uusi asetustiedosto
Luo redis6379.config, redis6380.config, redis6381.config, redis6382.config, redis6383.config, redis6384.config tiedostot Muokkaa kokoonpanotiedoston porttinumeroa niin, että se vastaa tiedoston porttinumeroa.

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

parametri：

• cluster-config-file: Cluster persistence -määritystiedosto, joka sisältää muiden solmujen tilan, pysyvyysmuuttujat jne., luodaan automaattisesti yllä määritettyyn dir-hakemistoon. Jokainen solmu ylläpitää klusterin määritystiedostoa käytön aikana, kun klusterin tiedot muuttuvat (kuten lisäämällä tai poistamalla solmuja), kaikki klusterin solmut päivittävät uusimmat tiedot konfigurointitiedostoon, kun solmu käynnistyy uudelleen määritystiedostoon saadaksesi klusterin tiedot, ja voit helposti liittyä klusteriin uudelleen. Redis ylläpitää klusterin määritystiedostoa, eikä sitä tarvitse muokata manuaalisesti.
• cluster-enabled: ota klusteri käyttöön

Luo kansio

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

Aloita kuusi solmua

[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

Tarkista, käynnistyvätkö kukin solmu onnistuneesti

[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

Määritä klusteri

Komentomuoto: --cluster-replicas 1 tarkoittaa orjasolmun luomista jokaiselle isännälle

Ilmoitus: IP tässä on koneen todellinen IP, jossa kukin solmu sijaitsee.

[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

Vahvista klusteri

Yhdistä mihin tahansa asiakkaaseen

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

parametri:

‐h: isäntäosoite
-p: portin numero
‐c: osoittaa klusteritilan

Tiedon kirjoitustesti

[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

Klusterimallin periaatteen analyysi

Redis-klusteri Kaikki data on jaettu 16384 aikaväliin (slots), ja kukin solmu vastaa osista aikavälejä. Paikkatiedot tallennetaan kuhunkin solmuun. Vain pääsolmulle määrätään aikavälejä, eikä orjasolmulle osoiteta aikavälejä.

Slot paikannusalgoritmi: k1 = 127001

Oletusarvoisesti Cluster käyttää crc16-algoritmia tiivistämään avaimen arvon kokonaisluvun arvon saamiseksi ja käyttää sitten tätä kokonaislukuarvoa modulo 16384:ään tietyn paikan hankkimiseksi.

HASH_SLOT = CRC16(avain) % 16384

Elpyminen
Näytä solmut

192.168.66.103:8001> cluster nodes
1

Tapa pääsolmu

lsof -i:8001
kill -9 pid
1
2

Tarkkaile solmutietoja

Java-käyttöinen Redis-klusteri

Muokkaa asetustiedostoa

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

Ilmoitus
1. Redis-klusteri vaatii vähintään 3 solmua korkean käytettävyyden varmistamiseksi.
2. Yritä välttää solmujen lisäämistä tai poistamista Redis-klusterin ollessa käynnissä, koska tämä voi aiheuttaa tietojen siirtymistä ja siten vaikuttaa Redis-klusterin yleiseen suorituskykyyn.

Javalla kirjoitettu koodi

@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

Jos sisällöstäni on sinulle apua, ole hyväTykkää, kommentoi, suosikki .Luominen ei ole helppoa, kaikkien tuki pitää minut eteenpäin