"Hadoop တွင် ဒေတာပမာဏများစွာကို ဖြန့်ဝေခြင်းအတွက် နည်းလမ်းများ" စီးရီးမှ "Hadoop. ZooKeeper" ဟောပြောပွဲ၏ စာသားမှတ်တမ်းကို ဖတ်ရန် အကြံပြုလိုပါသည်။
Hadoop ဂေဟစနစ်တွင် ၎င်း၏နေရာ၊ ZooKeeper ဟူသည် အဘယ်နည်း။ ဖြန့်ဝေထားသော တွက်ချက်မှုနှင့်ပတ်သက်၍ မှားယွင်းသောအချက်များ။ စံဖြန့်ဝေစနစ်၏ ပုံကြမ်း။ ဖြန့်ဝေမှုစနစ်များကို ညှိနှိုင်းရာတွင် ခက်ခဲခြင်း။ ပုံမှန်ညှိနှိုင်းမှုပြဿနာများ။ ZooKeeper ၏ဒီဇိုင်းနောက်ကွယ်မှအခြေခံမူများ။ ZooKeeper ဒေတာမော်ဒယ်။ znode အလံများ။ ဆက်ရှင်များ။ သုံးစွဲသူ API မူလအစများ (ဖွဲ့စည်းပုံ၊ အဖွဲ့၀င်ခြင်း၊ ရိုးရှင်းသောသော့ခလောက်များ၊ ခေါင်းဆောင်ရွေးကောက်ပွဲ၊ နွားအုပ်အကျိုးသက်ရောက်မှုမရှိဘဲ လော့ခ်ချခြင်း)။ ZooKeeper ဗိသုကာ။ ZooKeeper DB ZAB ကိုင်တွယ်သူကို တောင်းဆိုပါ။
ဒီနေ့တော့ ZooKeeper အကြောင်း ပြောပြပါမယ်။ ဤအရာသည်အလွန်အသုံးဝင်သည်။ Apache Hadoop ထုတ်ကုန်များကဲ့သို့၎င်းတွင် လိုဂိုပါရှိသည်။ လူတစ်ယောက်ကို ပုံဖော်တယ်။
ဒီမတိုင်ခင်မှာ၊ အဲဒီမှာ data တွေကို ဘယ်လိုလုပ်ဆောင်နိုင်သလဲ၊ အဲဒါကို ဘယ်လိုသိမ်းဆည်းရမလဲ၊ အဲဒါကို တစ်နည်းနည်းနဲ့ အသုံးပြုနည်းနဲ့ အဲဒါကို တစ်နည်းနည်းနဲ့ လုပ်ဆောင်နိုင်တဲ့အကြောင်း အဓိကထားပြီး ဆွေးနွေးခဲ့ပါတယ်။ ဒီနေ့မှာတော့ ဖြန့်ဝေတဲ့ Application တွေကို တည်ဆောက်ခြင်းအကြောင်း အနည်းငယ် ပြောပြချင်ပါတယ်။ ZooKeeper သည် ဤကိစ္စရပ်ကို ရိုးရှင်းလွယ်ကူစေမည့် အရာများထဲမှ တစ်ခုဖြစ်သည်။ ၎င်းသည် ဖြန့်ဝေထားသော အက်ပ်လီကေးရှင်းများတွင် ဖြန့်ဝေထားသော စနစ်များတွင် လုပ်ငန်းစဉ်များ၏ အပြန်အလှန် ပေါင်းစပ်ညှိနှိုင်းမှုမျိုးအတွက် ရည်ရွယ်သည့် ဝန်ဆောင်မှုတစ်မျိုးဖြစ်သည်။
ထိုသို့သော လျှောက်လွှာများအတွက် လိုအပ်ချက်သည် နေ့စဉ်နှင့်အမျှ ပိုများလာနေသည်၊ ထိုအရာသည် ကျွန်ုပ်တို့၏ သင်တန်းဖြစ်သည်။ တစ်ဖက်တွင်၊ MapReduce နှင့် ဤအဆင်သင့်လုပ်ထားသော မူဘောင်သည် သင့်အား ဤရှုပ်ထွေးမှုကို ဖယ်ရှားနိုင်ပြီး အပြန်အလှန်ဆက်ဆံရေးနှင့် လုပ်ငန်းစဉ်များ ပေါင်းစပ်ညှိနှိုင်းမှုကဲ့သို့သော မူလအစများကို ရေးသားခြင်းမှ ပရိုဂရမ်မာအား လွတ်မြောက်စေနိုင်သည်။ သို့သော် အခြားတစ်ဖက်တွင်မူ၊ ဤအရာသည် မည်သို့ပင်ဖြစ်လိမ့်မည်မဟုတ်ဟု မည်သူကမျှ အာမခံချက်မရှိပါ။ MapReduce သို့မဟုတ် အခြားသော အဆင်သင့်လုပ်ထားသော မူဘောင်များသည် ၎င်းကိုအသုံးပြု၍ အကောင်အထည်မဖော်နိုင်သော အချို့သောကိစ္စရပ်များကို အမြဲတမ်း လုံးလုံးအစားထိုး၍မရပါ။ MapReduce ကိုယ်တိုင်နှင့် အခြားသော Apache ပရောဂျက်များစွာ အပါအဝင်၊ ၎င်းတို့သည် အမှန်တကယ်လည်း ဖြန့်ဝေထားသော application များဖြစ်သည်။ စာရေးရတာ ပိုလွယ်အောင် ZooKeeper ရေးတယ်။
Hadoop နှင့်ပတ်သက်သော application များအားလုံးကဲ့သို့၎င်းကို Yahoo မှတီထွင်ခဲ့သည်။ ယခုအခါ ၎င်းသည် တရားဝင် Apache အက်ပ်တစ်ခုလည်းဖြစ်သည်။ ၎င်းသည် HBase ကဲ့သို့ တက်ကြွစွာ မဖွံ့ဖြိုးပါ။ သင် JIRA HBase သို့သွားပါက နေ့တိုင်းတွင် ချို့ယွင်းချက်အစီရင်ခံစာများ၊ တစ်စုံတစ်ခုကို အကောင်းဆုံးဖြစ်အောင်ပြုလုပ်ရန် အဆိုပြုချက်များစွာရှိသည်၊ ဆိုလိုသည်မှာ ပရောဂျက်ရှိဘဝသည် အဆက်မပြတ်ဖြစ်နေပါသည်။ တစ်ဖက်တွင် ZooKeeper သည် အတော်လေးရိုးရှင်းသောထုတ်ကုန်ဖြစ်ပြီး အခြားတစ်ဖက်တွင်၊ ၎င်းသည် ၎င်း၏ယုံကြည်စိတ်ချရမှုကို အာမခံပါသည်။ ၎င်းသည်အသုံးပြုရန်အတော်လေးလွယ်ကူသောကြောင့်၎င်းသည် Hadoop ဂေဟစနစ်အတွင်းရှိ application များတွင်စံတစ်ခုဖြစ်လာသည်။ ဒါကြောင့် ဘယ်လိုအလုပ်လုပ်တယ်၊ ဘယ်လိုသုံးရမယ်ဆိုတာ နားလည်အောင် ပြန်သုံးသပ်တာက အသုံးဝင်မယ်လို့ ထင်ပါတယ်။
ဒါက ကျွန်တော်တို့ သင်ကြားပြသပေးခဲ့တဲ့ ပုံရိပ်တစ်ခုပါ။ ယခုအချိန်အထိ ကျွန်ုပ်တို့ စဉ်းစားထားသမျှ အရာအားလုံးအတွက် အချိုးညီညီဟု ဆိုနိုင်ပါသည်။ ဤနေရာတွင် ဖော်ပြထားသည့်အရာအားလုံးသည် ZooKeeper နှင့် အလုပ်လုပ်သည်၊ ဆိုလိုသည်မှာ ဤထုတ်ကုန်အားလုံးကို အသုံးပြုသည့် ဝန်ဆောင်မှုတစ်ခုဖြစ်သည်။ HDFS နှင့် MapReduce နှစ်ခုလုံးသည် ၎င်းတို့အတွက် အထူးသင့်လျော်မည့် ၎င်းတို့၏ အလားတူဝန်ဆောင်မှုများကို မရေးကြပါ။ ထို့ကြောင့် ZooKeeper ကိုအသုံးပြုသည်။ ၎င်းသည် ဖွံ့ဖြိုးတိုးတက်မှုနှင့် အမှားအယွင်းများနှင့်ပတ်သက်သည့် အချို့အရာများကို ရိုးရှင်းစေသည်။
ဒါတွေအားလုံး ဘယ်ကလာတာလဲ။ မတူညီသောကွန်ပျူတာများပေါ်တွင် အပြိုင်အပလီကေးရှင်းနှစ်ခုကို ကျွန်ုပ်တို့လွှင့်တင်ခဲ့ပြီး ၎င်းတို့ကို စာကြောင်းတစ်ခု သို့မဟုတ် ကွက်တစ်ခုဖြင့် ချိတ်ဆက်ထားကာ အရာအားလုံး အဆင်ပြေသွားပုံရသည်။ သို့သော် ပြဿနာမှာ Network သည် စိတ်မချရသောကြောင့်၊ သင်သည် အသွားအလာကို ရှူရှိုက်မိသည် သို့မဟုတ် နိမ့်ပါးသော အဆင့်တွင် ဖြစ်ပျက်နေသည်များကို ကြည့်ရှုပါက၊ ကွန်ရက်ပေါ်တွင် သုံးစွဲသူများ အပြန်အလှန် တုံ့ပြန်ပုံ၊ အချို့သော packet များ ပျောက်ဆုံးသွားခြင်း သို့မဟုတ် ပြန်လည်ပေးပို့ခြင်းတို့ကို မကြာခဏ မြင်တွေ့နိုင်သည်။ သင့်အား သတ်မှတ်ထားသော စက်ရှင်တစ်ခုကို တည်ထောင်ရန်နှင့် မက်ဆေ့ချ်ပေးပို့မှုကို အာမခံနိုင်စေသည့် TCP ပရိုတိုကောများကို တီထွင်ခဲ့ခြင်းသည် မည်သည့်အတွက်မျှ မဟုတ်ပါ။ မည်သို့ပင်ဆိုစေ TCP ပင်လျှင် သင့်အား အမြဲမကယ်တင်နိုင်ပါ။ အရာရာတိုင်းဟာ အချိန်ကုန်ဆုံးမှုရှိတယ်။ ကွန်ရက်သည် ခဏတာ ပျက်သွားနိုင်သည်။ မျက်တောင်ခတ်နေနိုင်တယ်။ ဒါတွေအားလုံးက Network ကို ယုံကြည်စိတ်ချရတဲ့အပေါ်မှာ သင် အားကိုးလို့မရဘူးဆိုတဲ့အချက်ကို ဖြစ်ပေါ်စေတယ်။ ၎င်းသည် ကွန်ပျူတာတစ်လုံးပေါ်တွင် သို့မဟုတ် စူပါကွန်ပြူတာတစ်ခုပေါ်တွင် အလုပ်လုပ်သော အပြိုင်အပလီကေးရှင်းများကို ရေးသားခြင်းမှ အဓိကကွာခြားချက်မှာ ကွန်ရက်မရှိသော၊ မမ်မိုရီတွင် ပိုမိုစိတ်ချရသော ဒေတာလဲလှယ်ရေးဘတ်စ်တစ်ခုရှိသည့် ကွန်ရက်မရှိသည့်နေရာဖြစ်သည်။ ပြီးတော့ ဒါက အခြေခံ ခြားနားချက်ပါ။
အခြားအရာများထဲတွင် Network ကိုအသုံးပြုသောအခါတွင်၊ latency သည်အမြဲရှိနေပါသည်။ disk မှာလည်း ပါပါတယ်၊ ဒါပေမယ့် Network မှာ ပိုရှိပါတယ်။ Latency သည် အနည်းငယ် သို့မဟုတ် အလွန်သိသာစေသည့် နှောင့်နှေးသည့်အချိန်ဖြစ်သည်။
ကွန်ရက် topology သည် ပြောင်းလဲနေသည်။ topology ဟူသည် အဘယ်နည်း - ဤအရာသည် ကျွန်ုပ်တို့၏ ကွန်ရက်စက်ပစ္စည်းများ၏ နေရာချထားမှုဖြစ်သည်။ ဒေတာစင်တာတွေရှိတယ်၊ ဟိုမှာရပ်နေတဲ့ ကကွက်တွေရှိတယ်၊ ဖယောင်းတိုင်တွေရှိတယ်။ ဤအရာအားလုံးကို ပြန်လည်ချိတ်ဆက်နိုင်သည်၊ ရွှေ့နိုင်သည်၊ စသဖြင့်၊ ဤအရာအားလုံးကိုလည်း ထည့်သွင်းစဉ်းစားရန် လိုအပ်ပါသည်။ IP အမည်များ ပြောင်းလဲခြင်း၊ ကျွန်ုပ်တို့၏ လမ်းကြောင်းများ သွားလာနေသည့် လမ်းကြောင်း ပြောင်းလဲပါသည်။ ဒါကိုလည်း ထည့်သွင်းစဉ်းစားဖို့ လိုပါတယ်။
ကွန်ရက်သည် စက်ကိရိယာဆိုင်ရာ စည်းကမ်းချက်များတွင်လည်း ပြောင်းလဲနိုင်သည်။ လက်တွေ့အားဖြင့်၊ ကျွန်ုပ်တို့၏ကွန်ရက်အင်ဂျင်နီယာများသည် ဖယောင်းတိုင်များပေါ်တွင် တစ်ခုခုကို အခါအားလျော်စွာ အပ်ဒိတ်လုပ်ခြင်းကို အမှန်တကယ်နှစ်သက်သည်ဟု ကျွန်တော်ပြောနိုင်သည်။ ရုတ်တရက် Firmware အသစ်တစ်ခုထွက်လာပြီး Hadoop အစုအဝေးအချို့ကို အထူးစိတ်မဝင်စားခဲ့ကြပါ။ သူတို့မှာ ကိုယ်ပိုင်အလုပ်ရှိတယ်။ သူတို့အတွက် အဓိကအချက်က Network အလုပ်လုပ်ပါတယ်။ ထို့ကြောင့်၊ ၎င်းတို့သည် ထိုနေရာတွင် တစ်ခုခုကို ပြန်လည် အပ်လုဒ်လုပ်ရန်၊ ၎င်းတို့၏ ဟာ့ဒ်ဝဲပေါ်တွင် အလင်းပြန်ခြင်းကို ပြုလုပ်လိုကြပြီး ဟာ့ဒ်ဝဲကိုလည်း အခါအားလျော်စွာ ပြောင်းလဲလိုကြသည်။ ဤအရာအားလုံးကို တစ်နည်းနည်းဖြင့် ထည့်သွင်းစဉ်းစားရန် လိုအပ်ပါသည်။ ဤအရာအားလုံးသည် ကျွန်ုပ်တို့၏ ဖြန့်ဝေထားသော အပလီကေးရှင်းအပေါ် သက်ရောက်မှုရှိသည်။
အများအားဖြင့် ဒေတာပမာဏများစွာဖြင့် စတင်လုပ်ကိုင်သူများသည် အင်တာနက်သည် အကန့်အသတ်မရှိဟု ယုံကြည်ကြသည်။ အဲဒီမှာ terabytes အများအပြားရှိတဲ့ ဖိုင်တစ်ခုရှိတယ်ဆိုရင်၊ အဲဒါကို သင့်ဆာဗာ ဒါမှမဟုတ် ကွန်ပျူတာမှာ ယူပြီး ဖွင့်သုံးနိုင်ပါတယ်။ ကွောငျ စောင့်ကြည့်ပါ။ နောက်ထပ် error တစ်ခုရှိနေပါသည်။ Vim သစ်လုံးများကိုကြည့်ပါ။ မကောင်းတဲ့အတွက် ဘယ်တော့မှ မလုပ်ပါနဲ့။ Vim သည် အရာအားလုံးကို ကြားခံရန်ကြိုးစားသောကြောင့်၊ အထူးသဖြင့် ကျွန်ုပ်တို့သည် ဤမှတ်တမ်းကိုစတင်ရွေ့လျားပြီး တစ်ခုခုကိုရှာဖွေနေသောအခါတွင် အရာအားလုံးကို မှတ်ဉာဏ်တွင်တင်ပါ။ ဒါတွေက မေ့ပျောက်နေပေမယ့် ဆင်ခြင်သင့်တယ်။
ပရိုဆက်ဆာတစ်ခုနဲ့ ကွန်ပျူတာတစ်လုံးမှာ အလုပ်လုပ်တဲ့ ပရိုဂရမ်တစ်ခုကို ရေးရတာ ပိုလွယ်တယ်။
ကျွန်ုပ်တို့၏စနစ် ကြီးထွားလာသောအခါ၊ ကျွန်ုပ်တို့သည် ၎င်းအားလုံးကို မျဉ်းပြိုင်ပြုလုပ်လိုပြီး ၎င်းကို ကွန်ပျူတာပေါ်တွင်သာမက အစုအဝေးတစ်ခုတွင်ပါ အပြိုင်ပြုလုပ်လိုပါသည်။ မေးခွန်းပေါ်လာသည်- ဤကိစ္စကို မည်သို့ညှိနှိုင်းဆောင်ရွက်မည်နည်း။ ကျွန်ုပ်တို့၏ အပလီကေးရှင်းများသည် တစ်ခုနှင့်တစ်ခု အပြန်အလှန် အကျိုးသက်ရောက်မှုရှိနိုင်သော်လည်း ဆာဗာများစွာတွင် လုပ်ငန်းစဉ်များစွာကို ကျွန်ုပ်တို့ လုပ်ဆောင်ပါသည်။ ပြီးတော့ သူတို့အတွက် အရာအားလုံး အဆင်ပြေသွားအောင် ဘယ်လို စောင့်ကြည့်ရမလဲ။ ဥပမာ၊ အင်တာနက်ကနေ တစ်ခုခု ပို့တယ်။ ဥပမာအားဖြင့်၊ အချို့သော ဒေတာဘေ့စ် သို့မဟုတ် မှတ်တမ်းတစ်ခုခုတွင် ၎င်းတို့၏ အခြေအနေအကြောင်း ရေးရမည်ဖြစ်ပြီး၊ ထို့နောက် ဤမှတ်တမ်းကို စုစည်းပြီး တစ်နေရာရာတွင် ခွဲခြမ်းစိတ်ဖြာပါ။ ထို့အပြင်၊ လုပ်ငန်းစဉ်သည် အလုပ်လုပ်နေပြီး အလုပ်လုပ်နေကြောင်း ထည့်သွင်းစဉ်းစားရန်လိုသည်၊ ၎င်းတွင် အမှားအယွင်းအချို့ ပေါ်လာသည် သို့မဟုတ် ပျက်သွားသည်၊ ထို့နောက် ၎င်းအကြောင်းကို ကျွန်ုပ်တို့ မည်မျှမြန်မြန်ရှာဖွေနိုင်မည်နည်း။
ဒါတွေအားလုံးကို မြန်မြန်ဆန်ဆန် စောင့်ကြည့်နိုင်တယ်ဆိုတာ ရှင်းပါတယ်။ ၎င်းသည် ကောင်းမွန်သော်လည်း စောင့်ကြည့်ခြင်းသည် အချို့အရာများကို အမြင့်ဆုံးအဆင့်တွင် စောင့်ကြည့်နိုင်စေမည့် အကန့်အသတ်တစ်ခုဖြစ်သည်။
ကျွန်ုပ်တို့၏ လုပ်ငန်းစဉ်များသည် တစ်ခုနှင့်တစ်ခု အပြန်အလှန် အပြန်အလှန် အကျိုးသက်ရောက်စေလိုသောအခါ၊ ဥပမာအားဖြင့်၊ ဒေတာအချို့ကို အချင်းချင်း ပေးပို့လိုသောအခါတွင် မေးခွန်းပေါ်လာသည် - ဒါက ဘယ်လိုဖြစ်မလဲ။ ပြိုင်ပွဲအခြေအနေ တစ်မျိုးမျိုးရှိသလား၊ တစ်ခုနဲ့တစ်ခု ထပ်ရေးမလား၊ ဒေတာတွေ မှန်မှန်ကန်ကန် ရောက်လာမလား၊ လမ်းတစ်လျှောက်မှာ တစ်ခုခု ဆုံးရှုံးသွားမလား? ပရိုတိုကော တစ်မျိုးမျိုး စသည်တို့ကို ဖော်ဆောင်ရန် လိုအပ်ပါသည်။
ဤလုပ်ငန်းစဉ်များအားလုံးကို ညှိနှိုင်းဆောင်ရွက်ခြင်းသည် အသေးအဖွဲကိစ္စမဟုတ်ပါ။ ၎င်းသည် developer အား အောက်ခြေအဆင့်သို့ ဆင်းရန်နှင့် စနစ်များကို အစမှနေ၍ သို့မဟုတ် အစမှနေ၍ ရေးရန် တွန်းအားပေးသော်လည်း၊ ဤမျှ မရိုးရှင်းပါ။
အကယ်၍ သင်သည် cryptographic algorithm တစ်ခုနှင့် အကောင်အထည်ဖော်မည်ဆိုပါက၊ ၎င်းသည် သင့်အတွက် အလုပ်မဖြစ်နိုင်သောကြောင့် ၎င်းကို ချက်ချင်းစွန့်ပစ်ပါ။ ၎င်းတွင် သင်ပံ့ပိုးပေးရန် မေ့သွားသော အမှားအယွင်းများစွာ ပါဝင်နိုင်ဖွယ်ရှိသည်။ မတည်မငြိမ်ဖြစ်နိုင်သောကြောင့် ပြင်းထန်သော မည်သည့်အရာအတွက်မှ မသုံးပါနှင့်။ အဘယ်ကြောင့်ဆိုသော် တည်ရှိနေသော algorithms အားလုံးကို အချိန်အတော်ကြာအောင် စမ်းသပ်ထားသောကြောင့် ဖြစ်သည်။ အသိုင်းအဝန်းက နှောင့်ယှက်နေတယ်။ ဒါက သီးခြားအကြောင်းအရာပါ။ ဒီမှာ အတူတူပါပဲ။ လုပ်ငန်းစဉ်အချို့ကို သင်ကိုယ်တိုင် ထပ်တူပြုခြင်းမျိုး အကောင်အထည်ဖော်ရန် မဖြစ်နိုင်ပါက၊ ၎င်းသည် အလွန်ရှုပ်ထွေးပြီး အမှားအယွင်းများကို အဆက်မပြတ်ရှာဖွေနေသည့် သင့်အား တုန်လှုပ်ချောက်ချားစေသော လမ်းကြောင်းပေါ်သို့ ပို့ဆောင်ပေးသောကြောင့် ၎င်းကို မလုပ်ဆောင်ခြင်းက ပိုကောင်းပါသည်။
ယနေ့ကျွန်ုပ်တို့သည် ZooKeeper အကြောင်းပြောနေကြသည်။ တစ်ဖက်တွင်၊ ၎င်းသည် မူဘောင်တစ်ခုဖြစ်ပြီး အခြားတစ်ဖက်တွင်၊ ၎င်းသည် developer အတွက် ဘဝပိုမိုလွယ်ကူစေပြီး ကျွန်ုပ်တို့၏လုပ်ငန်းစဉ်များကို တတ်နိုင်သမျှ ယုတ္တိဗေဒနှင့် ပေါင်းစပ်ညှိနှိုင်းဆောင်ရွက်မှုများကို ရိုးရှင်းလွယ်ကူစေသည်။
စံဖြန့်ဝေမှုစနစ်က ဘယ်လိုပုံသဏ္ဌာန်ရှိလဲဆိုတာ မှတ်သားရအောင်။ ဒါက HDFS၊ HBase အကြောင်းပြောနေတာ။ အလုပ်သမားများနှင့် ကျွန်လုပ်ငန်းစဉ်များကို စီမံခန့်ခွဲသည့် Master လုပ်ငန်းစဉ်တစ်ခု ရှိပါသည်။ အလုပ်များကို ညှိနှိုင်းဝေငှခြင်း၊ အလုပ်သမားများ ပြန်လည်စတင်ခြင်း၊ အသစ်များစတင်ခြင်းနှင့် ဝန်ထုပ်ဝန်ပိုးများ ခွဲဝေပေးခြင်းတို့အတွက် တာဝန်ရှိပါသည်။
ပို၍အဆင့်မြင့်သည့်အရာမှာ ညှိနှိုင်းရေးဝန်ဆောင်မှု၊ ဆိုလိုသည်မှာ၊ ညှိနှိုင်းရေးတာဝန်ကို သီးခြားလုပ်ငန်းစဉ်တစ်ခုအဖြစ် သူ့ဘာသာသူ ရွှေ့ကာ မာစတာသည် ကျရှုံးနိုင်သောကြောင့် အရန်ကူးယူခြင်း သို့မဟုတ် stanby Master အချို့ကို အပြိုင်လုပ်ဆောင်ခြင်းဖြစ်သည်။ အကယ်၍ ဆရာကြီးပြုတ်ကျပါက ကျွန်ုပ်တို့၏စနစ်သည် အလုပ်မဖြစ်ပါ။ ကျွန်ုပ်တို့သည် အရန်သိမ်းခြင်းကို လုပ်ဆောင်နေပါသည်။ Master ကို အရန်ကူးယူရန် ထပ်တူလိုအပ်သည်ဟု အချို့က ဖော်ပြသည်။ ဒါကို ညှိနှိုင်းရေး ဝန်ဆောင်မှုကိုလည်း အပ်နှင်းနိုင်ပါတယ်။ သို့သော် ဤပုံကြမ်းတွင် ဆရာကြီးကိုယ်တိုင်က အလုပ်သမားများအား ညှိနှိုင်းဆောင်ရွက်ပေးရန် တာဝန်ရှိသည်၊ ဤနေရာတွင် ဝန်ဆောင်မှုသည် ဒေတာပုံတူပွားခြင်းဆိုင်ရာ လုပ်ငန်းများကို ညှိနှိုင်းဆောင်ရွက်ပေးပါသည်။
ပိုမိုအဆင့်မြင့်သော ရွေးချယ်မှုတစ်ခုသည် အများအားဖြင့် လုပ်ဆောင်သည့်အတိုင်း ကျွန်ုပ်တို့၏ဝန်ဆောင်မှုမှ ညှိနှိုင်းဆောင်ရွက်မှုအားလုံးကို ကိုင်တွယ်သည့်အခါဖြစ်သည်။ အရာရာကို သေချာအောင်လုပ်ဖို့ သူတာဝန်ယူတယ်။ တစ်ခုခုအဆင်မပြေပါက၊ ကျွန်ုပ်တို့သည် ၎င်းအကြောင်းကို သိရှိပြီး ဤအခြေအနေသို့ရောက်ရန် ကြိုးစားပါ။ မည်သို့ပင်ဆိုစေကာမူ၊ အချို့သောဝန်ဆောင်မှုမှတစ်ဆင့် ကျွန်များနှင့်ဆက်ဆံပြီး ဒေတာ၊ အချက်အလက်များ၊ မက်ဆေ့ချ်များစသည်တို့ကို ပေးပို့နိုင်သော ဆရာကြီးတစ်ဦးနှင့် ကျန်ရှိနေပါသည်။
ကျွန်ုပ်တို့တွင် မာစတာမရှိသောအခါ ပို၍ပင်အဆင့်မြင့်သောအစီအစဉ်တစ်ခုရှိပါသည်၊ ဆုံမှတ်များအားလုံးသည် သခင်ကျွန်များဖြစ်ပြီး ၎င်းတို့၏အပြုအမူနှင့် ကွဲပြားပါသည်။ သို့သော် ၎င်းတို့သည် အချင်းချင်းအပြန်အလှန် ဆက်ဆံရန် လိုအပ်နေသေးသောကြောင့် ဤလုပ်ဆောင်ချက်များကို ညှိနှိုင်းဆောင်ရွက်ရန် ဝန်ဆောင်မှုအချို့ ကျန်နေသေးသည်။ ဤနိယာမတွင်အလုပ်လုပ်သော Cassandra သည်ဤအစီအစဉ်နှင့်ကိုက်ညီသည်။
ဤအစီအစဥ်များထဲမှ မည်သည့်အစီအစဥ်ပိုကောင်းသည်ဆိုသည်ကို ပြောရခက်ပါသည်။ တစ်ခုချင်းစီတွင်၎င်း၏အားသာချက်များနှင့်အားနည်းချက်များရှိသည်။
အဘယ့်ကြောင့်ဆိုသော် အချို့သောအရာများကို ကြောက်ရွံ့နေရန် မလိုအပ်ပေ၊ အဘယ်ကြောင့်ဆိုသော် ကျင့်စဉ်ပြသည့်အတိုင်း၊ သူသည် အမြဲတစေ အမှုတော်ထမ်းဆောင်ရန် အလွန်အမင်း ကြောက်ရွံ့ဖွယ်မရှိပေ။ ဤနေရာတွင် အဓိကအချက်မှာ ဤဝန်ဆောင်မှုအား သီးခြားအားကောင်းသော node တစ်ခုတွင် လက်ခံကျင်းပရန်အတွက် မှန်ကန်သောဖြေရှင်းချက်ကို ရွေးချယ်ရန်ဖြစ်ပြီး၊ ထို့ကြောင့် ၎င်းတွင် အရင်းအမြစ်များ အလုံအလောက်ရှိစေရန်၊ သို့မှသာ ဖြစ်နိုင်ပါက အသုံးပြုသူများသည် ဤလုပ်ငန်းစဉ်ကို မတော်တဆ မသတ်မိစေရန်ဖြစ်သည်။ သို့သော်တစ်ချိန်တည်းမှာပင်၊ ထိုသို့သောအစီအစဥ်တွင် Master လုပ်ငန်းစဉ်မှအလုပ်သမားများကိုစီမံခန့်ခွဲရန်ပိုမိုလွယ်ကူသည်၊ ဆိုလိုသည်မှာဤအစီအစဥ်ကိုအကောင်အထည်ဖော်မှုရှုထောင့်မှပိုမိုရိုးရှင်းပါသည်။
ဤအစီအစဥ် (အထက်) သည် ပို၍ရှုပ်ထွေးနိုင်သည်၊ သို့သော် ပို၍ယုံကြည်စိတ်ချရသည်။
အဓိကပြဿနာမှာ တစ်စိတ်တစ်ပိုင်း ပျက်ကွက်မှုများဖြစ်သည်။ ဥပမာအားဖြင့်၊ ကျွန်ုပ်တို့သည် Network မှတဆင့် မက်ဆေ့ချ်ပို့သောအခါတွင် မတော်တဆမှု တစ်မျိုးမျိုး ဖြစ်ပေါ်ပြီး မက်ဆေ့ချ်ပို့သူသည် ၎င်း၏ မက်ဆေ့ချ်ကို လက်ခံရရှိခြင်း ရှိ၊ မရှိ သိရှိနိုင်မည်ဖြစ်ပြီး လက်ခံသူဘက်မှ မည်ကဲ့သို့ ဖြစ်ပျက်ခဲ့သည်ကို သိရှိနိုင်မည် မဟုတ်ပါ။ ဆိုလိုသည်မှာ သူသည် မည်သည့်အတည်ပြုချက်ကိုမျှ လက်ခံမည်မဟုတ်ပါ။
ဒါကြောင့် ဒီအခြေအနေကို စီမံဆောင်ရွက်ရမယ်။ အရိုးရှင်းဆုံးကတော့ ဒီစာကိုပြန်ပို့ပြီး တုံ့ပြန်မှုရရှိတဲ့အထိစောင့်ပါ။ ဤကိစ္စတွင်၊ လက်ခံသူ၏အခြေအနေပြောင်းလဲခြင်းရှိမရှိ ထည့်သွင်းစဉ်းစားမည်မဟုတ်ပါ။ မက်ဆေ့ချ်ပို့ပြီး တူညီသောဒေတာကို နှစ်ကြိမ်ထည့်နိုင်သည်။
ZooKeeper သည် ကျွန်ုပ်တို့၏ဘဝကို ပိုမိုလွယ်ကူစေသည့် ထိုငြင်းဆိုမှုများကို ကိုင်တွယ်ဖြေရှင်းရန် နည်းလမ်းများကို ပေးပါသည်။
အစောပိုင်းကပြောခဲ့သည့်အတိုင်း၊ ၎င်းသည် multi-threaded ပရိုဂရမ်များကိုရေးသားခြင်းနှင့်ဆင်တူသော်လည်း အဓိကကွာခြားချက်မှာ မတူညီသောစက်များတွင်ကျွန်ုပ်တို့တည်ဆောက်ထားသောဖြန့်ဝေသည့်အက်ပ်လီကေးရှင်းများတွင်ဆက်သွယ်ရန်တစ်ခုတည်းသောနည်းလမ်းမှာ Network ဖြစ်သည်။ အခြေခံအားဖြင့်၊ ဤအရာသည် မျှဝေခြင်းမရှိဘဲ ဗိသုကာတစ်ခုဖြစ်သည်။ စက်တစ်ခုပေါ်တွင်လည်ပတ်သည့် လုပ်ငန်းစဉ် သို့မဟုတ် ဝန်ဆောင်မှုတစ်ခုစီတွင် ၎င်း၏ကိုယ်ပိုင်မှတ်ဉာဏ်၊ ၎င်း၏ကိုယ်ပိုင်ဒစ်၊ ၎င်း၏ကိုယ်ပိုင်ပရိုဆက်ဆာ၊ ၎င်းသည် မည်သူတစ်ဦးတစ်ယောက်နှင့်မျှ မျှဝေခြင်းမရှိပေ။
ကွန်ပျူတာတစ်လုံးမှာ Multi-threaded ပရိုဂရမ်တစ်ခုကို ရေးမယ်ဆိုရင် ဒေတာဖလှယ်ဖို့အတွက် မျှဝေထားတဲ့ Memory ကို အသုံးပြုနိုင်ပါတယ်။ ကျွန်ုပ်တို့တွင် ဆက်စပ်ခလုတ်တစ်ခုရှိသည်၊ လုပ်ငန်းစဉ်များပြောင်းနိုင်သည်။ ဒါက စွမ်းဆောင်ရည်ကို ထိခိုက်စေတယ်။ တစ်ဖက်တွင်၊ အစုအဖွဲ့တစ်ခုရှိ ပရိုဂရမ်တွင် ထိုသို့သောအရာမျိုးမရှိသော်လည်း Network တွင် ပြဿနာများရှိနေသည်။
ထို့ကြောင့် ဖြန့်ဝေသည့်စနစ်များကို ရေးသားသည့်အခါတွင် ဖြစ်ပေါ်လာသည့် အဓိကပြဿနာများမှာ ဖွဲ့စည်းမှုဖြစ်သည်။ ကျွန်ုပ်တို့သည် အက်ပလီကေးရှင်းတစ်မျိုးကို ရေးနေပါသည်။ ရိုးရှင်းပါက၊ ကျွန်ုပ်တို့သည် ကုဒ်တွင် နံပါတ်အမျိုးမျိုးကို hardcode လုပ်ထားသော်လည်း ၎င်းသည် အဆင်မပြေသောကြောင့်၊ ကျွန်ုပ်တို့သည် စက္ကန့်ဝက်၏ အချိန်ကုန်ဆုံးမည့်အစား ကျွန်ုပ်တို့သည် တစ်စက္ကန့်၏ အချိန်ကုန်ဆုံးလိုကြောင်း ဆုံးဖြတ်ပါက၊ ကျွန်ုပ်တို့သည် အပလီကေးရှင်းကို ပြန်လည်ပေါင်းစည်းရန် လိုအပ်ပါသည်။ အရာအားလုံးကို ပြန်လှန်လိုက်ပါ။ အဲဒါက စက်တစ်လုံးမှာရှိတဲ့အခါ၊ သင်ကပဲ restart လုပ်လို့ရပေမယ့် စက်တွေအများကြီးရှိတဲ့အခါ၊ အရာအားလုံးကို အဆက်မပြတ်ကူးယူရပါမယ်။ အပလီကေးရှင်းကို configurable ဖြစ်အောင် ကြိုးစားရမယ်။
ဤတွင် ကျွန်ုပ်တို့သည် စနစ်လုပ်ငန်းစဉ်များအတွက် static configuration အကြောင်းပြောနေပါသည်။ ၎င်းသည် လုံး၀မဟုတ်ပါ၊ လည်ပတ်မှုစနစ်၏ရှုထောင့်မှဖြစ်နိုင်သည်၊ ၎င်းသည် ကျွန်ုပ်တို့၏လုပ်ငန်းစဉ်များအတွက် static configuration ဖြစ်ကောင်းဖြစ်နိုင်သည်၊ ဆိုလိုသည်မှာ၊ ဤသည်မှာ ရိုးရှင်းစွာယူ၍မွမ်းမံမရနိုင်သောဖွဲ့စည်းပုံတစ်ခုဖြစ်သည်။
ဒိုင်းနမစ်ဖွဲ့စည်းပုံလည်း ရှိပါသည်။ ဤအရာများသည် ၎င်းတို့ကို ထိုနေရာတွင် ကောက်ယူနိုင်ရန် ကျွန်ုပ်တို့ ပျံသန်းပြောင်းလဲလိုသော ဘောင်များဖြစ်သည်။
ဒီမှာ ဘာပြဿနာရှိလို့လဲ။ ကျွန်ုပ်တို့သည် config ကိုမွမ်းမံပြီး၎င်းကိုထုတ်ခဲ့သည်၊ ဒါဆိုဘာလဲ။ ပြဿနာက တဖက်မှာ config ကို ထုတ်ပေးပေမယ့် အသစ်ကို မေ့သွားလို့ config က အဲဒီမှာပဲ ကျန်နေခဲ့တာ။ ဒုတိယအနေဖြင့်၊ ကျွန်ုပ်တို့ စတင်ထုတ်လုပ်စဉ်တွင်၊ အချို့နေရာများတွင် ဖွဲ့စည်းမှုပုံစံကို အပ်ဒိတ်လုပ်ခဲ့သော်လည်း အခြားနေရာများတွင် မဟုတ်ပါ။ စက်တစ်လုံးတွင်လည်ပတ်နေသော ကျွန်ုပ်တို့၏အပလီကေးရှင်း၏လုပ်ငန်းစဉ်အချို့ကို config အသစ်တစ်ခုဖြင့် ပြန်လည်စတင်ခဲ့ပြီး အချို့နေရာတွင် အဟောင်းတစ်ခုဖြင့် ပြန်လည်စတင်ခဲ့သည်။ ၎င်းသည် ကျွန်ုပ်တို့၏ ဖြန့်ဝေထားသော အပလီကေးရှင်းကို ဖွဲ့စည်းမှုပုံစံရှုထောင့်မှ တသမတ်တည်းဖြစ်စေနိုင်သည်။ ဒီပြဿနာက အဖြစ်များတယ်။ ဒိုင်းနမစ်ဖွဲ့စည်းမှုတစ်ခုအတွက်၊ ၎င်းသည် ပျံသန်းမှုတွင် ပြောင်းလဲနိုင်သည်ဟု ဆိုလိုသောကြောင့် ၎င်းသည် ပိုမိုသက်ဆိုင်သည်။
နောက်ပြဿနာတစ်ခုကတော့ အဖွဲ့အဖွဲ့ဝင်ဖြစ်ခြင်းပါ။ ကျွန်တော်တို့မှာ အလုပ်သမားတွေ အမြဲရှိနေတယ်၊ သူတို့ထဲက ဘယ်သူက အသက်ရှင်နေလဲ၊ ဘယ်သူက သေသွားပြီလဲ ဆိုတာ အမြဲသိချင်နေတယ်။ မာစတာရှိပါက၊ တွက်ချက်မှုများလုပ်ဆောင်ရန် သို့မဟုတ် ဒေတာဖြင့်အလုပ်လုပ်နိုင်စေရန် မည်သည့်အလုပ်သမားများကို ဖောက်သည်များထံ ပြန်ညွှန်းနိုင်သည်ကို သူနားလည်ရပါမည်။ အဆက်မပြတ်ဖြစ်ပေါ်နေသည့် ပြဿနာတစ်ခုမှာ ကျွန်ုပ်တို့၏အစုအဝေးတွင် မည်သူမည်သည်ကို သိရှိရန် လိုအပ်ပါသည်။
နောက်ပြဿနာတစ်ခုကတော့ ခေါင်းဆောင် ရွေးကောက်ပွဲမှာ ဘယ်သူက ဘယ်သူတာဝန်ခံလဲ ဆိုတာ သိချင်ပါတယ်။ ဥပမာတစ်ခုသည် စာရေးခြင်းလုပ်ငန်းကို လက်ခံရရှိပြီးနောက် အခြားလုပ်ငန်းစဉ်များကြားတွင် ထပ်တူပြုသည့် လုပ်ငန်းစဉ်အချို့ရှိသောအခါ ဥပမာတစ်ခုသည် ကူးယူခြင်းဖြစ်ပါသည်။ သူသည် ခေါင်းဆောင်ဖြစ်လိမ့်မည်၊ အခြားလူတိုင်းက သူ့အား နာခံလိမ့်မည်၊ သူ့နောက်လိုက်ကြလိမ့်မည်။ ခေါင်းဆောင်နှစ်ဦးကို ရွေးချယ်ခြင်းမခံရစေရန် လူတိုင်းအတွက် ရှုပ်ထွေးမှုမရှိစေရန် လုပ်ငန်းစဉ်ကို ရွေးချယ်ရန် လိုအပ်ပါသည်။
သီးသန့်ဝင်ရောက်ခွင့်လည်း ရှိပါတယ်။ ဒီနေရာမှာ ပြဿနာက ပိုရှုပ်ထွေးတယ်။ Multi-threaded ပရိုဂရမ်များကို ရေးသားပြီး အချို့သော ရင်းမြစ် ဥပမာ မန်မိုရီဆဲလ်သို့ ဝင်ရောက်လိုသောအခါတွင် ကန့်သတ်ချက်တစ်ခုသာ လုပ်ဆောင်ရန် mutex ကဲ့သို့သော အရာတစ်ခု ရှိပါသည်။ ဤနေရာတွင် အရင်းအမြစ်သည် ပို၍ စိတ္တဇဖြစ်နိုင်သည်။ ကျွန်ုပ်တို့၏ Network ၏ မတူညီသော node များမှ မတူညီသော အပလီကေးရှင်းများသည် ပေးထားသော အရင်းအမြစ်တစ်ခုသို့ သီးသန့်ဝင်ရောက်ခွင့်ကိုသာ ရရှိသင့်သည်၊ သို့မှသာ လူတိုင်းက ၎င်းကို ပြောင်းလဲနိုင်သည် သို့မဟုတ် ထိုနေရာတွင် တစ်ခုခုရေးနိုင်မည်မဟုတ်ပေ။ အဲဒါတွေကို သော့ခတ်လို့ ခေါ်တာ။
ZooKeeper သည် သင့်အား ဤပြဿနာအားလုံးကို အတိုင်းအတာတစ်ခု သို့မဟုတ် အခြားတစ်ခုအထိ ဖြေရှင်းနိုင်စေပါသည်။ ပြီးတော့ အဲဒါက မင်းကို ဘယ်လို လုပ်ခွင့်ပေးသလဲ ဥပမာတွေနဲ့ ပြမယ်။
ပိတ်ဆို့ခြင်း၏ နောက်ဆက်တွဲများ မရှိပါ။ တစ်စုံတစ်ခုကို စတင်အသုံးပြုသောအခါ၊ ဤမူလဖြစ်စဉ်သည် မည်သည့်ဖြစ်ရပ်ကိုမဆို ဖြစ်ပေါ်လာစေရန် စောင့်မည်မဟုတ်ပါ။ ဖြစ်နိုင်ချေ အများစုမှာ၊ ဤအရာသည် တစ်စုံတစ်ခုကို စောင့်ဆိုင်းနေစဉ် အချိန်ဆွဲမနေစေရန် လုပ်ငန်းစဉ်များကို အချိန်မရွေး တပြိုင်နက် လုပ်ဆောင်နိုင်မည်ဖြစ်သည်။ ဒါက အရမ်းအသုံးဝင်တဲ့အရာပါ။
ဖောက်သည် တောင်းဆိုချက်အားလုံးကို ယေဘူယျတန်းစီ၏ အစီအစဥ်အတိုင်း လုပ်ဆောင်ပါသည်။
ဖောက်သည်များသည် ပြောင်းလဲထားသောဒေတာကို ကိုယ်တိုင်မမြင်မီ အချို့သောအခြေအနေများ၊ ဒေတာပြောင်းလဲမှုများအကြောင်း၊ အပြောင်းအလဲများအကြောင်း အကြောင်းကြားချက်ကို လက်ခံရရှိရန် အခွင့်အရေးရှိသည်။
ZooKeeper ကို မုဒ်နှစ်မျိုးနဲ့ လုပ်ဆောင်နိုင်ပါတယ်။ ပထမတစ်ခုက node တစ်ခုတည်းမှာ standalone ဖြစ်ပါတယ်။ ဒါက စမ်းသပ်ဖို့အတွက် အဆင်ပြေပါတယ်။ node အရေအတွက် မည်မျှပင်ရှိစေကာမူ cluster မုဒ်နဲ့လည်း လုပ်ဆောင်နိုင်ပါတယ်။ ဆာဗာများစက် ၁၀၀ ပါတဲ့ cluster ရှိရင် စက် ၁၀၀ မှာ run စရာမလိုပါဘူး။ ZooKeeper run နိုင်တဲ့ စက်အနည်းငယ်ကို ခွဲဝေပေးလိုက်ရုံနဲ့ လုံလောက်ပါတယ်။ ပြီးတော့ high availability မူဝါဒကိုလည်း လိုက်နာပါတယ်။ ZooKeeper က run နေတဲ့ instance တစ်ခုချင်းစီမှာ data ရဲ့ မိတ္တူအပြည့်အစုံကို သိမ်းဆည်းပါတယ်။ ဘယ်လိုလုပ်လဲဆိုတာ နောက်မှ ရှင်းပြပါမယ်။ data ကို shard မလုပ်ဘူး၊ partition မလုပ်ဘူး။ တစ်ဖက်ကကြည့်ရင် ဒါက အားနည်းချက်တစ်ခုပါ၊ ဘာလို့လဲဆိုတော့ အများကြီး store မလုပ်နိုင်လို့ပါ။ ဒါပေမယ့် တစ်ဖက်ကကြည့်ရင် မလိုအပ်ပါဘူး။ အဲဒါအတွက် ဒီဇိုင်းထုတ်ထားတာ မဟုတ်ပါဘူး။ database လည်း မဟုတ်ပါဘူး။
ဒေတာကို client ဘက်တွင် သိမ်းဆည်းနိုင်သည်။ ဤသည်မှာ ကျွန်ုပ်တို့သည် ဝန်ဆောင်မှုကို အနှောင့်အယှက်မဖြစ်စေဘဲ တူညီသောတောင်းဆိုမှုများဖြင့် မတင်ရန် စံမူတစ်ခုဖြစ်သည်။ စမတ်ဖောက်သည်တစ်ဦးသည် ဤအကြောင်းကို အများအားဖြင့်သိပြီး ၎င်းကို သိမ်းဆည်းထားသည်။
ဥပမာအားဖြင့်၊ ဤနေရာတွင် တစ်စုံတစ်ခု ပြောင်းလဲသွားသည်။ လျှောက်လွှာအမျိုးအစားအချို့ရှိသည်။ ဥပမာ- စာရေးခြင်း လုပ်ငန်းများကို ဆောင်ရွက်ရာတွင် တာဝန်ရှိသော ခေါင်းဆောင်အသစ်ကို ရွေးချယ်တင်မြှောက်ခြင်းခံရသည်။ ပြီးတော့ data တွေကို ထပ်တူလုပ်ချင်တယ်။ ဖြေရှင်းနည်းတစ်ခုကတော့ အဲဒါကို ကြိုးဝိုင်းထဲမှာ ထည့်ထားဖို့ပါပဲ။ ကျွန်ုပ်တို့သည် ကျွန်ုပ်တို့၏ဝန်ဆောင်မှုကို အဆက်မပြတ်မေးခွန်းထုတ်သည် - တစ်ခုခုပြောင်းလဲသွားပြီလား။ ဒုတိယရွေးချယ်မှုသည် ပို၍ အကောင်းဆုံးဖြစ်သည်။ ၎င်းသည် သင့်အား တစ်စုံတစ်ခု ပြောင်းလဲသွားကြောင်း သုံးစွဲသူများအား အသိပေးနိုင်သည့် နာရီယန္တရားတစ်ခုဖြစ်သည်။ ဤသည်မှာ အရင်းအမြစ်များနှင့်ပတ်သက်ပြီး စျေးသက်သာပြီး ဖောက်သည်များအတွက် ပိုမိုအဆင်ပြေစေသည်။
Client သည် ZooKeeper ကိုအသုံးပြုသောအသုံးပြုသူဖြစ်သည်။
ဆာဗာသည် ZooKeeper လုပ်ငန်းစဉ်ကိုယ်တိုင်ဖြစ်သည်။
Znode သည် ZooKeeper ၏အဓိကအရာဖြစ်သည်။ znodes အားလုံးကို ZooKeeper မှ မှတ်ဉာဏ်တွင် သိမ်းဆည်းထားပြီး သစ်ပင်ပုံစံဖြင့် အထက်အောက်ပုံသဏ္ဍာန်ပုံစံဖြင့် ဖွဲ့စည်းထားသည်။
လည်ပတ်မှု နှစ်မျိုးရှိသည်။ လုပ်ဆောင်ချက်အချို့သည် ကျွန်ုပ်တို့၏သစ်ပင်၏အခြေအနေကို ပြောင်းလဲသောအခါ ပထမအချက်မှာ အပ်ဒိတ်/ရေးခြင်းဖြစ်ပါသည်။ သစ်ပင်က အဖြစ်များတယ်။
ထို့အပြင် client သည် တောင်းဆိုချက်တစ်ခုအား မပြီးမြောက်ဘဲ အဆက်ပြတ်သွားခြင်း ဖြစ်နိုင်သော်လည်း ၎င်းသည် ZooKeeper နှင့် အပြန်အလှန်တုံ့ပြန်သည့် session တစ်ခုကို တည်ထောင်နိုင်သည်။
ZooKeeper ၏ ဒေတာမော်ဒယ်သည် ဖိုင်စနစ်နှင့် ဆင်တူသည်။ စံအမြစ်တစ်ခုရှိပြီး၊ ထို့နောက် ကျွန်ုပ်တို့သည် root မှသွားသော လမ်းညွှန်များအတိုင်းသွားပါသည်။ ပြီးတော့ ပထမအဆင့်၊ ဒုတိယအဆင့် ကက်တလောက်။ ဤသည်မှာ znodes အားလုံးဖြစ်သည်။
znode တစ်ခုစီသည် ဒေတာအချို့ကို သိမ်းဆည်းနိုင်သည်၊ များသောအားဖြင့် အလွန်မကြီးသော ဥပမာ၊ 10 ကီလိုဘိုက်များ။ znode တစ်ခုစီတွင် အချို့သော ကလေးအရေအတွက် ရှိနိုင်သည်။
Znodes အမျိုးအစားများစွာရှိသည်။ ဖန်တီးနိုင်ကြတယ်။ znode တစ်ခုဖန်တီးသောအခါ၊ ၎င်းနှင့်သက်ဆိုင်သည့်အမျိုးအစားကိုကျွန်ုပ်တို့သတ်မှတ်ပေးသည်။
နှစ်မျိုးရှိပါတယ်။ ပထမတစ်ခုက ပေါ်ပင်အလံ။ Znode သည် session တစ်ခုအတွင်းနေထိုင်သည်။ ဥပမာအားဖြင့်၊ client သည် session တစ်ခုကို တည်ထောင်ထားသည်။ ပြီးတော့ ဒီ session က အသက်ရှင်နေသရွေ့တော့ တည်ရှိနေမှာပါ။ မလိုအပ်သော အရာများ မထုတ်လုပ်နိုင်ရန် ဤအချက်သည် လိုအပ်ပါသည်။ ၎င်းသည် စက်ရှင်တစ်ခုအတွင်း ဒေတာ primitives များကို သိမ်းဆည်းရန် အရေးကြီးသည့်အချိန်များအတွက်လည်း သင့်လျော်ပါသည်။
ဒုတိယအမျိုးအစားမှာ ဆင့်ကဲအလံဖြစ်သည်။ ၎င်းသည် znode သို့သွားရာလမ်းတွင်ကောင်တာတိုးပေးသည်။ ဥပမာအားဖြင့်၊ ကျွန်ုပ်တို့တွင် အပလီကေးရှင်း 1_5 ပါသည့် လမ်းညွှန်တစ်ခုရှိသည်။ ပထမ node ကိုဖန်တီးသောအခါ၊ ၎င်းသည် p_1၊ ဒုတိယ - p_2 ကိုရရှိခဲ့သည်။ ကျွန်ုပ်တို့သည် ဤနည်းလမ်းကို အကြိမ်တိုင်းခေါ်ဆိုသောအခါ၊ ကျွန်ုပ်တို့သည် လမ်းကြောင်း၏ တစ်စိတ်တစ်ပိုင်းကိုသာ ညွှန်ပြပြီး လမ်းကြောင်းတစ်ခုလုံးကို ကျော်သွားကာ node အမျိုးအစားကို ဆက်တိုက်ဖော်ပြသောကြောင့် ဤနံပါတ်သည် အလိုအလျောက်တိုးလာပါသည်။
ပုံမှန် znode သူမသည် အမြဲနေထိုင်ပြီး ကျွန်ုပ်တို့ သူမကို ပြောပြသော နာမည်ရှိသည်။
နောက်ထပ်အသုံးဝင်တာကတော့ နာရီအလံပါ။ ၎င်းကို ကျွန်ုပ်တို့ထည့်သွင်းပါက၊ client သည် သီးခြား node တစ်ခုအတွက် အချို့သောဖြစ်ရပ်များကို စာရင်းသွင်းနိုင်ပါသည်။ အဲဒါကို ဘယ်လိုလုပ်ပြီးပြီလဲ နောက်မှ ဥပမာပြမယ်။ Node ပေါ်ရှိ ဒေတာများ ပြောင်းလဲသွားကြောင်း ZooKeeper ကိုယ်တိုင်က သုံးစွဲသူအား အသိပေးသည်။ သို့သော်၊ အကြောင်းကြားချက်များသည် အချို့သောဒေတာအသစ်များရောက်ရှိလာကြောင်း အာမမခံနိုင်ပါ။ တစ်ခုခုပြောင်းလဲသွားသည်ဟု ၎င်းတို့က ရိုးရိုးရှင်းရှင်းပြောသောကြောင့် နောက်ပိုင်းတွင် သီးခြားခေါ်ဆိုမှုများနှင့် ဒေတာကို နှိုင်းယှဉ်ရန် လိုအပ်နေသေးသည်။
ကျွန်တော်ပြောခဲ့သလိုပဲ ဒေတာရဲ့ အစီအစဥ်ကို ကီလိုဘိုက်နဲ့ ဆုံးဖြတ်ပါတယ်။ ဒေတာဘေ့စ်တစ်ခုမဟုတ်သောကြောင့် ၎င်းသည် ကြီးမားသော စာသားဒေတာကို သိမ်းဆည်းရန်မလိုအပ်ပါ၊ ၎င်းသည် လုပ်ဆောင်ချက်ညှိနှိုင်းရေးဆာဗာတစ်ခုဖြစ်သည်။
session တွေအကြောင်း နည်းနည်းပြောပြပါရစေ။ server အများအပြားရှိရင် server တစ်ခုကနေ နောက်တစ်ခုကို ပွင့်လင်းမြင်သာစွာ ပြောင်းလဲနိုင်ပါတယ်။ ဆာဗာsession ID ကိုသုံးခြင်း။ ဒါက အတော်လေးအဆင်ပြေပါတယ်။
Session တစ်ခုစီတွင် အချိန်ကုန်ဆုံးမှု တစ်မျိုးစီရှိသည်။ ထိုစက်ရှင်အတွင်း ဖောက်သည်သည် ဆာဗာသို့ တစ်စုံတစ်ရာ ပေးပို့ခြင်း ရှိ၊ အချိန်ကုန်သွားချိန်တွင် မည်သည့်အရာမှ မပို့ပါက၊ စက်ရှင် ပျက်သွားသည်၊ သို့မဟုတ် client သည် ၎င်းကို ကိုယ်တိုင်ပိတ်နိုင်သည်။
၎င်းတွင် များစွာသော အင်္ဂါရပ်များ မပါရှိသော်လည်း ဤ API ဖြင့် မတူညီသောအရာများကို သင်လုပ်ဆောင်နိုင်သည်။ ကျွန်ုပ်တို့ဖန်တီးထားသော ခေါ်ဆိုမှုသည် znode တစ်ခုကို ဖန်တီးပြီး ဘောင်သုံးခုကို ယူသည်။ ဤသည်မှာ znode သို့သွားရာလမ်းကြောင်းဖြစ်ပြီး ၎င်းကို root မှ အပြည့်အစုံသတ်မှတ်ထားရပါမည်။ နောက်ပြီး ဒါက ကျွန်တော်တို့ အဲဒီကို လွှဲပြောင်းချင်တဲ့ ဒေတာတချို့လည်း ဖြစ်ပါတယ်။ အလံအမျိုးအစားနှင့်။ ဖန်တီးပြီးနောက်၎င်းသည် znode သို့လမ်းကြောင်းပြန်ပေးသည်။
ဒုတိယအနေနဲ့ သင်က အဲဒါကို ဖျက်နိုင်တယ်။ ဤတွင်လှည့်ကွက်မှာ znode သို့သွားသည့်လမ်းကြောင်းအပြင် ဒုတိယ parameter သည် ဗားရှင်းကို သတ်မှတ်နိုင်သည် ။ ထို့ကြောင့်၊ ကျွန်ုပ်တို့လွှဲပြောင်းပေးသော ၎င်း၏ဗားရှင်းသည် အမှန်တကယ်ရှိနေသည့် ဗားရှင်းနှင့် ညီမျှပါက အဆိုပါ znode ကို ဖျက်လိုက်ပါမည်။
ဤဗားရှင်းကို ကျွန်ုပ်တို့ မစစ်ဆေးလိုပါက "-1" အငြင်းအခုံကို ရိုးရိုးရှင်းရှင်း ကျော်ဖြတ်ပါ။
တတိယ၊ ၎င်းသည် znode ၏တည်ရှိမှုကိုစစ်ဆေးသည်။ node ရှိလျှင် မှန်သည်၊ မဟုတ်ပါက false ပြန်ပေးသည်။
ထို့နောက် ဤ node ကို စောင့်ကြည့်ရန် ခွင့်ပြုသည့် အလံနာရီ ပေါ်လာသည်။
ဤအလံကို တည်ရှိခြင်းမရှိသော ကုဒ်တစ်ခုပေါ်တွင်ပင် သင်သတ်မှတ်နိုင်ပြီး ပေါ်လာသည့်အခါ အကြောင်းကြားချက်တစ်ခု လက်ခံရရှိနိုင်ပါသည်။ ဒါကလည်း အသုံးဝင်နိုင်ပါတယ်။
နောက်ထပ် စိန်ခေါ်မှုတွေ ရှိပါသေးတယ်။ getData. ကျွန်ုပ်တို့သည် znode မှတဆင့် data ကိုလက်ခံရရှိနိုင်ကြောင်းရှင်းလင်းသည်။ အလံနာရီကိုလည်း သုံးနိုင်သည်။ ဤကိစ္စတွင်၊ node မရှိပါက install လုပ်မည်မဟုတ်ပါ။ ထို့ကြောင့်၊ ၎င်းသည် တည်ရှိကြောင်း နားလည်ရန် လိုအပ်ပြီး ဒေတာကို ရယူပါ။
လည်းရှိတယ်။ SetData. ဤတွင်ကျွန်ုပ်တို့ဗားရှင်းကိုဖြတ်သန်းပါ။ ၎င်းကိုကျွန်ုပ်တို့ဖြတ်သန်းပါက၊ အချို့သောဗားရှင်း၏ znode ပေါ်ရှိဒေတာကိုမွမ်းမံမည်ဖြစ်သည်။
ဤစစ်ဆေးမှုကို ဖယ်ထုတ်ရန် "-1" ကိုလည်း သင် သတ်မှတ်နိုင်သည်။
နောက်ထပ်အသုံးဝင်သောနည်းလမ်းတစ်ခုဖြစ်သည်။ ကလေးယူပါ။. ၎င်းနှင့်သက်ဆိုင်သည့် znode များအားလုံး၏စာရင်းကိုလည်း ကျွန်ုပ်တို့ရနိုင်သည်။ အလံနာရီကို သတ်မှတ်ခြင်းဖြင့် ၎င်းကို ကျွန်ုပ်တို့ စောင့်ကြည့်နိုင်ပါသည်။
နှင့်နည်းလမ်း ထပ်တူပြုခြင်း ပြောင်းလဲမှုအားလုံးကို တစ်ပြိုင်နက် ပေးပို့နိုင်စေခြင်းဖြင့် ၎င်းတို့ကို သိမ်းဆည်းပြီး ဒေတာအားလုံးကို လုံးဝပြောင်းလဲသွားကြောင်း သေချာစေပါသည်။
ပုံမှန် ပရိုဂရမ်းမင်းစနစ်ဖြင့် တူညီသောအချက်များ ရေးဆွဲပါက၊ အကယ်၍ သင်သည် စာရေးရန်၊ ဒစ်ခ်သို့ တစ်ခုခုရေးပေးသည့် နည်းလမ်းများကို အသုံးပြုသည့်အခါ၊ ၎င်းသည် သင့်ထံ တုံ့ပြန်မှုကို ပြန်ပေးပြီးနောက်၊ သင်သည် ဒေတာကို ဒစ်ခ်သို့ ရေးထားကြောင်း အာမခံချက်မရှိပါ။ လည်ပတ်မှုစနစ်သည် အရာအားလုံးကို ရေးပြီးကြောင်း ယုံကြည်သောအခါတွင်ပင်၊ လုပ်ငန်းစဉ်သည် buffers အလွှာများမှတစ်ဆင့် ဖြတ်သန်းသွားသည့် ဒစ်ခ်တွင် ယန္တရားများရှိပြီး၊ ဒေတာကို ဒစ်ပေါ်တွင် ထားရှိပြီးနောက်မှသာ လုပ်ဆောင်သည်။
အများအားဖြင့် asynchronous ခေါ်ဆိုမှုများကို အသုံးပြုသည်။ ဒါက client ကို မတူညီတဲ့ တောင်းဆိုချက်တွေနဲ့ အပြိုင်အလုပ်လုပ်နိုင်စေတယ်။ synchronous ချဉ်းကပ်မှုကို သင်သုံးနိုင်သော်လည်း ၎င်းသည် အကျိုးနည်းသည်။
ကျွန်ုပ်တို့ပြောခဲ့သော လုပ်ဆောင်ချက်နှစ်ခုမှာ ဒေတာကို ပြောင်းလဲပေးသည့် အပ်ဒိတ်/ရေးခြင်း ဖြစ်သည်။ ၎င်းတို့သည် ဖန်တီးခြင်း၊ setData၊ ထပ်တူပြုခြင်း၊ ဖျက်ခြင်း တို့ဖြစ်သည်။ ပြီးသည်နှင့်ဖတ်ရန်၊ getData၊ getChildren ရှိနေသည်။
ယခုတွင် ဖြန့်ဝေမှုစနစ်တွင် အလုပ်လုပ်ရန်အတွက် primitives များကို သင်မည်ကဲ့သို့ပြုလုပ်နိုင်ပုံ၏ ဥပမာအချို့။ ဥပမာအားဖြင့်၊ တစ်စုံတစ်ခု၏ဖွဲ့စည်းပုံနှင့်သက်ဆိုင်သည်။ အလုပ်သမားအသစ် ပေါ်လာတယ်။ ကျွန်ုပ်တို့သည် စက်ကိုထည့်သွင်းပြီး လုပ်ငန်းစဉ်ကို စတင်ခဲ့သည်။ ပြီးတော့ အောက်ပါမေးခွန်းသုံးခုရှိပါတယ်။ ဖွဲ့စည်းမှုပုံစံအတွက် ZooKeeper ကို မည်သို့မေးမြန်းသနည်း။ configuration ကိုပြောင်းချင်ရင်၊ ဘယ်လိုပြောင်းမလဲ။ အဲဒါကို ငါတို့ပြောင်းပြီးရင် ငါတို့ရထားတဲ့ အလုပ်သမားတွေက ဘယ်လိုရလဲ။
ZooKeeper သည် ၎င်းကို အတော်လေး လွယ်ကူစေသည်။ ဥပမာအားဖြင့်၊ ကျွန်ုပ်တို့၏ znode tree ရှိသည်။ ဤနေရာတွင် ကျွန်ုပ်တို့၏အပလီကေးရှင်းအတွက် node တစ်ခုရှိသည်၊ ကျွန်ုပ်တို့သည် ၎င်းတွင် အပို node တစ်ခုကိုဖန်တီးပြီး configuration မှဒေတာများပါရှိသည်။ ၎င်းတို့သည် သီးခြားကန့်သတ်ချက်များ ဖြစ်နိုင်သည် သို့မဟုတ် ဖြစ်နိုင်သည်။ အရွယ်အစားသည် သေးငယ်သောကြောင့်၊ ဖွဲ့စည်းမှုအရွယ်အစားသည် အများအားဖြင့် သေးငယ်သောကြောင့် ဤနေရာတွင် သိမ်းဆည်းရန် အတော်လေး ဖြစ်နိုင်သည်။
သင်အသုံးပြုနေသောနည်းလမ်း getData node မှ အလုပ်သမားအတွက် configuration ကိုရယူရန်။ အမှန်ဟု သတ်မှတ်သည်။ အကြောင်းတစ်ခုခုကြောင့် ဤ node မရှိပါက၊ ၎င်းကို ပေါ်လာသည့်အခါ သို့မဟုတ် ပြောင်းလဲသည့်အခါတွင် ကျွန်ုပ်တို့အား အသိပေးပါမည်။ တစ်စုံတစ်ခု ပြောင်းလဲသွားကြောင်း သိချင်ပါက ၎င်းကို အမှန်အဖြစ် သတ်မှတ်လိုက်ပါ။ ပြီးတော့ ဒီ node ထဲက data တွေ ပြောင်းသွားရင်တော့ အဲဒါကို သိပါလိမ့်မယ်။
SetData. ကျွန်ုပ်တို့သည် ဒေတာကို သတ်မှတ်ပြီး၊ “-1” ဟု သတ်မှတ်သည်၊ ဆိုလိုသည်မှာ ကျွန်ုပ်တို့သည် ဗားရှင်းကို မစစ်ဆေးဘဲ၊ ကျွန်ုပ်တို့တွင် ဖွဲ့စည်းမှုပုံစံတစ်ခု အမြဲရှိနေသည်ဟု ကျွန်ုပ်တို့ ယူဆသည်၊ ကျွန်ုပ်တို့သည် များစွာသောဖွဲ့စည်းပုံများကို သိမ်းဆည်းရန် မလိုအပ်ပါ။ အများကြီး သိမ်းထားဖို့ လိုရင် နောက်ထပ် အဆင့်တစ်ခု ထပ်ထည့်ဖို့ လိုပါလိမ့်မယ်။ ဤတွင်တစ်ခုသာရှိမည်ဟုကျွန်ုပ်တို့ယုံကြည်သည်၊ ထို့ကြောင့်ကျွန်ုပ်တို့သည်နောက်ဆုံးထွက်တစ်ခုတည်းကိုသာအပ်ဒိတ်လုပ်သောကြောင့်ဗားရှင်းကိုမစစ်ဆေးပါ။ ယခုအချိန်တွင်၊ ယခင်က စာရင်းသွင်းထားသည့် သုံးစွဲသူများအားလုံးသည် ဤ node တွင် တစ်စုံတစ်ခု ပြောင်းလဲသွားကြောင်း အကြောင်းကြားချက်ကို ရရှိသည်။ သူတို့လက်ခံပြီးရင် အချက်အလက်တွေကိုလည်း ထပ်ပြီး တောင်းဆိုရမယ်။ အကြောင်းကြားချက်မှာ ၎င်းတို့ကိုယ်တိုင်က ဒေတာကို မရရှိသော်လည်း အပြောင်းအလဲများကို အသိပေးခြင်းသာဖြစ်သည်။ အဲဒါပြီးရင် ဒေတာအသစ်တွေ တောင်းရမယ်။
primitive ကိုအသုံးပြုရန် ဒုတိယရွေးချယ်မှုမှာ အုပ်စုအဖွဲ့ဝင်. ကျွန်ုပ်တို့တွင် ဖြန့်ဝေထားသော လျှောက်လွှာတစ်ခု ရှိပြီး အလုပ်သမားများ အစုအဝေး ရှိနေပြီး ၎င်းတို့အားလုံး နေရာတွင် ရှိနေကြောင်း နားလည်ပေးစေလိုပါသည်။ ထို့ကြောင့် ၎င်းတို့သည် ကျွန်ုပ်တို့၏လျှောက်လွှာတွင် အလုပ်လုပ်ရန် ၎င်းတို့ကိုယ်တိုင် မှတ်ပုံတင်ရမည်ဖြစ်သည်။ ထို့အပြင် ကျွန်ုပ်တို့သည် Master လုပ်ငန်းစဉ်မှဖြစ်စေ အခြားတစ်နေရာတွင်ဖြစ်စေ ကျွန်ုပ်တို့လက်ရှိရရှိနေသော တက်ကြွသောအလုပ်သမားများအားလုံးအကြောင်းကိုလည်း ကျွန်ုပ်တို့ သိရှိလိုပါသည်။
ဒါကို ဘယ်လို လုပ်မလဲ။ အပလီကေးရှင်းအတွက်၊ ကျွန်ုပ်တို့သည် အလုပ်သမား node တစ်ခုကို ဖန်တီးပြီး ဖန်တီးမှုနည်းလမ်းကို အသုံးပြု၍ ထိုနေရာတွင် အဆင့်ခွဲတစ်ခုကို ပေါင်းထည့်ပါသည်။ ဆလိုက်ပေါ်တွင် အမှားအယွင်းတစ်ခုရှိသည်။ ဒီမှာ မင်းလိုတယ်။ နောက်ဆက်တွဲ သတ်မှတ်ပါ၊ ထို့နောက် အလုပ်သမားအားလုံးကို တစ်ဦးပြီးတစ်ယောက် ဖန်တီးပါမည်။ ပြီးတော့ ဒီ node လေးတွေရဲ့ အချက်အလက်အားလုံးကို တောင်းဆိုတဲ့ application ဟာ ရှိနေတဲ့ တက်ကြွတဲ့ အလုပ်သမားအားလုံးကို လက်ခံပါတယ်။
၎င်းသည် Java ကုဒ်တွင် ဤကဲ့သို့ လုပ်ဆောင်နိုင်သည့် ဆိုးရွားသော အကောင်အထည်ဖော်မှုတစ်ခုဖြစ်သည်။ အဓိကနည်းလမ်းဖြင့် အဆုံးမှစကြပါစို့။ ဒါကျွန်ုပ်တို့ရဲ့အတန်းပါ၊ သူ့ရဲ့နည်းလမ်းကိုဖန်တီးကြပါစို့။ ပထမအငြင်းအခုံအဖြစ် ကျွန်ုပ်တို့ချိတ်ဆက်နေသည့် host ကိုအသုံးပြုသည်၊ ဆိုလိုသည်မှာ ၎င်းကို အငြင်းအခုံတစ်ခုအဖြစ် သတ်မှတ်သည်။ ဒုတိယအငြင်းအခုံသည် အဖွဲ့၏အမည်ဖြစ်သည်။
ချိတ်ဆက်မှုက ဘယ်လိုဖြစ်တာလဲ။ ဤသည်မှာ အသုံးပြုသော API ၏ ရိုးရှင်းသော ဥပမာတစ်ခုဖြစ်သည်။ ဤတွင်အရာအားလုံးသည်အတော်လေးရိုးရှင်းသည်။ စံအဆင့် ZooKeeper ရှိပါသည်။ ကျွန်တော်တို့က အိမ်ရှင်တွေကို လွှဲပေးတယ်။ ဥပမာအားဖြင့် အချိန်ကုန်ဆုံးချိန်ကို 5 စက္ကန့်သတ်မှတ်ပါ။ ပြီးတော့ ကျွန်တော်တို့မှာ connectionSignal လို့ခေါ်တဲ့ အဖွဲ့ဝင်တစ်ယောက်ရှိတယ်။ အခြေခံအားဖြင့်၊ ကျွန်ုပ်တို့သည် ကူးစက်လမ်းကြောင်းတစ်လျှောက်တွင် အုပ်စုတစ်ခုကို ဖန်တီးသည်။ တစ်ခုခုရေးနိုင်ပေမယ့် အဲဒီနေရာမှာ ဒေတာမရေးပါဘူး။ ဤနေရာတွင် node သည် persistent type ဖြစ်သည်။ အခြေခံအားဖြင့်၊ ၎င်းသည် အချိန်တိုင်းတည်ရှိနေမည့် သာမန်ပုံမှန် node တစ်ခုဖြစ်သည်။ ဤနေရာတွင် session ကိုဖန်တီးထားသည်။ ဒါက client ကိုယ်တိုင်ရဲ့ အကောင်အထည်ဖော်မှုပါ။ ကျွန်ုပ်တို့၏ဖောက်သည်သည် စက်ရှင်အသက်ဝင်ကြောင်း ညွှန်ပြသော အချိန်အခါအလိုက် မက်ဆေ့ဂျ်များ ပေးပို့ပါမည်။ ကျွန်ုပ်တို့သည် စက်ရှင်ကို အဆုံးသတ်သောအခါတွင် ကျွန်ုပ်တို့သည် အနီးကပ်ခေါ်ဆိုကြပြီး၊ အစည်းအဝေး ပျက်သွားပါသည်။ ဤအရာသည် ကျွန်ုပ်တို့အတွက် တစ်ခုခု ပျက်သွားပါက ZooKeeper သည် ၎င်းအကြောင်းကို သိရှိပြီး စက်ရှင်ကို ဖြတ်တောက်ရန်ဖြစ်သည်။
အရင်းအမြစ်ကို ဘယ်လိုလော့ခ်ချမလဲ။ ဤတွင်အရာအားလုံးအနည်းငယ်ပိုရှုပ်ထွေးသည်။ ကျွန်တော်တို့မှာ အလုပ်သမားတွေ အစုံရှိတယ်၊ သော့ခတ်ချင်တဲ့ အရင်းအမြစ်တွေရှိတယ်။ ဒါကိုလုပ်ဖို့၊ ဥပမာ၊ lock1 လို့ခေါ်တဲ့ သီးခြား node တစ်ခုကို ဖန်တီးတယ်။ အဲဒါကို ဖန်တီးနိုင်ရင် ဒီမှာ သော့ခတ်လို့ရပါပြီ။ ၎င်းကိုကျွန်ုပ်တို့မဖန်တီးနိုင်ခဲ့ပါက၊ အလုပ်သမားသည် ဤနေရာမှ getData ကိုရယူရန်ကြိုးစားပြီး node ကိုဖန်တီးပြီးဖြစ်သောကြောင့်၊ ကျွန်ုပ်တို့သည် စောင့်ကြည့်သူအား ဤနေရာတွင်ထားရှိပြီး ဤ node ၏အခြေအနေပြောင်းလဲမှုအခိုက်အတန့်တွင် ကျွန်ုပ်တို့သည် ၎င်းအကြောင်းကို သိရှိမည်ဖြစ်ပါသည်။ ပြီးတော့ အဲဒါကို ပြန်ဖန်တီးဖို့ ကျွန်တော်တို့ ကြိုးစားနိုင်တယ်။ အကယ်၍ ကျွန်ုပ်တို့သည် ဤ node ကိုယူကာ၊ ဤသော့ကိုယူခဲ့ပါက၊ ထို့နောက် ကျွန်ုပ်တို့သည် သော့ကို မလိုအပ်တော့သည့်နောက်၊ node သည် session အတွင်းသာရှိနေသောကြောင့် ၎င်းကို စွန့်လွှတ်လိုက်ပါမည်။ ထို့ကြောင့် ပျောက်ကွယ်သွားလိမ့်မည်။ အခြားစက်ရှင်၏ မူဘောင်အတွင်း အခြား client သည် ဤ node တွင် လော့ခ်ချနိုင်လိမ့်မည် သို့မဟုတ် တစ်ခုခုပြောင်းလဲသွားပြီဖြစ်ကြောင်း အသိပေးချက်ကို လက်ခံရရှိမည်ဖြစ်ပြီး ၎င်းကို အချိန်မီလုပ်ဆောင်နိုင်မည်ဖြစ်သည်။
ပင်မခေါင်းဆောင်ကို ဘယ်လိုရွေးချယ်နိုင်မလဲဆိုတာရဲ့ နောက်ထပ်ဥပမာတစ်ခု။ ၎င်းသည် အနည်းငယ်ပိုရှုပ်ထွေးသော်လည်း အတော်လေးရိုးရှင်းပါသည်။ ဒီမှာဘာတွေဖြစ်နေတာလဲ? အလုပ်သမားအားလုံးကို စုစည်းပေးသည့် အဓိက ဆုံမှတ်တစ်ခု ရှိသည်။ ခေါင်းဆောင်နှင့်ပတ်သက်သော အချက်အလက်များကို ရယူရန် ကြိုးစားနေပါသည်။ အကယ်၍ ဤအရာ အောင်မြင်ခဲ့ပါက၊ ဆိုလိုသည်မှာ ကျွန်ုပ်တို့သည် ဒေတာအချို့ကို လက်ခံရရှိပြီးနောက်၊ ကျွန်ုပ်တို့၏ အလုပ်သမားသည် ဤခေါင်းဆောင်နောက်သို့ စတင်လိုက်ပါသည်။ ခေါင်းဆောင်ရှိနေပြီဟု ယုံကြည်သည်။
ဥပမာအားဖြင့် ခေါင်းဆောင်က အကြောင်းတစ်ခုခုကြောင့် ပြုတ်ကျရင်၊ ခေါင်းဆောင်အသစ်ကို ဖန်တီးဖို့ ကြိုးစားတယ်။ ငါတို့အောင်မြင်ရင် ငါတို့အလုပ်သမားက ခေါင်းဆောင်ဖြစ်လာတယ်။ ဒီအချိန်မှာ တစ်ယောက်ယောက်က ခေါင်းဆောင်အသစ်ကို ဖန်တီးနိုင်ခဲ့ရင်၊ ငါတို့က ဘယ်သူလဲဆိုတာ နားလည်အောင်ကြိုးစားပြီး သူ့နောက်ကို လိုက်သွားလိုက်ပါ။
ဤတွင် အစုအပြုံလိုက်အကျိုးသက်ရောက်မှုသည် ဖြစ်ပေါ်လာသည်၊ ဆိုလိုသည်မှာ၊ ခေါင်းဆောင်တစ်ဦးသေဆုံးသောအခါ၊ အချိန်မီမီသောသူသည် ခေါင်းဆောင်ဖြစ်လာနိုင်သောကြောင့်ဖြစ်သည်။
အရင်းအမြစ်တစ်ခုအား ဖမ်းယူရာတွင် အောက်ပါအတိုင်း အနည်းငယ်ကွဲပြားသောချဉ်းကပ်နည်းကို အသုံးပြုရန် ကြိုးစားနိုင်သည်။ ဥပမာအားဖြင့်၊ ကျွန်ုပ်တို့သည် သော့ခတ်ခြင်းကို ရယူလိုသော်လည်း hert အကျိုးသက်ရောက်မှုမရှိပါ။ ကျွန်ုပ်တို့၏ အပလီကေးရှင်းသည် သော့ခတ်ထားပြီး ရှိပြီးသား node တစ်ခုအတွက် node ids များစာရင်းကို တောင်းဆိုနေသောကြောင့် ၎င်းတွင် ပါဝင်မည်ဖြစ်သည်။ ကျွန်ုပ်တို့ဖန်တီးထားသော သော့ခလောက်သည် ကျွန်ုပ်တို့လက်ခံရရှိသည့် set ၏အသေးဆုံးဖြစ်သည်ဆိုလျှင်၊ ယင်းက ကျွန်ုပ်တို့သည် သော့ကိုဖမ်းမိပြီဟု ဆိုလိုပါသည်။ ကျွန်ုပ်တို့သည် လော့ခ်ချခြင်းကို လက်ခံရရှိကြောင်း စစ်ဆေးပါသည်။ စစ်ဆေးမှုတစ်ခုအနေဖြင့် လော့ခ်အသစ်ဖန်တီးရာတွင် ကျွန်ုပ်တို့ရရှိသော id သည် အနည်းငယ်မျှသာရှိသော အခြေအနေတစ်ခုရှိပါမည်။ လက်ခံရရှိပါက၊ ဆက်လက်လုပ်ဆောင်သွားပါမည်။
ကျွန်ုပ်တို့၏သော့ထက်ငယ်သော ID အချို့ရှိပါက၊ ထို့နောက် ကျွန်ုပ်တို့သည် ဤဖြစ်ရပ်တွင် စောင့်ကြည့်သူအား ထားရှိကာ တစ်စုံတစ်ခု ပြောင်းလဲသွားသည်အထိ အကြောင်းကြားချက်ကို စောင့်ပါ။ ဆိုလိုသည်မှာ၊ ကျွန်ုပ်တို့သည် ဤသော့ခတ်ခြင်းကို လက်ခံရရှိခဲ့သည်။ ပြုတ်ကျသည်အထိ ကျွန်ုပ်တို့သည် အနိမ့်ဆုံး id ဖြစ်လာမည်မဟုတ်သည့်အပြင် အနိမ့်ဆုံးသော့ကို လက်ခံရရှိမည်မဟုတ်သောကြောင့် ကျွန်ုပ်တို့သည် လော့ဂ်အင်ဝင်နိုင်မည်ဖြစ်သည်။ အကယ်၍ ဤအခြေအနေနှင့်မကိုက်ညီပါက၊ ဤအချိန်အတောအတွင်း တစ်ခုခုပြောင်းလဲသွားနိုင်သောကြောင့် ဤလော့ခ်ကို ချက်ချင်းရယူရန် ကြိုးစားပါ။
ZooKeeper တွင် အဘယ်အရာပါဝင်သနည်း။ အဓိကအချက် ၄ ချက်ရှိပါတယ်။ ၎င်းသည် စီမံဆောင်ရွက်ဆဲ လုပ်ငန်းစဉ်များ - တောင်းဆိုချက်။ ZooKeeper Atomic Broadcast လည်းဖြစ်ပါတယ်။ လုပ်ဆောင်ချက်အားလုံးကို မှတ်တမ်းတင်ထားသည့် Commit Log တစ်ခုရှိသည်။ နှင့် In-memory Replicated DB ကိုယ်တိုင်၊ ဆိုလိုသည်မှာ ဤသစ်ပင်တစ်ခုလုံးကို သိမ်းဆည်းထားသည့် ဒေတာဘေ့စ်ကိုယ်တိုင်ဖြစ်သည်။
စာရေးခြင်းလုပ်ငန်းအားလုံးသည် Request Processor မှတဆင့်သွားသည်ကို သတိပြုသင့်သည်။ နှင့်ဖတ်ခြင်းလုပ်ဆောင်ချက်များသည် In-memory database သို့ တိုက်ရိုက်သွားပါသည်။
ဒေတာဘေ့စ်ကိုယ်တိုင်က အပြည့်အဝ ထပ်တူလုပ်ထားပါတယ်။ ZooKeeper ၏ဖြစ်ရပ်အားလုံးသည် အချက်အလက်အပြည့်အစုံကို မိတ္တူတစ်ခုသိမ်းဆည်းထားသည်။
ပျက်ကျပြီးနောက် ဒေတာဘေ့စ်ကို ပြန်လည်ရယူရန်အတွက်၊ Commit မှတ်တမ်းတစ်ခု ရှိပါသည်။ စံအလေ့အကျင့်တစ်ခုကတော့ ဒေတာမမ်မိုရီထဲကို မဝင်ခင်မှာ ပျက်သွားရင် ဒီလော့ဂ်ကို ပြန်ဖွင့်နိုင်ပြီး စနစ်အခြေအနေကို ပြန်ယူနိုင်စေဖို့ အဲဒီနေရာမှာ ရေးထားပါတယ်။ ဒေတာဘေ့စ်၏ အချိန်အပိုင်းအခြားအလိုက် လျှပ်တစ်ပြက်ရိုက်ချက်များကိုလည်း အသုံးပြုပါသည်။
ZooKeeper Atomic Broadcast သည် ပုံတူကူးထားသော ဒေတာကို ထိန်းသိမ်းရန် အသုံးပြုသည့် အရာတစ်ခုဖြစ်သည်။
ZAB သည် ZooKeeper node ၏ရှုထောင့်မှ ခေါင်းဆောင်တစ်ဦးကို အတွင်းပိုင်းမှ ရွေးချယ်သည်။ အခြား node များသည် သူမ၏နောက်လိုက်များဖြစ်လာပြီး သူမထံမှ လုပ်ဆောင်ချက်အချို့ကို မျှော်လင့်ထားသည်။ ဝင်ခွင့်ရရှိပါက အားလုံးကို ခေါင်းဆောင်ထံ ပေးပို့သည်။ သူသည် ပထမဦးစွာ စာရေးခြင်းလုပ်ငန်းကို လုပ်ဆောင်ပြီးနောက် ၎င်း၏နောက်လိုက်များထံ အပြောင်းအလဲများအကြောင်း မက်ဆေ့ချ်ပေးပို့သည်။ ၎င်းသည် အမှန်တကယ်အားဖြင့် အက်တမ်နည်းအရ လုပ်ဆောင်ရမည်၊ ဆိုလိုသည်မှာ အရာတစ်ခုလုံး၏ အသံသွင်းခြင်းနှင့် ထုတ်လွှင့်ခြင်းလုပ်ငန်းကို အက်တမ်ပုံစံအတိုင်း လုပ်ဆောင်ရမည်ဖြစ်ပြီး၊ ထို့ကြောင့် ဒေတာညီညွတ်မှုကို အာမခံပါသည်။
၎င်းသည် တောင်းဆိုမှုများကို ရေးရန်သာ လုပ်ဆောင်သည်။ ၎င်း၏အဓိကတာဝန်မှာ လုပ်ဆောင်ချက်အား အရောင်းအ၀ယ်ဆိုင်ရာ အပ်ဒိတ်အဖြစ်သို့ ပြောင်းလဲပေးခြင်းဖြစ်သည်။ ဤသည်မှာ အထူးထုတ်လုပ်ထားသော တောင်းဆိုချက်ဖြစ်သည်။
ဤနေရာတွင် တူညီသောလုပ်ဆောင်ချက်အတွက် အပ်ဒိတ်များ၏ အစွမ်းသတ္တိမရှိခြင်းကို အာမခံကြောင်း ဤနေရာတွင် သတိပြုသင့်သည်။ ဒါဘာလဲ? ဤအရာအား နှစ်ကြိမ်လုပ်ဆောင်ပါက တူညီသောအခြေအနေရှိမည်၊ ဆိုလိုသည်မှာ တောင်းဆိုချက်သည် ပြောင်းလဲမည်မဟုတ်ပါ။ ပျက်ကျသွားသည့်အခါတွင် သင်သည် လည်ပတ်မှုကို ပြန်လည်စတင်နိုင်ပြီး လက်ရှိအချိန်တွင် ပျက်သွားသော အပြောင်းအလဲများကို ပြန်လည်စတင်နိုင်ရန် ၎င်းကို လုပ်ဆောင်ရန်လိုအပ်သည်။ ဤအခြေအနေတွင်၊ စနစ်၏အခြေအနေသည် တူညီလိမ့်မည်၊ ဆိုလိုသည်မှာ တူညီသောစီးရီးများ၊ ဥပမာ၊ အပ်ဒိတ်လုပ်ငန်းစဉ်များသည် စနစ်၏မတူညီသောနောက်ဆုံးအခြေအနေများဆီသို့ ဦးတည်သွားသည့်ကိစ္စမျိုး မဖြစ်သင့်ပါ။
source: www.habr.com
