Он жылдан астам уақыт бойы дамып келе жатқан өнімге келетін болсақ, онда ескірген технологияларды табу таңқаларлық емес. Бірақ алты ай ішінде жүктемені 10 есе жоғары ұстау керек болса, ал құлау құны жүздеген есе өсетін болса ше? Бұл жағдайда сізге жоғары жүктеме инженері қажет. Бірақ қызметші болмаған соң мәселені шешуді маған сеніп тапсырды. Мақаланың бірінші бөлімінде мен Redis-тен Redis-cluster-ге қалай көшкенімізді айтамын, ал екінші бөлімде кластерді пайдалануды қалай бастау керек және оны пайдалану кезінде не нәрсеге назар аудару керектігі туралы кеңес беремін.

Технологияны таңдау

Соншалықты жаман ба? бөлек Redis (оқшауланған redis) 1 негізгі және N бағыныңқы конфигурацияда ма? Неліктен мен оны ескірген технология деймін?

Жоқ, Редис онша жаман емес... Дегенмен, назардан тыс қалдыруға болмайтын кемшіліктер де бар.

• Біріншіден, Redis негізгі сәтсіздіктен кейін апатты қалпына келтіру механизмдерін қолдамайды. Бұл мәселені шешу үшін біз VIP-ті жаңа шеберге автоматты түрде беру, құлдардың біреуінің рөлін өзгерту және қалғандарын ауыстыру арқылы конфигурацияны қолдандық. Бұл механизм жұмыс істеді, бірақ оны сенімді шешім деп атауға болмайды. Біріншіден, жалған дабылдар пайда болды, екіншіден, ол бір реттік болды және жұмыс істегеннен кейін серіппені зарядтау үшін қолмен әрекеттер қажет болды.

• Екіншіден, бір ғана шебердің болуы сынық мәселесіне әкелді. Бізге «1 басты және N құл» бірнеше тәуелсіз кластерлерді құруға тура келді, содан кейін деректер қорын осы машиналар арасында қолмен таратып, ертең дерекқорлардың бірі соншалықты өспейді, оны бөлек данаға көшіру керек деп үміттенеміз.

Опциялар қандай?

• Ең қымбат және ең бай шешім - Redis-Enterprise. Бұл толық техникалық қолдауы бар қорапты шешім. Техникалық тұрғыдан идеалды болып көрінгенімен, идеологиялық себептерге байланысты бізге сәйкес келмеді.
• Redis-кластер. Қораптың сыртында негізгі ауыстырып қосуға және үзіндіге қолдау бар. Интерфейс әдеттегі нұсқадан дерлік айырмашылығы жоқ. Бұл перспективалы болып көрінеді, біз тұзақтар туралы кейінірек айтатын боламыз.
• Tarantool, Memcache, Aerospike және т.б. Бұл құралдардың барлығы дерлік бірдей нәрсені жасайды. Бірақ әрқайсысының өз кемшіліктері бар. Біз барлық жұмыртқаларды бір себетке салмауды шештік. Біз Memcache және Tarantool-ті басқа тапсырмалар үшін қолданамыз, және болашаққа қарап, біздің тәжірибемізде олармен көбірек проблемалар болғанын айтамын.

Қолдану ерекшеліктері

Redis-пен тарихи түрде қандай мәселелерді шешкенімізді және қандай функционалдылықты пайдаланғанымызды қарастырайық:

• 2GIS | сияқты қашықтағы қызметтерге сұраулар алдында кэш Голанг
  

  ОРНАТУ MGET MSET "ДБ таңдау"

• MYSQL | алдындағы кэш PHP
  

  ОРНАТУ MGET MSET SCAN "КЕРНЕ БОЙЫНША ӨЛГЕН" "ДБ ТАҢДАУ"

• Сеанстармен және драйвер координаталарымен жұмыс істеуге арналған негізгі жады | Голанг
  

  ОРНАТУ MGET MSET "ДБ ТАҢДАУ" "ГЕО КІЛТІ ҚОСУ" "ГЕО КІЛТПЕН АЛУ" СКАНА АЛУ

Көріп отырғаныңыздай, жоғары математика жоқ. Сонда қиындық неде? Әрбір әдісті бөлек қарастырайық.

Әдіс
сипаттамасы
Redis кластерінің мүмкіндіктері
шешім

ОРНАТУ
Жазу/оқу кілті

MGET MSET
Бірнеше пернелерді жазу/оқу
Кілттер әртүрлі түйіндерде болады. Дайын кітапханалар тек бір түйіннің ішінде көп операцияларды орындай алады
MGET-ті N GET операцияларының конвейерімен ауыстырыңыз

ДҚ ТАҢДАУ
Біз жұмыс істейтін негізді таңдаңыз
Бірнеше дерекқорды қолдамайды
Барлығын бір дерекқорға салыңыз. Пернелерге префикстерді қосыңыз

SCAN
Дерекқордағы барлық кілттерді өтіңіз
Бізде бір дерекқор болғандықтан, кластердегі барлық кілттерден өту тым қымбат
Бір кілт ішінде инвариантты сақтаңыз және осы кілтте HSCAN жасаңыз. Немесе мүлдем бас тарту

GEO
Геокейтпен операциялар
Геокейд бөлінбеген

ӨЛГІСІ БОЙЫНША КЕРСЕ
Үлгі бойынша кілт іздеу
Бізде бір дерекқор болғандықтан, біз кластердегі барлық кілттерді іздейміз. Өте қымбат
SCAN жағдайындағыдай инварианттан бас тартыңыз немесе сақтаңыз

Redis және Redis кластері

Кластерге ауысқанда не ұтамыз және не ұтамыз?

• Кемшіліктері: біз бірнеше мәліметтер базасының функционалдығын жоғалтамыз.
  • Егер біз логикалық байланысы жоқ деректерді бір кластерде сақтағымыз келсе, біз префикстер түрінде балдақтарды жасауымыз керек.
  • Біз SCAN, DBSIZE, CLEAR DB және т.б. сияқты барлық «негізгі» операцияларды жоғалтамыз.
  • Көп операцияларды орындау әлдеқайда қиын болды, себебі ол бірнеше түйіндерге кіруді қажет етуі мүмкін.
• Тұтастай алғанда:
  • Негізгі ақаулық түріндегі ақауларға төзімділік.
  • Редис жағында бөлшектеу.
  • Деректерді түйіндер арасында атомдық түрде және тоқтаусыз тасымалдау.
  • Сыйымдылықты және жүктемелерді тоқтаусыз қосу және қайта бөлу.

Мен ақауларға төзімділіктің жоғары деңгейін қамтамасыз етудің қажеті болмаса, кластерге көшудің қажеті жоқ деп қорытындылаймын, өйткені бұл тривиальды емес тапсырма болуы мүмкін. Бірақ егер сіз бастапқыда бөлек нұсқа мен кластер нұсқасын таңдасаңыз, онда кластерді таңдауыңыз керек, өйткені бұл одан да жаман емес және сонымен қатар сізді кейбір бас ауруларынан босатады.

Көшіруге дайындық

Қозғалысқа қойылатын талаптардан бастайық:

• Ол біркелкі болуы керек. Қызметті 5 минутқа толық тоқтату бізге сәйкес келмейді.
• Ол мүмкіндігінше қауіпсіз және біртіндеп болуы керек. Мен жағдайды бақылауға алғым келеді. Біз бәрін бірден тастап, кері қайтару түймесін басып дұға еткіміз келмейді.
• Жылжыту кезінде деректердің минималды жоғалуы. Біз атомдық түрде жылжыту өте қиын болатынын түсінеміз, сондықтан біз әдеттегі және кластерленген Redis ішіндегі деректер арасында кейбір десинхронизацияға рұқсат етеміз.

Кластерге техникалық қызмет көрсету

Жылжымас бұрын, біз кластерді қолдауға болатындығы туралы ойлануымыз керек:

• Диаграммалар. Біз Prometheus және Grafana бағдарламаларын CPU жүктемесін, жадты пайдалануды, клиенттер санын, GET, SET, AUTH операцияларының санын және т.б.
• Сараптама. Елестетіп көріңізші, ертең сіздің жауапкершілігіңізде үлкен кластер болады. Егер ол бұзылса, оны сізден басқа ешкім жөндей алмайды. Егер ол баяулай бастаса, бәрі сізге қарай жүгіреді. Ресурстарды қосу немесе жүктемені қайта бөлу қажет болса, сізге қайта оралыңыз. 25 жаста сұр түспеу үшін осы жағдайларды қарастырып, белгілі бір әрекеттер кезінде технологияның қалай әрекет ететінін алдын ала тексерген жөн. Бұл туралы «Сараптама» бөлімінде толығырақ сөйлесейік.
• Бақылау және ескертулер. Кластер бұзылған кезде ол туралы бірінші болып білгіңіз келеді. Мұнда біз барлық түйіндер кластердің күйі туралы бірдей ақпаратты қайтаратыны туралы хабарландырумен шектелдік (иә, ол басқаша болады). Басқа мәселелерді Redis клиенттік қызметтерінің ескертулері арқылы тезірек байқауға болады.

Жылжыту

Біз қалай қозғаламыз:

• Ең алдымен кластермен жұмыс істеу үшін кітапхананы дайындау керек. Біз Go нұсқасына негіз ретінде go-redis алдық және оны өзімізге ыңғайлы етіп аздап өзгерттік. Біз құбырлар арқылы мульти-әдістерді енгіздік, сонымен қатар сұрауларды қайталау ережелерін аздап түзеттік. PHP нұсқасында көп мәселелер болды, бірақ біз ақырында php-redis-ге көштік. Олар жақында кластерлік қолдауды енгізді және бұл біздің ойымызша жақсы көрінеді.
• Әрі қарай кластердің өзін орналастыру керек. Бұл конфигурация файлына негізделген екі пәрменде орындалады. Төменде біз параметрді толығырақ қарастырамыз.
• Біртіндеп жылжыту үшін біз құрғақ режимді қолданамыз. Бізде бірдей интерфейсі бар кітапхананың екі нұсқасы (біреуі кәдімгі нұсқа үшін, екіншісі кластер үшін) болғандықтан, бөлек нұсқамен жұмыс істейтін және кластерге барлық сұрауларды параллельді қайталайтын қаптаманы жасау еш шығынсыз, жауаптарды салыстыру және журналдарға сәйкессіздіктерді жазу (біздің жағдайда NewRelic-те). Осылайша, шығару кезінде кластер нұсқасы бұзылса да, біздің өндірісімізге әсер етпейді.
• Кластерді құрғақ режимде шығара отырып, біз жауап қайшылықтарының графигіне тыныштықпен қарай аламыз. Егер қате деңгейі баяу, бірақ сенімді түрде кейбір шағын тұрақтыға қарай жылжитын болса, онда бәрі жақсы. Неліктен әлі де сәйкессіздіктер бар? Бөлек нұсқада жазу кластерге қарағанда сәл ертерек орын алатындықтан және микролагқа байланысты деректер әртүрлі болуы мүмкін. Бар болғаны сәйкессіздік журналдарын қарау ғана қалады, егер олардың барлығы жазбаның атомдық еместігімен түсіндірілсе, онда біз әрі қарай жүре аламыз.
• Енді сіз құрғақ режимді қарама-қарсы бағытта ауыстыра аласыз. Кластерден жазамыз және оқимыз және оны бөлек нұсқаға көшіреміз. Не үшін? Келесі аптада мен кластердің жұмысын бақылаймын. Егер кенеттен ең жоғары жүктеме кезінде проблемалар туындаса немесе біз бірдеңені ескермеген болсақ, құрғақ режимнің арқасында бізде әрқашан ескі кодқа және ағымдағы деректерге төтенше жағдайда қайтару мүмкіндігі бар.
• Құрғақ режимді өшіру және бөлек нұсқаны бөлшектеу ғана қалады.

Сараптама

Біріншіден, кластер дизайны туралы қысқаша.

Біріншіден, Redis - бұл негізгі құндылық дүкені. Кілттер ретінде ерікті жолдар пайдаланылады. Мәндер ретінде сандарды, жолдарды және тұтас құрылымдарды пайдалануға болады. Соңғылары өте көп, бірақ жалпы құрылымды түсіну үшін бұл біз үшін маңызды емес.
Кілттерден кейінгі абстракцияның келесі деңгейі - ұялар (SLOTS). Әрбір кілт 16 383 слоттың біріне жатады. Әрбір ұяшықта кілттердің кез келген саны болуы мүмкін. Осылайша, барлық кілттер 16 383 ажыратылған жиынтыққа бөлінеді.

Содан кейін кластерде N негізгі түйін болуы керек. Әрбір түйінді кластердегі басқа түйіндер туралы бәрін білетін жеке Redis данасы ретінде қарастыруға болады. Әрбір негізгі түйінде бірнеше ұяшықтар бар. Әрбір ұяшық бір ғана негізгі түйінге жатады. Барлық ұяшықтарды түйіндер арасында бөлу керек. Егер кейбір слоттар бөлінбесе, онда оларда сақталған кілттерге қол жетімсіз болады. Әрбір негізгі түйінді жеке логикалық немесе физикалық машинада іске қосу мағынасы бар. Әрбір түйін тек бір ядрода жұмыс істейтінін және бір логикалық машинада бірнеше Redis данасын іске қосқыңыз келсе, олардың әртүрлі ядроларда жұмыс істейтініне көз жеткізіңіз (біз мұны көрмедік, бірақ теориялық тұрғыдан ол жұмыс істеуі керек) . Негізінде, негізгі түйіндер тұрақты бөлуді қамтамасыз етеді және көбірек негізгі түйіндер жазу және оқу сұрауларын масштабтауға мүмкіндік береді.

Барлық кілттер слоттар арасында бөлінгеннен кейін және ұялар негізгі түйіндер арасында шашыраңқы болғаннан кейін әрбір негізгі түйінге бағынышты түйіндердің ерікті санын қосуға болады. Әрбір осындай басты-құлдық сілтемеде қалыпты репликация жұмыс істейді. Бағыттар оқу сұрауларын масштабтау үшін және негізгі сәтсіздік жағдайында ауыстырып қосу үшін қажет.

Енді жасай алатын жақсырақ болатын операцияларға тоқталайық.

Біз жүйеге Redis-CLI арқылы қол жеткіземіз. Redis жүйесінде бір кіру нүктесі болмағандықтан, кез келген түйінде келесі әрекеттерді орындауға болады. Әр нүктеде мен операцияны жүктеме кезінде орындау мүмкіндігіне жеке назар аударамын.

• Бізге қажет бірінші және ең маңызды нәрсе - кластер түйіндерінің жұмысы. Ол кластердің күйін қайтарады, түйіндер тізімін, олардың рөлдерін, ұяшықтарды бөлуді және т.б. көрсетеді. Қосымша ақпаратты кластер ақпараты мен кластер слоттары арқылы алуға болады.
• Түйіндерді қосу және жою мүмкіндігі болса жақсы болар еді. Осы мақсатта кластерді кездестіру және кластерді ұмыту операциялары бар. Кластерді ұмыту ӘР түйінге, шеберлерге де, көшірмелерге де қолданылуы керек екенін ескеріңіз. Ал кластер кездесуін тек бір түйінде шақыру қажет. Бұл айырмашылық алаңдатуы мүмкін, сондықтан кластермен тікелей эфирге шықпас бұрын бұл туралы біліп алған дұрыс. Түйінді қосу шайқаста қауіпсіз орындалады және кластердің жұмысына ешқандай әсер етпейді (бұл логикалық). Егер сіз түйінді кластерден алып тастағыңыз келсе, онда ешқандай слоттар қалмағанына көз жеткізіңіз (әйтпесе осы түйіндегі барлық кілттерге қол жеткізуді жоғалту қаупі бар). Сондай-ақ, құлдары бар шеберді жоймаңыз, әйтпесе жаңа қожайынға қажетсіз дауыс беріледі. Егер түйіндерде бұдан былай слоттар болмаса, онда бұл кішкентай мәселе, бірақ алдымен құлдарды жоя алатын болсақ, бізге қосымша таңдаулар не үшін қажет.
• Басты және бағынышты орындарды күшпен ауыстыру қажет болса, кластерді ауыстырып қосу пәрмені орындалады. Оны шайқаста шақырған кезде, шебердің операция кезінде қол жетімді болмайтынын түсіну керек. Әдетте коммутатор секундтан аз уақыт ішінде пайда болады, бірақ атомдық емес. Осы уақыт ішінде шеберге кейбір сұраулар сәтсіз болады деп күтуге болады.
• Кластерден түйінді алып тастамас бұрын, онда ұяшықтар қалмауы керек. Оларды кластерді қайта бөлу пәрмені арқылы қайта таратқан дұрыс. Слоттар бір шеберден екіншісіне ауыстырылады. Бүкіл операция бірнеше минутқа созылуы мүмкін, ол тасымалданатын деректер көлеміне байланысты, бірақ тасымалдау процесі қауіпсіз және кластердің жұмысына ешқандай әсер етпейді. Осылайша, барлық деректерді бір түйіннен екіншісіне тікелей жүктеме кезінде және оның қолжетімділігі туралы алаңдамай жіберуге болады. Дегенмен, нәзіктіктер де бар. Біріншіден, деректерді беру қабылдаушы мен жіберуші түйіндеріне белгілі бір жүктемемен байланысты. Егер алушы түйіні процессорға әлдеқашан қатты жүктелген болса, оны жаңа деректерді қабылдаумен жүктемеу керек. Екіншіден, жіберуші шеберде бірде-бір ұяшық қалмағанда, оның барлық құлдары дереу осы ұялар тасымалданған шеберге барады. Мәселе мынада, бұл құлдардың барлығы деректерді бірден синхрондауды қалайды. Толық синхрондау емес, ішінара болса, сіз бақытты боласыз. Осыны ескеріп, ұяшықтарды тасымалдау және бағындыларды өшіру/тасымалдау операцияларын біріктіріңіз. Немесе сізде жеткілікті қауіпсіздік шегі бар деп үміттеніңіз.
• Тасымалдау кезінде слоттарыңызды бір жерде жоғалтып алғаныңызды байқасаңыз, не істеу керек? Бұл мәселе сізге әсер етпейді деп үміттенемін, бірақ олай болса, кластерді түзету әрекеті бар. Кем дегенде, ол ұяшықтарды түйіндер бойынша кездейсоқ ретпен таратады. Алдымен кластерден бөлінген ұялары бар түйінді алып тастау арқылы оның жұмысын тексеруді ұсынамын. Бөлінбеген слоттардағы деректер қазірдің өзінде қолжетімсіз болғандықтан, бұл слоттардың қолжетімділігіне қатысты мәселелер туралы алаңдауға тым кеш. Өз кезегінде, операция бөлінген слоттарға әсер етпейді.
• Тағы бір пайдалы операция - монитор. Ол нақты уақыт режимінде түйінге түсетін сұраулардың толық тізімін көруге мүмкіндік береді. Сонымен қатар, сіз оны тексеріп, қажетті трафиктің бар-жоғын біле аласыз.

Сондай-ақ, негізгі ақаулық процедурасын атап өткен жөн. Қысқасы, ол бар және менің ойымша, ол керемет жұмыс істейді. Дегенмен, негізгі түйіні бар машинадағы қуат сымын ажыратсаңыз, Redis бірден ауысады және тұтынушылар жоғалғанын байқамайды деп ойламаңыз. Менің тәжірибемде ауысу бірнеше секундта орын алады. Осы уақыт ішінде кейбір деректер қолжетімсіз болады: шебердің қолжетімсіздігі анықталды, түйіндер жаңасына дауыс береді, бағыныштылар ауыстырылады, деректер синхрондалады. Схеманың жұмыс істеп тұрғанына көз жеткізудің ең жақсы жолы - жергілікті жаттығуларды өткізу. Ноутбукте кластерді көтеріңіз, оған ең аз жүктеме беріңіз, апатты модельдеңіз (мысалы, порттарды блоктау арқылы) және коммутация жылдамдығын бағалаңыз. Менің ойымша, бір-екі күн осылай ойнағаннан кейін ғана технологияның жұмысына сенімді бола аласыз. Немесе Интернеттің жартысы пайдаланатын бағдарламалық құрал жұмыс істейді деп үміттенеміз.

Конфигурация

Көбінесе конфигурация құралмен жұмыс істеуді бастау үшін қажет бірінші нәрсе және бәрі жұмыс істегенде, конфигурацияға қол тигізгіңіз де келмейді. Параметрлерге оралуға және оларды мұқият қарап шығуға күш салу үшін біраз күш қажет. Менің жадымда конфигурацияға назар аудармау салдарынан бізде кем дегенде екі маңызды сәтсіздік болды. Келесі тармақтарға ерекше назар аударыңыз:

• 0 күту уақыты
  Белсенді емес қосылымдар жабылатын уақыт (секундпен). 0 - жаппаңыз
  Біздің әрбір кітапхана байланыстарды дұрыс жауып тастай алмады. Бұл параметрді өшіру арқылы біз клиенттер санының шегіне жету қаупін тудырамыз. Екінші жағынан, егер мұндай мәселе болса, жоғалған қосылымдарды автоматты түрде тоқтату оны бүркемелейді және біз байқамауымыз мүмкін. Бұған қоса, тұрақты қосылымдарды пайдаланған кезде бұл параметрді қоспау керек.
• xy сақтаңыз және тек иә
  RDB суретін сақтау.
  Біз төменде RDB/AOF мәселелерін егжей-тегжейлі талқылаймыз.
• bgsave-қатесінде-жазуды тоқтату жоқ және slave-serve-stale-деректер иә
  Қосылған болса, RDB суреті үзілсе, шебер өзгерту сұрауларын қабылдауды тоқтатады. Мастермен байланыс үзілсе, бағынышты құрылғы сұрауларға жауап беруді жалғастыра алады (иә). Немесе жауап беруді тоқтатады (жоқ)
  Редистің асқабаққа айналуы бізді қуантпайды.
• repl-ping-slave-период 5
  Осы уақыт кезеңінен кейін біз шебер бұзылды деп алаңдай бастаймыз және істен шығу процедурасын орындау уақыты келді.
  Жалған позитивтер мен істен шығуды іске қосу арасындағы теңгерімді қолмен табу керек болады. Біздің тәжірибеде бұл 5 секунд.
• repl-backlog-өлшемі 1024mb & epl-backlog-ttl 0
  Біз дәл осыншама деректерді сәтсіз көшірме үшін буферде сақтай аламыз. Буфер бітсе, толық синхрондауға тура келеді.
  Тәжірибе көрсеткендей, жоғары мәнді орнату жақсы. Көшірменің кешігуінің көптеген себептері бар. Егер ол артта қалса, сіздің шеберіңіз қазірдің өзінде күресуге тырысады және толық синхрондау соңғы тамшы болады.
• maxclients 10000
  Бір реттік клиенттердің ең көп саны.
  Біздің тәжірибемізде жоғары мәнді қойған дұрыс. Redis 10к қосылымдарды жақсы өңдейді. Жүйеде жеткілікті розеткалар бар екеніне көз жеткізіңіз.
• maxmemory-policy volatile-ttl
  Қол жетімді жад шегіне жеткенде кілттер жойылатын ереже.
  Мұнда маңызды нәрсе ереженің өзі емес, оның қалай болатынын түсіну. Redis жад шегіне жеткенде оның қалыпты жұмыс істеу қабілеті үшін мақтауға болады.

RDB және AOF мәселелері

Redis өзі барлық ақпаратты жедел жадта сақтағанымен, деректерді дискіге сақтау механизмі де бар. Дәлірек айтқанда, үш механизм:

• RDB-snapshot – барлық деректердің толық суреті. SAVE XY конфигурациясын пайдаланып орнатыңыз және «Егер кем дегенде Y пернелері өзгерсе, әрбір X секунд сайын барлық деректердің толық суретін сақтаңыз» деп оқиды.
• Тек қосымша файл – орындалу реті бойынша операциялар тізімі. Файлға әр X секунд сайын немесе әрбір Y әрекеттерінде жаңа кіріс операцияларын қосады.
• RDB және AOF алдыңғы екеуінің тіркесімі болып табылады.

Барлық әдістердің өз артықшылықтары мен кемшіліктері бар, мен олардың барлығын тізімдемеймін, мен жай ғана, менің ойымша, айқын емес нүктелерге назар аударамын.

Біріншіден, RDB суретін сақтау FORK шақыруды қажет етеді. Егер деректер көп болса, бұл бірнеше миллисекунд пен секунд аралығындағы барлық Redis файлдарын іліп қоюы мүмкін. Сонымен қатар, жүйе мұндай суретке арналған жадты бөлуі керек, бұл логикалық машинада жедел жадтың қосарланған қорын сақтау қажеттілігіне әкеледі: егер Redis үшін 8 ГБ бөлінген болса, онда виртуалды машинада 16 ГБ қол жетімді болуы керек. ол.

Екіншіден, ішінара синхрондау проблемалары бар. AOF режимінде қосалқы қайта қосылғанда, ішінара синхрондаудың орнына толық синхрондауды орындауға болады. Неліктен бұлай болды, мен түсіне алмадым. Бірақ мұны есте ұстаған жөн.

Бұл екі нүкте қазірдің өзінде бәрі құлдармен қайталанатын болса, дискідегі бұл деректер бізге шынымен қажет пе деген ойға мәжбүр етеді. Деректер тек барлық құлдар сәтсіз болған жағдайда ғана жоғалуы мүмкін және бұл «тұрақты токтағы өрт» деңгейіндегі мәселе. Ымыра ретінде деректерді тек құлдарда сақтауды ұсына аласыз, бірақ бұл жағдайда апатты қалпына келтіру кезінде бұл құлдар ешқашан шебер болмайтынына көз жеткізуіңіз керек (бұл үшін олардың конфигурациясында құл басымдылығы параметрі бар). Өзіміз үшін әрбір нақты жағдайда деректерді дискіге сақтау қажет пе деп ойлаймыз және көбінесе жауап «жоқ».

қорытынды

Қорытындылай келе, мен бұл туралы мүлдем естімегендер үшін редис-кластердің қалай жұмыс істейтіні туралы жалпы түсінік бере алдым деп үміттенемін, сондай-ақ оны пайдаланатындар үшін кейбір анық емес тұстарға назар аудардым. узақ уақытқа.
Уақытыңыз үшін рақмет және әдеттегідей тақырып бойынша түсініктемелер қабылданады.

Ақпарат көзі: www.habr.com