Он жылдан ашык убакыттан бери өнүгүп келе жаткан буюмга келсек, анда эскирген технологияларды табуу таң калыштуу эмес. Ал эми алты айдын ичинде жүктү 10 эсе көп кармап турууга туура келсе, ал эми жыгылуунун баасы жүздөгөн эсеге көбөйүп кетсечи? Бул учурда, сизге сонун Highload инженери керек. Бирок үй кызматчысы жок болгондуктан маселени чечүүнү мага тапшырышты. Макаланын биринчи бөлүгүндө мен Redisтен Redis-clusterге кантип өткөнүбүздү айтып берем, ал эми экинчи бөлүгүндө кластерди кантип колдонууну баштоо жана аны колдонууда эмнелерге көңүл буруу керектиги боюнча кеңештерди берем.

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

Ушунчалык жаманбы? өзүнчө Redis (өз алдынча redis) 1 кожоюндун жана N кулдун конфигурациясындабы? Эмне үчүн мен аны эскирген технология деп атайм?

Жок, Редис анчалык деле жаман эмес... Бирок, көз жаздымда калтырууга болбой турган кемчиликтер да бар.

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

• Экинчиден, бир гана кожоюндун болушу сындыруу көйгөйүнө алып келди. Биз бир нече көз карандысыз кластерлерди түзүп, "1 мастер жана N кулдар" түзүшүбүз керек болчу, андан кийин маалымат базаларын бул машиналар арасында кол менен бөлүштүрүү жана эртең маалымат базаларынын бири ушунчалык чоңобой, аны өзүнчө инстанцияга жылдырууга туура келет деп үмүттөнөбүз.

Менин Бул эмнеге алып келет?

• Эң кымбат жана эң бай чечим бул Redis-Enterprise. Бул толук техникалык колдоо менен кутуча чечим болуп саналат. Техникалык жактан идеалдуу көрүнгөнү менен идеологиялык себептерден улам бизге туура келбеди.
• Redis-cluster. Кутудан тышкары, башкы иштебей калуу жана бөлүү үчүн колдоо бар. Интерфейси кадимки версиядан дээрлик айырмаланбайт. Бул келечектүү көрүнөт, тузактар ​​жөнүндө кийинчерээк сүйлөшөбүз.
• Tarantool, Memcache, Aerospike жана башкалар. Бул куралдардын баары дээрлик бирдей нерсени жасайт. Бирок ар биринин өзүнүн кемчиликтери бар. Бардык жумурткаларыбызды бир себетке салбайлы деп чечтик. Биз Memcache жана Tarantool'ду башка тапшырмалар үчүн колдонобуз жана алдыга карап, биздин практикада алар менен көйгөйлөр көп болгонун айтам.

Колдонуу өзгөчөлүктөрү

Келгиле, Redis менен тарыхый жактан кандай көйгөйлөрдү чечкенибизди жана кандай функцияларды колдонгонубузду карап көрөлү:

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

  GET SET MGET MSET "SELECT DB"

• MYSQLге чейинки кэш | PHP
  

  ОРНОТУУ MGET MSET SCAN "КЕРНЕТ БОЙЫНАН АЧКЫЧ" "МБ ТАНДОО"

• Сеанстар жана драйвер координаттары менен иштөө кызматы үчүн негизги сактагыч | Голанг
  

  ОРНОТУУ MGET MSET "МБны ТАНДОО" "ГЕО АЧКЫЧТЫ КОШУ" "ГЕО АЧКЫЧТЫ АЛУУ" Скандоо

Көрүнүп тургандай, жогорку математика жок. Анда эмне кыйынчылык? Келгиле, ар бир ыкманы өзүнчө карап көрөлү.

ыкма
баяндоо
Redis-cluster өзгөчөлүктөрү
чечим

ОРНАТУ
Жазуу/окуу ачкычы

MGET MSET
Бир нече баскычтарды жазыңыз/окуңуз
Ачкычтар ар кандай түйүндөрдө болот. Даяр китепканалар бир түйүн ичинде гана көп операцияларды аткара алат
MGETти N GET операцияларынын түтүгү менен алмаштырыңыз

ТАНДОО DB
Биз иштей турган базаны тандаңыз
Бир нече маалымат базасын колдобойт
Баарын бир маалымат базасына салыңыз. Баскычтарга префикстерди кошуңуз

скандоочу
Базадагы бардык ачкычтар аркылуу өтүңүз
Бизде бир маалымат базасы болгондуктан, кластердеги бардык ачкычтардан өтүү өтө кымбат
Бир ачкычтын ичинде инвариантты сактаңыз жана бул ачкычта HSCAN жасаңыз. Же толугу менен баш тартуу

GEO
Геокайк менен операциялар
Геокэй сынган эмес

ҮЛГӨ БОЮНЧА ачкыч
Үлгү боюнча ачкыч издөө
Бизде бир маалымат базасы болгондуктан, кластердеги бардык ачкычтарды издейбиз. Өтө кымбат
SCANдагыдай инварианттан баш тартыңыз же сактаңыз

Redis vs Redis-cluster

Кластерге өткөндө эмнени жоготуп, эмне утабыз?

• Кемчиликтери: биз бир нече маалымат базаларынын функционалдуулугун жоготобуз.
  • Эгерде биз логикалык жактан байланышпаган маалыматтарды бир кластерде сактагыбыз келсе, анда биз балдактарды префикс түрүндө жасашыбыз керек болот.
  • Биз 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тин бир да кирүү чекити жок болгондуктан, сиз каалаган түйүндөрдө төмөнкү операцияларды аткара аласыз. Ар бир пунктта мен өзүнчө жүк астында операцияны аткаруу мүмкүнчүлүгүнө көңүл бурам.

• Бизге керек болгон биринчи жана эң маанилүү нерсе - бул кластердик түйүндөрдүн иштеши. Ал кластердин абалын кайтарат, түйүндөрдүн тизмесин, алардын ролдорун, уячаларды бөлүштүрүү ж.б. көрсөтөт. Көбүрөөк маалыматты кластердик маалымат жана кластердик уячалар аркылуу алса болот.
• Түйүндөрдү кошуп, алып салсаңыз жакшы болмок. Бул үчүн кластердик жолугушуу жана кластерди унутуу операциялары бар. Кластерди унутуу АР БИР түйүнгө, мастерлерге да, репликага да колдонулушу керек экенин эске алыңыз. Ал эми кластердик жолугушууну бир түйүндө гана чакыруу керек. Бул айырмачылык тынчсыздандырышы мүмкүн, андыктан кластериңиз менен түз эфирге чыгаардан мурун бул тууралуу билип алганыңыз жакшы. Түйүн кошуу согушта коопсуз жасалат жана кластердин иштешине эч кандай таасир этпейт (бул логикалуу). Эгер сиз түйүндү кластерден алып салгыңыз келсе, анда анда уячалар калбагандыгын текшеришиңиз керек (антпесе бул түйүндөгү бардык баскычтарга кирүү мүмкүнчүлүгүн жоготуп алуу коркунучу бар). Ошондой эле, кулдары бар кожоюнду жок кылбаңыз, антпесе жаңы кожоюн үчүн керексиз добуш берилет. Эгерде түйүндөрдө уячалар жок болсо, анда бул кичинекей көйгөй, бирок адегенде кулдарды жок кылсак, эмне үчүн бизге кошумча тандоо керек.
• Кожоюндун жана кулдун позицияларын күч менен алмаштыруу керек болсо, анда кластердин иштен чыгуу буйругу аткарылат. Аны согушта чакырганда, кожоюн операция учурунда жеткиликсиз болорун түшүнүү керек. Адатта, которуу бир секундага жетпеген убакытта ишке ашат, бирок атомдук эмес. Бул убакыттын ичинде кожоюнга айрым өтүнүчтөр аткарылбай калат деп күтсөңүз болот.
• Түйүндү кластерден алып салуудан мурун, анда уячалар калбашы керек. Аларды кластерди кайра бөлүштүрүү буйругун колдонуп кайра бөлүштүрүү жакшы. Слоттор бир мастерден экинчисине өткөрүлөт. Бүт операция бир нече мүнөткө созулушу мүмкүн, ал берилүүчү маалыматтардын көлөмүнө жараша болот, бирок өткөрүп берүү процесси коопсуз жана кластердин иштешине эч кандай таасир этпейт. Ошентип, бардык маалыматтар бир түйүндөн экинчи түйүнгө түздөн-түз жүктөм астында жана анын жеткиликтүүлүгү жөнүндө кабатырланбастан өткөрүлүп берилиши мүмкүн. Бирок, ошондой эле майда-чүйдөсүнө чейин бар. Биринчиден, маалыматтарды берүү алуучу жана жөнөтүүчү түйүндөрүндө белгилүү бир жүк менен байланышкан. Эгерде алуучунун түйүнү процессорго катуу жүктөлгөн болсо, анда аны жаңы маалыматтарды алуу менен жүктөбөшүңүз керек. Экинчиден, жөнөтүүчү кожоюнда бир да уя калбай калганда, анын бардык кулдары ошол замат бул уячалар которулган кожоюнга барат. Ал эми маселе, бул кулдар бир эле учурда маалыматтарды синхрондоштурууну каалайт. Жана толук синхрондоштуруу эмес, жарым-жартылай болсо, сиз бактылуу болосуз. Муну эске алып, уячаларды өткөрүү жана кулдарды өчүрүү/өткөрүү операцияларын бириктириңиз. Же сизде жетиштүү коопсуздук чеги бар деп үмүттөнөбүз.
• Эгер которуу учурунда сиз слоттарыңызды бир жерден жоготуп алганыңызды байкасаңыз, эмне кылышыңыз керек? Бул көйгөй сизге таасир этпейт деп үмүттөнөм, бирок ал тийсе, кластердик оңдоо операциясы бар. Жок дегенде, ал түйүндөр боюнча уячаларды туш келди тартипте чачат. Адегенде кластерден бөлүштүрүлгөн уячалары бар түйүндү алып салуу менен анын иштешин текшерүүнү сунуштайм. Бөлүнбөгөн уячалардагы маалыматтар буга чейин жеткиликсиз болгондуктан, бул уячалардын болушуна байланыштуу көйгөйлөр жөнүндө тынчсызданууга өтө кеч. Өз кезегинде операция бөлүштүрүлгөн уячаларга таасирин тийгизбейт.
• Дагы бир пайдалуу операция - монитор. Бул түйүнгө бара турган суроо-талаптардын толук тизмесин реалдуу убакытта көрүүгө мүмкүндүк берет. Андан тышкары, сиз аны grep жана керектүү трафик бар же жок экенин биле аласыз.

Ошондой эле, башкы иштебей калуу процедурасын да айта кетүү керек. Кыскасы, ал бар, менин оюмча, ал сонун иштейт. Бирок, эгер сиз устат түйүнү бар машинанын электр шнурунун розеткасын сууруп алсаңыз, Редис дароо өтүп кетет жана кардарлар жоготууну байкабайт деп ойлобоңуз. Менин практикамда которуу бир нече секунданын ичинде ишке ашат. Бул убакыттын ичинде кээ бир маалыматтар жеткиликсиз болот: кожоюндун жеткиликтүү эместиги аныкталды, түйүндөр жаңысына добуш беришет, кулдар которулат, маалыматтар синхрондолот. Схема иштеп жаткандыгына ишенүүнүн эң жакшы жолу - бул жергиликтүү көнүгүүлөрдү өткөрүү. Ноутбугуңуздагы кластерди көтөрүңүз, ага минималдуу жүктөмдү бериңиз, аварияны имитациялаңыз (мисалы, портторду бөгөттөө менен) жана которуу ылдамдыгын баалаңыз. Менимче, бир-эки күн ушинтип ойногондон кийин гана технологиянын иштешине ишенүүгө болот. Ооба, же Интернеттин жарымы колдонгон программа иштейт деп үмүттөнөбүз.

тарам

Көбүнчө, конфигурация - бул курал менен иштөөнү баштоо үчүн, баары иштегенде, конфигурацияга тийгиңиз да келбейт. Жөндөөлөргө кайтып келип, аларды кылдаттык менен карап чыгууга өзүңүздү мажбурлоо үчүн бир аз күч-аракет талап кылынат. Менин эсимде, биз конфигурацияга көңүл бурбагандыктан, жок эле дегенде, эки олуттуу ката кетирдик. Төмөнкү пункттарга өзгөчө көңүл буруңуз:

• тыныгуу 0
  Активдүү эмес байланыштар жабылгандан кийин (секунд менен). 0 - жаппаңыз
  Биздин ар бир китепкана байланыштарды туура жаба алган эмес. Бул жөндөөнү өчүрүү менен, биз кардарлардын санынын чегине жетебиз. Башка жагынан алганда, эгерде мындай көйгөй бар болсо, анда жоголгон байланыштарды автоматтык түрдө токтотуу аны маскага түшүрөт жана биз байкабай калышыбыз мүмкүн. Мындан тышкары, туруктуу туташууларды колдонууда бул жөндөөнү иштетпеңиз.
• xy жана тиркемесин сактаңыз ооба
  RDB сүрөтүн сактоо.
  Төмөндө биз RDB/AOF маселелерин кеңири талкуулайбыз.
• stop-writes on-bgsave-error жок & slave-serve-stale-дата ооба
  Эгер иштетилсе, RDB сүрөтү бузулса, мастер өзгөртүү сурамдарын кабыл алууну токтотот. Кожоюн менен байланыш үзүлүп калса, кул суроо-талаптарга жооп бере алат (ооба). Же жооп берүүнү токтотот (жок)
  Редистин ашкабакка айланганы бизди кубандырбайт.
• repl-ping-кулчулук мезгили 5
  Бул убакыт өткөндөн кийин, биз кожоюн бузулуп калды деп тынчсыздана баштайбыз жана иштен чыгуу процедурасын аткарууга убакыт келди.
  Жалган позитивдер менен иштен чыгуунун ортосундагы балансты кол менен табышыңыз керек болот. Биздин практикада бул 5 секунд.
• repl-backlog-size 1024mb & epl-backlog-ttl 0
  Биз дал ушул көлөмдөгү маалыматтарды буферде ийгиликсиз реплика үчүн сактай алабыз. Буфер бүтсө, сиз толугу менен синхрондоштурууга туура келет.
  Практика көрсөткөндөй, жогору баа коюу жакшы. Репликанын артта калышынын көптөгөн себептери бар. Эгер ал артта калса, анда сиздин кожоюнуңуз буга чейин күрөшүп жаткандыр жана толук синхрондоштуруу акыркы тамчы болот.
• максималдуу кардарлар 10000
  Бир жолку кардарлардын максималдуу саны.
  Биздин тажрыйбабызда жогору баа койгон жакшы. Redis 10k байланышты жакшы иштетет. Жөн гана тутумда жетиштүү розетка бар экенин текшериңиз.
• maxmemory-policy volatile-ttl
  Жеткиликтүү эстутум чегине жеткенде баскычтар өчүрүлө турган эреже.
  Бул жерде маанилүү нерсе эреженин өзү эмес, мунун кандай болорун түшүнүү. Редис эстутум чегине жеткенде кадимкидей иштөө жөндөмдүүлүгү үчүн мактоого болот.

RDB жана AOF көйгөйлөрү

Redis өзү бардык маалыматты RAMда сактаса да, дискке маалыматтарды сактоо механизми да бар. Тагыраак айтканда, үч механизм:

• RDB-snapshot - бардык маалыматтардын толук сүрөтү. SAVE XY конфигурациясын колдонуп орнотуңуз жана "Эгер жок дегенде Y баскычтары өзгөргөн болсо, ар бир X секунд сайын бардык маалыматтардын толук сүрөтүн сактаңыз" деп окуйт.
• Тиркеме гана файл - аткарылган тартиптеги операциялардын тизмеси. Ар бир X секунд сайын же ар бир Y операцияларында файлга жаңы кирүүчү операцияларды кошот.
• RDB жана AOF мурунку экөөнүн айкалышы.

Бардык ыкмалардын артыкчылыктары жана кемчиликтери бар, мен алардын баарын санабай эле коёюн, мен жөн гана, менин оюмча, ачык-айкын эмес жагдайларга көңүл бурам.

Биринчиден, RDB сүрөтүн сактоо үчүн FORK чалууну талап кылат. Эгерде маалымат көп болсо, бул бардык Redisди бир нече миллисекунддан секундага чейин илип коюшу мүмкүн. Мындан тышкары, система мындай снапшот үчүн эстутум бөлүшү керек, бул логикалык машинада эки эселенген оперативдүү эстутумду сактап калуу зарылдыгына алып келет: эгерде Redis үчүн 8 ГБ бөлүнгөн болсо, анда виртуалдык машинада 16 ГБ болушу керек. ал.

Экинчиден, жарым-жартылай синхрондоштуруу менен көйгөйлөр бар. AOF режиминде, кул кайра туташтырылганда, жарым-жартылай синхрондоштуруунун ордуна, толук синхрондоштуруу аткарылышы мүмкүн. Эмне үчүн мындай болуп жатат, мен түшүнө алган жокмун. Бирок муну эстен чыгарбоо керек.

Бул эки пункт мурунтан эле баары кулдар тарабынан кайталанган болсо, дискте бул маалыматтар чындап керекпи же жокпу деген ойго түртөт. Маалыматтар бардык кулдар иштебей калса гана жоголуп кетиши мүмкүн жана бул "ДСдагы өрт" деңгээлиндеги көйгөй. Компромисс катары, сиз маалыматты кулдарда гана сактоону сунуштай аласыз, бирок бул учурда бул кулдар кырсыктан калыбына келтирүү учурунда эч качан кожоюн болуп калбасына ынанышыңыз керек (бул үчүн алардын конфигурациясында кул приоритети бар). Өзүбүз үчүн, ар бир конкреттүү учурда биз дискке маалыматтарды сактоо керекпи же жокпу деп ойлонобуз жана көбүнчө "жок" деп жооп беребиз.

жыйынтыктоо

Жыйынтыктап айтканда, мен бул жөнүндө такыр укпагандар үчүн редис-кластер кандайча иштээри жөнүндө жалпы түшүнүк бере алдым деп үмүттөнөм, ошондой эле аны колдонуп жүргөндөр үчүн кээ бир түшүнүксүз жагдайларга көңүл бурдум. узак убакыт бою.
Убакытыңыз үчүн рахмат жана, адаттагыдай эле, тема боюнча комментарийлер кабыл алынат.

Source: www.habr.com