Redis ကို အသုံးပြု၍ ဖြန့်ဝေသောသော့ခတ်ခြင်း။

ဟေး ဟာဘ!

ယနေ့ ကျွန်ုပ်တို့သည် Redis ကို အသုံးပြု၍ ဖြန့်ဝေသောသော့ခတ်ခြင်းကို အကောင်အထည်ဖော်ခြင်းအကြောင်း ရှုပ်ထွေးသောဆောင်းပါးတစ်ပုဒ်ကို ဘာသာပြန်ပြီး သင့်အား အကြောင်းအရာတစ်ခုအနေဖြင့် Redis ၏အလားအလာများအကြောင်း ဆွေးနွေးရန် ဖိတ်ခေါ်အပ်ပါသည်။ စာအုပ်ရေးသားသူ Martin Kleppmann မှ Redlock algorithm ကို လေ့လာခြင်းမြင့်မားသောလျှောက်လွှာများ" ၊ ပေးသည် ဒီမှာ.

Distributed locking သည် မတူညီသော လုပ်ငန်းစဉ်များ အပြန်အလှန် သီးသန့်ပုံစံဖြင့် မျှဝေထားသော အရင်းအမြစ်များပေါ်တွင် လုပ်ဆောင်ရမည့် ပတ်ဝန်းကျင်များစွာတွင် အသုံးပြုသည့် အလွန်အသုံးဝင်သော မူလအစဖြစ်သည်။

Redis ကို အသုံးပြု၍ DLM (Distributed Lock Manager) ကို အကောင်အထည်ဖော်နည်းကို ဖော်ပြသည့် စာကြည့်တိုက်များနှင့် ပို့စ်များစွာရှိသော်လည်း စာကြည့်တိုက်တစ်ခုစီသည် မတူညီသောချဉ်းကပ်နည်းနှင့် ၎င်းတို့ပေးဆောင်သော အာမခံချက်များသည် အနည်းငယ်ပိုမိုဆန်းပြားသောဒီဇိုင်းဖြင့် ရရှိနိုင်သည့်အရာများနှင့် နှိုင်းယှဉ်ပါက အတော်လေး အားနည်းပါသည်။

ဤဆောင်းပါးတွင် Redis ကို အသုံးပြု၍ ဖြန့်ဝေသောသော့ခတ်ခြင်းကို မည်သို့အကောင်အထည်ဖော်ရမည်ကို သရုပ်ပြသည့် အခြေအနေအလိုက် canonical algorithm တစ်ခုကို ဖော်ပြရန် ကြိုးစားပါမည်။ ခေါ်တဲ့ algorithm အကြောင်း ပြောပြပါမယ်။ သော့ခတ်၎င်းသည် ဖြန့်ဝေသောသော့ခတ်မန်နေဂျာကို အကောင်အထည်ဖော်ပြီး ကျွန်ုပ်တို့၏အမြင်အရ၊ ဤအယ်လဂိုရီသမ်သည် ပုံမှန်သာဓကတစ်ခုတည်းချဉ်းကပ်မှုထက် ပိုလုံခြုံသည်။ အသိုက်အဝန်းသည် ၎င်းကို ပိုင်းခြားစိတ်ဖြာပြီး တုံ့ပြန်ချက်ပေးကာ ပိုမိုရှုပ်ထွေးသော သို့မဟုတ် အခြားရွေးချယ်စရာ ပရောဂျက်များအတွက် အစမှတ်အဖြစ် အသုံးပြုမည်ဟု မျှော်လင့်ပါသည်။

အကောင်အထည်ဖော်ခြင်း

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

• Redlock-rb (ပတ္တမြားအတွက် အကောင်အထည်ဖော်ခြင်း)။ လည်းရှိတယ်။ အမဲချိတ် ဖြန့်ဖြူးရာတွင် လွယ်ကူစေရန်အတွက် ပက်ကေ့ဂျ် (ကျောက်မျက်) ကို ပေါင်းထည့်သည့် Redlock-rb၊
• Redlock-py (Python အကောင်အထည်ဖော်မှု)။
• Airedlock (Asyncio Python အတွက် အကောင်အထည်ဖော်မှု)။
• Redlock-php ( PHP အတွက် အကောင်အထည်ဖော်ခြင်း)။
• PHPRedisMutex ( PHP အတွက် အခြားသော အကောင်အထည်ဖော်မှု)
• cheprasov/php-redis-lock (သော့ခတ်များအတွက် PHP စာကြည့်တိုက်)
• RedSync (သွားရန်အတွက် အကောင်အထည်ဖော်ခြင်း)။
• ပြန်လည်ပြင်ဆင်ခြင်း။ (Java အတွက် အကောင်အထည်ဖော်မှု)။
• Redis::DistLock (Perl အတွက် အကောင်အထည်ဖော်မှု)။
• Redlock-cpp (C++ အတွက် အကောင်အထည်ဖော်ခြင်း)။
• Redlock-cs (C#/.NET အတွက် အကောင်အထည်ဖော်မှု)။
• RedLock.net (C#/.NET အတွက် အကောင်အထည်ဖော်မှု)။ async နှင့် lock extensions များအတွက် ပံ့ပိုးမှုဖြင့်။
• ScarletLock (Configureable data store ဖြင့် C# .NET အတွက် အကောင်အထည်ဖော်ခြင်း)
• Redlock4Net (C# .NET အတွက် အကောင်အထည်ဖော်ခြင်း)
• node-redlock (NodeJS အတွက် အကောင်အထည်ဖော်မှု)။ သော့ချဲ့ခြင်းအတွက် ပံ့ပိုးမှု ပါဝင်သည်။

လုံခြုံရေးနှင့် ရရှိနိုင်မှု အာမခံချက်များ

ဖြန့်ဝေသောသော့ခတ်ခြင်းကို ထိထိရောက်ရောက်အသုံးပြုရန် လိုအပ်သော အနည်းဆုံးအာမခံချက်ပေးမည်ဟု ကျွန်ုပ်တို့ထင်မြင်သည့် ဂုဏ်သတ္တိသုံးခုမျှဖြင့် ကျွန်ုပ်တို့၏ဒီဇိုင်းကို စံနမူနာပြုပါမည်။

1. လုံခြုံရေး ပိုင်ဆိုင်မှု- အပြန်အလှန် ချန်လှပ်မှု။ သတ်မှတ်ထားသောအချိန်တွင်၊ သုံးစွဲသူတစ်ဦးတည်းသာသော့ကို ကိုင်ထားနိုင်သည်။
2. ရရှိနိုင်မှုပိုင်ဆိုင်မှု A- သော့ခတ်မှုများမရှိပါ။ အရင်းအမြစ်ကို လော့ခ်ချသောကလိုင်းယင့်သည် ပျက်ကွက်ခြင်း သို့မဟုတ် မတူညီသောဒစ်အပိုင်းတစ်ခုပေါ်တွင် ဆင်းသက်လာလျှင်ပင် နောက်ဆုံးတွင် လော့ခ်တစ်ခုရရှိရန် အမြဲတမ်းဖြစ်နိုင်သည်။
3. ရရှိနိုင်မှု ပိုင်ဆိုင်မှု B- Fault Tolerance Redis node အများစုသည် အလုပ်လုပ်နေသရွေ့၊ client များသည် သော့ခလောက်များကို ရယူပြီး ထုတ်ပေးနိုင်သည်။

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

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

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

ထင်ရှားသည်မှာ ထိုကဲ့သို့သော မော်ဒယ်တွင် ပြိုင်ပွဲအခြေအနေတစ်ခု ဖြစ်ပေါ်သည်-

1. ဖောက်သည် A သည် မာစတာပေါ်တွင် သော့ခတ်မှုတစ်ခု ရရှိသည်။
2. သော့ဝင်ရောက်မှုကို ကျွန်ထံမလွှဲပြောင်းမီ မာစတာသည် ပျက်ကွက်သည်။
3. နောက်လိုက်ကို ခေါင်းဆောင်အဖြစ် ရာထူးတိုးတယ်။
4. Client B သည် A သော့ခတ်ထားပြီးဖြစ်သော တူညီသောအရင်းအမြစ်တွင် သော့ခတ်ခြင်းကို ရယူသည်။ လုံခြုံရေးချိုးဖောက်မှု။

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

သာဓကတစ်ခုတည်းဖြင့် မှန်ကန်စွာ အကောင်အထည်ဖော်ပါ။

အထက်တွင်ဖော်ပြထားသော single-instance configuration ၏ချို့ယွင်းချက်များကို ကျော်လွှားရန် မကြိုးစားမီ၊ ဤရိုးရှင်းသောကိစ္စရပ်ကို ကောင်းစွာကိုင်တွယ်နည်းကို နားလည်ကြပါစို့၊ အဘယ်ကြောင့်ဆိုသော် ဤဖြေရှင်းချက်သည် ပြိုင်ပွဲအခြေအနေတစ်ခုအား အခါအားလျော်စွာ လက်ခံနိုင်သော အပလီကေးရှင်းများတွင် အမှန်တကယ် အကျုံးဝင်သောကြောင့်လည်းကောင်း၊ single instance သည် ဤနေရာတွင် ဖော်ပြထားသော ဖြန့်ဝေထားသော algorithm တွင် အသုံးပြုသော အခြေခံအဖြစ် ဆောင်ရွက်ပါသည်။

လော့ခ်တစ်ခုရယူရန်၊ ဤအရာကိုလုပ်ဆောင်ပါ-

SET resource_name my_random_value NX PX 30000

30000 မီလီစက္ကန့် (PX ရွေးချယ်မှု) ဖြင့် တရားဝင်မှုကာလ XNUMX မီလီစက္ကန့် (NX ရွေးချယ်မှု) မရှိသေးမှသာ ဤအမိန့်မှာ သော့တစ်ခုကို ထည့်သွင်းပါသည်။ သော့ကို "myrandomvalue“ ဤတန်ဖိုးသည် သုံးစွဲသူများအားလုံးနှင့် လော့ခ်ချတောင်းဆိုမှုအားလုံးတွင် သီးသန့်ဖြစ်ရပါမည်။
အခြေခံအားဖြင့်၊ Redis ကိုပြောသော script တစ်ခုဖြင့် လော့ခ်ကို ဘေးကင်းစွာ လွှတ်ပေးရန် ကျပန်းတန်ဖိုးကို အသုံးပြုသည်- ၎င်းတွင် ရှိနေပါက သော့ကိုသာ ဖယ်ရှားပြီး ၎င်းတွင် သိမ်းဆည်းထားသည့် တန်ဖိုးသည် မျှော်လင့်ထားသည့်အတိုင်း အတိအကျဖြစ်သည်။ အောက်ပါ Lua script ကို အသုံးပြု၍ ၎င်းကို အောင်မြင်သည် ။

if redis.call("get",KEYS[1]) == ARGV[1] then
    return redis.call("del",KEYS[1])
else
    return 0
end

အခြား client မှကိုင်ဆောင်ထားသောသော့ကိုဖယ်ရှားခြင်းမှကာကွယ်ရန်၎င်းသည်အရေးကြီးပါသည်။ ဥပမာအားဖြင့်၊ client သည် လော့ခ်တစ်ခုရရှိနိုင်ပြီး၊ ထို့နောက် ပထမသော့ထက် ပိုကြာသည့်လုပ်ဆောင်ချက်အချို့တွင် သော့ခတ်သွားသည် (ထို့ကြောင့် သော့သည် သက်တမ်းကုန်ဆုံးရန်အချိန်ရှိသည်) နှင့် နောက်ပိုင်းတွင် အခြား client အချို့ချထားသောသော့ကို ဖယ်ရှားလိုက်ပါ။
ရိုးရှင်းသော DEL ကို အသုံးပြုခြင်းသည် ကလိုင်းယင့်သည် အခြားကလိုင်းယင့်မှ ကိုင်ဆောင်ထားသောသော့ကို ဖယ်ရှားနိုင်သောကြောင့် မလုံခြုံပါ။ ဆန့်ကျင်ဘက်အနေနှင့်၊ အထက်ဖော်ပြပါ script ကိုအသုံးပြုသည့်အခါ၊ လော့ခ်တစ်ခုစီသည် ကျပန်းစာတန်းတစ်ခုဖြင့် "လက်မှတ်ထိုးထားသည်" ဖြစ်သောကြောင့် ယခင်ချထားပေးသော client ကသာ ၎င်းကိုဖယ်ရှားနိုင်သည်။

ဤကျပန်းကြိုးသည် အဘယ်အရာဖြစ်သင့်သနည်း။ /dev/urandom မှ 20 bytes ဖြစ်သင့်သည်ဟု ကျွန်ုပ်ထင်သည်၊ သို့သော် သင့်ရည်ရွယ်ချက်များအတွက် လုံလောက်သော string ကိုထူးခြားစေရန်အတွက် စျေးနည်းသောနည်းလမ်းများကို သင်ရှာဖွေနိုင်ပါသည်။ ဥပမာအားဖြင့်၊ RC4 ကို /dev/urandom ဖြင့် မျိုးစေ့ချပြီး ၎င်းမှ pseudo-random stream ကိုထုတ်ပေးခြင်းသည် ကောင်းမွန်ပါသည်။ ပိုမိုရိုးရှင်းသောဖြေရှင်းချက်တစ်ခုတွင် microsecond resolution နှင့် client ID တွင် unix time ပေါင်းစပ်ပါဝင်ပါသည်။ ၎င်းသည် မလုံခြုံသော်လည်း အခြေအနေအများစုတွင် ၎င်းသည် အလုပ်နှင့်ပတ်သက်သည်။

သော့၏သက်တမ်းကို တိုင်းတာရန် ကျွန်ုပ်တို့အသုံးပြုသည့်အချိန်ကို "သော့တစ်သက်တာ" ဟုခေါ်သည်။ ဤတန်ဖိုးသည် သော့ခတ်ခြင်းကို အလိုအလျောက်မထုတ်ပြန်မီ အချိန်ပမာဏနှင့် အခြားဖောက်သည်တစ်ဦးသည် အပြန်အလှန်ဖယ်ထုတ်ခြင်းဆိုင်ရာ အာမခံချက်များကို ချိုးဖောက်ခြင်းမရှိဘဲ အခြားဖောက်သည်တစ်ဦးမှ အဆိုပါအရင်းအမြစ်ကို လော့ခ်ချခြင်းမပြုမီ လည်ပတ်မှုတစ်ခုပြီးမြောက်ရန် အချိန်ပမာဏနှစ်ခုလုံးဖြစ်သည်။ ဤအာမခံချက်သည် လော့ခ်ချသည့်အချိန်မှ စတင်သည့် အချိန်ကာလတစ်ခုအတွင်းသာ ကန့်သတ်ထားသည်။

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

Redlock algorithm

ဖြန့်ဝေထားသော အယ်လဂိုရီသမ်၏ ဗားရှင်းသည် ကျွန်ုပ်တို့တွင် N Redis မာစတာများရှိသည်ဟု ယူဆသည်။ ဤဆုံမှတ်များသည် တစ်ခုနှင့်တစ်ခု လုံးလုံးလျားလျား ကင်းကွာသောကြောင့် ကျွန်ုပ်တို့သည် ပုံတူပွားခြင်း သို့မဟုတ် အခြားသော သွယ်ဝိုက်သောညှိနှိုင်းရေးစနစ်ကို မသုံးပါ။ သာဓကတစ်ခုတည်းတွင် သော့ခတ်ခြင်းကို လုံလုံခြုံခြုံရယူနည်းနှင့် ထုတ်လွှတ်နည်းကို ကျွန်ုပ်တို့ ခြုံငုံပြီးဖြစ်သည်။ ဥပမာတစ်ခုနှင့်အလုပ်လုပ်သောအခါ algorithm သည် ဤနည်းလမ်းကို အတိအကျအသုံးပြုမည်ကို ကျွန်ုပ်တို့လက်ခံပါသည်။ ကျွန်ုပ်တို့၏နမူနာများတွင် ကျိုးကြောင်းဆီလျော်သောတန်ဖိုးဖြစ်သည့် N ကို 5 ဟု သတ်မှတ်သည်။ ထို့ကြောင့်၊ ၎င်းတို့သည် တစ်ခုနှင့်တစ်ခု သီးခြားလွတ်လပ်စွာ လုပ်ဆောင်နိုင်စေရန် သေချာစေရန် မတူညီသော ကွန်ပျူတာများ သို့မဟုတ် virtual machine များတွင် Redis master 5 ခုကို အသုံးပြုရန် လိုအပ်ပါသည်။

လော့ခ်တစ်ခုရယူရန်၊ client သည် အောက်ပါလုပ်ဆောင်ချက်များကို လုပ်ဆောင်သည်-

1. လက်ရှိအချိန်ကို မီလီစက္ကန့်ဖြင့် ရရှိသည်။
2. ကိစ္စရပ်တိုင်းတွင် တူညီသောသော့အမည်နှင့် ကျပန်းတန်ဖိုးများကို အသုံးပြု၍ N ဖြစ်ရပ်များအားလုံးတွင် လော့ခ်တစ်ခုရရှိရန် ဆက်တိုက်ကြိုးပမ်းသည်။ အဆင့် 2 တွင်၊ client သည် သော့ကို တစ်ကြိမ်စီတွင် အခြေခံ၍ သတ်မှတ်သောအခါတွင်၊ client သည် လော့ခ်ကို အလိုအလျောက်ထုတ်ပြီးသည့်အချိန်နှင့် နှိုင်းယှဉ်ပါက ၎င်းကိုရရှိရန် နှောင့်နှေးမှုကို အသုံးပြုသည်။ ဥပမာအားဖြင့်၊ ပိတ်ဆို့ခြင်းကြာချိန်သည် 10 စက္ကန့်ဖြစ်ပါက၊ နှောင့်နှေးမှုသည် ~ 5-50 မီလီစက္ကန့်အတွင်း ဖြစ်နိုင်သည်။ ၎င်းသည် မအောင်မြင်သော Redis node တစ်ခုသို့ရောက်ရှိရန် ကြိုးပမ်းရာတွင် အချိန်အကြာကြီး ပိတ်ဆို့ထားနိုင်သည့် client ၏အခြေအနေကို ဖယ်ရှားပေးသည်- ဥပမာ မရနိုင်ပါက၊ ကျွန်ုပ်တို့သည် အခြားဥပမာတစ်ခုသို့ အမြန်ဆုံးချိတ်ဆက်ရန် ကြိုးစားသည်။
3. သော့ခတ်ရန်၊ client သည် အချိန်မည်မျှကြာသွားသည်ကို တွက်ချက်သည်။ ၎င်းကိုလုပ်ဆောင်ရန်၊ ၎င်းသည် အဆင့် 1 တွင်ရရှိသောအချိန်တံဆိပ်ကို အမှန်တကယ်အချိန်တန်ဖိုးမှနုတ်နုတ်သည်။ အကယ်၍ အမှုသည်အများစု (အနည်းဆုံး 3) တွင်သော့ခတ်ခြင်းကို ရယူနိုင်ခဲ့ပါက၊ နှင့် စုစုပေါင်းအချိန်ကြာမြင့်မည်ဖြစ်သည်။ သော့ကိုရယူသည်၊ သော့ခတ်ချိန်ထက်နည်းသည်၊ သော့ကိုရရှိခဲ့သည်ဟုယူဆသည်။
4. လော့ခ်တစ်ခုရရှိပါက လော့ခ်ဖွင့်ချိန်ကို မူလလော့ခ်ကြာချိန်အဖြစ် အဆင့် 3 တွင် တွက်ချက်ထားသော လွန်သွားသောအချိန်ကို အနုတ်လက္ခဏာအဖြစ် သတ်မှတ်သည်။
5. အကယ်၍ client သည် အကြောင်းတစ်ခုခုကြောင့် လော့ခ်မရရှိပါက (၎င်းသည် N/2+1 instances များကို လော့ခ်မချနိုင်ခြင်း သို့မဟုတ် လော့ခ်ချသည့်ကြာချိန်သည် အနုတ်လက္ခဏာဖြစ်နိုင်သည်)၊ ထို့နောက် ၎င်းသည် ဖြစ်ရပ်အားလုံးကို လော့ခ်ဖွင့်ရန် ကြိုးပမ်းလိမ့်မည် (၎င်းကို မပိတ်ဆို့နိုင်ဟု ထင်ထားသည့်တိုင် )

အယ်လဂိုရီသမ်သည် ဆန့်ကျင်ဘက်ဖြစ်နေပါသလား။

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

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

အောက်ဖော်ပြပါ စိတ်ဝင်စားစရာကောင်းသော ဆောင်းပါးသည် အချိန်အပိုင်းအခြားများကို ညှိနှိုင်းရန် လိုအပ်သော စနစ်များအကြောင်း ပိုမိုပြောပြသည်- ငှားရမ်းမှုများ- ဖြန့်ဝေဖိုင် ကက်ရှ် ညီညွတ်မှုအတွက် ထိရောက်သော အမှားအယွင်းများကို ခံနိုင်ရည်ရှိသော ယန္တရား.

ရှုံးနိမ့်မှုကို ပြန်ကြိုးစားပါ။

ဖောက်သည်တစ်ဦးသည် လော့ခ်ချရန် ပျက်ကွက်သောအခါ၊ ကျပန်းနှောင့်နှေးပြီးနောက် ထပ်မံကြိုးစားရမည်ဖြစ်သည်။ ၎င်းသည် တစ်ချိန်တည်းတွင် အရင်းအမြစ်တစ်ခုတည်းရှိ သော့ခတ်မှုကို ရယူရန် ကြိုးစားနေသည့် client အများအပြားကို synchronize လုပ်ခြင်းအား ဖယ်ရှားရန် လုပ်ဆောင်သည် (၎င်းသည် အနိုင်ရသူမရှိသည့် "split-bin" အခြေအနေကို ဖြစ်ပေါ်စေနိုင်သည်)။ ထို့အပြင်၊ ဖောက်သည်တစ်ဦးသည် Redis ဖြစ်ရပ်အများစုတွင် သော့ခတ်ရန်ကြိုးစားလေလေ၊ ဦးနှောက်ကွဲသည့်အခြေအနေဖြစ်ပေါ်လာနိုင်သည့် ပြတင်းပေါက်သည် ကျဉ်းလေလေ (နှင့် ထပ်မံကြိုးစားရန် လိုအပ်လေလေ)။ ထို့ကြောင့်၊ အကောင်းဆုံးအားဖြင့်၊ client သည် multiplexing ကိုအသုံးပြု၍ N instances သို့ SET command များကို တပြိုင်နက်ပေးပို့ရန် ကြိုးစားသင့်သည်။

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

သော့ကို လွှတ်လိုက်ပါ။

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

လုံခြုံရေး ထည့်သွင်းစဉ်းစားမှုများ

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

စစချင်းအားဖြင့်၊ ကလိုင်းယင့်သည် သာဓကအများစုတွင် သော့ခတ်ခြင်းကို ရယူနိုင်ခဲ့သည်ဟု ယူဆကြပါစို့။ ဥပမာ တစ်ခုစီတွင် အားလုံးအတွက် တူညီသော တစ်သက်တာ သော့တစ်ခု ပါရှိသည်။ သို့သော်၊ ဤသော့တစ်ခုစီကို မတူညီသောအချိန်တစ်ခုတွင် ထည့်သွင်းထားသောကြောင့် ၎င်းတို့သည် မတူညီသောအချိန်များတွင် သက်တမ်းကုန်ဆုံးမည်ဖြစ်သည်။ သို့သော်၊ အကယ်၍ ပထမသော့ကို T1 ထက်မဆိုးဘဲ (ပထမဆာဗာကို မဆက်သွယ်မီ ကျွန်ုပ်တို့ရွေးချယ်သည့်အချိန်) နှင့် T2 ထက်မဆိုးဘဲ တစ်ချိန်တည်းတွင် နောက်ဆုံးသော့ကို ထည့်သွင်းခဲ့သည် (တုံ့ပြန်မှုရရှိသည့်အချိန်၊ နောက်ဆုံး server မှ) ထို့နောက် သက်တမ်းကုန်ဆုံးသည့် set အတွင်းရှိ ပထမသော့သည် အနည်းဆုံး အသက်ရှင်နေမည်ဟု ကျွန်ုပ်တို့ ယုံကြည်ပါသည်။ MIN_VALIDITY=TTL-(T2-T1)-CLOCK_DRIFT. အခြားသော့များအားလုံးသည် နောက်ပိုင်းတွင် သက်တမ်းကုန်မည်ဖြစ်သဖြင့် သော့များအားလုံးသည် အနည်းဆုံး ဤတစ်ကြိမ်တွင် တစ်ပြိုင်နက် သက်တမ်းရှိမည်ဖြစ်ကြောင်း ကျွန်ုပ်တို့ စိတ်ချနိုင်ပါသည်။

N/2+1 SET NX လုပ်ဆောင်ချက်များသည် N/2+1 သော့များရှိပြီးသားဆိုလျှင် မအောင်မြင်နိုင်သောကြောင့် သော့အများစုသည် တရားဝင်ကျန်ရှိနေသည့်အချိန်အတွင်း၊ အခြား client သည် လော့ခ်ကို ရယူနိုင်မည်မဟုတ်ပါ။ ထို့ကြောင့် သော့ခတ်ပြီးသည်နှင့် တစ်ပြိုင်နက်တည်းတွင် ၎င်းကို ထပ်မံရယူရန် မဖြစ်နိုင်တော့သည် (၎င်းသည် အပြန်အလှန် ချန်လှပ်ထားသည့် ပိုင်ဆိုင်မှုကို ချိုးဖောက်ရာရောက်သည်)။
သို့သော်၊ တစ်ချိန်တည်းတွင်သော့ကိုရယူရန်ကြိုးစားနေသောဖောက်သည်များစွာသည်တစ်ချိန်တည်းတွင်မအောင်မြင်ကြောင်းသေချာစေလိုပါသည်။

ကလိုင်းယင့်သည် အများဆုံးသော့ခတ်မှုကြာချိန်ထက် သာမာန်အများစုကို လော့ခ်ချထားပါက၊ လော့ခ်မမှန်ကန်ကြောင်း ယူဆပြီး ဖြစ်ရပ်များကို လော့ခ်ဖွင့်ပေးမည်ဖြစ်သည်။ ထို့ကြောင့်၊ client သည် သက်တမ်းကုန်ဆုံးရက်ထက် နည်းသည့်အချိန်အတွင်း သာဓကအများစုကို ပိတ်ဆို့နိုင်ခဲ့သည့်ကိစ္စတွင်သာ ထည့်သွင်းစဉ်းစားရန်လိုသည်။ ဤကိစ္စနှင့် ပတ်သက်၍ အထက်ဖော်ပြပါ အငြင်းအခုံများ အချိန်အတောအတွင်း၊ MIN_VALIDITY မည်သည့် client မှ သော့ကို ပြန်လည်ရရှိနိုင်မည်မဟုတ်ပါ။ ထို့ကြောင့်၊ သော့ခတ်ရန်အချိန်အများစုသည် TTL အချိန်ထက် ပိုကြီးနေမှသာလျှင် သုံးစွဲသူအများအပြားသည် N/2+1 ဖြစ်ရပ်များကို တစ်ချိန်တည်းတွင် လော့ခ်ချနိုင်မည်ဖြစ်သည်။

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

သုံးစွဲနိုင်မှု ထည့်သွင်းစဉ်းစားမှုများ

စနစ်ရရှိနိုင်မှုမှာ အဓိကလက္ခဏာ သုံးခုအပေါ် မူတည်သည်-

1. သော့ခများ အလိုအလျောက် ထုတ်ပေးသည် (သော့များ သက်တမ်းကုန်သွားသည်နှင့်အမျှ) သော့ခတ်ရန်အတွက် အသုံးပြုရန်အတွက် နောက်ဆုံးတွင် သော့များ ထပ်မံရရှိနိုင်ပါမည်။
2. ဖောက်သည်များသည် လိုချင်သောသော့ကို မရယူမီ သို့မဟုတ် ရယူပြီး အလုပ်ပြီးမြောက်သောအခါတွင် သော့ခလောက်များကို ဖယ်ရှားခြင်းဖြင့် ဖောက်သည်များ အချင်းချင်း ကူညီလေ့ရှိသည့်အချက်၊ ထို့ကြောင့် သော့ကိုပြန်လည်ရရှိရန် သော့သက်တမ်းကုန်ဆုံးရန် ကျွန်ုပ်တို့စောင့်ဆိုင်းနေရန် မလိုအပ်ပါ။
3. ဖောက်သည်တစ်ဦးသည် သော့ကိုရယူရန် ထပ်မံကြိုးစားရန် လိုအပ်သည့်အခါ၊ သော့ခလောက်အများစုကိုရယူရန် လိုအပ်သည့်အချိန်ထက် နှိုင်းယှဉ်ပါက အချိန်ပိုကြာအောင်စောင့်ဆိုင်းရသည့်အချက်ဖြစ်သည်။ ၎င်းသည် အရင်းအမြစ်များကို ယှဉ်ပြိုင်သောအခါတွင် ဖြစ်ပေါ်လာသည့် ဦးနှောက်ကွဲအခြေအနေ ဖြစ်နိုင်ခြေကို လျော့နည်းစေသည်။

သို့သော်၊ ကွန်ရက်အပိုင်းများ၏ TTL နှင့်ညီမျှသော ဒဏ်ငွေရရှိနိုင်မှုတစ်ခုရှိနေသည်၊ ထို့ကြောင့် ဆက်နွှယ်နေသည့်အပိုင်းများရှိပါက၊ ပြစ်ဒဏ်သည် အကန့်အသတ်မရှိဖြစ်နိုင်သည်။ ဖောက်သည်တစ်ဦး သော့ကိုရယူပြီးနောက် ၎င်းကိုမထုတ်မီ အခြားအပိုင်းသို့ ဆုတ်သွားသည့်အခါတိုင်း ၎င်းသည် ဖြစ်ပေါ်သည်။

မူအရ၊ အကန့်အသတ်မရှိ ဆက်နွှယ်နေသော ကွန်ရက်အပိုင်းများကို ပေးထားသည့် စနစ်တစ်ခုသည် အချိန်အကန့်အသတ်မရှိ အချိန်အတိုင်းအတာတစ်ခုအထိ ဆက်လက်၍မရနိုင်ပါ။

စွမ်းဆောင်ရည်၊ ရှုံးနိမ့်မှုနှင့် fsync

လူအများအပြားသည် သော့ခတ်မှုများရယူရန်နှင့် ထုတ်လွှတ်ရန် လိုအပ်သည့် latency နှင့် တစ်စက္ကန့်လျှင် ပြီးမြောက်နိုင်သော ဝယ်ယူမှု/ထုတ်ဝေမှုအရေအတွက်တို့၌ မြင့်မားသောသော့ခတ်ဆာဗာစွမ်းဆောင်ရည် လိုအပ်သောကြောင့် Redis ကို အသုံးပြုကြသည်။ ဤလိုအပ်ချက်ကိုဖြည့်ဆည်းရန်၊ latency လျှော့ချရန် N Redis ဆာဗာများနှင့် ဆက်သွယ်ရန် ဗျူဟာတစ်ခုရှိသည်။ ၎င်းသည် multiplexing နည်းဗျူဟာ (သို့မဟုတ် "ညံ့သောသူ၏ multiplexing" ဟူသည်မှာ socket ကို ပိတ်ဆို့ခြင်းမပြုသည့်မုဒ်တွင် ထားရှိပြီး၊ ညွှန်ကြားချက်များအားလုံးကို ပေးပို့ကာ နောက်ပိုင်းတွင် ညွှန်ကြားချက်များကို ဖတ်ကာ၊ client နှင့် instance တစ်ခုစီကြား အသွားအပြန် အချိန်ကာလသည် ဆင်တူသည်ဟု ယူဆရသော) .

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

အခြေခံအားဖြင့်၊ ပြဿနာကိုရှင်းလင်းရန်၊ ကျွန်ုပ်တို့သည် Redis ကိုရေရှည်ဒေတာသိုလှောင်မှုလုံးဝမရှိဘဲ configure လုပ်သည်ဟုယူဆကြပါစို့။ client သည် instance 3 ခုတွင် 5 ခုကို block လုပ်နိုင်သည်။ ကလိုင်းယင့်က ပိတ်ဆို့ရန် စီမံထားသည့် ဖြစ်ရပ်များထဲမှ တစ်ခုကို ပြန်လည်စတင်ပြီး ယခုအချိန်တွင် တူညီသော အရင်းအမြစ်အတွက် ထပ်ပြီး ဖြစ်ရပ် 3 ခု ရှိပါသည်၊ ၎င်းကို ကျွန်ုပ်တို့ ပိတ်ဆို့နိုင်သည့် အခြားသော ကလိုင်းယင့်သည် လုံခြုံရေး ပိုင်ဆိုင်မှုကို ချိုးဖောက်ကာ ပြန်လည်စတင်သည့် စံနမူနာကို ပိတ်ဆို့နိုင်သည်။ သော့ခတ်ခြင်း၏ သီးသန့်ဖြစ်သည်ဟု ယူဆသည်။

အကယ်၍ သင်သည် ဒေတာကြိုတင်ဖွင့်ထားလျှင် (AOF) အခြေအနေ အနည်းငယ် တိုးတက်လာမည်ဖြစ်သည်။ ဥပမာအားဖြင့်၊ သင်သည် SHUTDOWN အမိန့်ကို ပေးပို့ပြီး ၎င်းကို ပြန်လည်စတင်ခြင်းဖြင့် ဆာဗာတစ်ခုအား မြှင့်တင်နိုင်သည်။ Redis တွင် သက်တမ်းကုန်ဆုံးသည့် လုပ်ဆောင်ချက်များကို ဆာဗာပိတ်ထားသည့်တိုင် အချိန်ဆက်လက်စီးဆင်းနေသည့်ပုံစံဖြင့် အဓိပ္ပာယ်ဖွင့်ဆိုထားသောကြောင့် ကျွန်ုပ်တို့၏လိုအပ်ချက်များအားလုံး ကောင်းမွန်ပါသည်။ ပုံမှန်ပိတ်ရန် သေချာနေသရွေ့ ၎င်းသည် ပုံမှန်ဖြစ်သည်။ ဓာတ်အားပြတ်တောက်ပါက ဘာလုပ်ရမလဲ။ အကယ်၍ Redis သည် စက္ကန့်တိုင်းတွင် fsync synchronizing ဖြင့် default ဖြင့် configure လုပ်ထားပါက၊ restart လုပ်ပြီးနောက်တွင် ကျွန်ုပ်တို့၏သော့ရှိမည်မဟုတ်ပါ။ သီအိုရီအရ၊ မည်သည့်အရာမဆို ပြန်လည်စတင်ချိန်တွင် လော့ခ်လုံခြုံရေးကို အာမခံလိုပါက၊ ကျွန်ုပ်တို့ ဖွင့်သင့်သည်။ fsync=always ရေရှည်ဒေတာသိုလှောင်မှုအတွက် ဆက်တင်များတွင်။ ၎င်းသည် ဖြန့်ဝေသောသော့များကို လုံခြုံစွာအကောင်အထည်ဖော်ရန်အတွက် အစဉ်အလာအတိုင်းအသုံးပြုသည့် CP စနစ်များအဆင့်အထိ စွမ်းဆောင်ရည်ကို လုံးဝအဆုံးသတ်စေမည်ဖြစ်သည်။

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

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

နှောင့်နှေးနေသောပြန်လည်စတင်မှုများကိုအသုံးပြုခြင်းဖြင့် Redis တွင်ရေရှည်တည်မြဲမှုမရှိသည့်တိုင်လုံခြုံရေးကိုရရှိရန်မူအရဖြစ်နိုင်သည်။ မည်သို့ပင်ဆိုစေကာမူ၊ ၎င်းသည် ဝင်ရောက်နိုင်မှုအား ချိုးဖောက်မှုအတွက် ဒဏ်ငွေဖြစ်စေနိုင်ကြောင်း သတိပြုပါ။ ဥပမာအားဖြင့်၊ သာဓကအများစုသည် ပျက်ကွက်ပါက TTL အတွက် စနစ်သည် တစ်ကမ္ဘာလုံးတွင် မရနိုင်တော့ပါ (ထိုအချိန်အတွင်း မည်သည့်အရင်းအမြစ်ကိုမျှ ပိတ်ဆို့ထားနိုင်မည်မဟုတ်ပါ)။

ကျွန်ုပ်တို့သည် အယ်လဂိုရီသမ်၏ရရှိနိုင်မှုကို တိုးမြှင့်သည်- ကျွန်ုပ်တို့သည် ပိတ်ဆို့ခြင်းကို သက်တမ်းတိုးပါသည်။

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

အသုံးပြုသူသည် တရားဝင်မှုကာလအတွင်း သာဓကအများစုကို လော့ခ်ချရန် စီမံထားမှသာ သော့ခတ်ခြင်းကို ပြန်လည်ရယူရန် စဉ်းစားသင့်သည်။

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

source: www.habr.com