ဆယ်စုနှစ်တစ်ခုကျော်ကြာ ဖွံ့ဖြိုးလာခဲ့သည့် ထုတ်ကုန်တစ်ခုသို့ ရောက်ရှိလာသည်မှာ ခေတ်မမီတော့သော နည်းပညာများကို တွေ့ရှိရခြင်းမှာ အံ့သြစရာမဟုတ်ပေ။ ဒါပေမယ့် ခြောက်လမှာ ဝန်ကို 10 ဆ ပိုမြင့်အောင်ထားရမယ်ဆိုရင် ပြုတ်ကျမှုကုန်ကျစရိတ်က အဆရာနဲ့ချီ တိုးလာမယ် ဆိုရင်ကော။ ဤကိစ္စတွင်၊ သင်သည် အေးမြသော Highload Engineer လိုအပ်သည်။ ဒါပေမယ့် အိမ်အကူမရှိရင် ပြဿနာဖြေရှင်းဖို့ ကျွန်တော့်ကို အပ်ပေးတယ်။ ဆောင်းပါး၏ပထမပိုင်း၌ကျွန်ုပ်တို့သည် Redis မှ Redis-cluster သို့ကျွန်ုပ်တို့မည်သို့ပြောင်းရွှေ့ခဲ့သည်ကိုပြောပြမည်ဖြစ်ပြီးဒုတိယအပိုင်းတွင် cluster ကိုမည်သို့စတင်အသုံးပြုရမည်နှင့်၎င်းကိုအသုံးပြုသောအခါအာရုံစိုက်သင့်သည်များကိုပြောပြပါမည်။

နည်းပညာရွေးချယ်မှု

ဆိုးသလား။ သီးခြား Redis မာစတာနှင့် N ကျေးကျွန် 1 ဦးတို့၏ ဖွဲ့စည်းမှုပုံစံတွင် (သီးသန့် အနီရောင်ဒီစ်)။ ဘာကြောင့် အသုံးမဝင်တဲ့ နည်းပညာလို့ခေါ်တာလဲ။

မဟုတ်ဘူး၊ Redis က သိပ်မဆိုးပါဘူး... ဒါပေမယ့် လျစ်လျူမရှုနိုင်တဲ့ ချို့ယွင်းချက်တချို့ ရှိပါတယ်။

• ပထမဦးစွာ Redis သည် မဟာချို့ယွင်းမှုတစ်ခုပြီးနောက် ဘေးအန္တရာယ်ပြန်လည်ရယူရေးယန္တရားများကို မပံ့ပိုးပါ။ ဤပြဿနာကိုဖြေရှင်းရန်၊ ကျွန်ုပ်တို့သည် VIP များကို သခင်အသစ်ထံ အလိုအလျောက်လွှဲပြောင်းပေးကာ ကျွန်တစ်ဦး၏အခန်းကဏ္ဍကိုပြောင်းလဲကာ ကျန်တစ်ဦးကိုပြောင်းခြင်းဖြင့် ဖွဲ့စည်းမှုပုံစံကိုအသုံးပြုခဲ့သည်။ ဤယန္တရားသည် အလုပ်လုပ်သော်လည်း ယုံကြည်စိတ်ချရသော ဖြေရှင်းချက်ဟု မခေါ်ဆိုနိုင်ပါ။ ပထမအချက်မှာ မှားယွင်းသော အချက်ပေးမှုများ ဖြစ်ပေါ်ပြီး ဒုတိယအချက်မှာ ၎င်းသည် တစ်ခါသုံးဖြစ်ပြီး၊ လည်ပတ်ပြီးနောက် နွေဦးအား အားသွင်းရန် လက်စွဲလုပ်ဆောင်မှုများ လိုအပ်ပါသည်။

• ဒုတိယအချက်မှာ သခင်တစ်ဦးတည်းရှိခြင်းက ခွဲထွက်ခြင်းပြဿနာကို ဖြစ်စေသည်။ "1 master နှင့် N slaves" အမှီအခိုကင်းသောအစုအဝေးများစွာကို ဖန်တီးရမည်ဖြစ်ပြီး၊ ထို့နောက် ဤစက်များကြားတွင် ဒေတာဘေ့စ်များကို ကိုယ်တိုင်ဖြန့်ဝေပြီး မနက်ဖြန်တွင် ဒေတာဘေ့စ်များထဲမှ တစ်ခုသည် သီးခြားဥပမာတစ်ခုသို့ ရွှေ့ရမည်ဟု မျှော်လင့်ပါသည်။

ရွေးချယ်စရာတွေကဘာတွေလဲ။

• ဈေးအကြီးဆုံးနှင့် အချမ်းသာဆုံးဖြေရှင်းချက်မှာ Redis-Enterprise ဖြစ်သည်။ ၎င်းသည် နည်းပညာပိုင်းဆိုင်ရာ ပံ့ပိုးမှုအပြည့်ဖြင့် ထုပ်ပိုးထားသော ဖြေရှင်းချက်တစ်ခုဖြစ်သည်။ နည်းပညာရှုထောင့်မှကြည့်လျှင် စံနမူနာရှိသော်လည်း အယူဝါဒဆိုင်ရာ အကြောင်းပြချက်များကြောင့် ကျွန်ုပ်တို့နှင့် မကိုက်ညီပါ။
• ပြန်လည်ပြင်ဆင်ခြင်း အကွက်ထဲတွင် master failover နှင့် sharding အတွက် ပံ့ပိုးမှု ရှိပါသည်။ အင်တာဖေ့စ်သည် ပုံမှန်ဗားရှင်းနှင့် မတူပေ။ အလားအလာကောင်းပုံရသည်၊ နောင်တွင် ချို့ယွင်းချက်များအကြောင်း ပြောပါမည်။
• Tarantool၊ Memcache၊ Aerospike နှင့် အခြားအရာများ။ ဤကိရိယာအားလုံးသည် တူညီသောအရာကို လုပ်ဆောင်သည်။ ဒါပေမယ့် တစ်ခုစီတိုင်းမှာ အားနည်းချက်ကိုယ်စီရှိကြပါတယ်။ ကြက်ဥအားလုံးကို ခြင်းတောင်းတစ်ခုတည်းမှာ မထည့်ဖို့ ဆုံးဖြတ်ခဲ့ပါတယ်။ ကျွန်ုပ်တို့သည် အခြားလုပ်ဆောင်စရာများအတွက် Memcache နှင့် Tarantool ကို အသုံးပြုပြီး ကျွန်ုပ်တို့၏ လက်တွေ့လုပ်ဆောင်မှုတွင် ၎င်းတို့နှင့် ပြဿနာများ ပိုမိုရှိကြောင်း ကျွန်ုပ်ပြောပါမည်။

အသုံးပြုမှုအသေးစိတ်

Redis ဖြင့်ကျွန်ုပ်တို့သမိုင်းကြောင်းအရဖြေရှင်းခဲ့သောပြဿနာများနှင့်ကျွန်ုပ်တို့အသုံးပြုခဲ့သည့်လုပ်ဆောင်ချက်များကိုကြည့်ရှုကြပါစို့။

• 2GIS | ကဲ့သို့သော အဝေးထိန်းဝန်ဆောင်မှုများသို့ မတောင်းဆိုမီ ကက်ရှ် Golang
  

  MGET MSET "SELECT DB" ကိုရယူပါ

• MYSQL | ရှေ့တွင် ကက်ရှ် PHP
  

  MGET MSET စကင်န်ရယူပါ "ပုံစံအလိုက်ကီး" "SELECT DB"

• ဝန်ဆောင်မှုအတွက် အဓိကသိုလှောင်မှု အစည်းအဝေးများနှင့် ယာဉ်မောင်း သြဒိနိတ်များ | Golang
  

  MGET MSET "SELECT DB" "GEO KEY ထည့်ပါ" "GEO KEY GET" စကင်န်ရယူပါ

သင်မြင်နိုင်သကဲ့သို့၊ မြင့်မားသောသင်္ချာမရှိပါ။ ဒါဆိုအခက်အခဲကဘာလဲ။ နည်းလမ်းတစ်ခုစီကို ခွဲကြည့်ရအောင်။

နည်းလမ်း
ဖေါ်ပြချက်
Redis-cluster ၏အင်္ဂါရပ်များ
ဆုံးဖြတ်ချက်

ချိန်ညှိပါ
ရေး/ဖတ်သော့

MGET MSET
သော့များစွာကို ရေး/ဖတ်ပါ။
သော့များသည် မတူညီသော node များတွင် ရှိနေလိမ့်မည်။ အဆင်သင့်လုပ်ထားသည့် ဒစ်ဂျစ်တယ်များသည် node တစ်ခုအတွင်းသာ လုပ်ဆောင်မှုပေါင်းများစွာ လုပ်ဆောင်နိုင်သည်။
MGET ကို N GET ၏ ပိုက်လိုင်းဖြင့် အစားထိုးပါ။

DB ကို ရွေးပါ။
ကျွန်ုပ်တို့နှင့် လုပ်ဆောင်မည့် အခြေခံကို ရွေးချယ်ပါ။
ဒေတာဘေ့စ်များစွာကို မပံ့ပိုးပါ။
အရာအားလုံးကိုဒေတာဘေ့စ်တစ်ခုတည်းတွင်ထည့်ပါ။ သော့များသို့ ရှေ့ဆက်များထည့်ပါ။

စကင်ဖတ်စစ်ဆေးခြင်း
ဒေတာဘေ့စ်ရှိ သော့များအားလုံးကို ဖြတ်သွားပါ။
ကျွန်ုပ်တို့တွင် ဒေတာဘေ့စ်တစ်ခုရှိသောကြောင့်၊ အစုအဝေးရှိ သော့များအားလုံးကို ဖြတ်သွားခြင်းသည် အလွန်စျေးကြီးသည်။
သော့တစ်ခုအတွင်း မူကွဲတစ်ခုကို ထိန်းသိမ်းပြီး ဤကီးပေါ်တွင် HSCAN ပြုလုပ်ပါ။ သို့မဟုတ် လုံးဝငြင်းဆန်ပါ။

GEO
geokey ဖြင့် လည်ပတ်ခြင်း။
ဘူမိကီးကို ခွဲမထားပါ။

ပုံစံဖြင့်သော့
ပုံစံဖြင့် သော့ကို ရှာဖွေခြင်း။
ကျွန်ုပ်တို့တွင် ဒေတာဘေ့စ်တစ်ခုရှိသောကြောင့်၊ အစုအဝေးရှိ သော့အားလုံးကို ရှာဖွေပါမည်။ ဈေးကြီးလွန်းတယ်။
SCAN ၏ဖြစ်ရပ်တွင်ကဲ့သို့ မူကွဲကို ငြင်းဆို သို့မဟုတ် ထိန်းသိမ်းပါ။

Redis နှင့် Redis-cluster

အစုအဖွဲ့တစ်ခုသို့ပြောင်းသောအခါ ကျွန်ုပ်တို့ဘာများဆုံးရှုံးပြီး ဘာများရရှိမည်နည်း။

• အားနည်းချက်များ- ကျွန်ုပ်တို့သည် ဒေတာဘေ့စ်များစွာ၏ လုပ်ဆောင်နိုင်စွမ်းကို ဆုံးရှုံးစေသည်။
  • အကယ်၍ ကျွန်ုပ်တို့သည် ယုတ္တိမတန်သော အချက်အလက်များကို အစုအဝေးတစ်ခုတွင် သိမ်းဆည်းလိုပါက၊ ရှေ့ဆက်ပုံစံဖြင့် ချိုင်းထောက်များ ပြုလုပ်ရပါမည်။
  • ကျွန်ုပ်တို့သည် SCAN၊ DBSIZE၊ CLEAR DB စသည်တို့ကဲ့သို့သော "အခြေခံ" လုပ်ဆောင်ချက်များအားလုံး ဆုံးရှုံးသွားပါသည်။
  • များစွာသော node များသို့ဝင်ရောက်ခွင့် လိုအပ်နိုင်သောကြောင့် Multi-operation များသည် အကောင်အထည်ဖော်ရန် ပိုမိုခက်ခဲလာပါသည်။
• အားသာချက်များ:
  • မာစတာရှုံးနိမ့်မှုပုံစံဖြင့် အမှားခံနိုင်ရည်ရှိသည်။
  • Redis ဘက်မှ Sharing လုပ်ခြင်း။
  • node များအကြား ဒေတာကို အက်တမ်နည်းဖြင့် နှင့် အချိန်မဆွဲဘဲ လွှဲပြောင်းပါ။
  • စက်ရပ်စရာမလိုဘဲ စွမ်းရည်နှင့် load များကို ပေါင်းထည့်ကာ ပြန်လည်ဖြန့်ဝေပါ။

အကယ်၍ သင်သည် အမှားခံနိုင်ရည်မြင့်မားမှုကို ပေးဆောင်ရန် မလိုအပ်ပါက၊ အစုအဖွဲ့တစ်ခုသို့ ပြောင်းရွှေ့ခြင်းသည် အသေးအဖွဲမဟုတ်သော အလုပ်တစ်ခုဖြစ်နိုင်သောကြောင့် ၎င်းသည် မထိုက်တန်ကြောင်း ကျွန်ုပ်ကောက်ချက်ချပါမည်။ သို့သော် သင်သည် သီးခြားဗားရှင်းနှင့် အစုလိုက်ဗားရှင်းကို ကနဦးရွေးချယ်ပါက၊ ၎င်းသည် ပိုမိုဆိုးရွားခြင်းမရှိသည့်အတွက်ကြောင့် အစုအဖွဲ့တစ်ခုကို ရွေးချယ်သင့်ပြီး ထို့အပြင် ခေါင်းကိုက်ခြင်းအချို့ကိုလည်း သက်သာရာရစေမည်ဖြစ်သည်။

ပြောင်းရွှေ့ရန် ပြင်ဆင်နေသည်။

ပြောင်းရွှေ့ခြင်းအတွက် လိုအပ်ချက်များနှင့် စတင်ကြပါစို့။

• ချောမွေ့စေသင့်သည်။ ဝန်ဆောင်မှုကို 5 မိနစ်ကြာအောင် ရပ်တန့်ခြင်းသည် ကျွန်ုပ်တို့နှင့် မကိုက်ညီပါ။
• တတ်နိုင်သမျှ ဘေးကင်းပြီး တဖြည်းဖြည်းချင်း ဖြစ်သင့်သည်။ အခြေအနေကို ထိန်းထားချင်တယ်။ ကျွန်ုပ်တို့သည် အရာအားလုံးကို တစ်ပြိုင်နက် မစွန့်ပစ်ချင်ဘဲ နောက်ပြန်ခလုတ်ကို နှိပ်၍ ဆုတောင်းပါ။
• ရွေ့လျားသည့်အခါ ဒေတာဆုံးရှုံးမှု အနည်းဆုံး။ အက်တမ်ပုံစံအတိုင်း ရွေ့လျားရန် အလွန်ခက်ခဲမည်ကို ကျွန်ုပ်တို့ နားလည်ပါသည်၊ ထို့ကြောင့် ကျွန်ုပ်တို့သည် ပုံမှန်နှင့် အစုလိုက်ပြုလုပ်ထားသော Redis တွင် ဒေတာများကြားတွင် ကွဲထွက်မှုအချို့ကို ခွင့်ပြုပါသည်။

အစုအဝေးထိန်းသိမ်းခြင်း။

မရွှေ့ခင်မှာ အစုအဖွဲ့ကို ပံ့ပိုးပေးနိုင်မလားဆိုတာ စဉ်းစားသင့်ပါတယ်။

• ဇယားများ။ ကျွန်ုပ်တို့သည် CPU load၊ မှတ်ဉာဏ်အသုံးပြုမှု၊ သုံးစွဲသူအရေအတွက်၊ GET၊ SET၊ AUTH လုပ်ဆောင်ချက်စသည်ဖြင့် ဂရပ်ဖစ်ရန်အတွက် Prometheus နှင့် Grafana ကိုအသုံးပြုပါသည်။
• ကျွမ်းကျင်မှု။ မနက်ဖြန် မင်းမှာ မင်းရဲ့ တာဝန်အောက်မှာ ကြီးမားတဲ့ အစုအဝေးတစ်ခု ရှိနေမယ်လို့ စိတ်ကူးကြည့်ပါ။ ပျက်သွားရင် ဘယ်သူမှ ပြင်လို့ မရဘူး။ သူနှေးကွေးလာလျှင် လူတိုင်းသည် သင့်ဆီသို့ ပြေးလာကြလိမ့်မည်။ အရင်းအမြစ်များ ထည့်ရန် သို့မဟုတ် ဝန်ကို ပြန်လည်ဖြန့်ဝေရန် လိုအပ်ပါက သင့်ထံ ပြန်လာပါ။ အသက် 25 နှစ်တွင် မီးခိုးရောင်မပြောင်းစေရန်၊ ဤကိစ္စများအတွက် ပံ့ပိုးပေးပြီး အချို့သောလုပ်ဆောင်ချက်များတွင် နည်းပညာသည် မည်သို့ပြုမူမည်ကို ကြိုတင်စစ်ဆေးရန် အကြံပြုလိုပါသည်။ ဤအကြောင်းကို "ကျွမ်းကျင်မှု" ကဏ္ဍတွင် ပိုမိုအသေးစိတ်ပြောဆိုကြပါစို့။
• စောင့်ကြည့်ခြင်းနှင့် သတိပေးချက်များ။ အစုအဖွဲ့တစ်ခု ပြိုကွဲသွားသောအခါ၊ သင်သည် ၎င်းအကြောင်းကို ပထမဆုံး သိလိုသည်။ ဤနေရာတွင် ကျွန်ုပ်တို့သည် အစုအဝေးများအားလုံး အစုအဝေး၏အခြေအနေနှင့် ပတ်သက်သည့် တူညီသောအချက်အလက်များကို ပြန်ပေးကြောင်း အကြောင်းကြားချက်တစ်ခုတွင် ကျွန်ုပ်တို့အား ကန့်သတ်ထားသည်။ Redis သုံးစွဲသူဝန်ဆောင်မှုများမှ သတိပေးချက်များဖြင့် အခြားပြဿနာများကို ပိုမိုလျင်မြန်စွာ သတိပြုမိနိုင်သည်။

လမ်းကူး

ဘယ်လိုရွှေ့မလဲ-

• ပထမဦးစွာ၊ အစုအဖွဲ့နှင့်အလုပ်လုပ်ရန် စာကြည့်တိုက်တစ်ခုကို သင်ပြင်ဆင်ရန်လိုအပ်သည်။ Go ဗားရှင်းအတွက် အခြေခံအဖြစ် go-redis ကိုယူကာ မိမိနှင့်လိုက်ဖက်ရန် အနည်းငယ်ပြောင်းလဲခဲ့သည်။ ကျွန်ုပ်တို့သည် ပိုက်လိုင်းများမှတစ်ဆင့် နည်းလမ်းပေါင်းစုံကို အကောင်အထည်ဖော်ခဲ့ပြီး ထပ်တလဲလဲ တောင်းဆိုမှုများအတွက် စည်းမျဉ်းများကို အနည်းငယ် ပြုပြင်ခဲ့သည်။ PHP ဗားရှင်းတွင် ပြဿနာများ ပိုရှိသော်လည်း နောက်ဆုံးတွင် ကျွန်ုပ်တို့သည် php-redis ကို ဖြေရှင်းခဲ့သည်။ မကြာသေးမီက ၎င်းတို့သည် အစုလိုက်ပံ့ပိုးမှုကို မိတ်ဆက်ခဲ့ပြီး ကျွန်ုပ်တို့၏အမြင်တွင် ကောင်းမွန်ပါသည်။
• ထို့နောက် သင်သည် အစုအဝေးကို အသုံးချရန် လိုအပ်သည်။ ၎င်းကို configuration file ကို အခြေခံ၍ command နှစ်ခုဖြင့် လုပ်ဆောင်သည်။ သတ်မှတ်ချက်များကို အောက်တွင် အသေးစိတ် ဆွေးနွေးပါမည်။
• တဖြည်းဖြည်းရွေ့လျားရန်အတွက် ကျွန်ုပ်တို့သည် အခြောက်မုဒ်ကို အသုံးပြုသည်။ ကျွန်ုပ်တို့တွင် တူညီသောမျက်နှာပြင်ပါသည့် ဒစ်ဂျစ်တိုက်၏ ဗားရှင်းနှစ်မျိုးရှိသောကြောင့် (ပုံမှန်ဗားရှင်းအတွက် တစ်ခု၊ အခြားတစ်ခုသည် အစုအဝေးအတွက်) ဖြစ်သောကြောင့် သီးခြားဗားရှင်းတစ်ခုနှင့် အလုပ်လုပ်မည့် wrapper တစ်ခုကို ဖန်တီးရန် မလိုအပ်ဘဲ အစုအဝေးသို့ တောင်းဆိုချက်အားလုံးကို အပြိုင်ပွားခြင်း၊ တုံ့ပြန်မှုများကို နှိုင်းယှဉ်ပြီး မှတ်တမ်းများတွင် ကွဲလွဲမှုများကို ရေးပါ (ကျွန်ုပ်တို့၏ကိစ္စတွင် NewRelic တွင်)။ ထို့ကြောင့်၊ စတင်ထုတ်ဝေစဉ်အတွင်း အစုလိုက်ဗားရှင်းကွဲသွားသော်လည်း ကျွန်ုပ်တို့၏ထုတ်လုပ်မှုကို ထိခိုက်မည်မဟုတ်ပါ။
• ခြောက်သွေ့သောမုဒ်တွင် အစုအဝေးကို လှိမ့်ထုတ်ပြီး တုံ့ပြန်မှုကွာဟချက်များ၏ ဂရပ်ကို တည်ငြိမ်စွာကြည့်ရှုနိုင်သည်။ error rate သည် နှေးကွေးသော်လည်း သေးငယ်သော ကိန်းသေဆီသို့ ဦးတည်သွားပါက၊ အားလုံးအဆင်ပြေပါသည်။ ဘာကြောင့် ကွဲလွဲမှုတွေ ရှိပါသေးလဲ။ သီးခြားဗားရှင်းတွင် အသံသွင်းခြင်းသည် အစုအဝေးတွင်ထက် အနည်းငယ်စောပြီး microlag ကြောင့် ဒေတာကွဲပြားနိုင်သည်။ ကျန်တာအားလုံးက ကွာဟချက်မှတ်တမ်းတွေကို ကြည့်ဖို့ဖြစ်ပြီး၊ အဲဒါတွေကို မှတ်တမ်းရဲ့ အနုမြူဓာတ်မဟုတ်တဲ့အကြောင်း ရှင်းပြမယ်ဆိုရင်၊ ငါတို့ ဆက်သွားနိုင်ပါတယ်။
• ယခု သင်သည် အခြောက်မုဒ်ကို ဆန့်ကျင်ဘက်သို့ ပြောင်းနိုင်သည်။ ကျွန်ုပ်တို့သည် အစုအဝေးမှ ရေးပြီး ဖတ်မည်ဖြစ်ပြီး ၎င်းကို သီးခြားဗားရှင်းအဖြစ် ပွားပါမည်။ ဘာအတွက်လဲ? နောက်အပတ်တွေမှာ အစုအဖွဲ့ရဲ့ လုပ်ဆောင်ချက်ကို စောင့်ကြည့်ချင်ပါတယ်။ peak load တွင် ပြဿနာများ ရုတ်တရက် ပေါ်ပေါက်လာပါက သို့မဟုတ် တစ်စုံတစ်ခုကို ထည့်သွင်းစဉ်းစားခြင်း မပြုပါက၊ dry-mode ကြောင့် ကုဒ်ဟောင်းနှင့် လက်ရှိဒေတာသို့ အရေးပေါ် ပြန်လှည့်ရန် အမြဲရှိသည်။
• ကျန်တာကတော့ dry-mode ကို disable လုပ်ပြီး သီးခြားဗားရှင်းကို ဖျက်သိမ်းဖို့ပါပဲ။

စာမေးပှဲ

ပထမဦးစွာ၊ အစုအဝေးဒီဇိုင်းအကြောင်း အကျဉ်းချုပ်ပြောပြပါ။

ပထမဦးစွာ Redis သည် သော့တန်ဖိုးစတိုးဆိုင်တစ်ခုဖြစ်သည်။ မတရားသော ကြိုးများကို သော့များအဖြစ် အသုံးပြုသည်။ နံပါတ်များ၊ စာကြောင်းများနှင့် ဖွဲ့စည်းပုံတစ်ခုလုံးကို တန်ဖိုးများအဖြစ် အသုံးပြုနိုင်သည်။ နောက်ပိုင်းမှာ အများကြီးရှိပေမယ့် ယေဘူယျဖွဲ့စည်းပုံကို နားလည်ဖို့အတွက် ဒါက ကျွန်တော်တို့အတွက် အရေးမကြီးပါဘူး။
သော့များပြီးနောက် abstraction ၏ နောက်တစ်ဆင့်မှာ slots (SLOTS) ဖြစ်သည်။ သော့တစ်ခုစီသည် 16 slots တစ်ခုမှတစ်ခုဖြစ်သည်။ အပေါက်တစ်ခုစီတွင် သော့အရေအတွက်မည်မျှရှိနိုင်သည်။ ထို့ကြောင့် သော့အားလုံးကို 383 disjoint set များအဖြစ် ပိုင်းခြားထားသည်။

ထို့နောက်၊ အစုအဝေးတွင် N master nodes ရှိရမည်။ node တစ်ခုစီကို cluster အတွင်းရှိ အခြားသော node များအကြောင်း အားလုံးသိသော သီးခြား Redis instance တစ်ခုအဖြစ် ယူဆနိုင်သည်။ master node တစ်ခုစီတွင် slot အများအပြားပါရှိသည်။ slot တစ်ခုစီသည် master node တစ်ခုသာရှိသည်။ အကွက်များအားလုံးကို node များကြားတွင် ဖြန့်ဝေရန် လိုအပ်သည်။ အချို့သော slot များကို ခွဲဝေမထားပါက၊ ၎င်းတို့တွင် သိမ်းဆည်းထားသော သော့များကို အသုံးပြု၍ မရနိုင်ပါ။ သီးခြား logical သို့မဟုတ် Physical machine တစ်ခုတွင် master node တစ်ခုစီကို run ခြင်းသည် အဓိပ္ပါယ်ရှိပေသည်။ node တစ်ခုစီသည် core တစ်ခုပေါ်တွင်သာအလုပ်လုပ်ကြောင်းကိုလည်း မှတ်သားထားသင့်ပြီး အကယ်၍ သင်သည် တူညီသောယုတ္တိစက်တစ်ခုတွင် Redis instances များစွာကို run လိုပါက၊ ၎င်းတို့သည် မတူညီသော cores များပေါ်တွင်အလုပ်လုပ်ကြောင်းသေချာပါစေ (ကျွန်ုပ်တို့ ၎င်းကိုမစမ်းရသေးသော်လည်း သီအိုရီအရ ၎င်းသည် အလုပ်လုပ်သင့်သည်) . အခြေခံအားဖြင့်၊ master node များသည် ပုံမှန် sharding များကို ပေးဆောင်ပြီး master node များသည် အတိုင်းအတာတစ်ခုအထိ ရေးရန်နှင့် ဖတ်ရန် တောင်းဆိုမှုများကို ခွင့်ပြုသည်။

သော့အားလုံးကို slots များကြားတွင် ဖြန့်ဝေပြီးသောအခါ၊ slot များသည် master node များကြားတွင် ပြန့်ကျဲနေပြီး၊ slave node များ အများအပြားကို master node တစ်ခုစီသို့ ပေါင်းထည့်နိုင်သည်။ ထိုကဲ့သို့သော master-slave လင့်ခ်တစ်ခုစီတွင်၊ ပုံမှန်ပြန်လည်ပုံတူခြင်း အလုပ်လုပ်ပါမည်။ ဖတ်ရှုရန် တောင်းဆိုမှုများကို အတိုင်းအတာနှင့် ကျွမ်းကျင်မှု မအောင်မြင်ပါက ကျွန်များ လိုအပ်ပါသည်။

အခု လုပ်နိုင်ရင် ပိုကောင်းမယ့် လုပ်ငန်းတွေအကြောင်း ပြောကြည့်ရအောင်။

ကျွန်ုပ်တို့သည် Redis-CLI မှတစ်ဆင့် စနစ်သို့ ဝင်ရောက်ပါမည်။ Redis တွင် entry point တစ်ခုမှမရှိသောကြောင့်၊ သင်သည် node တစ်ခုခုတွင် အောက်ပါလုပ်ဆောင်ချက်များကို လုပ်ဆောင်နိုင်ပါသည်။ အချက်တစ်ခုစီတိုင်းတွင် ဝန်အောက်တွင်ရှိသော လုပ်ဆောင်ချက်ကို လုပ်ဆောင်နိုင်ခြေကို သီးခြားအာရုံစိုက်ပါသည်။

• ကျွန်ုပ်တို့လိုအပ်သော ပထမဆုံးနှင့် အရေးအကြီးဆုံးမှာ cluster nodes လုပ်ဆောင်ချက်ဖြစ်သည်။ ၎င်းသည် အစုအဝေး၏အခြေအနေကို ပြန်ပေးသည်၊ ဆုံမှတ်များစာရင်း၊ ၎င်းတို့၏ အခန်းကဏ္ဍ၊ အထိုင်ဖြန့်ဖြူးမှုစသည်တို့ကို ပြသသည်။ အစုအဝေးအချက်အလက်နှင့် အစုလိုက်အကွက်များကို အသုံးပြု၍ နောက်ထပ်အချက်အလက်များကို ရယူနိုင်ပါသည်။
• node များကို ပေါင်းထည့်ခြင်းနှင့် ဖယ်ရှားနိုင်ခြင်းသည် ကောင်းပါတယ်။ ဤရည်ရွယ်ချက်အတွက် အစုလိုက်အစည်းအဝေးနှင့် အစုလိုက်အပြုံလိုက် မေ့သွားသော လုပ်ဆောင်မှုများရှိသည်။ ကျေးဇူးပြု၍ ကျေးဇူးပြု၍ ကျေးဇူးပြု၍ မှတ်သားထားပါက cluster forget ကို node တိုင်း၊ masters နှင့် replicas များအားလုံးတွင် အသုံးပြုရပါမည်။ နှင့် cluster တွေ့ဆုံမှုကို node တစ်ခုပေါ်တွင်သာ ခေါ်ရန် လိုအပ်သည်။ ဤခြားနားချက်သည် စိတ်ပျက်ဖွယ်ကောင်းနိုင်သည်၊ ထို့ကြောင့် သင့်အစုအဖွဲ့နှင့် တိုက်ရိုက်မလွှင့်မီ ၎င်းအကြောင်းကို လေ့လာရန် အကောင်းဆုံးဖြစ်သည်။ node တစ်ခုကို ပေါင်းထည့်ခြင်းသည် တိုက်ပွဲတွင် လုံခြုံစွာ လုပ်ဆောင်ပြီး အစုအဝေး၏ လုပ်ဆောင်မှုကို မည်သည့်နည်းဖြင့်မျှ မထိခိုက်စေပါ (ယုတ္တိတန်သော)။ အကယ်၍ သင်သည် node တစ်ခုကို အစုအဝေးမှ ဖယ်ရှားတော့မည်ဆိုပါက၊ ၎င်းတွင် အကွက်များ မကျန်တော့ကြောင်း သေချာစေသင့်သည် (မဟုတ်ပါက ဤ node ပေါ်ရှိ သော့များအားလုံးသို့ ဝင်ရောက်ခွင့် ဆုံးရှုံးနိုင်ခြေရှိသည်)။ ထို့အပြင်၊ ကျွန်များရှိသည့်သခင်ကို မဖျက်ပါနှင့်၊ သို့မဟုတ်ပါက သခင်အသစ်အတွက် မလိုအပ်သောမဲပေးခြင်းကို လုပ်ဆောင်မည်ဖြစ်သည်။ အကယ်၍ node များတွင် slot များမရှိတော့ပါက၊ ၎င်းသည်သေးငယ်သောပြဿနာဖြစ်သည်၊ သို့သော်ကျွန်ုပ်တို့ကိုပထမဦးစွာဖျက်နိုင်လျှင်ကျွန်ုပ်တို့ဘာကြောင့်အပိုရွေးချယ်မှုများလိုအပ်သနည်း။
• master နှင့် slave ရာထူးများကို အတင်းအကျပ် လဲလှယ်ရန် လိုအပ်ပါက၊ cluster failover command သည် လုပ်ဆောင်လိမ့်မည်။ စစ်တိုက်ရာတွင် ခေါ်သောအခါ၊ စစ်ဆင်ရေးအတွင်း မာစတာမရနိုင်ကြောင်း နားလည်ထားရန် လိုအပ်သည်။ ပုံမှန်အားဖြင့် switch သည် တစ်စက္ကန့်ထက်နည်းသော အချိန်တွင် ဖြစ်ပေါ်သော်လည်း atomic မဟုတ်ပါ။ ဤကာလအတွင်း သခင်ထံ တောင်းဆိုမှုအချို့ ကျရှုံးမည်ဟု သင်မျှော်လင့်နိုင်သည်။
• အစုအဝေးမှ node ကို မဖယ်ရှားမီ၊ ၎င်းတွင် အကွက်များ မကျန်ရှိသင့်ပါ။ cluster reshard command ကို အသုံးပြု၍ ၎င်းတို့ကို ပြန်လည်ဖြန့်ဝေခြင်းသည် ပိုမိုကောင်းမွန်သည်။ အကွက်များကို မာစတာတစ်ခုမှ အခြားတစ်ခုသို့ လွှဲပြောင်းပေးမည်ဖြစ်သည်။ လုပ်ဆောင်ချက်တစ်ခုလုံးသည် မိနစ်အနည်းငယ်ကြာနိုင်ပြီး၊ လွှဲပြောင်းသည့်ဒေတာပမာဏအပေါ်မူတည်သော်လည်း လွှဲပြောင်းခြင်းလုပ်ငန်းစဉ်သည် လုံခြုံပြီး အစုအဖွဲ့၏လည်ပတ်မှုကို မည်သည့်နည်းဖြင့်မျှ မထိခိုက်စေပါ။ ထို့ကြောင့်၊ ဒေတာအားလုံးကို node တစ်ခုမှ နောက်တစ်ခုသို့ တိုက်ရိုက် လွှဲပြောင်းနိုင်ပြီး ၎င်း၏ရရှိနိုင်မှုနှင့်ပတ်သက်၍ စိုးရိမ်စရာမလိုဘဲ တိုက်ရိုက်လွှဲပြောင်းနိုင်သည်။ သို့သော် ပရိယာယ်များလည်း ရှိပါသည်။ ပထမဦးစွာ၊ ဒေတာလွှဲပြောင်းမှုသည် လက်ခံသူနှင့် ပေးပို့သူဆုံမှတ်များပေါ်ရှိ အချို့သောဝန်နှင့် ဆက်စပ်နေသည်။ လက်ခံသူသည် ပရိုဆက်ဆာပေါ်တွင် ကြီးကြီးမားမား တင်ဆောင်ထားပြီးဖြစ်ပါက၊ ဒေတာအသစ်လက်ခံရယူခြင်းဖြင့် ၎င်းကို မတင်သင့်ပါ။ ဒုတိယအနေဖြင့်၊ ပေးပို့သူသခင်တွင် slot တစ်ခုမျှမကျန်သည်နှင့်တပြိုင်နက်၊ ၎င်း၏ကျွန်များအားလုံးသည် ဤ slot များကိုလွှဲပြောင်းသည့်သခင်ထံချက်ချင်းရောက်သွားလိမ့်မည်။ ပြဿနာမှာ ဤကျွန်များအားလုံးသည် ဒေတာများကို တစ်ပြိုင်နက်တည်း တစ်ပြိုင်နက်တည်း လုပ်လိုလိမ့်မည်ဖြစ်သည်။ ပြီးပြည့်စုံသော ထပ်တူပြုခြင်းထက် တစ်စိတ်တစ်ပိုင်းဖြစ်လျှင် သင်ကံကောင်းပါလိမ့်မည်။ ၎င်းကိုထည့်သွင်းစဉ်းစားပြီး slots များလွှဲပြောင်းခြင်းနှင့်ကျွန်များကိုပိတ်ခြင်း / လွှဲပြောင်းခြင်း၏လုပ်ဆောင်မှုများကိုပေါင်းစပ်ပါ။ သို့မဟုတ် သင့်တွင် လုံလောက်သော ဘေးကင်းလုံခြုံမှုရှိရန် မျှော်လင့်ပါ။
• အပြောင်းအရွှေ့ကာလတွင် သင့် slot များ တစ်နေရာရာမှာ ပျောက်ဆုံးသွားပါက သင် ဘာလုပ်သင့်သလဲ။ ဒီပြဿနာက သင့်အပေါ် မသက်ရောက်ဘူးလို့ ကျွန်တော် မျှော်လင့်ပါတယ်၊ ဒါပေမယ့် အဲဒါဆိုရင်တော့၊ အစုလိုက် ပြုပြင်တဲ့ လုပ်ဆောင်ချက်တစ်ခု ရှိပါတယ်။ အနည်းဆုံးတော့၊ သူမသည် ကျပန်းအစီအစဥ်ဖြင့် node များတစ်လျှောက် slot များကိုဖြန့်ကြဲလိမ့်မည်။ အစုအဝေးမှ ဖြန့်ဝေထားသော အကွက်များပါရှိသော node ကို ဦးစွာဖယ်ရှားခြင်းဖြင့် ၎င်း၏လုပ်ဆောင်ချက်ကို စစ်ဆေးရန် အကြံပြုအပ်ပါသည်။ ခွဲဝေမထားသောအပေါက်များရှိ ဒေတာကို မရရှိနိုင်သေးသောကြောင့်၊ ဤ slot များရရှိနိုင်မှုနှင့်ပတ်သက်ပြီး ပြဿနာများအတွက် စိတ်ပူရန်မှာ နောက်ကျနေပြီဖြစ်သည်။ တစ်ဖန်၊ လုပ်ဆောင်ချက်သည် ဖြန့်ဝေထားသော slot များကို ထိခိုက်မည်မဟုတ်ပါ။
• နောက်ထပ်အသုံးဝင်သောလုပ်ဆောင်ချက်မှာ Monitor ဖြစ်သည်။ ၎င်းသည် node သို့သွားသော တောင်းဆိုချက်စာရင်းတစ်ခုလုံးကို အချိန်နှင့်တပြေးညီကြည့်ရှုနိုင်မည်ဖြစ်သည်။ ထို့အပြင်၊ သင်သည် ၎င်းကို grep လုပ်ပြီး လိုအပ်သော traffic ရှိမရှိ ရှာဖွေနိုင်သည်။

မာစတာကျရှုံးခြင်းလုပ်ငန်းစဉ်ကိုလည်း မှတ်သားထိုက်သည်။ အတိုချုပ်ပြောရလျှင် ၎င်းသည်တည်ရှိပြီး ကျွန်ုပ်၏အမြင်အရ၊ ၎င်းသည် ကောင်းမွန်စွာအလုပ်လုပ်ပါသည်။ သို့သော်၊ မာစတာ node ပါသည့်စက်တွင် ပါဝါကြိုးကို ဖြုတ်ပါက Redis သည် ချက်ချင်းပြန်ပြောင်းမည်ဖြစ်ပြီး သုံးစွဲသူများ ဆုံးရှုံးမှုကို သတိပြုမိမည်မဟုတ်ကြောင်း မထင်ပါနှင့်။ ကျွန်ုပ်၏လက်တွေ့တွင်၊ ကူးပြောင်းမှုသည် စက္ကန့်အနည်းငယ်အတွင်း ဖြစ်ပေါ်ပါသည်။ ဤအချိန်အတောအတွင်း၊ ဒေတာအချို့ကို မရနိုင်ပါ- မာစတာ၏မရရှိနိုင်မှုကို တွေ့ရှိသည်၊ အသစ်တစ်ခုကို node များမဲပေးသည်၊ ကျွန်များကိုပြောင်းသည်၊ ဒေတာကို ထပ်တူပြုပါသည်။ အစီအစဥ်က အလုပ်ဖြစ်တယ်ဆိုတာကို သင်ကိုယ်တိုင်သေချာအောင် အကောင်းဆုံးနည်းလမ်းကတော့ ဒေသဆိုင်ရာ လေ့ကျင့်ခန်းတွေ ပြုလုပ်ဖို့ပါပဲ။ သင့်လက်တော့ပ်ပေါ်ရှိ အစုအဝေးကို မြှင့်တင်ပါ၊ အနည်းဆုံး ဝန်တစ်ခုပေးပါ၊ ပျက်စီးမှုတစ်ခု (ဥပမာ၊ ဆိပ်ကမ်းများကို ပိတ်ဆို့ခြင်းဖြင့်) ပုံဖော်ကာ ကူးပြောင်းမှုမြန်နှုန်းကို အကဲဖြတ်ပါ။ ကျွန်တော့်အမြင်အရတော့ ဒီနည်းလမ်းကို တစ်ရက်နှစ်ရက်လောက်ကစားပြီးမှသာ နည်းပညာရဲ့လည်ပတ်မှုကို သင်ယုံကြည်နိုင်မှာပါ။ ဒါမှမဟုတ် အင်တာနက် တစ်ဝက်လောက်သုံးတဲ့ ဆော့ဖ်ဝဲလ်က အဆင်ပြေမယ်လို့ မျှော်လင့်ပါတယ်။

configuration များ

မကြာခဏဆိုသလို၊ configuration သည် tool ဖြင့်စတင်အလုပ်လုပ်ရန်လိုအပ်သည့်ပထမဆုံးအရာဖြစ်သည်။ ၎င်းနှင့်အားလုံးအလုပ်လုပ်သောအခါ၊ config ကိုပင်မထိချင်ပါ။ ဆက်တင်များသို့ ပြန်သွားပြီး ဂရုတစိုက်ဖြတ်ကျော်ရန် သင့်ကိုယ်သင် အားထုတ်မှု အနည်းငယ် လိုအပ်သည်။ ကျွန်ုပ်၏မှတ်ဉာဏ်တွင်၊ ဖွဲ့စည်းမှုပုံစံကို ဂရုမစိုက်ခြင်းကြောင့် အနည်းဆုံး လေးနက်သော ချို့ယွင်းချက်နှစ်ခုရှိခဲ့သည်။ အောက်ပါအချက်များကို အထူးဂရုပြုပါ။

• အချစ်က 0
  မလှုပ်ရှားနိုင်သော ချိတ်ဆက်မှုများကို ပိတ်သည့်အချိန် (စက္ကန့်ပိုင်းအတွင်း)။ 0 - မပိတ်ပါနဲ့။
  ကျွန်ုပ်တို့၏ စာကြည့်တိုက်တိုင်းသည် ချိတ်ဆက်မှုများကို မှန်ကန်စွာ ပိတ်နိုင်ခြင်း မရှိပေ။ ဤဆက်တင်ကို ပိတ်ထားခြင်းဖြင့်၊ ကျွန်ုပ်တို့သည် သုံးစွဲသူအရေအတွက် ကန့်သတ်ချက်ကို ထိပါးရန် အန္တရာယ်ရှိသည်။ အခြားတစ်ဖက်တွင်၊ ထိုသို့သောပြဿနာရှိပါက၊ ပျောက်ဆုံးနေသောချိတ်ဆက်မှုများကို အလိုအလျောက်ရပ်စဲခြင်းသည် ၎င်းကိုဖုံးကွယ်ထားမည်ဖြစ်ပြီး ကျွန်ုပ်တို့သတိမထားမိနိုင်ပါ။ ထို့အပြင် ဆက်တင်ဆက်တင်များကို ဆက်လက်အသုံးပြုနေချိန်တွင် သင်သည် ဤဆက်တင်ကို မဖွင့်သင့်ပါ။
• xy ကို သိမ်းဆည်းပြီး နောက်ဆက်တွဲအနေနဲ့ ဟုတ်ပါတယ်။
  RDB လျှပ်တစ်ပြက်ဓာတ်ပုံကို သိမ်းဆည်းနေသည်။
  RDB/AOF ကိစ္စရပ်များကို အောက်တွင် အသေးစိတ် ဆွေးနွေးပါမည်။
• stop-writes-on-bgsave-error no & slave-serve-stale-data yes
  ဖွင့်ထားလျှင် RDB လျှပ်တစ်ပြက်ရိုက်ချက် ပျက်သွားပါက မာစတာသည် ပြောင်းလဲမှု တောင်းဆိုချက်များကို လက်ခံခြင်းကို ရပ်သွားပါမည်။ မာစတာနှင့် ချိတ်ဆက်မှု ပျောက်ဆုံးပါက၊ ကျွန်သည် တောင်းဆိုမှုများကို ဆက်လက်တုံ့ပြန်နိုင်သည် (ဟုတ်သည်)။ သို့မဟုတ် တုံ့ပြန်မှု ရပ်သွားမည် (မဟုတ်ပါ)၊
  Redis သည် ရွှေဖရုံသီးအဖြစ်သို့ ပြောင်းလဲသွားသည့် အခြေအနေအတွက် ကျွန်ုပ်တို့ မကျေနပ်ပါ။
• repl-ping-slave-period ၅
  ဤအချိန်ကာလပြီးနောက်၊ သခင်ပြိုကွဲသွားပြီး ပျက်ကွက်မှုလုပ်ငန်းစဉ်ကို ဆောင်ရွက်ရန်အချိန်ကျပြီဟု ကျွန်ုပ်တို့ စတင်စိုးရိမ်လာပါမည်။
  မှားယွင်းသော အပြုသဘောဆောင်မှုများနှင့် ရှုံးနိမ့်မှုကို အစပျိုးခြင်းကြား ချိန်ခွင်လျှာကို ကိုယ်တိုင်ရှာဖွေရမည်ဖြစ်ပါသည်။ ကျွန်ုပ်တို့၏အလေ့အကျင့်တွင်ဤသည် 5 စက္ကန့်ဖြစ်သည်။
• repl-backlog-size 1024mb & epl-backlog-ttl 0
  မအောင်မြင်သော ပုံစံတူအတွက် ဒေတာများစွာကို ကြားခံတစ်ခုတွင် ကျွန်ုပ်တို့ အတိအကျ သိမ်းဆည်းနိုင်ပါသည်။ ကြားခံကုန်သွားပါက၊ သင်သည် လုံးဝထပ်တူပြုရပါမည်။
  အလေ့အကျင့်က ပိုမြင့်တဲ့တန်ဖိုးကို သတ်မှတ်တာ ပိုကောင်းတယ်လို့ အကြံပြုပါတယ်။ ပုံတူတစ်ခုသည် နောက်ကျသွားနိုင်သည့် အကြောင်းရင်းများစွာရှိပါသည်။ နောက်ကျနေပါက၊ သင်၏သခင်သည် ရင်ဆိုင်ရန် ရုန်းကန်နေရပြီဖြစ်ပြီး အပြည့်အဝ ထပ်တူပြုခြင်းသည် နောက်ဆုံးကောက်ရိုးဖြစ်သည်။
• maxclients 10000
  တစ်ကြိမ်တည်း အသုံးပြုသူ အများဆုံးအရေအတွက်။
  ကျွန်ုပ်တို့၏အတွေ့အကြုံအရ၊ မြင့်မားသောတန်ဖိုးကို သတ်မှတ်ခြင်းသည် ပိုမိုကောင်းမွန်ပါသည်။ Redis သည် 10k ချိတ်ဆက်မှုများကို ကောင်းမွန်စွာကိုင်တွယ်သည်။ စနစ်တွင် socket များ လုံလုံလောက်လောက်ရှိကြောင်း သေချာပါစေ။
• maxmemory-policy volatile-ttl
  ရနိုင်သောမှတ်ဉာဏ်ကန့်သတ်ချက်သို့ရောက်ရှိသောအခါသော့များကိုဖျက်ပစ်သည့်စည်းမျဉ်း။
  ဤနေရာတွင် အရေးကြီးသည်မှာ စည်းကမ်းကိုယ်တိုင်မဟုတ်၊ မည်သို့မည်ပုံ ဖြစ်လာမည်ကို နားလည်ရန်ဖြစ်သည်။ Memory ကန့်သတ်ချက်ပြည့်သွားသောအခါတွင် Redis သည် ပုံမှန်အတိုင်း အလုပ်လုပ်နိုင်သည့်အတွက် ချီးကျူးနိုင်ပါသည်။

RDB နှင့် AOF ပြဿနာများ

Redis ကိုယ်တိုင်က အချက်အလက်အားလုံးကို RAM မှာ သိမ်းဆည်းထားပေမယ့် ဒေတာတွေကို disk မှာ သိမ်းဆည်းနိုင်တဲ့ ယန္တရားလည်း ရှိပါတယ်။ ပိုမိုတိကျစွာ၊ ယန္တရားသုံးခု

• RDB-snapshot - ဒေတာအားလုံး၏ ပြီးပြည့်စုံသော လျှပ်တစ်ပြက်ဓာတ်ပုံ။ SAVE XY ဖွဲ့စည်းမှုပုံစံကို အသုံးပြုပြီး သတ်မှတ်ပြီး "အနည်းဆုံး Y သော့များ ပြောင်းလဲသွားပါက X စက္ကန့်တိုင်း ဒေတာအားလုံးကို လျှပ်တစ်ပြက်တစ်ပုံချင်းစီ သိမ်းဆည်းပါ။"
• နောက်ဆက်တွဲ-သပ်သပ်ဖိုင် - ၎င်းတို့လုပ်ဆောင်သည့်အစီအစဥ်အတိုင်း လုပ်ဆောင်ချက်များစာရင်း။ X စက္ကန့်တိုင်း သို့မဟုတ် Y လုပ်ဆောင်ချက်တိုင်းကို ဖိုင်ထဲသို့ ဝင်လာသော လုပ်ဆောင်ချက်အသစ်များကို ပေါင်းထည့်သည်။
• RDB နှင့် AOF သည် ယခင်နှစ်ခု၏ပေါင်းစပ်မှုဖြစ်သည်။

နည်းလမ်းအားလုံးတွင် ၎င်းတို့၏ အားသာချက်များနှင့် အားနည်းချက်များ ရှိသည်၊ ကျွန်ုပ်သည် ၎င်းတို့အားလုံးကို စာရင်းပြုစုမည်မဟုတ်ပါ၊ ကျွန်ုပ်၏အမြင်အရ၊ မထင်ရှားသောအချက်များကိုသာ အာရုံစိုက်ပါမည်။

ပထမဦးစွာ RDB လျှပ်တစ်ပြက်ရိုက်ချက်တစ်ခုကို သိမ်းဆည်းခြင်းသည် FORK ကိုခေါ်ဆိုရန် လိုအပ်သည်။ ဒေတာများစွာရှိပါက၊ ၎င်းသည် Redis အားလုံးကို မီလီစက္ကန့်အနည်းငယ်မှ တစ်စက္ကန့်အထိ အချိန်ဆွဲထားနိုင်သည်။ ထို့အပြင်၊ စနစ်သည် ထိုသို့သောလျှပ်တစ်ပြက်ရိုက်ချက်အတွက် မမ်မိုရီကို ခွဲဝေပေးရန်လိုအပ်ပြီး ယုတ္တိစက်တွင် RAM နှစ်ဆထောက်ပံ့ပေးရန် လိုအပ်သည်- Redis အတွက် 8 GB ကို ခွဲဝေပေးမည်ဆိုလျှင် 16 GB ကို virtual machine တွင်ရရှိနိုင်သင့်သည်။ အဲဒါ။

ဒုတိယအနေဖြင့်၊ တစ်စိတ်တစ်ပိုင်းထပ်တူပြုခြင်းတွင်ပြဿနာများရှိသည်။ AOF မုဒ်တွင်၊ slave ကို ပြန်လည်ချိတ်ဆက်သောအခါ၊ တစ်စိတ်တစ်ပိုင်း ထပ်တူပြုခြင်းအစား၊ အပြည့်အဝ ထပ်တူပြုခြင်းကို လုပ်ဆောင်နိုင်သည်။ ဘာ့ကြောင့် ဒီလိုဖြစ်သွားတာလဲ ကျွန်တော် နားမလည်နိုင်ခဲ့ပါ။ ဒါပေမယ့် ဒါကို မှတ်သားထိုက်ပါတယ်။

ဤအချက်နှစ်ချက်သည် ကျေးကျွန်များ ပွားနေပြီးသားဖြစ်ပါက disk ပေါ်ရှိ ဤဒေတာကို အမှန်တကယ် လိုအပ်ခြင်းရှိမရှိ စဉ်းစားပေးထားပြီးဖြစ်သည်။ slave အားလုံး ပျက်ကွက်မှသာ ဒေတာ ဆုံးရှုံးနိုင်ပြီး၊ ၎င်းသည် "DC in the fire" အဆင့် ပြဿနာ ဖြစ်သည်။ အပေးအယူတစ်ခုအနေဖြင့်၊ သင်သည် ကျွန်များပေါ်တွင်သာ ဒေတာသိမ်းဆည်းရန် အဆိုပြုနိုင်သော်လည်း ဤအခြေအနေတွင် ဤကျွန်များသည် ဘေးဥပဒ်ပြန်လည်ရရှိချိန်တွင် မည်သည့်အခါမျှ သခင်ဖြစ်လာမည်မဟုတ်ကြောင်း သေချာရန် လိုအပ်သည် (၎င်းအတွက် ၎င်းအတွက် ၎င်းတို့၏ config တွင် ကျွန်ဦးစားပေးဆက်တင်ရှိပါသည်)။ ကျွန်ုပ်တို့ကိုယ်တိုင်အတွက်၊ သီးခြားကိစ္စတစ်ခုစီတွင် ကျွန်ုပ်တို့သည် ဒေတာကို disk သို့သိမ်းဆည်းရန် လိုအပ်သည်ရှိမရှိကို ကျွန်ုပ်တို့စဉ်းစားကြပြီး အများစုမှာ အဖြေမှာ “မဟုတ်” ပါ။

ကောက်ချက်

နိဂုံးချုပ်အနေဖြင့်၊ လုံးဝမကြားရသေးသူများအတွက် redis-cluster အလုပ်လုပ်ပုံကို ယေဘူယျအကြံဥာဏ်တစ်ခုပေးနိုင်မည်ဟု မျှော်လင့်ပြီး ၎င်းကိုအသုံးပြုနေသူများအတွက် ထင်ရှားမဟုတ်သောအချက်အချို့ကိုလည်း အာရုံစိုက်စေပါသည်။ အချိန်ကြာမြင့်စွာ။
သင့်အချိန်အတွက် ကျေးဇူးတင်ပြီး ခေါင်းစဉ်နှင့်ပတ်သက်သည့် မှတ်ချက်များကို အမြဲကြိုဆိုပါသည်။

source: www.habr.com