မော်စကိုအိတ်ချိန်း၏ ကုန်သွယ်မှုနှင့် ရှင်းလင်းရေးစနစ်၏ ဆင့်ကဲဖြစ်စဉ်။ အပိုင်း 2

ဤသည်မှာ Exchange ၏လည်ပတ်မှုကိုသေချာစေမည့် အားကောင်းပြီး မြင့်မားသောဝန်စနစ်တစ်ခုဖန်တီးရန် ကျွန်ုပ်တို့၏ဆူးပင်လမ်းကြောင်းအကြောင်းရှည်လျားသောဇာတ်လမ်း၏အဆက်ဖြစ်သည်။ ပထမပိုင်းကတော့ ဒီမှာပါ habr.com/en/post/444300

ဆန်းကြယ်သောအမှား

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

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

အဝိုင်းဘစ်အစုံဖြင့် ထပ်ကိန်းကို တွက်ချက်ရန် ရိုးရှင်းသော စမ်းသပ်ကိရိယာတစ်ခု ရေးခဲ့သည်။ ကျွန်ုပ်တို့အသုံးပြုသော RedHat Linux ဗားရှင်းတွင် ကံကြမ္မာဆိုးဘစ်ကို ထည့်သွင်းသောအခါတွင် သင်္ချာလုပ်ဆောင်ချက်နှင့် လုပ်ဆောင်ရာတွင် ချွတ်ယွင်းချက်တစ်ခု ရှိနေကြောင်း တွေ့ရှိရပါသည်။ ခဏအကြာတွင် ၎င်းတို့ထံမှ patch တစ်ခုကို လက်ခံရရှိပြီး ၎င်းကို RedHat သို့ တိုင်ကြားခဲ့သည်။ error မရှိတော့ပေမယ့် ဒီနည်းနည်းက ဘယ်ကလာမှန်း မသေချာသေးပါဘူး။ လုပ်ငန်းဆောင်တာများတွင် တာဝန်ရှိသည်။ fesetround C language မှ ကျွန်ုပ်တို့သည် ယူဆချက်အမှားကို ရှာဖွေရာတွင် ကျွန်ုပ်တို့၏ကုဒ်ကို ဂရုတစိုက် ခွဲခြမ်းစိတ်ဖြာခဲ့သည်- ဖြစ်နိုင်သည့် အခြေအနေအားလုံးကို စစ်ဆေးထားပါသည်။ rounding ကိုသုံးတဲ့ function အားလုံးကိုကြည့်တယ်။ မအောင်မြင်သော session တစ်ခုကို ပြန်လည်ထုတ်လုပ်ရန် ကြိုးစားခဲ့သည်။ မတူညီသောရွေးချယ်မှုများဖြင့် မတူညီသော compilers ကိုအသုံးပြုခဲ့သည်။ Static နှင့် dynamic analysis ကို အသုံးပြုခဲ့သည်။

အမှားအယွင်းဖြစ်ရသည့် အကြောင်းရင်းကို ရှာမတွေ့ပါ။

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

အဆုံးတွင်၊ ကျွန်ုပ်တို့သည် စွမ်းအင်မြင့်မားသော ရူပဗေဒလောကမှ သီအိုရီတစ်ခုအပေါ် အခြေချနေထိုင်ခဲ့သည်- စွမ်းအင်မြင့်အမှုန်အမွှားအချို့သည် ကျွန်ုပ်တို့၏ဒေတာစင်တာထဲသို့ ပျံတက်သွားကာ case wall ကိုဖောက်၊ ပရိုဆက်ဆာကိုထိမှန်ကာ trigger latch ကို ကပ်စေခဲ့သည်။ အဓိပ္ပါယ်မဲ့သော သီအိုရီကို "နျူထရီနို" ဟုခေါ်သည်။ အကယ်၍ သင်သည် particle physics နှင့် ဝေးနေပါက- နျူထရီနိုများသည် ပြင်ပကမ္ဘာနှင့် ဓါတ်မတည့်လုနီးပါးဖြစ်ပြီး ပရိုဆက်ဆာ၏ လည်ပတ်မှုကို သေချာပေါက် မထိခိုက်စေနိုင်ပါ။

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

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

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

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

အခြေအနေ၏နောက်ထပ်ခွဲခြမ်းစိတ်ဖြာမှုတွင်၊ ပြဿနာသည် OS နှင့်ဆက်စပ်နိုင်သည်ဟုသီအိုရီတစ်ခုထွက်ပေါ်လာခဲ့သည်။ ကျွန်ုပ်တို့သည် အဆုံးမဲ့ loop တစ်ခုတွင် function တစ်ခုကိုခေါ်သည့် ရိုးရှင်းသော ပရိုဂရမ်တစ်ခုကို ရေးသားခဲ့သည်။ fesetround၊ လက်ရှိအခြေအနေကို မှတ်မိပြီး အိပ်စက်ခြင်းမှတစ်ဆင့် စစ်ဆေးပြီး ၎င်းကို ပြိုင်ဆိုင်မှုအများအပြားတွင် လုပ်ဆောင်သည်။ အိပ်စက်ခြင်းအတွက် ကန့်သတ်ဘောင်များနှင့် စာတွဲအရေအတွက်ကို ရွေးချယ်ပြီးနောက်၊ ကျွန်ုပ်တို့သည် utility ကိုဖွင့်ပြီး 5 မိနစ်ခန့်အကြာတွင် ဘစ်ချို့ယွင်းမှုကို တစ်သမတ်တည်းပြန်ထုတ်ပေးပါသည်။ သို့သော်လည်း Red Hat ၏ ပံ့ပိုးကူညီမှုသည် ၎င်းကို ပြန်လည်ထုတ်လုပ်နိုင်ခြင်း မရှိခဲ့ပေ။ ကျွန်ုပ်တို့၏အခြားဆာဗာများကို စမ်းသပ်ခြင်းသည် အချို့သော ပရိုဆက်ဆာများသာ အမှားအယွင်းဖြစ်နိုင်ချေရှိကြောင်း ပြသထားသည်။ တစ်ချိန်တည်းမှာပင်၊ kernel အသစ်တစ်ခုသို့ပြောင်းခြင်းသည်ပြဿနာကိုဖြေရှင်းခဲ့သည်။ နောက်ဆုံးတွင်၊ ကျွန်ုပ်တို့သည် OS ကို ရိုးရိုးရှင်းရှင်း အစားထိုးပြီး bug ၏ အကြောင်းရင်းအမှန်ကို မရှင်းလင်းပါ။

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

စနစ်၏နောက်ထပ်ဖွံ့ဖြိုးတိုးတက်မှု

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

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

• မင်း ဘယ်သူ့ကိုမှ ယုံလို့မရဘူး။ ဆာဗာများ ကောင်းမွန်စွာ လုပ်ဆောင်နိုင်မည်မဟုတ်ပေ။
• အများစု ကြိုတင်မှာထား။
• သဘောတူညီမှုရရှိစေရေး။ ယုတ္တိရှိတဲ့အပြင် လူများစု ကြိုတင်မှာထားသလိုပါပဲ။
• နှစ်ကြိမ် ပျက်ကွက်မှုများ ဖြစ်နိုင်သည်။
• တက်ကြွမှု။ ပူပြင်းသော အသင့်အနေအထား အစီအစဉ်အသစ်သည် ယခင်ပုံစံထက် မဆိုးသင့်ပါ။ အရောင်းအ၀ယ်သည် နောက်ဆုံးဆာဗာအထိ အနှောင့်အယှက်မရှိ ဆက်လက်လုပ်ဆောင်သင့်သည်။
• latency အနည်းငယ်တိုးလာသည်။ မည်သည့်အချိန်ကမဆို ကြီးမားသောဘဏ္ဍာရေးဆုံးရှုံးမှုများရှိသည်။
• latency နည်းနိုင်သမျှနည်းအောင် ထိန်းသိမ်းရန် ကွန်ရက် အပြန်အလှန်ဆက်သွယ်မှု အနည်းဆုံး။
• စက္ကန့်ပိုင်းအတွင်း မာစတာဆာဗာအသစ်ကို ရွေးချယ်ခြင်း။

စျေးကွက်တွင်ရရှိနိုင်သည့်ဖြေရှင်းချက်တစ်ခုမှကျွန်ုပ်တို့နှင့်ကိုက်ညီမှုမရှိပါ၊ Raft protocol သည်၎င်း၏ငယ်ရွယ်စဉ်တွင်ရှိနေဆဲဖြစ်သောကြောင့်ကျွန်ုပ်တို့၏ကိုယ်ပိုင်ဖြေရှင်းချက်ကိုဖန်တီးခဲ့သည်။

ကွန်ရက်ချိတ်ဆက်ခြင်း။

ကြိုတင်မှာယူမှုစနစ်အပြင်၊ ကျွန်ုပ်တို့သည် ကွန်ရက်အပြန်အလှန်ဆက်သွယ်မှုကို ခေတ်မီအောင် လုပ်ဆောင်ခဲ့သည်။ I/O စနစ်ခွဲတွင် တုန်လှုပ်ခြင်းနှင့် latency အပေါ် အဆိုးရွားဆုံး သက်ရောက်မှုရှိသော လုပ်ငန်းစဉ်များစွာ ပါဝင်ပါသည်။ TCP ချိတ်ဆက်မှုများကို ကိုင်တွယ်သည့် ရာနှင့်ချီသော လုပ်ငန်းစဉ်များဖြင့် ၎င်းတို့ကြားတွင် အဆက်မပြတ်ပြောင်းရန် တွန်းအားပေးခံခဲ့ရပြီး မိုက်ခရိုစက္ကန့်စကေးတွင် ၎င်းသည် အချိန်ကုန်သော လုပ်ဆောင်ချက်ဖြစ်သည်။ သို့သော် အဆိုးဆုံးမှာ လုပ်ငန်းစဉ်တစ်ခုသည် လုပ်ဆောင်ရန်အတွက် packet တစ်ခုကို လက်ခံရရှိသောအခါ၊ ၎င်းသည် ၎င်းအား SystemV တန်းစီတစ်ခုသို့ ပေးပို့ပြီးနောက် အခြား SystemV တန်းစီမှ ဖြစ်ရပ်တစ်ခုကို စောင့်ဆိုင်းနေခြင်းဖြစ်သည်။ သို့သော်၊ node အများအပြားရှိသောအခါ၊ လုပ်ငန်းစဉ်တစ်ခုတွင် TCP ပက်ကတ်အသစ်တစ်ခုရောက်ရှိလာခြင်းနှင့် နောက်တစ်ခုရှိ တန်းစီရှိဒေတာလက်ခံရရှိမှုသည် OS အတွက်ပြိုင်ဆိုင်သည့်ဖြစ်ရပ်နှစ်ခုကိုကိုယ်စားပြုသည်။ ဤကိစ္စတွင်၊ အလုပ်နှစ်ခုလုံးအတွက် ရရှိနိုင်သော ရုပ်ပိုင်းဆိုင်ရာပရိုဆက်ဆာများမရှိပါက၊ တစ်ခုအား စီမံဆောင်ရွက်မည်ဖြစ်ပြီး ဒုတိယအား စောင့်ဆိုင်းနေသောတန်းစီတွင် ထားရှိမည်ဖြစ်သည်။ အကျိုးဆက်များကို ခန့်မှန်းရန် မဖြစ်နိုင်ပေ။

ထိုသို့သောအခြေအနေများတွင်၊ တက်ကြွသောလုပ်ငန်းစဉ်ဦးစားပေးထိန်းချုပ်မှုကိုအသုံးပြုနိုင်သော်လည်း ၎င်းသည် အရင်းအမြစ်-အလေးပေးစနစ်ခေါ်ဆိုမှုများကိုအသုံးပြုရန် လိုအပ်မည်ဖြစ်သည်။ ရလဒ်အနေဖြင့်၊ ကျွန်ုပ်တို့သည် ဂန္တဝင် epoll ကို အသုံးပြု၍ ကြိုးတစ်ခုသို့ ပြောင်းလိုက်သည်၊ ၎င်းသည် အမြန်နှုန်းကို အလွန်တိုးစေပြီး ငွေပေးငွေယူ လုပ်ဆောင်ချိန်ကို လျှော့ချပေးသည်။ SystemV မှတဆင့် သီးခြားကွန်ရက်ဆက်သွယ်ရေး လုပ်ငန်းစဉ်များနှင့် ဆက်သွယ်မှုများကိုလည်း ဖယ်ရှားခဲ့ပြီး၊ စနစ်ခေါ်ဆိုမှု အရေအတွက်ကို သိသိသာသာ လျှော့ချပြီး လုပ်ငန်းဆောင်ရွက်မှုများ၏ ဦးစားပေးများကို စတင်ထိန်းချုပ်ခဲ့သည်။ I/O စနစ်ခွဲတစ်ခုတည်းတွင်၊ ဇာတ်လမ်းအပေါ်မူတည်၍ 8-17 မိုက်ခရိုစက္ကန့်ခန့် သိမ်းဆည်းနိုင်သည်။ ဤချည်မျှင်တစ်ခုတည်းအစီအစဥ်ကို ထိုအချိန်မှစ၍ မပြောင်းလဲဘဲ အသုံးပြုခဲ့သည်၊ အနားသတ်ပါရှိသော epoll ကြိုးတစ်ခုသည် ချိတ်ဆက်မှုအားလုံးကို ဝန်ဆောင်မှုပေးရန် လုံလောက်ပါသည်။

ငွေပေးငွေယူ ဆောင်ရွက်ခြင်း။

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

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

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

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

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

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

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

ဤသည်မှာ ASTS+ စနစ်ဖြင့် ပေါ်ပေါက်လာခြင်းဖြစ်သည်။

မှန်ပါတယ်၊ အရာအားလုံးဟာ Conveyor တွေနဲ့ သိပ်မချောမွေ့ပါဘူး။ အိမ်နီးနားချင်း အရောင်းအ၀ယ်တစ်ခုတွင် data array များကို သက်ရောက်မှုရှိသော ငွေပေးငွေယူတစ်ခုရှိသည် ဆိုကြပါစို့၊ ၎င်းသည် လဲလှယ်မှုအတွက် ပုံမှန်အခြေအနေတစ်ခုဖြစ်သည်။ အခြားသူများကို ထိခိုက်နိုင်သောကြောင့် ထိုသို့သောငွေပေးငွေယူကို ပိုက်လိုင်းတစ်ခုတွင် လုပ်ဆောင်၍မရပါ။ ဤအခြေအနေကို data hazard ဟုခေါ်သည်၊ ထိုကဲ့သို့သောငွေပေးငွေယူများကိုသီးခြားစီလုပ်ဆောင်သည်- တန်းစီရှိ "အမြန်" အရောင်းအ၀ယ်များကုန်သွားသောအခါ၊ ပိုက်လိုင်းရပ်တန့်သွားသည်၊ စနစ်သည် "နှေးကွေးသော" ငွေပေးငွေယူကိုလုပ်ဆောင်သည်၊ ထို့နောက်ပိုက်လိုင်းကိုပြန်လည်စတင်သည်။ ကံကောင်းထောက်မစွာ၊ အလုံးစုံစီးဆင်းမှုတွင် ထိုကဲ့သို့သော လွှဲပြောင်းမှုအချိုးအစားသည် အလွန်သေးငယ်သောကြောင့် ပိုက်လိုင်းသည် အလုံးစုံစွမ်းဆောင်ရည်ကို မထိခိုက်စေရန်အတွက် အလွန်နည်းပါးပါသည်။

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

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

တန်းစီတစ်ခုလုံးကို ဤနည်းဖြင့် လုပ်ဆောင်သည်။

အဆင့်တစ်ခုစီ၏ လုပ်ဆောင်မှုသည် ယူနစ် သို့မဟုတ် ဆယ်ဂဏန်းမိုက်ခရိုစက္ကန့် ကြာသည်။ ကျွန်ုပ်တို့သည် ပုံမှန် OS ထပ်တူပြုခြင်းအစီအစဉ်များကို အသုံးပြုပါက၊ ထပ်တူပြုခြင်းအတွက် အချိန်ပိုဆုံးရှုံးပါမည်။ အဲဒါကြောင့် ကျွန်တော်တို့ spinlock ကို စသုံးတယ်။ သို့သော်၊ ၎င်းသည် အချိန်နှင့်တစ်ပြေးညီစနစ်တွင် အလွန်ဆိုးရွားသောပုံစံဖြစ်ပြီး RedHat သည် ၎င်းကိုလုပ်ဆောင်ရန် တင်းကြပ်စွာအကြံပြုထားခြင်းမရှိသောကြောင့် ကျွန်ုပ်တို့သည် 100 ms အတွက် spinlock ကိုအသုံးပြုကာ deadlock ဖြစ်နိုင်ချေကိုဖယ်ရှားရန်အတွက် semaphore မုဒ်သို့ပြောင်းပါ။

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

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

လဲလှယ်အန္တရာယ်စီမံခန့်ခွဲမှုစနစ်

ပြီးပြည့်စုံမှုတွင် အကန့်အသတ်မရှိပါ၊ မကြာမီတွင် ကျွန်ုပ်တို့သည် ခေတ်မီမှုကို ထပ်မံလုပ်ဆောင်ခဲ့သည်- ASTS+ ၏ မူဘောင်အတွင်းတွင်၊ ကျွန်ုပ်တို့သည် စွန့်စားစီမံခန့်ခွဲမှုနှင့် ဖြေရှင်းမှုစနစ်များကို ကိုယ်ပိုင်အုပ်ချုပ်ခွင့်ရ အစိတ်အပိုင်းများအဖြစ်သို့ ပြောင်းရွှေ့ရန် စတင်ခဲ့သည်။ ကျွန်ုပ်တို့သည် လိုက်လျောညီထွေရှိသော ခေတ်မီဗိသုကာပညာတစ်ခုနှင့် အထက်အောက် စွန့်စားခန်းပုံစံအသစ်ကို တီထွင်ခဲ့ပြီး အတန်းကို တတ်နိုင်သမျှ အသုံးပြုရန် ကြိုးစားခဲ့သည်။ fixed_point အစား double.

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

စနစ်အသစ်ကိုရွေးချယ်သောအခါ၊ ကျွန်ုပ်တို့သည် အပြန်အလှန်ဆက်သွယ်မှုပြဿနာကို ချက်ချင်းဖြေရှင်းခဲ့ရသည်။ ဒေတာဘတ်စ်ကို ရွေးချယ်သည့်အခါ တည်ငြိမ်တုန်လှုပ်မှုနှင့် latency အနည်းဆုံးဖြစ်ကြောင်း သေချာစေရန် လိုအပ်ပါသည်။ InfiniBand RDMA ကွန်ရက်သည် ၎င်းအတွက် အသင့်တော်ဆုံးဖြစ်သည်- ပျမ်းမျှလုပ်ဆောင်ချိန်သည် 4 G Ethernet ကွန်ရက်များထက် 10 ဆ လျော့နည်းသည်။ သို့သော် ကျွန်ုပ်တို့ကို တကယ်စွဲလမ်းစေသောအရာမှာ ရာခိုင်နှုန်း ၉၉ နှင့် ၉၉.၉ ကွာခြားချက်ဖြစ်သည်။

ဟုတ်ပါတယ်, InfiniBand တွင်၎င်း၏စိန်ခေါ်မှုများရှိသည်။ ပထမဦးစွာ၊ မတူညီသော API - sockets များအစား ibverbs။ ဒုတိယအနေဖြင့်၊ ကျယ်ပြန့်စွာရရှိနိုင်သော open source စာတိုပေးပို့ခြင်းဖြေရှင်းချက်နီးပါးမရှိပါ။ ကျွန်ုပ်တို့သည် ကျွန်ုပ်တို့၏ကိုယ်ပိုင် ရှေ့ပြေးပုံစံကို ဖန်တီးရန် ကြိုးစားခဲ့သော်လည်း အလွန်ခက်ခဲလာသောကြောင့် စီးပွားဖြစ်ဖြေရှင်းချက် - Confinity Low Latency Messaging (ယခင် IBM MQ LLM) ကို ရွေးချယ်ခဲ့သည်။

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

Ultra Low Latency ဖြေရှင်းချက်များတွင် ပြန်လည်စီစစ်ခြင်းမုဒ်ပါရှိသည်- ရင်းမြစ်နှစ်ခုမှ ငွေပေးငွေယူများကို လက်ခံရရှိပြီးနောက် လိုအပ်သောအမှာစာဖြင့် စီစဉ်နိုင်သည်၊ ၎င်းကို အမှာစာနှင့်ပတ်သက်သည့် အချက်အလက်ဖလှယ်ရန်အတွက် သီးခြားချန်နယ်ကို အသုံးပြု၍ လုပ်ဆောင်သည်။ သို့သော် ကျွန်ုပ်တို့သည် ဤမုဒ်ကို အသုံးမပြုသေးပါ- ၎င်းသည် လုပ်ငန်းစဉ်တစ်ခုလုံးကို ရှုပ်ထွေးစေပြီး ဖြေရှင်းချက်အများအပြားတွင် ၎င်းကို လုံးဝမပံ့ပိုးပါ။ ထို့အပြင်၊ ငွေပေးငွေယူတစ်ခုစီတိုင်းသည် သက်ဆိုင်ရာအချိန်တံဆိပ်တုံးများကို သတ်မှတ်ပေးရမည်ဖြစ်ပြီး ကျွန်ုပ်တို့၏အစီအစဉ်တွင် ဤယန္တရားသည် မှန်ကန်စွာအကောင်အထည်ဖော်ရန် အလွန်ခက်ခဲပါသည်။ ထို့ကြောင့်၊ ကျွန်ုပ်တို့သည် Risk Engine အကြား မက်ဆေ့ချ်များကို ဖြန့်ဝေပေးသည့် dispatcher နှင့် ဆိုလိုသည်မှာ မက်ဆေ့ချ်ပွဲစားနှင့် ဂန္တဝင်အစီအစဥ်ကို အသုံးပြုပါသည်။

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

မူရငျးခှဲ

ကျွန်ုပ်တို့၏စနစ်တွင် ချို့ယွင်းချက်တစ်ချက်မရှိသင့်ပါ၊ ဆိုလိုသည်မှာ မက်ဆေ့ချ်ပွဲစားအပါအဝင် အစိတ်အပိုင်းအားလုံးကို ပွားရပါမည်။ CLLM စနစ်ဖြင့် ဤပြဿနာကို ကျွန်ုပ်တို့ဖြေရှင်းခဲ့သည်- ၎င်းတွင် dispatchers နှစ်ဦးသည် master-slave မုဒ်တွင် အလုပ်လုပ်နိုင်ပြီး တစ်ခုပျက်သွားသောအခါ၊ စနစ်သည် အခြားတစ်ခုသို့ အလိုအလျောက်ပြောင်းသွားသည့် RCMS အစုအဝေးတစ်ခုပါရှိသည်။

အရန်ဒေတာစင်တာတစ်ခုနှင့် အလုပ်လုပ်ခြင်း။

InfiniBand ကို ဒေသတွင်း ကွန်ရက်တစ်ခုအနေဖြင့် လုပ်ဆောင်ရန် အကောင်းဆုံးဖြစ်ပြီး၊ ဆိုလိုသည်မှာ rack-mount ပစ္စည်းများကို ချိတ်ဆက်ရန်အတွက်၊ InfiniBand ကွန်ရက်ကို ပထဝီဝင်အရ ဖြန့်ဝေထားသော ဒေတာစင်တာနှစ်ခုကြားတွင် ချထား၍မရပါ။ ထို့ကြောင့်၊ ကျွန်ုပ်တို့သည် ပုံမှန် Ethernet ကွန်ရက်များမှတစ်ဆင့် မက်ဆေ့ချ်သိုလှောင်မှုသို့ ချိတ်ဆက်ပြီး ဒုတိယ IB ကွန်ရက်သို့ လွှဲပြောင်းပေးသည့် လွှဲပြောင်းမှုအားလုံးကို ချိတ်ဆက်ပေးသည့် တံတား/ dispatcher တစ်ခုကို အကောင်အထည်ဖော်ခဲ့သည်။ ကျွန်ုပ်တို့သည် ဒေတာစင်တာတစ်ခုမှ ပြောင်းရွှေ့ရန် လိုအပ်သည့်အခါ၊ ယခုနှင့် လုပ်ဆောင်ရမည့်ဒေတာစင်တာကို ကျွန်ုပ်တို့ ရွေးချယ်နိုင်ပါသည်။

ရလဒ်များကို

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

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

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

ကျွန်ုပ်တို့သည် ကျွန်ုပ်တို့၏ ပလက်ဖောင်း၏ လက်ရှိဗားရှင်းကို Rebus ဟုခေါ်သည် - ဗိသုကာပညာတွင် အထင်ရှားဆုံးသော ဆန်းသစ်တီထွင်မှုနှစ်ခုဖြစ်သည့် Risk Engine နှင့် BUS တို့အတွက် အတိုကောက်အဖြစ် ခေါ်ဝေါ်ပါသည်။

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

ကျွန်ုပ်တို့ နောက်ဆုံးအောင်မြင်ခဲ့သည်

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

တစ်စက္ကန့်လျှင် 50 မှ 180 အထိ အရောင်းအ၀ယ် အမြင့်ဆုံးဖြစ်သည်။ နောက်ထပ် တိုးလာမှုသည် တစ်ခုတည်းသော အမှာစာနှင့်ကိုက်ညီသော စီးကြောင်းကြောင့် အတားအဆီးဖြစ်သည်။

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

နောက်ဆုံးအနေနဲ့၊ လုပ်ငန်းစနစ်တွေကို အပြီးသတ်လုပ်ဆောင်နေသူတွေကို အကြံဉာဏ်တချို့ ပေးနိုင်ပါတယ်။

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

source: www.habr.com