ကျောင်းသားငါးဦးနှင့် သော့ဖိုးစတိုးဆိုင်သုံးဆိုင် ခွဲဝေပေးသည်။

သို့မဟုတ် ZooKeeper၊ etcd နှင့် Consul KV အတွက် client C++ စာကြည့်တိုက်ကို ကျွန်ုပ်တို့ မည်သို့ရေးသားခဲ့သည်

ဖြန့်ဝေသည့်စနစ်များ၏ ကမ္ဘာတွင်၊ ပုံမှန်လုပ်ဆောင်စရာများစွာရှိသည်- အစုအဝေး၏ဖွဲ့စည်းပုံအကြောင်း အချက်အလက်များကို သိမ်းဆည်းခြင်း၊ nodes များ၏ဖွဲ့စည်းပုံကို စီမံခန့်ခွဲခြင်း၊ မှားယွင်းနေသော node များကို ရှာဖွေခြင်း၊ ခေါင်းဆောင်တစ်ဦးကို ရွေးချယ်ခြင်း Ryo RґSЂSѓRіRoRμ. အဆိုပါပြဿနာများကိုဖြေရှင်းရန်, အထူးဖြန့်ဝေစနစ်များကိုဖန်တီးခဲ့သည် - ညှိနှိုင်းရေးဝန်ဆောင်မှုများ။ ယခု ၎င်းတို့ထဲမှ ၃ ဦးမှာ ZooKeeper၊ etcd နှင့် Consul တို့ စိတ်ဝင်စားမည်ဖြစ်သည်။ Consul ၏ ကြွယ်ဝသော လုပ်ဆောင်နိုင်စွမ်းများထဲမှ ကျွန်ုပ်တို့သည် Consul KV ကို အာရုံစိုက်ပါမည်။

အနှစ်သာရအားဖြင့်၊ ဤစနစ်များအားလုံးသည် အမှား-ခံနိုင်ရည်ရှိသော၊ linearizable key-value စတိုးဆိုင်များဖြစ်သည်။ ၎င်းတို့၏ ဒေတာမော်ဒယ်များသည် သိသာထင်ရှားသော ကွဲပြားမှုများရှိသော်လည်း နောက်ပိုင်းတွင် ကျွန်ုပ်တို့ ဆွေးနွေးမည့်အရာများသည် တူညီသော လက်တွေ့ကျသော ပြဿနာများကို ဖြေရှင်းနိုင်ကြသည်။ ထင်ရှားသည်မှာ၊ ညှိနှိုင်းရေးဝန်ဆောင်မှုကိုအသုံးပြုသည့် အပလီကေးရှင်းတစ်ခုစီသည် ၎င်းတို့ထဲမှတစ်ခုနှင့် ချိတ်ဆက်ထားသောကြောင့် မတူညီသောအပလီကေးရှင်းများအတွက် တူညီသောပြဿနာများကိုဖြေရှင်းပေးသည့် ဒေတာစင်တာတစ်ခုရှိ စနစ်များစွာကို ပံ့ပိုးပေးရန် လိုအပ်လာနိုင်သည်။

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

ZooKeeper၊ etcd နှင့် Consul KV တို့နှင့် တွဲဖက်လုပ်ဆောင်ရန်အတွက် ဘုံအင်တာဖေ့စ်ကို ပံ့ပိုးပေးသည့် စာကြည့်တိုက်တစ်ခုကို ဖန်တီးနိုင်ခဲ့သည်။ စာကြည့်တိုက်ကို C++ ဖြင့် ရေးသားထားသော်လည်း ၎င်းကို အခြားဘာသာစကားများသို့ ပို့ရန် အစီအစဉ်ရှိပါသည်။

ဒေတာမော်ဒယ်များ

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

ZooKeeper

သော့များကို သစ်ပင်တွင် စုစည်းထားပြီး nodes ဟုခေါ်သည်။ ထို့ကြောင့်၊ node တစ်ခုအတွက်၎င်း၏ကလေးများစာရင်းကိုသင်ရနိုင်သည်။ znode ဖန်တီးခြင်း (create) နှင့် value (setData) ကို ပြောင်းလဲခြင်း၏ လုပ်ဆောင်ချက်များကို ခွဲခြားထားပါသည်- ရှိပြီးသားသော့များကိုသာ ဖတ်ပြီး ပြောင်းလဲနိုင်ပါသည်။ နာရီများသည် node တစ်ခု၏တည်ရှိမှုကိုစစ်ဆေးခြင်း၊ တန်ဖိုးတစ်ခုဖတ်ခြင်းနှင့်ကလေးများရယူခြင်း၏လုပ်ဆောင်မှုများတွင်တွဲနိုင်သည်။ Watch သည် ဆာဗာပေါ်ရှိ သက်ဆိုင်ရာဒေတာဗားရှင်းပြောင်းလဲသွားသောအခါတွင် တစ်ကြိမ်တည်းလုပ်ဆောင်သည့် အစပျိုးတစ်ခုဖြစ်သည်။ ပျက်ကွက်မှုများကို ရှာဖွေရန် ပေါ်ပင်ဆုံမှတ်များကို အသုံးပြုသည်။ ၎င်းတို့ကို ဖန်တီးသော client ၏ session နှင့် ချိတ်ဆက်ထားသည်။ ကလိုင်းယင့်တစ်ဦးသည် စက်ရှင်တစ်ခုအား ပိတ်လိုက်သောအခါ သို့မဟုတ် ၎င်း၏တည်ရှိမှုကို ZooKeeper အကြောင်းကြားခြင်းကို ရပ်လိုက်သောအခါ၊ အဆိုပါ node များကို အလိုအလျောက် ဖျက်သွားမည်ဖြစ်သည်။ ရိုးရှင်းသော ငွေပေးငွေယူများကို ပံ့ပိုးပေးသည် - ၎င်းတို့အနက်မှ အနည်းဆုံးတစ်ခုအတွက် မဖြစ်နိုင်ပါက အားလုံးအောင်မြင်သည် သို့မဟုတ် ကျရှုံးသည့် လုပ်ဆောင်ချက်အစုံ။

စသည်တို့

ဤစနစ်၏ developer များသည် ZooKeeper မှ ထင်ရှားစွာ လှုံ့ဆော်ခံခဲ့ရသောကြောင့် အရာအားလုံးကို ကွဲပြားစွာ လုပ်ဆောင်ခဲ့သည်။ သော့များ၏ အထက်တန်းအဆင့်မရှိသော်လည်း ၎င်းတို့သည် အဘိဓာန်အရ စီစဥ်ထားသည့် သတ်မှတ်ပုံစံဖြစ်သည်။ သင်သည် သတ်မှတ်ထားသော အပိုင်းအခြားတစ်ခုရှိ သော့အားလုံးကို ရယူ သို့မဟုတ် ဖျက်နိုင်သည်။ ဤဖွဲ့စည်းပုံသည် ထူးဆန်းသည်ဟုထင်ရသော်လည်း အမှန်တကယ်အားဖြင့် ၎င်းသည် အလွန်ထင်ရှားပြီး အထက်အောက်အမြင်ကို ၎င်းမှတစ်ဆင့် အလွယ်တကူ အတုယူနိုင်သည်။

etcd တွင် စံနှိုင်းယှဥ်ပြီး သတ်မှတ်လုပ်ဆောင်မှု မပါရှိသော်လည်း ၎င်းတွင် ပိုမိုကောင်းမွန်သော အရာတစ်ခုရှိသည်- ငွေပေးငွေယူများ။ ဟုတ်ပါတယ်၊ ၎င်းတို့သည် စနစ်သုံးခုစလုံးတွင် တည်ရှိသော်လည်း၊ etcd အရောင်းအဝယ်များသည် အထူးကောင်းမွန်ပါသည်။ ၎င်းတို့တွင် စစ်ဆေးရန်၊ အောင်မြင်မှု၊ ကျရှုံးမှု သုံးခုပါဝင်သည်။ ပထမဘလောက်တွင် အခြေအနေများ အစုံပါရှိသည်၊ ဒုတိယနှင့် တတိယ - လုပ်ဆောင်ချက်များ။ ငွေပေးငွေယူကို အနုမြူစနစ်ဖြင့် လုပ်ဆောင်ပါသည်။ အခြေအနေအားလုံးမှန်ပါက၊ အောင်မြင်မှုဘလောက်ကိုလုပ်ဆောင်သည်၊ သို့မဟုတ်ပါက ကျရှုံးမှုပိတ်ဆို့ခြင်းကိုလုပ်ဆောင်သည်။ API 3.3 တွင်၊ အောင်မြင်မှုနှင့် ကျရှုံးမှုပိတ်ဆို့ခြင်းများတွင် အသိုက်အမြုံပြုထားသော ငွေပေးငွေယူများ ပါဝင်နိုင်သည်။ ဆိုလိုသည်မှာ၊ မတရားအသိုက်များ နီးပါးအဆင့်၏ အခြေအနေအလိုက် တည်ဆောက်မှုများကို အက်တမ်ဖြင့် လုပ်ဆောင်ရန် ဖြစ်နိုင်သည်။ စစ်ဆေးမှုများနှင့် လုပ်ဆောင်ချက်များမှ မည်သည့်အရာများ ရှိသည်ကို သင်ပိုမိုလေ့လာနိုင်ပါသည်။ စာရွက်စာတမ်း.

နာရီများသည် အနည်းငယ်ပိုမိုရှုပ်ထွေးပြီး ပြန်လည်အသုံးပြုနိုင်သော်လည်း ဤနေရာတွင်လည်းရှိပါသည်။ ဆိုလိုသည်မှာ၊ သော့အကွာအဝေးတစ်ခုတွင် နာရီကို ထည့်သွင်းပြီးနောက်၊ သင်သည် ပထမဆုံးနာရီကို မပယ်ဖျက်မချင်း ဤအကွာအဝေးရှိ အပ်ဒိတ်အားလုံးကို လက်ခံရရှိမည်ဖြစ်သည်။ etcd တွင် ZooKeeper client sessions ၏ analogue များသည် အငှားများဖြစ်သည်။

ကောင်စစ်ဝန် K.V.

ဤနေရာတွင် တင်းကျပ်သော အထက်အောက်ဖွဲ့စည်းပုံလည်းမရှိသော်လည်း ကောင်စစ်ဝန်သည် ၎င်းတွင်ရှိနေသည့်အသွင်အပြင်ကို ဖန်တီးနိုင်သည်- သတ်မှတ်ထားသောရှေ့ဆက်ဖြင့် သော့အားလုံးကို ရယူနိုင်ပြီး၊ ဆိုလိုသည်မှာ သော့၏ "subtree" ဖြင့် အလုပ်လုပ်နိုင်သည်။ ထိုသို့သောမေးခွန်းများကို recursive ဟုခေါ်သည်။ ထို့အပြင်၊ ကောင်စစ်ဝန်သည် ချက်ချင်း “ကလေးများ” ရရှိခြင်းနှင့် သက်ဆိုင်သည့် ရှေ့ဆက်နောက်တွင် သတ်မှတ်ထားသော အက္ခရာမပါသော သော့များကိုသာ ရွေးချယ်နိုင်သည်။ သို့သော် ၎င်းသည် အထက်အောက်ဖွဲ့စည်းပုံ၏ ပုံပန်းသဏ္ဌာန်ဖြစ်ကြောင်း အတိအကျ မှတ်သားထားသင့်ပါသည်- ၎င်း၏မိဘမရှိပါက သော့တစ်ခုဖန်တီးရန် သို့မဟုတ် ကလေးများပါရှိသောသော့ကို ဖျက်ပစ်နိုင်ပြီး၊ ကလေးများကို စနစ်တွင် ဆက်လက်သိမ်းဆည်းထားမည်ဖြစ်ပြီး၊

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

အားလုံးကို ပေါင်းထည့်လိုက်ပါ။

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

• sequence၊ container နှင့် TTL node များ မထောက်ခံပါ။
• ACL များကို မပံ့ပိုးပါ။
• set method သည် ၎င်းတွင်မရှိလျှင် သော့တစ်ခုဖန်တီးသည် (ZK setData တွင် ဤကိစ္စတွင် error တစ်ခုပြန်ပေးသည်)
• set နှင့် cas နည်းလမ်းများကို ခွဲခြားထားပါသည် (ZK တွင် ၎င်းတို့သည် အခြေခံအားဖြင့် တူညီသောအရာဖြစ်သည်)
• erase method သည် node တစ်ခုအား ၎င်း၏ subtree နှင့်အတူ ဖျက်သည် (ZK delete တွင် node တွင် ကလေးများပါလျှင် error တစ်ခုပြန်ပေးသည်)
• သော့တစ်ခုစီအတွက် ဗားရှင်းတစ်ခုသာရှိသည် - တန်ဖိုးဗားရှင်း (ZK တွင် သူတို့သုံးယောက်ရှိတယ်)

sequential node များကို ငြင်းပယ်ခြင်းသည် etcd နှင့် Consul တို့အတွက် built-in ပံ့ပိုးမှု မရှိခြင်းကြောင့်ဖြစ်ပြီး ၎င်းတို့ကို ရရှိလာသော library interface ၏ထိပ်တွင် အသုံးပြုသူမှ ၎င်းတို့ကို အလွယ်တကူ အကောင်အထည်ဖော်နိုင်သည်။

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

ပရိယာယ်အားဖြင့် အကောင်အထည်ဖော်ခြင်း။

မတူညီသောစနစ်များတွင် စာကြည့်တိုက်မျက်နှာပြင်ကို အကောင်အထည်ဖော်ခြင်း၏ အချို့သောကဏ္ဍများကို အနီးကပ်လေ့လာကြည့်ကြပါစို့။

အထက်အောက် စသည်ဖြင့်

etcd တွင် အထက်အောက် မြင်ကွင်းကို ထိန်းသိမ်းခြင်းသည် စိတ်ဝင်စားစရာ အကောင်းဆုံး အလုပ်များထဲမှ တစ်ခု ဖြစ်လာခဲ့သည်။ Range queries သည် သတ်မှတ်ထားသော prefix ဖြင့် သော့များစာရင်းကို လွယ်ကူစွာ ပြန်လည်ရယူစေသည်။ ဥပမာအားဖြင့်၊ သင်လိုအပ်သမျှအရာအားလုံးနှင့်စတင်သည်။ "/foo"အကွာအဝေးတစ်ခုတောင်းပါတယ်။ ["/foo", "/fop"). သို့သော် ၎င်းသည် သော့၏သစ်ပင်၏အခွဲတစ်ခုလုံးကို ပြန်ပေးလိမ့်မည်၊ ၎င်းသည် အပင်ခွဲကြီးသည်ဆိုလျှင် လက်ခံနိုင်မည်မဟုတ်ပေ။ ပထမတော့ ကျွန်တော်တို့က အဓိက ဘာသာပြန်တဲ့ ယန္တရားတစ်ခုကို သုံးဖို့ စီစဉ်ထားတယ်၊ zetcd တွင်အကောင်အထည်ဖော်ခဲ့သည်။. ၎င်းတွင် သော့၏အစတွင် တစ်ဘိုက်ထည့်ခြင်း၊ သစ်ပင်ရှိ node ၏အတိမ်အနက်နှင့် ညီမျှသည်။ ဥပမာတစ်ခုပေးပါရစေ။

"/foo" -> "u01/foo"
"/foo/bar" -> "u02/foo/bar"

ပြီးရင် သော့လေးတွေ အားလုံးကို ချက်ချင်း ယူလိုက်ပါ။ "/foo" အပိုင်းအခြားကို တောင်းဆိုခြင်းဖြင့် ဖြစ်နိုင်သည်။ ["u02/foo/", "u02/foo0"). ဟုတ်တယ်၊ ASCII မှာ "0" နောက်မှရပ်တယ်။ "/".

သို့သော်ဤကိစ္စတွင် vertex ကိုဖယ်ရှားရန်မည်သို့အကောင်အထည်ဖော်မည်နည်း။ အမျိုးအစား၏ အပိုင်းအခြားအားလုံးကို ဖျက်ရန် လိုအပ်ကြောင်း ထွက်ပေါ်လာပါသည်။ ["uXX/foo/", "uXX/foo0") 01 မှ FF မှ XX အတွက်။ ပြီးတော့ ကျွန်တော်တို့ အထဲကို ပြေးသွားတယ်။ လည်ပတ်မှုအရေအတွက်ကန့်သတ် အရောင်းအဝယ်တစ်ခုအတွင်း။

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

"/very" -> "/u00very"
"/very/long" -> "/very/u00long"
"/very/long/path" -> "/very/long/u00path"

ထို့နောက် သော့ကို ဖျက်လိုက်သည်။ "/very" ဖျက်မှုအဖြစ်သို့ပြောင်းလဲသွားသည်။ "/u00very" နှင့် အပိုင်းအခြား ["/very/", "/very0")နှင့် ကလေးများအားလုံး ရယူခြင်း - အပိုင်းအခြားမှ သော့များတောင်းခံခြင်း။ ["/very/u00", "/very/u01").

ZooKeeper ရှိ သော့ကို ဖယ်ရှားခြင်း။

ကျွန်တော်ပြောခဲ့သလိုပဲ ZooKeeper မှာ Node လေးတွေရှိရင် ဖျက်လို့မရပါဘူး။ ကျွန်ုပ်တို့သည် သစ်ပင်ခွဲနှင့်အတူ သော့ကို ဖျက်လိုပါသည်။ ကျွန်တော်ဘာလုပ်သင့်သလဲ? ဒါကို အကောင်းမြင်စိတ်နဲ့ လုပ်တယ်။ ပထမဦးစွာ၊ ကျွန်ုပ်တို့သည် သီးခြားမေးခွန်းတစ်ခုဖြင့် vertex တစ်ခုစီ၏ ကလေးများကို ရယူပြီး သစ်ပင်ခွဲကို ထပ်ခါတလဲလဲ လှန်ကြည့်သည်။ ထို့နောက် ကျွန်ုပ်တို့သည် မှန်ကန်သောအစီအစဥ်ဖြင့် subtree ၏ node အားလုံးကိုဖျက်ရန်ကြိုးစားသော ငွေပေးငွေယူတစ်ခုတည်ဆောက်ပါသည်။ ဟုတ်ပါတယ်၊၊ သစ်ပင်ခွဲတစ်ခုကိုဖတ်ပြီး ဖျက်လိုက်တဲ့အခါ အပြောင်းအလဲတွေ ဖြစ်ပေါ်လာနိုင်ပါတယ်။ ဤကိစ္စတွင်၊ ငွေပေးငွေယူပျက်ကွက်လိမ့်မည်။ ထို့အပြင်၊ ဖတ်ရှုခြင်းလုပ်ငန်းစဉ်အတွင်း သစ်ပင်ခွဲသည် ပြောင်းလဲနိုင်သည်။ ဥပမာ၊ ဤ node ကို ဖျက်ပြီးဖြစ်ပါက နောက် node ၏ သားသမီးများအတွက် တောင်းဆိုမှုတစ်ခုသည် အမှားအယွင်းတစ်ခု ပြန်ဖြစ်သွားနိုင်သည်။ ကိစ္စနှစ်ခုစလုံးတွင်၊ ကျွန်ုပ်တို့သည် လုပ်ငန်းစဉ်တစ်ခုလုံးကို တစ်ဖန်ပြန်လုပ်ပါသည်။

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

ZooKeeper တွင်သတ်မှတ်ထားသည်။

ZooKeeper တွင် သစ်ပင်ဖွဲ့စည်းပုံ (ဖန်တီး၊ ဖျက်ပစ်၊ getChildren) နှင့် လုပ်ဆောင်သည့် သီးခြားနည်းလမ်းများ ရှိပြီး node များ (setData၊ getData) တွင် ဒေတာနှင့် အလုပ်လုပ်သော သီးခြားနည်းလမ်းများ ရှိပါသည်။ ထို့အပြင်၊ နည်းလမ်းအားလုံးတွင် တင်းကျပ်သော ကြိုတင်သတ်မှတ်ချက်များ ရှိသည်- node တွင် ရှိနေပါက ဖန်တီးပါက အမှားတစ်ခု ပြန်ဖြစ်သွားပါမည်။ မရှိသေးပါက ဖန်တီးခြင်း၊ ဖျက်ခြင်း သို့မဟုတ် သတ်မှတ်ဒေတာ။ သော့တစ်ခုရှိနေခြင်းကို မစဉ်းစားဘဲ ခေါ်နိုင်သော သတ်မှတ်နည်းလမ်းတစ်ခု လိုအပ်ပါသည်။

ရွေးချယ်စရာတစ်ခုမှာ ဖျက်ခြင်းကဲ့သို့ အကောင်းမြင်ချဉ်းကပ်နည်းကို ယူခြင်းဖြစ်သည်။ Node ရှိမရှိ စစ်ဆေးပါ။ ရှိလျှင် setData ကိုခေါ်ဆိုပါ၊ မဟုတ်ပါက ဖန်တီးပါ။ နောက်ဆုံးနည်းလမ်းမှာ error တစ်ခုပြန်ပေါ်လာပါက၊ ၎င်းကို တစ်ဖန်ပြန်လုပ်ပါ။ ပထမဆုံးသတိပြုရမည့်အချက်မှာ ဖြစ်တည်မှုစမ်းသပ်မှုသည် အဓိပ္ပာယ်မရှိပေ။ သင်ချက်ချင်းဖန်တီးမှုကိုခေါ်ဆိုနိုင်သည်။ အောင်မြင်စွာ ပြီးမြောက်ခြင်းမှာ node မရှိ၍ ၎င်းကို ဖန်တီးထားကြောင်း ဆိုလိုသည်။ မဟုတ်ပါက create သည် setData ကိုခေါ်ရန် လိုအပ်ပြီး သင့်လျော်သော error ကို ပြန်ပေးပါမည်။ ဟုတ်ပါတယ်၊ ခေါ်ဆိုမှုများကြားတွင်၊ အပြိုင်ခေါ်ဆိုမှုတစ်ခုမှ vertex ကို ဖျက်ပစ်နိုင်ပြီး setData သည်လည်း error တစ်ခုပြန်တက်လာမည်ဖြစ်သည်။ ဤကိစ္စတွင်၊ သင်သည် ၎င်းကို ထပ်၍ပြုလုပ်နိုင်သော်လည်း ၎င်းသည် ထိုက်တန်ပါသလား။

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

နည်းပညာဆိုင်ရာအသေးစိတ်အချက်များ

ဤကဏ္ဍတွင် ကျွန်ုပ်တို့သည် ဖြန့်ဝေမှုစနစ်များမှ ခေတ္တအနားယူပြီး ကုဒ်ရေးနည်းအကြောင်း ဆွေးနွေးပါမည်။
ဖောက်သည်၏ အဓိကလိုအပ်ချက်များထဲမှ တစ်ခုသည် ဖြတ်ကျော်ပလပ်ဖောင်းဖြစ်သည်- အနည်းဆုံး ဝန်ဆောင်မှုများထဲမှ တစ်ခုကို Linux၊ MacOS နှင့် Windows တို့တွင် ပံ့ပိုးပေးရပါမည်။ အစပိုင်းတွင်၊ ကျွန်ုပ်တို့သည် Linux အတွက်သာ တီထွင်ခဲ့ပြီး နောက်ပိုင်းတွင် အခြားသော စနစ်များကို စတင်စမ်းသပ်ခဲ့သည်။ ယင်းက ပြဿနာများစွာကို ဖြစ်ပေါ်စေပြီး မည်ကဲ့သို့ ချဉ်းကပ်ရမည်ကို အချိန်အတော်ကြာ ရှင်းရှင်းလင်းလင်း မသိရသေးပေ။ ရလဒ်အနေဖြင့်၊ Consul KV ကိုသာ Windows တွင် ပံ့ပိုးထားသော်လည်း ယခုအခါ ညှိနှိုင်းရေးဝန်ဆောင်မှုသုံးခုလုံးကို Linux နှင့် MacOS တွင် ပံ့ပိုးထားပါသည်။

အစကတည်းက ကျွန်ုပ်တို့သည် ဝန်ဆောင်မှုများရယူရန် အဆင်သင့်လုပ်ထားသည့် စာကြည့်တိုက်များကို အသုံးပြုရန် ကြိုးစားခဲ့သည်။ ZooKeeper ကိစ္စတွင်၊ ရွေးချယ်မှု ကျဆင်းခဲ့သည်။ ZooKeeper C++နောက်ဆုံးတွင် Windows တွင် compile လုပ်ရန်ပျက်ကွက်ခဲ့သည်။ သို့သော် ၎င်းသည် အံ့သြစရာမဟုတ်ပါ- စာကြည့်တိုက်ကို linux-only အဖြစ် နေရာချထားပါသည်။ ကောင်စစ်ဝန်အတွက် တစ်ခုတည်းသော ရွေးချယ်မှုဖြစ်ခဲ့သည်။ ppconsul. ပံ့ပိုးကူညီမှုတွေ ထည့်ပေးရမယ်။ အစည်းအဝေးများ и အရောင်းအဝယ်များ. etcd အတွက်၊ ပရိုတိုကော၏ နောက်ဆုံးဗားရှင်းကို ပံ့ပိုးပေးသည့် ပြည့်စုံသောစာကြည့်တိုက်ကို ရှာမတွေ့သောကြောင့် ကျွန်ုပ်တို့ ရိုးရိုးရှင်းရှင်းပင်၊ grpc client ကိုထုတ်ပေးသည်။.

ZooKeeper C++ စာကြည့်တိုက်၏ အပျက်သဘောဆောင်သည့် အင်တာဖေ့စ်အား လှုံ့ဆော်မှုဖြင့် ကျွန်ုပ်တို့သည် အပြိုင်အဆိုင်လုပ်ဆောင်ရန် ဆုံးဖြတ်ခဲ့သည်။ ZooKeeper C++ သည် ၎င်းအတွက် အနာဂတ်/ကတိအခြေခံများကို အသုံးပြုသည်။ STL တွင်၊ ကံမကောင်းစွာဖြင့်၊ ၎င်းတို့ကို အလွန်ကျိုးနွံစွာ အကောင်အထည်ဖော်ပါသည်။ ဥပမာ မဟုတ်ဘူး၊ ထို့နောက်နည်းလမ်းရရှိလာသောအခါတွင်၊ ၎င်းသည် ရရှိလာသောအခါတွင် အနာဂတ်၏ရလဒ်နှင့် သက်ဆိုင်ပါသည်။ ကျွန်ုပ်တို့၏အခြေအနေတွင်၊ ရလဒ်ကို ကျွန်ုပ်တို့၏စာကြည့်တိုက်ပုံစံသို့ ပြောင်းလဲရန် ထိုနည်းလမ်းသည် လိုအပ်ပါသည်။ ဤပြဿနာကိုဖြေရှင်းရန်၊ ကျွန်ုပ်တို့သည် ဖောက်သည်၏တောင်းဆိုချက်အရ Boost ကဲ့သို့သော ကြီးလေးသောတတိယပါတီစာကြည့်တိုက်များကို အသုံးမပြုနိုင်သောကြောင့် ကျွန်ုပ်တို့၏ကိုယ်ပိုင်ရိုးရှင်းသော thread pool ကိုအကောင်အထည်ဖော်ရမည်ဖြစ်ပါသည်။

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

etcd နှင့် Consul သို့ queries များလုပ်ဆောင်ရန် တူညီသော thread pool ကိုအသုံးပြုခဲ့သည်။ ဆိုလိုသည်မှာ အရင်းခံ စာကြည့်တိုက်များကို မတူညီသော အကြောင်းအရာများစွာဖြင့် ဝင်ရောက်ကြည့်ရှုနိုင်မည်ဖြစ်သည်။ ppconsul သည် ချည်မျှင်မလုံခြုံသောကြောင့် ဖုန်းခေါ်ဆိုမှုများကို လော့ခ်ဖြင့်ကာကွယ်ထားသည်။
စာတွဲများစွာမှ grpc နှင့်အလုပ်လုပ်နိုင်သော်လည်း သိမ်ငယ်မှုများရှိပါသည်။ etcd နာရီများတွင် grpc လမ်းကြောင်းများမှတဆင့်အကောင်အထည်ဖော်သည်။ ၎င်းတို့သည် အမျိုးအစားတစ်ခု၏ မက်ဆေ့ချ်များအတွက် နှစ်ထပ်လမ်းကြောင်းများဖြစ်သည်။ ဒစ်ဂျစ်တိုက်သည် နာရီအားလုံးအတွက် စာတွဲတစ်ခုနှင့် အဝင်မက်ဆေ့ဂျ်များကို လုပ်ဆောင်ပေးသည့် စာတွဲတစ်ခု ဖန်တီးပေးသည်။ ထို့ကြောင့် grpc သည် မျဉ်းပြိုင်ရေးခြင်းကို တားမြစ်ထားသည်။ ဆိုလိုသည်မှာ နာရီတစ်လုံးကို အစပြုခြင်း သို့မဟုတ် ဖျက်သည့်အခါ၊ နောက်တစ်ခုမပို့မီ ယခင်တောင်းဆိုချက်သည် ပေးပို့ခြင်းပြီးဆုံးသည်အထိ စောင့်ရပါမည်။ ထပ်တူပြုခြင်းအတွက် ကျွန်ုပ်တို့အသုံးပြုသည်။ အခြေအနေဆိုင်ရာ ကိန်းရှင်များ.

ရလဒ်

ကိုယ်တိုင်ကြည့်ပါ- liboffkv.

ကျွန်ုပ်တို့၏အဖွဲ့- Raed နော့, Ivan Glushenkov, Dmitry Kamaldinov, Victor Krapivensky, Vitaly Ivanin.

source: www.habr.com