Yli vuosikymmenen ajan kehitetyn tuotteen kohdalla ei ole ollenkaan yllättävää löytää siitä vanhentuneita teknologioita. Mutta entä jos kuuden kuukauden aikana joudut pitämään kuorman 10 kertaa korkeampana ja putoamiskustannukset nousevat satoja kertoja? Tässä tapauksessa tarvitset viileän Highload Engineerin. Mutta piikaa puuttuessa he uskoivat ongelman ratkaisemisen minulle. Artikkelin ensimmäisessä osassa kerron kuinka Rediksestä Redis-klusteriin siirryttiin ja toisessa osassa annan neuvoja klusterin käytön aloittamiseen ja mihin kannattaa kiinnittää huomiota sen käytössä.

Teknologian valinta

Onko se niin paha? erillinen Redis (erillinen redis) kokoonpanossa, jossa on 1 isäntä ja N orjaa? Miksi kutsun sitä vanhentuneeksi teknologiaksi?

Ei, Redis ei ole niin huono... On kuitenkin joitain puutteita, joita ei voida jättää huomiotta.

• Ensinnäkin Redis ei tue hätäpalautusmekanismeja päävian jälkeen. Tämän ongelman ratkaisemiseksi käytimme konfiguraatiota, jossa VIP-henkilöt siirrettiin automaattisesti uudelle isännälle, muutettiin yhden orjan roolia ja vaihdettiin loput. Tämä mekanismi toimi, mutta sitä ei voitu kutsua luotettavaksi ratkaisuksi. Ensinnäkin tapahtui vääriä hälytyksiä, ja toiseksi se oli kertakäyttöinen, ja käytön jälkeen vaadittiin manuaalisia toimenpiteitä jousen lataamiseksi.

• Toiseksi vain yhden isäntä johti sirpalointiongelmaan. Piti luoda useita itsenäisiä klustereita "1 isäntä ja N orjaa", sitten jakaa tietokannat manuaalisesti näiden koneiden kesken ja toivoa, että huomenna yksi tietokannoista ei paisuisi niin paljon, että se joutuisi siirtämään erilliseen esiintymään.

Mitkä ovat vaihtoehdot?

• Kallein ja rikkain ratkaisu on Redis-Enterprise. Tämä on laatikkoratkaisu, jossa on täysi tekninen tuki. Huolimatta siitä, että se näyttää tekniseltä kannalta ihanteelliselta, se ei ideologisista syistä sopinut meille.
• Redis-klusteri. Pakkauksessa on tuki master-vikasiirrolle ja shardingille. Käyttöliittymä ei juuri eroa tavallisesta versiosta. Se näyttää lupaavalta, puhumme sudenkuopat myöhemmin.
• Tarantool, Memcache, Aerospike ja muut. Kaikki nämä työkalut tekevät melko saman asian. Mutta jokaisella on omat puutteensa. Päätimme olla laittamatta kaikkia munia samaan koriin. Käytämme Memcachea ja Tarantoolia muihin tehtäviin, ja eteenpäin katsoen sanon, että käytännössämme niiden kanssa oli enemmän ongelmia.

Käytön erityispiirteet

Katsotaanpa, mitä ongelmia olemme historiallisesti ratkaisseet Rediksen kanssa ja mitä toimintoja käytimme:

• Välimuisti ennen pyyntöjä etäpalveluihin, kuten 2GIS | Golang
  

  GET SET MGET MSET "SELECT DB"

• Välimuisti ennen MYSQL | PHP
  

  GET SET MGET MSET SCAN "KEY BY PATTERN" "SELECT DB"

• Päämuisti istuntojen ja kuljettajan koordinaattien käsittelyä varten | Golang
  

  GET SET MGET MSET "VALITSE DB" "LISÄÄ GEO KEY" "HAE GEO KEY" SCAN

Kuten näette, ei korkeampaa matematiikkaa. Mikä sitten on vaikeus? Tarkastellaan jokaista menetelmää erikseen.

menetelmä
Kuvaus
Redis-klusterin ominaisuudet
päätös

VALMISTAUDU
Kirjoitus/luku avain

MGET MSET
Kirjoita/lue useita avaimia
Avaimet ovat eri solmuissa. Valmiit kirjastot voivat suorittaa useita toimintoja vain yhdessä solmussa
Korvaa MGET N GET-operaatiolla

VALITSE DB
Valitse pohja, jonka kanssa työskentelemme
Ei tue useita tietokantoja
Laita kaikki yhteen tietokantaan. Lisää avaimiin etuliitteitä

SKANNATA
Käy läpi kaikki tietokannan avaimet
Koska meillä on yksi tietokanta, klusterin kaikkien avainten läpikäynti on liian kallista
Säilytä invariantti yhdessä avaimessa ja tee HSCAN tälle avaimelle. Tai kieltäytyä kokonaan

GEO
Toiminnot geoavaimella
Geoavain ei ole sirpaloitu

AVAIN KUVION MUKAAN
Etsitään avainta kuvion mukaan
Koska meillä on yksi tietokanta, teemme haun kaikista klusterin avaimista. Liian kallis
Kiellä tai säilytä invariantti, kuten SCAN:n tapauksessa

Redis vs Redis-klusteri

Mitä menetämme ja mitä saamme, kun siirrymme klusteriin?

• Haitat: menetämme useiden tietokantojen toiminnallisuuden.
  • Jos haluamme tallentaa loogisesti toisiinsa liittymättömiä tietoja yhteen klusteriin, meidän on tehtävä kainalosauvat etuliitteiden muodossa.
  • Menetämme kaikki "perus"-toiminnot, kuten SCAN, DBSIZE, CLEAR DB jne.
  • Monioperaatioista on tullut paljon vaikeampi toteuttaa, koska se voi vaatia pääsyn useisiin solmuihin.
• edut:
  • Vikasietokyky master-vikasiirron muodossa.
  • Jakaminen Redisin puolella.
  • Siirrä dataa solmujen välillä atomisesti ja ilman seisokkeja.
  • Lisää ja jaa uudelleen kapasiteettia ja kuormia ilman seisokkeja.

Päätäisin, että jos sinun ei tarvitse tarjota korkeaa vikasietokykyä, klusteriin siirtyminen ei ole sen arvoista, koska se voi olla ei-triviaali tehtävä. Mutta jos valitset aluksi erillisen version ja klusteriversion välillä, sinun tulee valita klusteri, koska se ei ole pahempi ja lisäksi se vapauttaa sinut päänsärkyistä

Valmistautuminen liikkumaan

Aloitetaan muuton vaatimuksista:

• Sen pitäisi olla saumaton. Palvelun täydellinen keskeytys 5 minuutiksi ei sovi meille.
• Sen tulee olla mahdollisimman turvallista ja asteittaista. Haluan hallita tilannetta. Emme halua hylätä kaikkea kerralla ja rukoilla palautuspainiketta.
• Minimaalinen tietojen menetys siirron aikana. Ymmärrämme, että atomien siirtäminen on erittäin vaikeaa, joten sallimme jonkin verran tietojen synkronointia tavallisessa ja klusteroidussa Redisissä.

Klusterin ylläpito

Juuri ennen muuttoa kannattaa miettiä, voimmeko tukea klusteria:

• Kaaviot. Käytämme Prometheusta ja Grafanaa CPU-kuormituksen, muistin käytön, asiakkaiden lukumäärän, GET-, SET-, AUTH-toimintojen jne. määrän kuvaamiseen.
• Asiantuntemus. Kuvittele, että huomenna sinulla on vastuullasi valtava klusteri. Jos se hajoaa, sitä ei voi korjata kukaan muu kuin sinä. Jos hän alkaa hidastaa vauhtia, kaikki juoksevat sinua kohti. Jos sinun on lisättävä resursseja tai jaettava kuorma uudelleen, palaa takaisin. Jotta ei harmaantuisi 25-vuotiaana, on suositeltavaa varata nämä tapaukset ja tarkistaa etukäteen, kuinka tekniikka käyttäytyy tietyissä toimissa. Puhutaanpa tästä tarkemmin "Asiantuntemus"-osiossa.
• Valvonta ja hälytykset. Kun klusteri hajoaa, haluat tietää siitä ensimmäisenä. Tässä rajoittuimme ilmoitukseen, että kaikki solmut palauttavat saman tiedon klusterin tilasta (kyllä, se tapahtuu eri tavalla). Ja muut ongelmat voidaan havaita nopeammin Redis-asiakaspalveluiden hälytyksellä.

ylitys

Miten liikumme:

• Ensinnäkin sinun on valmisteltava kirjasto työskentelemään klusterin kanssa. Otimme go-rediksen pohjaksi Go-versiolle ja muutimme sitä hieman itsellemme sopivaksi. Otimme Multi-menetelmät käyttöön putkien kautta ja korjasimme myös hieman toistuvien pyyntöjen sääntöjä. PHP-versiossa oli enemmän ongelmia, mutta lopulta päädyimme php-redisiin. He ottivat äskettäin käyttöön klusterituen, ja se näyttää mielestämme hyvältä.
• Seuraavaksi sinun on otettava käyttöön itse klusteri. Tämä tehdään kirjaimellisesti kahdella komennolla, jotka perustuvat asetustiedostoon. Keskustelemme asetuksista tarkemmin alla.
• Asteittaiseen siirtoon käytämme kuivaustilaa. Koska meillä on kaksi versiota kirjastosta, joissa on sama käyttöliittymä (yksi tavalliselle versiolle, toinen klusterille), ei maksa mitään sellaisen kääreen luominen, joka toimii erillisen version kanssa ja kopioi samanaikaisesti kaikki klusterin pyynnöt, vertailla vastauksia ja kirjoittaa eroja lokeihin (tapauksessamme NewRelicissä). Näin ollen, vaikka klusteriversio hajoaisi käyttöönoton aikana, se ei vaikuta tuotantoomme.
• Kun klusteri on otettu käyttöön kuivassa tilassa, voimme rauhallisesti katsoa vasteerojen kaaviota. Jos virheprosentti liikkuu hitaasti mutta varmasti kohti jotain pientä vakiota, niin kaikki on hyvin. Miksi eroja on edelleen? Koska erilliseen versioon tallentaminen tapahtuu hieman aikaisemmin kuin klusterissa ja mikroviiveen vuoksi tiedot voivat poiketa toisistaan. Jäljelle jää vain katsoa poikkeamalokeja, ja jos ne kaikki selitetään tietueen ei-atomisuudella, voimme siirtyä eteenpäin.
• Nyt voit vaihtaa kuivaustilan vastakkaiseen suuntaan. Kirjoitamme ja luemme klusterista ja kopioimme sen erilliseksi versioksi. Minkä vuoksi? Ensi viikolla haluan seurata klusterin työtä. Jos yhtäkkiä ilmenee, että huippukuormituksessa on ongelmia tai emme ole ottaneet jotain huomioon, meillä on aina hätäpalautus vanhaan koodiin ja nykyisiin tietoihin kuivaustilan ansiosta.
• Jäljelle jää vain poistaa kuivaustila käytöstä ja purkaa erillinen versio.

tutkimus

Ensinnäkin lyhyesti klusterin suunnittelusta.

Ensinnäkin Redis on avainarvokauppa. Avaimina käytetään mielivaltaisia ​​merkkijonoja. Arvoina voidaan käyttää numeroita, merkkijonoja ja kokonaisia ​​rakenteita. Jälkimmäisiä on paljon, mutta yleisen rakenteen ymmärtämiseksi tämä ei ole meille tärkeää.
Seuraava abstraktiotaso avainten jälkeen on slotit (SLOTS). Jokainen avain kuuluu yhteen 16 383 paikasta. Jokaisen paikan sisällä voi olla mikä tahansa määrä avaimia. Siten kaikki avaimet on jaettu 16 383 erilliseen joukkoon.

Seuraavaksi klusterissa täytyy olla N pääsolmua. Jokaista solmua voidaan pitää erillisenä Redis-esiintymänä, joka tietää kaiken muista klusterin solmuista. Jokainen pääsolmu sisältää joukon aikavälejä. Jokainen paikka kuuluu vain yhdelle pääsolmulle. Kaikki paikat on jaettava solmujen kesken. Jos joitain paikkoja ei ole varattu, niihin tallennettuihin avaimiin ei päästä. On järkevää ajaa jokainen pääsolmu erillisessä loogisessa tai fyysisessä koneessa. On myös syytä muistaa, että jokainen solmu toimii vain yhdessä ytimessä, ja jos haluat ajaa useita Redis-esiintymiä samassa loogisessa koneessa, varmista, että ne toimivat eri ytimissä (emme ole kokeilleet tätä, mutta teoriassa sen pitäisi toimia) . Pohjimmiltaan pääsolmut tarjoavat säännöllistä jakoa, ja useammat pääsolmut mahdollistavat kirjoitus- ja lukupyyntöjen skaalaamisen.

Kun kaikki avaimet on jaettu aikavälien kesken ja aikavälit on hajallaan isäntäsolmujen kesken, jokaiseen pääsolmuun voidaan lisätä mielivaltainen määrä orjasolmuja. Jokaisessa tällaisessa master-slave-linkissä normaali replikointi toimii. Slave-laitteita tarvitaan lukupyyntöjen skaalaamiseen ja vikasietotilaan isäntävian sattuessa.

Puhutaan nyt operaatioista, joita olisi parempi pystyä tekemään.

Pääsemme järjestelmään Redis-CLI:n kautta. Koska Redisillä ei ole yhtä sisääntulopistettä, voit suorittaa seuraavat toiminnot mille tahansa solmulle. Jokaisessa kohdassa kiinnitän erikseen huomion mahdollisuuteen suorittaa toimenpide kuormitettuna.

• Ensimmäinen ja tärkein asia, jonka tarvitsemme, on klusterisolmujen toiminta. Se palauttaa klusterin tilan, näyttää luettelon solmuista, niiden rooleista, paikkajakaumasta jne. Lisätietoja saa klusteritiedoista ja klusteripaikoista.
• Olisi mukavaa pystyä lisäämään ja poistamaan solmuja. Tätä tarkoitusta varten on olemassa klusterin kohtaaminen ja klusterin unohtaminen. Huomaa, että klusterin unohtamista on sovellettava JOKAiseen solmuun, sekä isäntäkoneisiin että replikoihin. Ja klusteritapaaminen tarvitsee kutsua vain yhdessä solmussa. Tämä ero voi olla hämmentävä, joten on parasta ottaa selvää siitä ennen kuin aloitat klusterin kanssa. Solmun lisääminen tapahtuu turvallisesti taistelussa, eikä se vaikuta klusterin toimintaan millään tavalla (mikä on loogista). Jos aiot poistaa solmun klusterista, varmista, että siinä ei ole paikkoja jäljellä (muuten voit menettää pääsyn kaikkiin tämän solmun avaimiin). Älä myöskään poista isäntäkonetta, jolla on orjia, muuten suoritetaan tarpeeton äänestys uudelle isännälle. Jos solmuissa ei enää ole paikkoja, tämä on pieni ongelma, mutta miksi tarvitsemme ylimääräisiä valintoja, jos voimme poistaa orjat ensin.
• Jos sinun on vaihdettava väkisin isäntä- ja orja-asemaa, klusterin vikasietokomento tekee sen. Kun soitat sitä taistelussa, sinun on ymmärrettävä, että mestari ei ole käytettävissä operaation aikana. Tyypillisesti vaihto tapahtuu alle sekunnissa, mutta se ei ole atominen. Voit odottaa, että jotkin isännälle lähetetyt pyynnöt epäonnistuvat tänä aikana.
• Ennen kuin poistat solmun klusterista, siinä ei saa olla paikkoja jäljellä. On parempi jakaa ne uudelleen käyttämällä cluster reshard -komentoa. Slotit siirretään masterilta toiselle. Koko toiminta voi kestää useita minuutteja, riippuu siirrettävän tiedon määrästä, mutta siirtoprosessi on turvallinen eikä vaikuta klusterin toimintaan millään tavalla. Siten kaikki tiedot voidaan siirtää solmusta toiseen suoraan kuormitettuna ja huolehtimatta sen saatavuudesta. Siinä on kuitenkin myös hienouksia. Ensinnäkin tiedonsiirtoon liittyy tietty kuormitus vastaanottajan ja lähettäjän solmuille. Jos vastaanottajasolmu on jo raskaasti kuormitettu prosessoriin, sinun ei pitäisi ladata sitä vastaanottamalla uusia tietoja. Toiseksi, heti kun lähettävässä isännässä ei ole yhtään aikaväliä jäljellä, kaikki sen orjat siirtyvät välittömästi isännälle, jolle nämä aikavälit siirrettiin. Ja ongelma on, että kaikki nämä orjat haluavat synkronoida tiedot kerralla. Ja olet onnekas, jos se on pikemminkin osittainen kuin täydellinen synkronointi. Ota tämä huomioon ja yhdistä aikavälien siirto ja orjien poistaminen käytöstä/siirtäminen. Tai toivoa, että sinulla on riittävä turvamarginaali.
• Mitä sinun tulee tehdä, jos huomaat siirron aikana, että olet kadottanut kolikkopelisi jonnekin? Toivottavasti tämä ongelma ei koske sinua, mutta jos vaikuttaa, on olemassa klusterin korjaustoiminto. Ainakin hän hajottaa paikat solmujen poikki satunnaisessa järjestyksessä. Suosittelen sen toiminnan tarkistamista poistamalla ensin solmu, jossa on hajautetut paikat klusterista. Koska jakamattomissa paikoissa olevat tiedot eivät ole jo saatavilla, on liian myöhäistä huolehtia näiden paikkojen saatavuuteen liittyvistä ongelmista. Toiminto ei puolestaan ​​vaikuta hajautettuihin lähtöihin.
• Toinen hyödyllinen toiminto on monitori. Sen avulla voit nähdä reaaliajassa koko luettelon solmulle tulevista pyynnöistä. Lisäksi voit grep sen ja selvittää, onko siellä tarvittavaa liikennettä.

On myös syytä mainita päävirheenvaihtomenettely. Lyhyesti sanottuna se on olemassa, ja mielestäni se toimii loistavasti. Älä kuitenkaan ajattele, että jos irrotat virtajohdon koneesta, jossa on pääsolmu, Redis vaihtaa välittömästi eivätkä asiakkaat huomaa menetystä. Käytännössäni vaihto tapahtuu muutamassa sekunnissa. Tänä aikana osa tiedoista on poissa käytöstä: isäntäkoneen epäkäytettävyys havaitaan, solmut äänestävät uuden puolesta, orjia vaihdetaan, tiedot synkronoidaan. Paras tapa varmistaa itse, että järjestelmä toimii, on suorittaa paikallisia harjoituksia. Nosta kannettavan tietokoneen klusteria, anna sille minimikuormitus, simuloi kaatuminen (esimerkiksi estämällä portit) ja arvioi kytkentänopeus. Mielestäni vasta päivän tai parin tällä tavalla pelattuasi voit luottaa tekniikan toimintaan. No, tai toivoa, että ohjelmisto, jota puolet Internetistä käyttää, todennäköisesti toimii.

kokoonpano

Usein konfigurointi on ensimmäinen asia, joka sinun täytyy aloittaa työskentely työkalun kanssa. Ja kun kaikki toimii, et halua edes koskea konfiguraatioon. Vaatii hieman vaivaa pakottaaksesi itsesi palaamaan asetuksiin ja käymään ne huolellisesti läpi. Muistaakseni meillä oli ainakin kaksi vakavaa vikaa, jotka johtuivat kokoonpanon huomioimattomuudesta. Kiinnitä erityistä huomiota seuraaviin kohtiin:

• timeout 0
  Aika, jonka jälkeen ei-aktiiviset yhteydet suljetaan (sekunteina). 0 - älä sulje
  Kaikki kirjastomme eivät pystyneet sulkemaan yhteyksiä oikein. Jos poistat tämän asetuksen käytöstä, uhkaamme saavuttaa asiakasmäärän rajan. Toisaalta, jos tällainen ongelma on olemassa, katkenneiden yhteyksien automaattinen lopettaminen peittää sen, emmekä välttämättä huomaa. Älä myöskään ota tätä asetusta käyttöön, kun käytät jatkuvia yhteyksiä.
• Tallenna xy ja liitä vain kyllä
  RDB-tilanteen tallentaminen.
  Keskustelemme RDB/AOF-ongelmista yksityiskohtaisesti alla.
• stop-writes-on-bgsave-error ei & slave-serve-stale-data kyllä
  Jos tämä on käytössä, jos RDB-vedos katkeaa, isäntä lopettaa muutospyyntöjen hyväksymisen. Jos yhteys isäntään katkeaa, orja voi jatkaa pyyntöihin vastaamista (kyllä). Tai lakkaa vastaamasta (ei)
  Emme ole tyytyväisiä tilanteeseen, jossa Redis muuttuu kurpitsaksi.
• repl-ping-slave-jakso 5
  Tämän ajanjakson jälkeen alamme huolestua siitä, että isäntä on rikki ja on aika suorittaa vikasietoprosessi.
  Sinun on löydettävä manuaalisesti tasapaino väärien positiivisten tulosten ja vikasietotilan käynnistämisen välillä. Käytännössämme tämä on 5 sekuntia.
• repl-backlog-size 1024mb & epl-backlog-ttl 0
  Voimme tallentaa täsmälleen näin paljon dataa epäonnistuneen replikan puskuriin. Jos puskuri loppuu, sinun on synkronoitava kokonaan.
  Käytäntö ehdottaa, että on parempi asettaa suurempi arvo. On monia syitä, miksi replika voi alkaa viivästyä. Jos se viivästyy, isäntälläsi on todennäköisesti jo vaikeuksia selviytyä, ja täydellinen synkronointi on viimeinen pisara.
• max asiakkaita 10000
  Kertaasiakkaiden enimmäismäärä.
  Kokemuksemme mukaan on parempi asettaa suurempi arvo. Redis käsittelee 10k yhteyttä hienosti. Varmista vain, että järjestelmässä on tarpeeksi pistorasioita.
• maxmemory-policy volatile-ttl
  Sääntö, jonka mukaan avaimet poistetaan, kun käytettävissä olevan muistin raja saavutetaan.
  Tässä ei ole tärkeää itse sääntö, vaan sen ymmärtäminen, kuinka tämä tapahtuu. Redistä voi kehua sen kyvystä toimia normaalisti, kun muistiraja saavutetaan.

RDB- ja AOF-ongelmat

Vaikka Redis itse tallentaa kaikki tiedot RAM-muistiin, siellä on myös mekanismi tietojen tallentamiseksi levylle. Tarkemmin sanottuna kolme mekanismia:

• RDB-snapshot - täydellinen tilannekuva kaikista tiedoista. Aseta käyttämällä SAVE XY -kokoonpanoa ja lukee "Tallenna täydellinen tilannekuva kaikista tiedoista X sekunnin välein, jos vähintään Y-avain on muuttunut."
• Vain liitetiedosto - luettelo toiminnoista niiden suoritusjärjestyksessä. Lisää uusia saapuvia operaatioita tiedostoon joka X sekunti tai joka Y-toiminto.
• RDB ja AOF ovat kahden edellisen yhdistelmä.

Kaikilla menetelmillä on hyvät ja huonot puolensa, en luettele niitä kaikkia, kiinnitän vain huomion kohtiin, jotka eivät mielestäni ole ilmeisiä.

Ensinnäkin RDB-tilanteen tallentaminen edellyttää FORKin kutsumista. Jos dataa on paljon, tämä voi jumittaa koko Rediksen muutamasta millisekunnista sekuntiin. Lisäksi järjestelmän on varattava muistia tällaista tilannekuvaa varten, mikä johtaa tarpeeseen pitää loogisessa koneessa kaksinkertainen RAM-muisti: jos Redikselle on varattu 8 Gt, virtuaalikoneessa pitäisi olla 16 Gt. se.

Toiseksi osittaisessa synkronoinnissa on ongelmia. AOF-tilassa, kun orja on yhdistetty uudelleen, osittaisen synkronoinnin sijaan voidaan suorittaa täydellinen synkronointi. Miksi näin tapahtuu, en voinut ymmärtää. Mutta tämä kannattaa muistaa.

Nämä kaksi kohtaa saavat meidät jo miettimään, tarvitsemmeko todella näitä tietoja levylle, jos kaikki on jo kopioitu orjien toimesta. Tiedot voidaan menettää vain, jos kaikki orjat epäonnistuvat, ja tämä on "fire in the DC" -tason ongelma. Kompromissina voit ehdottaa tietojen tallentamista vain orjille, mutta tässä tapauksessa sinun on varmistettava, että näistä orjista ei koskaan tule isäntiä katastrofipalautuksen aikana (tätä varten heidän asetuksissaan on orjaprioriteettiasetus). Itsellemme kussakin tapauksessa ajattelemme, onko tarpeen tallentaa tiedot levylle, ja useimmiten vastaus on "ei".

Johtopäätös

Lopuksi toivon, että pystyin antamaan yleiskäsityksen siitä, kuinka redis-klusteri toimii niille, jotka eivät ole kuulleet siitä ollenkaan, ja kiinnitin myös huomiota joihinkin epäselviin kohtiin niille, jotka ovat käyttäneet sitä. pitkään aikaan.
Kiitos ajastasi ja kuten aina, kommentit aiheesta ovat tervetulleita.

Lähde: will.com