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

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

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

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

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

Single Node Resilience Primitives

ခံနိုင်ရည်ရှိသော တန်းစီခြင်း/လမ်းကြောင်းပေးခြင်း

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

node ကို ပြန်လည်စတင်သောအခါ မတည်ငြိမ်သော တန်းစီခြင်းများနှင့် လမ်းကြောင်းကို ဖယ်ရှားသည်။

မြဲသောစာများ

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

ထမင်း။ 1. ရေရှည်တည်တံ့မှု မက်ထရစ်

တန်းစီခြင်း ဖြင့် အစုအဝေး ပြုလုပ်ခြင်း။

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

တန်းစီခြင်းကို ပုံတူကူးခြင်း-

• ရေးပြီးဖတ်သည့် command အားလုံးကို လက်ခံသည့် ပင်မတန်းစီတစ်ခု (မာစတာ)
• ပင်မတန်းစီမှ စာများနှင့် မက်တာဒေတာအားလုံးကို လက်ခံသည့် မှန်ချပ်တစ်ခု သို့မဟုတ် တစ်ခုထက်ပိုသည်။ ဤကြေးမုံများသည် ချိန်ညှိရန်အတွက် မဟုတ်ဘဲ အထပ်ထပ်အတွက်သာဖြစ်သည်။

ထမင်း။ 2. တန်းစီကြည့်ခြင်း

Mirroring ကို သင့်လျော်သောမူဝါဒဖြင့် သတ်မှတ်သည်။ ၎င်းတွင်သင်သည် ပွားကိန်းကိန်းနှင့် တန်းစီတည်ရှိသင့်သည့် ဆုံမှတ်များကိုပင် ရွေးချယ်နိုင်သည်။ ဥပမာများ-

• ha-mode: all
• ha-mode: exactly, ha-params: 2 (မာစတာတစ်ခုနှင့် မှန်တစ်ချပ်)
• ha-mode: nodes, ha-params: rabbit@node1, rabbit@node2

ထုတ်ဝေသူ အတည်ပြုချက်

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

ရှုံးသူတန်းစီ

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

ထမင်း။ 3. ပုံတူကူးထားသော စီတန်းများနှင့် ၎င်းတို့၏မူဝါဒများ

ပွဲစား ၃ ယောက် ကျသွားတယ်။ Broker 3 ရှိ Queue C ကြေးမုံအား ကျွမ်းကျင်အဆင့်သို့ တိုးမြှင့်ထားကြောင်း သတိပြုပါ။ Broker 2 တွင် Queue C အတွက် မှန်အသစ်တစ်ခုကို ဖန်တီးထားကြောင်းလည်း သတိပြုပါ။ RabbitMQ သည် သင့်မူဝါဒများတွင် သတ်မှတ်ထားသည့် ထပ်တူပွားမှုအချက်ကို ထိန်းသိမ်းရန် အမြဲကြိုးစားနေပါသည်။

ထမင်း။ 4. Broker 3 သည် မအောင်မြင်သဖြင့် တန်းစီ C ကို ကျရှုံးစေပါသည်။

နောက် Broker 1 က ကျသွားတယ်။ ကျွန်တော်တို့မှာ ပွဲစားတစ်ယောက်ပဲ ကျန်တော့တယ်။ Queue B ကြေးမုံအား မာစတာအဖြစ် တိုးမြှင့်ထားသည်။

ပုံ - ၁

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

ဤကိစ္စတွင်၊ Broker 1 ၏ ဆုံးရှုံးမှုသည် ဒေတာကဲ့သို့ပင် ပြီးသွားသည်၊ ထို့ကြောင့် ကြေးမုံပြင်ထားသော Queue B သည် လုံးဝဆုံးရှုံးသွားပါသည်။

ထမင်း။ 6. ပွဲစား 1 သည် ဝန်ဆောင်မှုသို့ ပြန်သွားသည်။

Broker 3 သည် အွန်လိုင်းတွင် ပြန်လည်ရောက်ရှိနေပြီဖြစ်သောကြောင့် ၎င်းတို့၏ HA မူဝါဒများကို ကျေနပ်စေရန် A နှင့် B သည် စီတန်းထားသောကြေးမုံများကို ပြန်လည်ရရှိမည်ဖြစ်သည်။ ယခုမူကား ပင်မတန်းစီများအားလုံးသည် node တစ်ခုတွင်ရှိနေပြီဖြစ်သည်။ ၎င်းသည် စံပြမဟုတ်ပါ၊ node များကြားတွင်ပင် ဖြန့်ဝေခြင်းသည် ပိုကောင်းပါသည်။ ကံမကောင်းစွာဖြင့်၊ ဤနေရာတွင် မာစတာများကို ပြန်လည်ချိန်ညှိရန်အတွက် ရွေးချယ်စရာများစွာမရှိပါ။ တန်းစီဇယား ထပ်တူပြုခြင်းကို ဦးစွာကြည့်ရှုရန် လိုအပ်သောကြောင့် နောက်ပိုင်းတွင် ဤပြဿနာကို ပြန်လည်တင်ပြပါမည်။

ထမင်း။ 7. ပွဲစား 3 သည် ဝန်ဆောင်မှုသို့ ပြန်သွားသည်။ node တစ်ခုရှိ ပင်မတန်းစီများအားလုံး။

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

ထပ်တူ

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

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

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

ထမင်း။ 8. မတူညီသော ထပ်တူပြုခြင်းမုဒ်များဖြင့် တန်းစီနှစ်ခု

ယခု ကျွန်ုပ်တို့သည် Broker 3 ကို ဆုံးရှုံးနေပါသည်။

ထမင်း။ 9. ပွဲစား 3 ကျသွားတယ်။

ပွဲစား 3 သည် ဝန်ဆောင်မှုသို့ ပြန်သွားသည်။ အစုအဖွဲ့သည် node အသစ်ရှိ တန်းစီတစ်ခုစီအတွက် မှန်တစ်ချပ်ကို ဖန်တီးပြီး Queue A အသစ်ကို မာစတာနှင့် အလိုအလျောက် ထပ်တူပြုပါသည်။ သို့သော် Queue B အသစ်၏မှန်သည် ဗလာဖြစ်နေသည်။ ဤနည်းဖြင့် ကျွန်ုပ်တို့တွင် Queue A တွင် အပြည့်အ၀ ထပ်နေပြီး လက်ရှိ Queue B မက်ဆေ့ချ်များအတွက် မှန်တစ်ချပ်သာရှိသည်။

ထမင်း။ 10. Queue A ၏ကြေးမုံမှန်အသစ်သည် ရှိပြီးသားမက်ဆေ့ဂျ်များအားလုံးကို လက်ခံရရှိသော်လည်း Queue B ၏ကြေးမုံပြင်အသစ်သည် မရှိပါ။

တန်းစီခြင်းနှစ်ခုလုံးတွင် နောက်ထပ်မက်ဆေ့ဂျ်ဆယ်စောင် ရောက်လာသည်။ ထို့နောက် Broker 2 ပျက်သွားပြီး Queue A သည် Broker 1 တွင်ရှိသော ရှေးအကျဆုံးမှန်သို့ ပြန်သွားပါသည်။ ပျက်သွားသည့်အခါ ဒေတာဆုံးရှုံးမှုမရှိပါ။ Queue B တွင်၊ မာစတာတွင် မက်ဆေ့ချ် နှစ်ဆယ်ရှိပြီး မှန်ထဲတွင် ဆယ်စောင်သာ ရှိသည်၊

ထမင်း။ 11. Queue A သည် မက်ဆေ့ချ်များ မဆုံးရှုံးဘဲ Broker 1 သို့ ပြန်သွားပါသည်။

စီတန်းနှစ်ခုလုံးတွင် နောက်ထပ် မက်ဆေ့ဂျ်ဆယ်စောင် ရောက်ရှိလာသည်။ ယခု Broker 1 ပျက်သွားပါသည်။ Queue A သည် မက်ဆေ့ချ်များ မဆုံးရှုံးဘဲ မှန်သို့ အလွယ်တကူ ပြောင်းသွားပါသည်။ သို့သော်လည်း Queue B တွင် ပြဿနာများ ရှိနေသည်။ ဤအချိန်တွင် ကျွန်ုပ်တို့သည် ရနိုင်မှု သို့မဟုတ် ညီညွတ်မှုကို အကောင်းဆုံးဖြစ်အောင် လုပ်ဆောင်နိုင်သည်။

ကျွန်ုပ်တို့သည် အများသူငှာ အသုံးပြုနိုင်စွမ်းကို အကောင်းဆုံးဖြစ်အောင် လုပ်ဆောင်လိုပါက မူဝါဒကို ချမှတ်ပါ။ ha-promote-on-failure တွင်တပ်ဆင်သင့်သည်။ အမြဲ. ၎င်းသည် မူရင်းတန်ဖိုးဖြစ်သောကြောင့် သင်သည် မူဝါဒကို လုံးဝမသတ်မှတ်နိုင်ပါ။ ဤကိစ္စတွင်၊ ကျွန်ုပ်တို့သည် အဓိကအားဖြင့် တစ်ပြိုင်နက်တည်းမဟုတ်သောမှန်များတွင် ကျရှုံးမှုများကို ခွင့်ပြုပါသည်။ ၎င်းသည် မက်ဆေ့ဂျ်များကို ဆုံးရှုံးသွားစေလိမ့်မည်၊ သို့သော် တန်းစီသည် ဖတ်နိုင်၊ ရေးနိုင်နေဦးမည်ဖြစ်သည်။

ထမင်း။ 12. Queue A သည် မက်ဆေ့ချ်များ မဆုံးရှုံးဘဲ Broker 3 သို့ ပြန်လည်ရောက်ရှိသွားပါသည်။ Queue B သည် စာတို ဆယ်စောင် ဆုံးရှုံးသွားသဖြင့် Broker 3 သို့ ပြန်လှည့်သည်။

တပ်ဆင်နိုင်သည်။ ha-promote-on-failure အဓိပ္ပါယ်သို့ when-synced. ဤကိစ္စတွင်၊ မှန်သို့ပြန်လှည့်မည့်အစား၊ Broker 1 သည် ၎င်း၏ဒေတာအွန်လိုင်းမုဒ်သို့ ပြန်လည်ရောက်ရှိသည်အထိ တန်းစီစောင့်ဆိုင်းပါမည်။ ပြန်လာပြီးနောက်၊ ပင်မတန်းစီသည် ဒေတာဆုံးရှုံးခြင်းမရှိဘဲ Broker 1 တွင် ပြန်လည်ရောက်ရှိသွားပါသည်။ ဒေတာလုံခြုံရေးအတွက် ရရှိနိုင်မှုကို စတေးသည်။ သို့သော် ၎င်းသည် ဒေတာဆုံးရှုံးမှုကိုပင် ဖြစ်ပေါ်စေနိုင်သည့် အန္တရာယ်ရှိသော မုဒ်တစ်ခုဖြစ်ပြီး မကြာမီ ကျွန်ုပ်တို့ကြည့်ရှုပါမည်။

ထမင်း။ 13. Broker 1 ကိုဆုံးရှုံးပြီးနောက် Queue B မရနိုင်ပါ။

“အလိုအလျောက် ထပ်တူပြုခြင်းကို ဘယ်တော့မှ မသုံးတာက ပိုကောင်းသလား” လို့ မေးနိုင်ပါတယ်။ အဖြေမှာ synchronization သည် blocking operation ဖြစ်သည်။ ထပ်တူပြုခြင်းတွင်၊ ပင်မတန်းစီသည် ဖတ်ရှုခြင်း သို့မဟုတ် ရေးခြင်းဆိုင်ရာ လုပ်ဆောင်ချက်များကို လုပ်ဆောင်နိုင်မည်မဟုတ်ပေ။

ဥပမာတစ်ခုကိုကြည့်ရအောင်။ အခု ကျွန်တော်တို့ တန်းစီနေတာ တော်တော်ကြာနေပြီ။ ဒီလိုမျိုး အရွယ်ရောက်အောင် ဘယ်လို ကြီးထွားနိုင်မလဲ။ အကြောင်းရင်းများစွာအတွက်-

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

ထမင်း။ 14. မတူညီသော ထပ်တူပြုမှုမုဒ်များဖြင့် ကြီးမားသောတန်းစီနှစ်ခု

အခု Broker 3 က ကျသွားတယ်။

ထမင်း။ 15. ပွဲစား 3 သည် တန်းစီတိုင်းတွင် မာစတာတစ်ပုံနှင့် မှန်တစ်ချပ်ချန်ထားသည်။

Broker 3 သည် အွန်လိုင်းတွင် ပြန်လည်ရောက်ရှိလာပြီး မှန်အသစ်များကို ဖန်တီးထားသည်။ Main Queue A သည် ရှိပြီးသားစာများကို မှန်အသစ်သို့ ပုံတူကူးခြင်းစတင်ပြီး ဤကာလအတွင်း Queue မရနိုင်ပါ။ ဒေတာကို ပုံတူပွားရန် နှစ်နာရီကြာပြီး ဤတန်းစီအတွက် နှစ်နာရီကြာ ရပ်နားခဲ့ရသည်။

သို့သော်လည်း Queue B သည် ကာလတစ်လျှောက်လုံးတွင် ရှိနေသေးသည်။ သုံးစွဲနိုင်မှု အတွက် သူမသည် လိုအပ်ချက်အချို့ကို စတေးခဲ့သည်။

ထမင်း။ 16. စင့်ခ်လုပ်နေစဉ်တွင် တန်းစီခြင်းကို မရရှိနိုင်ပါ။

နှစ်နာရီကြာပြီးနောက်၊ Queue A လည်းရရှိနိုင်ပြီး စာပြန်ရေးခြင်းများကို စတင်လက်ခံနိုင်ပါသည်။

မွမ်းမံ

ထပ်တူပြုခြင်းတွင် ဤပိတ်ဆို့ခြင်းအပြုအမူသည် အလွန်ကြီးမားသော တန်းစီများဖြင့် အစုအဝေးများကို အပ်ဒိတ်လုပ်ရန် ခက်ခဲစေသည်။ တစ်ချိန်ချိန်တွင်၊ ဆာဗာကို အဆင့်မြှင့်တင်နေချိန်တွင် မာစတာ node ကို ပြန်လည်စတင်ရန် လိုအပ်သည်၊ ဆိုလိုသည်မှာ မှန်တစ်ချပ်သို့ ပြောင်းခြင်း သို့မဟုတ် ဆာဗာကို အဆင့်မြှင့်တင်နေချိန်တွင် တန်းစီခြင်းကို ပိတ်ခြင်းဖြစ်စေနိုင်သည်။ အကယ်၍ ကျွန်ုပ်တို့သည် ကူးပြောင်းရန် ရွေးချယ်ပါက၊ မှန်များကို ထပ်တူပြုခြင်းမရှိပါက မက်ဆေ့ချ်များ ဆုံးရှုံးပါမည်။ ပုံမှန်အားဖြင့်၊ ပွဲစားပြတ်တောက်ချိန်တွင်၊ တစ်ပြိုင်နက်တည်းမဟုတ်သောမှန်တစ်ခုသို့ ပျက်ကွက်ခြင်းကို လုပ်ဆောင်မည်မဟုတ်ပါ။ ဆိုလိုသည်မှာ ပွဲစားပြန်လာသည်နှင့်တပြိုင်နက် ကျွန်ုပ်တို့သည် မည်သည့်မက်ဆေ့ချ်မှ မဆုံးရှုံးပါ၊ တစ်ခုတည်းသော ပျက်စီးမှုသည် ရိုးရိုးတန်းစီခြင်းပင်ဖြစ်သည်။ ပွဲစားတစ်ဦးကို အဆက်ပြတ်သွားသောအခါ အပြုအမူဆိုင်ရာ စည်းမျဉ်းများကို မူဝါဒဖြင့် သတ်မှတ်သည်။ ha-promote-on-shutdown. တန်ဖိုးနှစ်ခုထဲမှ တစ်ခုကို သင်သတ်မှတ်နိုင်သည်-

• always= ထပ်တူမကျသော မှန်များဆီသို့ ကူးပြောင်းခြင်းကို ဖွင့်ထားသည်။
• when-synced= တစ်ပြိုင်တည်းလုပ်ထားသည့် မှန်တစ်ချပ်သို့ ကူးပြောင်းခြင်းသာ၊ မဟုတ်ပါက တန်းစီသည် ဖတ်၍မရ၊ စာမရေးနိုင်ဖြစ်သွားသည်။ ပွဲစားပြန်လာသည်နှင့်တပြိုင်နက် တန်းစီသည် ဝန်ဆောင်မှုသို့ ပြန်သွားသည်။

တစ်နည်းမဟုတ်တစ်နည်း၊ တန်းစီကြီးများဖြင့် ဒေတာဆုံးရှုံးမှုနှင့် မရရှိနိုင်မှုကြားတွင် သင်ရွေးချယ်ရမည်ဖြစ်သည်။

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

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

ဤနေရာတွင် အောက်ပါတို့ကို ထည့်သွင်းစဉ်းစားရန် လိုအပ်ပါသည်။

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

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

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

ha-promote-on-failure=when-synced ပြဿနာများ

စိတ်ကူး ha-promote-on-failure= စင့်ခ်လုပ်ထားသည်။ ကျွန်ုပ်တို့သည် တစ်ပြိုင်နက်တည်းမဟုတ်သော မှန်သို့ပြောင်းခြင်းကို တားဆီးပြီး ဒေတာဆုံးရှုံးမှုကို ရှောင်ရှားနိုင်စေရန်ဖြစ်သည်။ တန်းစီသည် မဖတ်ရ သို့မဟုတ် စာရေး၍မရပါ။ ယင်းအစား၊ ကျွန်ုပ်တို့သည် ပျက်စီးသွားသော ပွဲစားကို ၎င်း၏ဒေတာကို နဂိုအတိုင်း ပြန်လည်ရယူရန် ကြိုးစားပြီး ၎င်းသည် ဒေတာဆုံးရှုံးမှုမရှိဘဲ မာစတာတစ်ဦးအဖြစ် ပြန်လည်လုပ်ဆောင်နိုင်စေရန် ကြိုးစားပါသည်။

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

အမည်တူ node တစ်ခုကို ပြန်လည်ထည့်သွင်းရန်၊ ဆုံးရှုံးသွားသော node ကို မေ့ပစ်ရန် အစုအဖွဲ့အား ကျွန်ုပ်တို့ ပြောသည် (အမိန့်တော်ဖြင့် rabbitmqctl မေ့_cluster_node) တူညီသော hostname ဖြင့် ပွဲစားအသစ်ကို စတင်ပါ။ cluster သည် ပျောက်ဆုံးသွားသော node ကို မှတ်မိနေချိန်တွင်၊ ၎င်းသည် တန်းစီဟောင်းနှင့် ထပ်တူမကျသော မှန်များကို မှတ်မိသည်။ မိဘမဲ့ node တစ်ခုကို မေ့ရန် အစုအဖွဲ့တစ်ခုအား ပြောသောအခါ၊ ထိုတန်းစီကိုလည်း မေ့သွားပါသည်။ အခုတော့ အဲဒါကို ပြန်ပြီး ကြေငြာရမယ်။ ကျွန်ုပ်တို့တွင် ဒေတာတစ်စိတ်တစ်ပိုင်းပါရှိသော မှန်များပါရှိသော်လည်း ဒေတာအားလုံး ဆုံးရှုံးသွားခဲ့သည်။ တစ်ပြိုင်နက်တည်းမဟုတ်သောမှန်သို့ပြောင်းခြင်းသည် ပိုကောင်းလိမ့်မည်။

ထို့ကြောင့်, manual synchronization (နှင့် synchronize ပျက်ကွက်) နှင့်အတူပေါင်းစပ် ha-promote-on-failure=when-syncedကျွန်တော့်အမြင်အရတော့ တော်တော်လေး အန္တရာယ်များပါတယ်။ ဒေတာလုံခြုံရေးအတွက် ဤရွေးချယ်မှုသည် ရှိကြောင်း Docs ကပြောသော်လည်း ၎င်းသည် နှစ်ဖက်သောဓားဖြစ်သည်။

Master rebalancing

ကတိပြုထားသည့်အတိုင်း၊ ကျွန်ုပ်တို့သည် node တစ်ခု သို့မဟုတ် အများအပြားတွင် မာစတာအားလုံးကို စုစည်းမှုပြဿနာသို့ ပြန်သွားပါသည်။ လှိမ့်နေသော အစုအဝေး အပ်ဒိတ်ကြောင့်ပင် ၎င်းသည် ဖြစ်ပေါ်လာနိုင်သည်။ သုံးခု-node အစုအဝေးတွင်၊ မာစတာတန်းစီများအားလုံးသည် node တစ်ခု သို့မဟုတ် နှစ်ခုတွင် စုပုံနေလိမ့်မည်။

Rebalancing masters များသည် အကြောင်းရင်းနှစ်ခုကြောင့် ပြဿနာရှိနိုင်သည်-

• ပြန်လည်ချိန်ညှိရန် ကောင်းမွန်သောကိရိယာများ မရှိပါ။
• တန်းစီခြင်းကို ထပ်တူပြုခြင်း

ပြန်လည်ချိန်ညှိရန် တတိယအဖွဲ့အစည်းတစ်ခု ရှိပါသည်။ ပလပ်ဂင်တရားဝင် ပံ့ပိုးထားခြင်း မရှိပါ။ RabbitMQ လက်စွဲရှိ Third Party Plugins များအကြောင်း ဟုဆိုသည်။: “ပလပ်အင်သည် နောက်ထပ်ဖွဲ့စည်းပုံနှင့် အစီရင်ခံခြင်းကိရိယာအချို့ကို ပံ့ပိုးပေးသော်လည်း RabbitMQ အဖွဲ့မှ ပံ့ပိုးပေးခြင်း သို့မဟုတ် စစ်ဆေးခြင်းမပြုပါ။ ကိုယ့်အန္တရာယ်ကိုယ်သုံးပါ။"

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

• လက်ရှိ HA မူဝါဒထက် ပိုမိုဦးစားပေးသော ယာယီမူဝါဒကို အသုံးပြု၍ မှန်များအားလုံးကို ဖယ်ရှားသည်။
• node မုဒ်ကို အသုံးပြုရန် ယာယီ HA ပေါ်လစီကို ပြောင်းပြီး၊ မာစတာတန်းစီကို လွှဲပြောင်းသင့်သည့် ကုဒ်ကို သတ်မှတ်ခြင်း။
• push migration အတွက် တန်းစီဇယားကို စင့်ခ်လုပ်သည်။
• ရွှေ့ပြောင်းခြင်းပြီးပါက၊ ယာယီမူဝါဒကို ဖျက်ပါ။ ကနဦး HA မူဝါဒသည် အသက်ဝင်မည်ဖြစ်ပြီး လိုအပ်သော မှန်ချပ်အရေအတွက်ကို ဖန်တီးထားသည်။

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

ယခု RabbitMQ အစုအဝေးများသည် network partitions များနှင့် မည်သို့အလုပ်လုပ်သည်ကို ကြည့်ကြပါစို့။

ချိတ်ဆက်မှုပျောက်ဆုံးခြင်း။

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

RabbitMQ ဖြင့် ကျွန်ုပ်တို့တွင် အဓိကရွေးချယ်စရာနှစ်ခုရှိသည်။

• ယုတ္တိ ပိုင်းခြားခြင်း (split-bin) ကို ခွင့်ပြုပါ။ ၎င်းသည် ရရှိနိုင်မှုကို သေချာစေသော်လည်း ဒေတာဆုံးရှုံးမှု ဖြစ်စေနိုင်သည်။
• ယုတ္တိခွဲခြားမှုကို ပိတ်ပါ။ client များ အစုအဝေးသို့ ချိတ်ဆက်ပုံပေါ်မူတည်၍ ရရှိနိုင်မှုရေတို ဆုံးရှုံးသွားနိုင်သည်။ နှစ်ခု-node အစုအဝေးတွင် ပြီးပြည့်စုံသော မရရှိနိုင်မှုကိုလည်း ဖြစ်ပေါ်စေနိုင်သည်။

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

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

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

RabbitMQ ၏ မတူညီသောမုဒ်များသည် ရရှိနိုင်မှု သို့မဟုတ် လိုက်လျောညီထွေဖြစ်စေသည်။

လျစ်လျူရှုမုဒ် (မူလ)

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

ထမင်း။ 18. ကြေညာသူသုံးဦးသည် ပွဲစားသုံးဦးနှင့် ဆက်စပ်နေသည်။ အတွင်းပိုင်း၊ အစုအဖွဲ့သည် တောင်းဆိုချက်အားလုံးကို Broker 2 ရှိ ပင်မတန်းစီသို့ လမ်းကြောင်းပေးသည်။

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

ထမင်း။ 19. Logical division (ဦးနှောက်ကွဲ)။ မှတ်တမ်းများသည် ပင်မတန်းစီနှစ်ခုသို့ ရောက်သွားပြီး မိတ္တူနှစ်စောင် ကွဲပြားသွားပါသည်။

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

ထမင်း။ 20. စီမံခန့်ခွဲသူက Broker 3 ကို ပိတ်သည်။

ထမင်း။ 21. အက်ဒမင်သည် Broker 3 ကို စတင်ပြီး ၎င်းသည် အစုအဝေးတွင် ပါ၀င်ပြီး ထိုနေရာတွင် ကျန်ရစ်ခဲ့သည့် စာများအားလုံးကို ဆုံးရှုံးသွားစေသည်။

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

Autoheal မုဒ်

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

လူနည်းစုမုဒ်ကို ခဏရပ်ပါ။

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

ထမင်း။ 22. ကြေညာသူသုံးဦးသည် ပွဲစားသုံးဦးနှင့် ဆက်စပ်နေသည်။ အတွင်းပိုင်း၊ အစုအဖွဲ့သည် တောင်းဆိုချက်အားလုံးကို Broker 2 ရှိ ပင်မတန်းစီသို့ လမ်းကြောင်းပေးသည်။

ထို့နောက် ပွဲစား 1 နှင့် 2 သည် ပွဲစား 3 မှ ခွဲထွက်သွားသည်။ ၎င်းတို့၏ ကြေးမုံကို သခင်အဖြစ် မြှင့်တင်မည့်အစား Broker 3 သည် ရပ်ဆိုင်းပြီး မရနိုင်တော့ပါ။

ထမင်း။ 23. ပွဲစား 3 သည် ခေတ္တရပ်သည်၊ ဖောက်သည်များအားလုံးကို ချိတ်ဆက်မှုဖြုတ်ပြီး ချိတ်ဆက်မှုတောင်းဆိုမှုများကို ငြင်းပယ်သည်။

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

Broker 3 တွင် အဓိကတန်းစီနေသည့် အခြားဥပမာကို ကြည့်ကြပါစို့။

ထမင်း။ 24. Broker 3 တွင် အဓိကတန်းစီသည်။

အဲဒီအခါမှာ တူညီတဲ့ ချိတ်ဆက်မှု ပျောက်ဆုံးမှု ဖြစ်ပေါ်ပါတယ်။ ပွဲစား 3 သည် သေးငယ်သည့်ဘက်တွင် ရှိနေသောကြောင့် ခေတ္တရပ်သည်။ အခြားတစ်ဖက်တွင်၊ Broker 3 ပြုတ်ကျသွားသည်ကို node များကမြင်ရသောကြောင့် Brokers 1 နှင့် 2 မှ mirror အဟောင်းများကို master အဖြစ်သို့တိုးမြှင့်ထားသည်။

ထမင်း။ 25. Broker 2 ကို မရရှိနိုင်ပါက Broker 3 သို့ ကူးပြောင်းခြင်း။

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

ထမင်း။ 26. အစုအဝေးသည် ပုံမှန်လည်ပတ်မှုသို့ ပြန်သွားပါပြီ။

ဤနေရာတွင် နားလည်ရန် အရေးကြီးသောအချက်မှာ ကျွန်ုပ်တို့သည် ညီညွတ်မှုရရှိရန်၊ သို့သော် ကျွန်ုပ်တို့သည်လည်း ရရှိနိုင်မှု၊ လျှင် ကျွန်ုပ်တို့သည် ကဏ္ဍအများစုသို့ ဖောက်သည်များကို အောင်မြင်စွာ လွှဲပြောင်းပေးပါမည်။ အခြေအနေအများစုအတွက်၊ ကျွန်ုပ်သည် Pause Minority မုဒ်ကို ကိုယ်တိုင်ကိုယ်ကျ ရွေးချယ်မည်ဖြစ်ပြီး၊ သို့သော် ၎င်းသည် တစ်ဦးချင်းကိစ္စပေါ်မူတည်ပါသည်။

ရရှိနိုင်မှုသေချာစေရန်၊ client များသည် host သို့ အောင်မြင်စွာချိတ်ဆက်ကြောင်းသေချာစေရန်အရေးကြီးပါသည်။ ကျွန်ုပ်တို့၏ရွေးချယ်မှုများကို ကြည့်ကြပါစို့။

Customer ချိတ်ဆက်မှုကို သေချာစေခြင်း။

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

ကျွန်ုပ်တို့၏ရွေးချယ်မှုများ-

• အစုအဝေးကို node များမှတစ်ဆင့် ရိုးရိုးလည်ပတ်သည့် load balancer ကိုအသုံးပြု၍ အစုအဝေးကို ဝင်ရောက်ပြီး အောင်မြင်သည်အထိ ချိတ်ဆက်မှုများ ထပ်မံကြိုးစားပါ။ အကယ်၍ node တစ်ခု ပျက်နေသည် သို့မဟုတ် ဆိုင်းငံ့ထားလျှင် ထို node သို့ ချိတ်ဆက်ရန် ကြိုးပမ်းမှုများ မအောင်မြင်သော်လည်း နောက်ဆက်တွဲ ကြိုးပမ်းမှုများသည် အခြားဆာဗာများသို့ ရောက်သွားလိမ့်မည် ( round-robin ပုံစံ) ။ ၎င်းသည် ရေတိုဆက်သွယ်မှု ဆုံးရှုံးခြင်း သို့မဟုတ် အမြန်ပြန်ယူလာမည့် ဆာဗာ ပျက်သွားခြင်းအတွက် သင့်လျော်သည်။
• load balancer မှတဆင့် အစုအဝေးကို ဝင်ရောက်ပြီး ဆိုင်းငံ့ထားသော/မအောင်မြင်သော ဆုံမှတ်များကို ၎င်းတို့ တွေ့ရှိသည်နှင့်တပြိုင်နက် စာရင်းမှ ဖယ်ရှားပါ။ အကယ်၍ ကျွန်ုပ်တို့သည် ၎င်းကို လျင်မြန်စွာလုပ်ဆောင်ပြီး ဖောက်သည်များသည် ချိတ်ဆက်မှုကို ပြန်လည်ကြိုးစားနိုင်ပါက၊ ကျွန်ုပ်တို့သည် အဆက်မပြတ်ရရှိနိုင်မှုကို ရရှိမည်ဖြစ်သည်။
• ကလိုင်းယင့်တစ်ဦးစီအား node များအားလုံး၏စာရင်းတစ်ခုပေး၍ client သည် ချိတ်ဆက်သည့်အခါ ၎င်းတို့ထဲမှ တစ်ခုကို ကျပန်းရွေးချယ်သည်။ ချိတ်ဆက်ရန် ကြိုးပမ်းရာတွင် အမှားအယွင်းတစ်ခု ရရှိပါက ၎င်းသည် ချိတ်ဆက်သည်အထိ စာရင်းရှိ နောက် node သို့ ရွှေ့သည်။
• DNS ကို အသုံးပြု၍ မအောင်မြင်သော/ဆိုင်းငံ့ထားသော node မှ လမ်းကြောင်းများကို ဖယ်ရှားပါ။ ၎င်းသည် TTL အသေးကို အသုံးပြု၍ လုပ်ဆောင်သည်။

တွေ့ရှိချက်များ

RabbitMQ အစုအဝေးတွင် ၎င်း၏ အားသာချက်များနှင့် အားနည်းချက်များရှိသည်။ အဆိုးရွားဆုံး အားနည်းချက်များမှာ-

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

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

• စိတ်မချရသော ကွန်ရက်။
• စိတ်မချရသော သိုလှောင်မှု။
• အလွန်ရှည်လျားသောတန်းစီ။

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

• ha-promote-on-failure=always
• ha-sync-mode=manual
• cluster_partition_handling=ignore (သို့မဟုတ် autoheal)
• အမြဲရှိနေသောမက်ဆေ့ခ်ျများ
• အချို့သော node များ ပျက်ကွက်သောအခါတွင် clients များသည် active node သို့ ချိတ်ဆက်ကြောင်း သေချာပါစေ။

တစ်သမတ်တည်း (ဒေတာလုံခြုံရေးအတွက်) အောက်ပါဆက်တင်များကို စဉ်းစားပါ။

• ထုတ်ဝေသူသည် စားသုံးသူဘက်မှ အတည်ပြုပြီး လက်ဖြင့် အသိအမှတ်ပြုမှုများ
• ha-promote-on-failure=when-syncedအကယ်၍ ထုတ်ဝေသူများ နောက်မှ ထပ်စမ်းကြည့်နိုင်လျှင် နှင့် သင့်တွင် အလွန်ယုံကြည်စိတ်ချရသော သိုလှောင်မှုရှိပါက၊ မဟုတ်ရင် တင်ပါ။ =always.
• ha-sync-mode=automatic (သို့သော် ကြီးမားသော မလှုပ်ရှားနိုင်သော စီတန်းများအတွက် လက်စွဲမုဒ် လိုအပ်နိုင်သည်၊ မရရှိနိုင်ပါက မက်ဆေ့ချ်များကို ဆုံးရှုံးစေခြင်း ရှိမရှိကိုလည်း ထည့်သွင်းစဉ်းစားပါ)
• လူနည်းစုမုဒ်ကို ခဏရပ်ပါ။
• အမြဲရှိနေသောမက်ဆေ့ခ်ျများ

ကျွန်ုပ်တို့သည် အမှားခံနိုင်ရည်ရှိမှုနှင့် မြင့်မားသောရရှိနိုင်မှုဆိုင်ရာ ပြဿနာအားလုံးကို မခြုံငုံမိသေးပါ။ ဥပမာအားဖြင့်၊ စီမံခန့်ခွဲရေးဆိုင်ရာ လုပ်ထုံးလုပ်နည်းများကို လုံခြုံအောင် မည်သို့လုပ်ဆောင်ရမည် (ဥပမာ- အပ်ဒိတ်များ)။ အဖွဲ့ချုပ်နှင့် Shovel plugin အကြောင်းလည်း ပြောရန်လိုပါသည်။

တခြားအရာတွေ လွဲချော်ခဲ့ရင် ကျေးဇူးပြုပြီး ပြောပြပေးပါ။

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

စီးရီးရှိ ယခင်ဆောင်းပါးများ-
နံပါတ် ၁ - habr.com/ru/company/itsumma/blog/416629
နံပါတ် ၁ - habr.com/ru/company/itsumma/blog/418389
နံပါတ် ၁ - habr.com/ru/company/itsumma/blog/437446

source: www.habr.com