ဖြန့်ဝေထားသော Application များကို တည်ဆောက်ခြင်း။ ဒုတိယအနီးစပ်ဆုံး

ကြေငြာချက်

လုပ်ဖော်ကိုင်ဖက်များ ၊ နွေရာသီလယ်တွင် တန်းစီခြင်းစနစ်များ၏ ဒီဇိုင်းဆိုင်ရာ ဆောင်းပါးတွဲများကို ထုတ်ဝေရန် စီစဉ်ထားပါသည်- "The VTrade Experiment" - ကုန်သွယ်မှုစနစ်များအတွက် မူဘောင်တစ်ခုရေးရန် ကြိုးပမ်းမှု။ စီးရီးသည် လဲလှယ်မှု၊ လေလံနှင့် စတိုးဆိုင်တည်ဆောက်ခြင်းဆိုင်ရာ သီအိုရီနှင့် လက်တွေ့ကို ဆန်းစစ်မည်ဖြစ်သည်။ ဆောင်းပါးရဲ့အဆုံးမှာ သင်စိတ်ဝင်စားဆုံးအကြောင်းအရာတွေကို မဲပေးဖို့ ဖိတ်ခေါ်ပါတယ်။

ဤသည်မှာ Erlang/Elixir ရှိ ဖြန့်ဝေထားသော ဓာတ်ပြုအက်ပ်လီကေးရှင်းများအကြောင်း စီးရီး၏ နောက်ဆုံးဆောင်းပါးဖြစ်သည်။ IN ပထမဆောင်းပါး ဓာတ်ပြုမှုဗိသုကာပညာ၏ သီအိုရီအခြေခံအုတ်မြစ်များကို သင်တွေ့ရှိနိုင်သည်။ ဒုတိယဆောင်းပါး ထိုကဲ့သို့သော စနစ်များကို တည်ဆောက်ရန်အတွက် အခြေခံပုံစံများနှင့် ယန္တရားများကို သရုပ်ဖော်သည်။

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

ဝန်ဆောင်မှုအဖွဲ့အစည်း

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

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

1. ယခု ဝန်ဆောင်မှုသည် အစုအဖွဲ့ 5 ခုတွင် တောင်းဆိုမှုများကို လုပ်ဆောင်သင့်သည်၊
2. နောက်ခံလုပ်ဆောင်ခြင်းလုပ်ငန်းများကို လုပ်ဆောင်နိုင်ခြင်း၊
3. ပရိုဖိုင်အပ်ဒိတ်များအတွက် စာရင်းသွင်းမှုစာရင်းများကို ဒိုင်းနမစ်ဖြင့် စီမံခန့်ခွဲနိုင်သည်။

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

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

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

အမှတ် 3 သည် pub-sub template တိုးချဲ့မှု လိုအပ်သည်။ အကောင်အထည်ဖော်ရန်အတွက်၊ pub-sub exchange point တစ်ခုဖန်တီးပြီးနောက်၊ ကျွန်ုပ်တို့သည် ကျွန်ုပ်တို့၏ဝန်ဆောင်မှုအတွင်းတွင် ဤအမှတ်၏ ထိန်းချုပ်ကိရိယာကို ထပ်လောင်းဖွင့်ရန် လိုအပ်ပါသည်။ ထို့ကြောင့်၊ ကျွန်ုပ်တို့သည် စာရင်းသွင်းမှုများကို လုပ်ဆောင်ခြင်းနှင့် စာတိုပေးပို့ခြင်းအလွှာမှ စာရင်းသွင်းခြင်းမှ ရပ်ဆိုင်းခြင်းအတွက် ယုတ္တိဗေဒကို သုံးစွဲသူများ၏ အကောင်အထည်ဖော်မှုအဖြစ်သို့ ရွှေ့နေသကဲ့သို့ဖြစ်သည်။

ရလဒ်အနေဖြင့် ပြဿနာ၏ပြိုကွဲမှုသည် လိုအပ်ချက်များပြည့်မီစေရန်အတွက် မတူညီသော node များတွင် ဝန်ဆောင်မှု၏ ဖြစ်ရပ် ၅ ခုကို ဖွင့်ပြီး စာရင်းသွင်းမှုအတွက် တာဝန်ရှိသည့် pub-sub controller တစ်ခု ထပ်မံဖန်တီးရန် လိုအပ်ကြောင်း ပြသခဲ့သည်။
ကိုင်တွယ်သူ 5 ဦးကို လုပ်ဆောင်ရန် သင်သည် ဝန်ဆောင်မှုကုဒ်ကို ပြောင်းလဲရန် မလိုအပ်ပါ။ တစ်ခုတည်းသော နောက်ထပ်လုပ်ဆောင်ချက်မှာ ငွေလဲပွိုင့်တွင် ဟန်ချက်ညီအောင် စည်းမျဥ်းစည်းမျဥ်းများသတ်မှတ်ခြင်း၊
ရှုပ်ထွေးမှုတစ်ခုလည်း ရှိသည်- pub-sub controller နှင့် custom task scheduler သည် မိတ္တူတစ်ခုတည်းတွင် အလုပ်လုပ်ရပါမည်။ တဖန်၊ အခြေခံအချက်အနေဖြင့် စာတိုပေးပို့ခြင်းဝန်ဆောင်မှုသည် ခေါင်းဆောင်တစ်ဦးကို ရွေးချယ်ရန်အတွက် ယန္တရားတစ်ခု ပံ့ပိုးပေးရမည်ဖြစ်သည်။

ခေါင်းဆောင်ရွေးချယ်မှု

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

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

ငွေလဲပွိုင့်သို့ စတင်ပြီး ချိတ်ဆက်ပြီးနောက်၊ ဝန်ဆောင်မှုအားလုံးသည် စနစ်မက်ဆေ့ချ်ကို ရရှိသည်။ #'$leader'{exchange = ?EXCHANGE, pid = LeaderPid, servers = Servers}. ရှိရင် LeaderPid နှင့်တိုက်ဆိုင် pid လက်ရှိ လုပ်ငန်းစဉ်မှာ ဦးဆောင်သူအဖြစ် ခန့်အပ်တာပေါ့နော်။ Servers node များအားလုံးနှင့် ၎င်းတို့၏ parameters များပါဝင်သည်။
အသစ်တစ်ခုပေါ်လာပြီး အလုပ်လုပ်နေသော အစုအဝေးတစ်ခု ချိတ်ဆက်မှုပြတ်တောက်သွားချိန်တွင် ဝန်ဆောင်မှုထိန်းချုပ်သူအားလုံး လက်ခံရရှိမည်ဖြစ်သည်။ #'$slave_up'{exchange = ?EXCHANGE, pid = SlavePid, options = SlaveOpts} и #'$slave_down'{exchange = ?EXCHANGE, pid = SlavePid, options = SlaveOpts} အသီးသီး။

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

ကြားခံ

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

pub-sub optimization ၏ ဂန္တဝင်နမူနာတစ်ခုသည် စျေးကွက်အတွင်း စျေးနှုန်းပြောင်းလဲမှုများနှင့် ဝဘ်ဖောက်သည်များအတွက် websocket API ကို ပံ့ပိုးပေးသည့် အပ်ဒိတ်ဖြစ်ရပ်များကဲ့သို့သော အပ်ဒိတ်ဖြစ်ရပ်များကို ထုတ်ပေးသည့် လုပ်ငန်းအမာခံဖြင့် ဖြန့်ဝေထားသော အပလီကေးရှင်းတစ်ခုဖြစ်သည်။
ထိပ်တိုက်ဆုံးဖြတ်ပါက ဖောက်သည်ဝန်ဆောင်မှုသည် အောက်ပါအတိုင်းဖြစ်သည်-

• client သည် platform နှင့်ချိတ်ဆက်မှုများပြုလုပ်သည်။ အသွားအလာကို ရပ်စဲသည့် ဆာဗာ၏ တစ်ဖက်တွင်၊ ဤချိတ်ဆက်မှုကို ဝန်ဆောင်မှုပေးရန်အတွက် လုပ်ငန်းစဉ်တစ်ခု စတင်သည်။
• ဝန်ဆောင်မှုလုပ်ငန်းစဉ်၏ အခြေအနေတွင်၊ အပ်ဒိတ်များအတွက် ခွင့်ပြုချက်နှင့် စာရင်းသွင်းမှု ဖြစ်ပေါ်လာပါသည်။ လုပ်ငန်းစဉ်သည် အကြောင်းအရာများအတွက် စာရင်းသွင်းနည်းလမ်းကို ခေါ်သည်။
• kernel တွင်ဖြစ်ရပ်တစ်ခုထုတ်လုပ်ပြီးသည်နှင့်၎င်းသည်ချိတ်ဆက်မှုများကိုဝန်ဆောင်မှုပေးသည့်လုပ်ငန်းစဉ်များသို့ပေးပို့သည်။

ကျွန်ုပ်တို့တွင် "သတင်း" ခေါင်းစဉ်အတွက် စာရင်းသွင်းသူ 50000 ရှိသည်ဟု စိတ်ကူးကြည့်ကြပါစို့။ စာရင်းသွင်းသူများကို ဆာဗာ ၅ ခုတွင် အညီအမျှ ဖြန့်ဝေထားသည်။ ရလဒ်အနေဖြင့်၊ ငွေလဲပွိုင့်သို့ရောက်ရှိလာသော အပ်ဒိတ်တစ်ခုစီတိုင်းသည် အကြိမ် ၅၀,၀၀၀၊ ဆာဗာတစ်ခုစီတွင် အကြိမ် ၁၀,၀၀၀၊ ၎င်းပေါ်ရှိ စာရင်းသွင်းသူအရေအတွက်အရ အကြိမ် ၅၀,၀၀၀ ကို ထပ်တူပွားမည်ဖြစ်သည်။ အလွန်ထိရောက်သောအစီအစဥ်မဟုတ်ပေ?
အခြေအနေတိုးတက်စေရန်၊ လဲလှယ်ပွိုင့်နှင့် အမည်တူသော ပရောက်စီကို မိတ်ဆက်ပေးလိုက်ကြပါစို့။ ကမ္ဘာလုံးဆိုင်ရာအမည် မှတ်ပုံတင်အရာရှိသည် အနီးစပ်ဆုံး လုပ်ငန်းစဉ်ကို အမည်ဖြင့် ပြန်ပေးနိုင်ရမည်၊ ယင်းသည် အရေးကြီးပါသည်။

ဤပရောက်စီကို ဝင်သုံးအလွှာဆာဗာများပေါ်တွင် စတင်လိုက်ကြပါစို့၊ websocket api ဝန်ဆောင်မှုပေးသည့် ကျွန်ုပ်တို့၏လုပ်ငန်းစဉ်များအားလုံးသည် ၎င်းကို စာရင်းသွင်းမည်ဖြစ်ပြီး၊ kernel ရှိ မူရင်းအရက်ဆိုင်ခွဲခွဲလဲလှယ်မှတ်သို့ မဟုတ်ပါ။ Proxy သည် ထူးခြားသောစာရင်းသွင်းမှုတစ်ခုတွင်သာ အဓိကစာရင်းသွင်းပြီး ၎င်း၏စာရင်းသွင်းသူအားလုံးထံ အဝင်မက်ဆေ့ဂျ်ကို ထပ်တူပွားသည်။
ရလဒ်အနေဖြင့် 5 အစား kernel နှင့် access server များကြားတွင် မက်ဆေ့ဂျ် ၅ စောင် ပေးပို့မည်ဖြစ်သည်။

လမ်းပြခြင်းနှင့် ဟန်ချက်ညီခြင်း။

Req-Resp

လက်ရှိ စာတိုပေးပို့မှု အကောင်အထည်ဖော်မှုတွင် တောင်းဆိုမှု ဖြန့်ဖြူးရေး ဗျူဟာ ၇ ခု ရှိသည်-

• default. တောင်းဆိုချက်ကို ထိန်းချုပ်သူအားလုံးထံ ပေးပို့သည်။
• round-robin. တောင်းဆိုမှုများကို ထိန်းချုပ်သူများကြားတွင် စာရင်းကောက်ယူပြီး စက်ဝိုင်းပုံစံ ဖြန့်ဝေပါသည်။
• consensus. ဝန်ဆောင်မှုပေးသော ထိန်းချုပ်ကိရိယာများကို ခေါင်းဆောင်များနှင့် ကျွန်များအဖြစ် ပိုင်းခြားထားသည်။ တောင်းဆိုချက်များကို ခေါင်းဆောင်ထံသို့သာ ပေးပို့သည်။
• consensus & round-robin. အဖွဲ့တွင် ခေါင်းဆောင်တစ်ဦးရှိသော်လည်း တောင်းဆိုချက်များကို အဖွဲ့ဝင်အားလုံးကြားတွင် ဖြန့်ဝေထားသည်။
• sticky. hash လုပ်ဆောင်ချက်ကို တွက်ချက်ပြီး သီးခြားကိုင်တွယ်သူထံ တာဝန်ပေးအပ်သည်။ ဤလက်မှတ်ပါသော နောက်ဆက်တွဲ တောင်းဆိုချက်များသည် တူညီသော ကိုင်တွယ်သူထံ ရောက်သွားပါသည်။
• sticky-fun. လဲလှယ်ပွိုင့်ကို စတင်သောအခါ၊ hash တွက်ချက်မှု လုပ်ဆောင်ချက်ကို ပြုလုပ်ပါ။ sticky ဟန်ချက်ညီခြင်း။
• fun. sticky-fun နှင့်ဆင်တူသည်၊ သင်တစ်ဦးတည်းသာ ၎င်းကို ထပ်ဆင့်လမ်းညွှန်ခြင်း၊ ငြင်းပယ်ခြင်း သို့မဟုတ် ကြိုတင်လုပ်ဆောင်နိုင်ပါသည်။

လဲလှယ်ပွိုင့်ကို စတင်သောအခါ ဖြန့်ဖြူးမှုဗျူဟာကို သတ်မှတ်သည်။

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

• ချိတ်ဆက်မှု tag အဖြစ်အပျက်များ မည်သည့်ချိတ်ဆက်မှုမှ သင့်အား နားလည်နိုင်စေပါသည်။ controller လုပ်ငန်းစဉ်သည် တူညီသော exchange point သို့ ချိတ်ဆက်သောအခါတွင်၊ မတူညီသော routing keys များဖြင့် အသုံးပြုပါသည်။
• ဝန်ဆောင်မှုပေးထားသည်။ ဝန်ဆောင်မှုတစ်ခုအတွက် အုပ်စုများအဖြစ် ကိုင်တွယ်သူများကို ပေါင်းစပ်စေပြီး လမ်းကြောင်းသတ်မှတ်ခြင်းနှင့် ဟန်ချက်ညီခြင်းစွမ်းရည်များကို ချဲ့ထွင်ခွင့်ပြုသည်။ req-resp ပုံစံအတွက်၊ routing သည် linear ဖြစ်သည်။ ကျွန်ုပ်တို့သည် ငွေလဲပွိုင့်သို့ တောင်းဆိုချက်တစ်ခု ပေးပို့ပြီးနောက် ၎င်းကို ဝန်ဆောင်မှုသို့ ပေးပို့ပါသည်။ သို့သော် ကျွန်ုပ်တို့သည် ကိုင်တွယ်သူများကို ကျိုးကြောင်းဆီလျော်သော အုပ်စုများအဖြစ် ခွဲထုတ်ရန် လိုအပ်ပါက၊ ခွဲခြမ်းခြင်းကို tags များဖြင့် လုပ်ဆောင်ပါသည်။ တဂ်ကို သတ်မှတ်သောအခါ၊ တောင်းဆိုချက်ကို ထိန်းချုပ်သူအုပ်စုတစ်ခုထံ ပေးပို့မည်ဖြစ်သည်။
• တဂ်တောင်းဆိုပါ။ အဖြေများအကြား ခွဲခြားနိုင်စေပါသည်။ ကျွန်ုပ်တို့၏စနစ်သည် တစ်ပြိုင်နက်တည်းဖြစ်သောကြောင့်၊ ဝန်ဆောင်မှုတုံ့ပြန်မှုများကို လုပ်ဆောင်ရန်အတွက် တောင်းဆိုချက်တစ်ခုပေးပို့သည့်အခါ RequestTag တစ်ခုကို သတ်မှတ်နိုင်ရန်လိုအပ်ပါသည်။ ယင်းမှ ကျွန်ုပ်တို့ထံ တောင်းဆိုလာသည့် အဖြေကို ကျွန်ုပ်တို့ နားလည်နိုင်မည်ဖြစ်သည်။

အရက်ဆိုင်ခွဲ

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

အတိုင်းအတာနှင့် အမှားခံနိုင်မှု

စနစ်တစ်ခုလုံး၏ ချဲ့ထွင်နိုင်မှုသည် စနစ်၏ အလွှာများနှင့် အစိတ်အပိုင်းများ၏ အတိုင်းအတာအပေါ်တွင် မူတည်သည်-

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

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

ယူထား

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

ကျွန်ုပ်၏ပရောဂျက်များတွင် ပြုတ်ကျပါက load တက်လာသည့်နောက်ထပ် node ကိုသုံးပါသည်။ Erlang တွင် OTP အပလီကေးရှင်းများအတွက် စံဖြန့်ဝေမုဒ် အကောင်အထည်ဖော်မှုတစ်ခုရှိသည်။ Distributed mode သည် ယခင်ထွက်ရှိခဲ့ဖူးသော အခြား node တစ်ခုပေါ်တွင် မအောင်မြင်သော အပလီကေးရှင်းကို ဖွင့်ခြင်းဖြင့် ချို့ယွင်းမှုရှိပါက ပြန်လည်ရယူခြင်းကို လုပ်ဆောင်ပါသည်။ လုပ်ငန်းစဉ်သည် ပွင့်လင်းမြင်သာမှုရှိပြီး ပျက်ကွက်ပြီးနောက်၊ အပလီကေးရှင်းသည် ပျက်ကွက်သည့်နေရာသို့ အလိုအလျောက်ရွေ့လျားသည်။ ဤလုပ်ဆောင်ချက်အကြောင်း ပိုမိုဖတ်ရှုနိုင်ပါသည်။ ဒီမှာ.

ထွက်နိုင်ရေး

rabbitmq ၏ စွမ်းဆောင်ရည်နှင့် ကျွန်ုပ်တို့၏ စိတ်ကြိုက်စာတိုပေးပို့ခြင်းတို့ကို အနည်းဆုံး အကြမ်းဖျင်း နှိုင်းယှဉ်ကြည့်ကြပါစို့။
တွေ့ခဲ့တယ် တရားဝင်ရလဒ်များ openstack အဖွဲ့မှ rabbitmq စမ်းသပ်ခြင်း။

စာပိုဒ် ၆.၁၄.၁.၂.၁.၂.၂ တွင်။ မူရင်းစာရွက်စာတမ်းသည် RPC CAST ၏ရလဒ်ကိုပြသသည်-

ကျွန်ုပ်တို့သည် OS kernel သို့မဟုတ် erlang VM အတွက် နောက်ထပ်ဆက်တင်များကို ပြုလုပ်မည်မဟုတ်ပါ။ စမ်းသပ်မှုအခြေအနေများ

• erl ရွေးချယ်မှု- +A1 +sbtu။
• erlang node တစ်ခုအတွင်း စမ်းသပ်မှုကို မိုဘိုင်းဗားရှင်းရှိ i7 အဟောင်းနှင့် လက်ပ်တော့ပေါ်တွင် လုပ်ဆောင်သည်။
• Cluster စမ်းသပ်မှုများကို 10G ကွန်ရက်ရှိသော ဆာဗာများတွင် ပြုလုပ်သည်။
• ကုဒ်သည် docker containers တွင်အလုပ်လုပ်သည်။ NAT မုဒ်တွင် ကွန်ရက်။

စမ်းသပ်ကုဒ်-

req_resp_bench(_) ->
  W = perftest:comprehensive(10000,
    fun() ->
      messaging:request(?EXCHANGE, default, ping, self()),
      receive
        #'$msg'{message = pong} -> ok
      after 5000 ->
        throw(timeout)
      end
    end
  ),
  true = lists:any(fun(E) -> E >= 30000 end, W),
  ok.

ဇာတ်လမ်း 1- အဆိုပါစမ်းသပ်မှုကို i7 မိုဘိုင်းဗားရှင်းအဟောင်းနှင့်လက်ပ်တော့ပေါ်တွင်လုပ်ဆောင်သည်။ စမ်းသပ်မှု၊ စာတိုပေးပို့မှုနှင့် ဝန်ဆောင်မှုကို Docker ကွန်တိန်နာတစ်ခုရှိ node တစ်ခုတွင် လုပ်ဆောင်သည်-

Sequential 10000 cycles in ~0 seconds (26987 cycles/s)
Sequential 20000 cycles in ~1 seconds (26915 cycles/s)
Sequential 100000 cycles in ~4 seconds (26957 cycles/s)
Parallel 2 100000 cycles in ~2 seconds (44240 cycles/s)
Parallel 4 100000 cycles in ~2 seconds (53459 cycles/s)
Parallel 10 100000 cycles in ~2 seconds (52283 cycles/s)
Parallel 100 100000 cycles in ~3 seconds (49317 cycles/s)

ဇာတ်လမ်း ၂- docker (NAT) အောက်ရှိ မတူညီသော စက်များတွင် လုပ်ဆောင်နေသော node 3 ခု။

Sequential 10000 cycles in ~1 seconds (8684 cycles/s)
Sequential 20000 cycles in ~2 seconds (8424 cycles/s)
Sequential 100000 cycles in ~12 seconds (8655 cycles/s)
Parallel 2 100000 cycles in ~7 seconds (15160 cycles/s)
Parallel 4 100000 cycles in ~5 seconds (19133 cycles/s)
Parallel 10 100000 cycles in ~4 seconds (24399 cycles/s)
Parallel 100 100000 cycles in ~3 seconds (34517 cycles/s)

အခြေအနေတိုင်းတွင် CPU အသုံးချမှုသည် 250% ထက်မပိုခဲ့ပါ။

ရလဒ်များကို

ဤစက်ဝန်းသည် စိတ်အနှောက်အယှက်ဖြစ်ပုံမပေါ်ပါ၊ ကျွန်ုပ်၏အတွေ့အကြုံသည် ဖြန့်ဝေထားသောစနစ်များမှ သုတေသီများနှင့် ၎င်းတို့၏စီးပွားရေးစနစ်များအတွက် ဖြန့်ဝေထားသောဗိသုကာများကိုတည်ဆောက်ပြီး Erlang/Elixir ကို စိတ်ဝင်တစားကြည့်ရှုနေသည့် သုတေသီနှစ်ဦးစလုံးအတွက် အမှန်တကယ်အကျိုးရှိလိမ့်မည်ဟု မျှော်လင့်ပါသည်။ ဒါ​ပေမယ့်​ တန်​ဖိုးရှိလားလို့ သံသယရှိ​တော့...

ဓာတ်ပုံ @chuttersnap

စာရင်းသွင်းအသုံးပြုသူများသာ စစ်တမ်းတွင် ပါဝင်နိုင်ပါသည်။ ဆိုင်းအင်လုပ်ခြင်း, ကျေးဇူးပြု။

VTrade စမ်းသပ်မှုစီးရီး၏ တစ်စိတ်တစ်ပိုင်းအနေဖြင့် မည်သည့်အကြောင်းအရာများကို အသေးစိတ်ဖော်ပြသင့်သနည်း။

• သီအိုရီ- စျေးကွက်များ၊ အမှာစာများနှင့် ၎င်းတို့၏အချိန်- DAY၊ GTD၊ GTC၊ IOC၊ FOK၊ MOO၊ MOC၊ LOO၊ LOC

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

• အရောင်းအ၀ယ်ကို မြင်ယောင်ခြင်း- လက်မှတ်များ၊ ဘားများ၊ ဆုံးဖြတ်ချက်များ။ ကော်ဘယ်လိုသိမ်းမလဲ။

• Backoffice စီမံကိန်းနှင့်ဖွံ့ဖြိုးရေး။ ဝန်ထမ်းစောင့်ကြည့်ခြင်းနှင့် အဖြစ်အပျက်စုံစမ်းစစ်ဆေးခြင်း။

• API ဘာအင်တာဖေ့စ်တွေ လိုအပ်သလဲ ဆိုတာကို အဖြေရှာကြည့်ရအောင်

• အချက်အလက်သိုလှောင်မှု- ကုန်သွယ်မှုစနစ်များတွင် PostgreSQL၊ Timescale၊ Tarantool

• ကုန်သွယ်မှုစနစ်များတွင် တုံ့ပြန်မှု

• တခြား။ comment မှာရေးပါ့မယ်

အသုံးပြုသူ ၁၄၇ ဦး မဲပေးခဲ့သည်။ အသုံးပြုသူ 6 ဦး ကြားနေခဲ့ပါတယ်။

source: www.habr.com