VKontakte ၏ဗိသုကာနှင့်အလုပ်ဆိုင်ရာ FAQ

VKontakte ၏ဖန်တီးမှုသမိုင်းကြောင်း Wikipedia တွင်ရှိပြီး Pavel ကိုယ်တိုင်ကပြောပြသည်။ သူမကို လူတိုင်းသိပြီးသားဖြစ်ပုံရသည်။ HighLoad++ Pavel ရှိ site ၏အတွင်းပိုင်း၊ ဗိသုကာနှင့်ဖွဲ့စည်းပုံအကြောင်း 2010 တုန်းက ပြန်ပြောပြတယ်။. ဆာဗာများစွာသည် ထိုအချိန်မှစ၍ ပေါက်ကြားလာသောကြောင့် အချက်အလက်များကို အပ်ဒိတ်လုပ်ပါမည်- ၎င်းကို ခွဲခြမ်းစိပ်ဖြာကာ အတွင်းပိုင်းကို ထုတ်ထုတ်ကာ ချိန်တွယ်ကာ VK စက်ပစ္စည်းကို နည်းပညာဆိုင်ရာ ရှုထောင့်မှ ကြည့်ပါမည်။

Alexey Akulovich (AterCattus) VKontakte အဖွဲ့ရှိ နောက်ခံဆော့ဖ်ဝဲရေးသားသူ။ ဤအစီရင်ခံစာ၏ စာသားမှတ်တမ်းသည် ပလပ်ဖောင်း၏လည်ပတ်ဆောင်ရွက်မှု၊ အခြေခံအဆောက်အအုံ၊ ဆာဗာများနှင့် ၎င်းတို့ကြားရှိ အပြန်အလှန်ဆက်သွယ်မှုများအကြောင်း မကြာခဏမေးလေ့ရှိသည့်မေးခွန်းများအတွက် စုပေါင်းအဖြေတစ်ခုဖြစ်သော်လည်း ဖွံ့ဖြိုးတိုးတက်မှုအကြောင်းမဟုတ်ဘဲ၊ သံအကြောင်း. သီးခြားစီ၊ ဒေတာဘေ့စ်များနှင့် VK အစား မှတ်တမ်းများ စုဆောင်းခြင်းနှင့် ပရောဂျက်တစ်ခုလုံးကို စောင့်ကြည့်ခြင်းအကြောင်း သီးခြားဖြစ်သည်။ အသေးစိတ်အချက်အလတ်များကို အောက်တွင်ဖော်ပြထားပါသည်။

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

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

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

အထွေထွေဗိသုကာ

ထုံးစံအတိုင်း အရာအားလုံးသည် တောင်းဆိုမှုများကို လက်ခံသော ဆာဗာ သို့မဟုတ် ဆာဗာအုပ်စုတစ်ခုဖြင့် စတင်သည်။

ရှေ့ဆာဗာ

ရှေ့ဆာဗာသည် HTTPS၊ RTMP နှင့် WSS မှတစ်ဆင့် တောင်းဆိုမှုများကို လက်ခံသည်။

HTTPS ကို - ၎င်းတို့သည် ဆိုက်၏ ပင်မနှင့် မိုဘိုင်းဝဘ်ဗားရှင်းများအတွက် တောင်းဆိုမှုများဖြစ်သည်- vk.com နှင့် m.vk.com နှင့် ကျွန်ုပ်တို့၏ API ၏ အခြားတရားဝင်နှင့် တရားဝင်မဟုတ်သော ဖောက်သည်များ- မိုဘိုင်းဖုန်းလိုင်းများ၊ မက်ဆေ့ချ်များ။ ဧည့်ခံပွဲတစ်ခုရှိသည်။ RTMP- သီးခြားရှေ့ဆာဗာများနှင့် တိုက်ရိုက်ထုတ်လွှင့်မှုများအတွက် Traffic WSS- Streaming API အတွက် ချိတ်ဆက်မှုများ။

ဆာဗာများပေါ်တွင် HTTPS နှင့် WSS အတွက် ၎င်းသည် တန်ဖိုးရှိသည်။ nginx. RTMP ထုတ်လွှင့်မှုအတွက်၊ ကျွန်ုပ်တို့သည် ကျွန်ုပ်တို့၏ကိုယ်ပိုင်ဖြေရှင်းချက်သို့ မကြာသေးမီကမှ ပြောင်းခဲ့သည်။ kiveဒါပေမယ့် အစီရင်ခံစာရဲ့ အတိုင်းအတာထက် ကျော်လွန်နေပါတယ်။ အမှားခံနိုင်ရည်ရှိရန်အတွက်၊ ဤဆာဗာများသည် ဘုံ IP လိပ်စာများကို ကြော်ငြာပြီး ဆာဗာများထဲမှ တစ်ခုတွင် ပြဿနာရှိပါက၊ အသုံးပြုသူ တောင်းဆိုချက်များ မဆုံးရှုံးစေရန်အတွက် အုပ်စုများအတွင်း လုပ်ဆောင်သည်။ HTTPS နှင့် WSS အတွက်၊ ၎င်းတို့အပေါ် CPU load ၏ တစ်စိတ်တစ်ပိုင်းကို ရယူရန်အတွက် ဤတူညီသောဆာဗာများသည် အသွားအလာကို စာဝှက်ထားသည်။

WSS နှင့် RTMP အကြောင်း ဆက်လက်ပြောဆိုမည်မဟုတ်သော်လည်း အများအားဖြင့် ဝဘ်ပရောဂျက်တစ်ခုနှင့် ဆက်စပ်နေသည့် စံ HTTPS တောင်းဆိုမှုများအကြောင်းသာ ပြောပါမည်။

backend

ရှေ့နောက်တွင် များသောအားဖြင့် backend ဆာဗာများရှိသည်။ ၎င်းတို့သည် ဖောက်သည်များထံမှ ရှေ့ဆာဗာမှ လက်ခံရရှိသည့် တောင်းဆိုမှုများကို လုပ်ဆောင်သည်။

ဤ kPHP ဆာဗာများHTTPS ကို စာဝှက်ထားပြီးဖြစ်သောကြောင့် HTTP daemon လည်ပတ်နေပါသည်။ kPHP သည် လည်ပတ်နေသော ဆာဗာတစ်ခုဖြစ်သည်။ prefork မော်ဒယ်များ: ပင်မ လုပ်ငန်းစဉ်ကို စတင်သည်၊ ကလေး လုပ်ငန်းစဉ်များ အစုအဝေး ၊ ၎င်းတို့ထံ နားထောင်ခြင်း စကတ်များကို ပေးပို့ပြီး ၎င်းတို့၏ တောင်းဆိုချက်များကို လုပ်ဆောင်သည်။ ဤကိစ္စတွင်၊ အသုံးပြုသူထံမှ တောင်းဆိုချက်တစ်ခုစီကြားတွင် လုပ်ငန်းစဉ်များကို ပြန်လည်စတင်ခြင်းမပြုသော်လည်း ၎င်းတို့၏အခြေအနေကို မူလသုညတန်ဖိုးအခြေအနေသို့ ပြန်လည်သတ်မှတ်ပါ - ပြန်လည်စတင်မည့်အစား တောင်းဆိုပြီးနောက် တောင်းဆိုချက်ပြီးနောက် ပြန်လည်စတင်ပါ။

load ဖြန့်ဖြူး

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

မက်ထရစ် စုဆောင်းခြင်းနှင့် ပြန်လည်ချိန်ညှိခြင်း။

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

ကျွန်ုပ်တို့တွင် ထိုကဲ့သို့သော ဆာဗာထောင်ပေါင်းများစွာရှိသည်။ ရုပ်ပိုင်းဆိုင်ရာဆာဗာတစ်ခုစီသည် cores အားလုံးကို ပြန်လည်အသုံးပြုရန် kPHP အုပ်စုကို လုပ်ဆောင်သည် (kPHP သည် တစ်ခုတည်းသော threaded ဖြစ်သောကြောင့်)။

အကြောင်းအရာဆာဗာ

CS သို့မဟုတ် Content Server သည် သိုလှောင်မှုတစ်ခုဖြစ်သည်။. CS သည် ဖိုင်များကို သိမ်းဆည်းကာ အပ်လုဒ်လုပ်ထားသော ဖိုင်များနှင့် ၎င်းကို ပင်မဝဘ်ရှေ့တန်းမှ သတ်မှတ်ပေးသည့် နောက်ခံထပ်တူကျသည့် အလုပ်အမျိုးအစားအားလုံးကိုလည်း လုပ်ဆောင်ပေးသည့် ဆာဗာတစ်ခုဖြစ်သည်။

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

pu/pp

သင် VK တွင် ကွန်ရက်တက်ဘ်ကို ဖွင့်ပါက pu/pp ကို သင်တွေ့နိုင်သည်။

pu/pp ဆိုတာဘာလဲ။ အကယ်၍ ကျွန်ုပ်တို့သည် ဆာဗာတစ်ခုပြီးတစ်ခု ပိတ်ပါက၊ ပိတ်ထားသော ဆာဗာသို့ ဖိုင်တစ်ခုကို အပ်လုဒ်တင်ခြင်းနှင့် ဒေါင်းလုဒ်လုပ်ခြင်းအတွက် ရွေးချယ်စရာ နှစ်ခုရှိသည်။ တိုက်ရိုက် ဖြတ်. http://cs100500.userapi.com/path သို့မဟုတ် အလယ်အလတ်ဆာဗာမှတဆင့် - http://pu.vk.com/c100500/path.

Pu သည် ဓာတ်ပုံတင်ခြင်းအတွက် သမိုင်းဝင်အမည်ဖြစ်ပြီး pp သည် photo proxy ဖြစ်သည်။. ဆိုလိုသည်မှာ ဆာဗာတစ်ခုသည် ဓာတ်ပုံများတင်ရန်ဖြစ်ပြီး နောက်တစ်ခုသည် အပ်လုဒ်တင်ရန်အတွက်ဖြစ်သည်။ ယခုအခါ ဓာတ်ပုံများတင်ရုံသာမက နာမည်ကိုပါ သိမ်းဆည်းထားသည်။

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

ကျွန်ုပ်တို့၏အခြားစက်များမှ စက်များကိုပိတ်ထားသောကြောင့်၊ ၎င်းတို့အား "အဖြူ" ပြင်ပ IP များကို မပေးဆောင်နိုင်ဘဲ၊ "မီးခိုးရောင်" ပေးပါ. ဤနည်းဖြင့် ကျွန်ုပ်တို့သည် IP pool တွင်သိမ်းဆည်းပြီး စက်များကို ပြင်ပသို့ဝင်ရောက်ခြင်းမှကာကွယ်ရန်အာမခံပါသည် - ၎င်းထဲသို့ဝင်ရန် IP မရှိပါ။

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

အငြင်းပွားစရာအချက်ကတော့ ဒီကိစ္စမှာ client သည် ချိတ်ဆက်မှုနည်းသည်။. စက်အများအပြားအတွက် တူညီသော IP ရှိလျှင် - တူညီသောအိမ်ရှင်- pu.vk.com သို့မဟုတ် pp.vk.com တွင်၊ client browser သည် host တစ်ခုသို့ တပြိုင်နက်တည်း တောင်းဆိုမှုအရေအတွက်အပေါ် ကန့်သတ်ချက်ရှိသည်။ သို့သော် နေရာအနှံ့ HTTP/2 တွင်၊ ၎င်းသည် သိပ်မသက်ဆိုင်တော့ဟု ကျွန်ုပ်ယုံကြည်ပါသည်။

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

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

နေ

၂၀၁၇ ခုနှစ် စက်တင်ဘာလတွင် Oracle သည် ယခင်က ဝယ်ယူခဲ့ဖူးသည့် Sun၊ Sun ဝန်ထမ်း အများအပြားကို အလုပ်ထုတ်ခဲ့သည်။. ဒီအချိန်မှာ ကုမ္ပဏီက ရပ်သွားပြီလို့ ပြောလို့ရတယ်။ စနစ်သစ်အတွက် အမည်တစ်ခုကို ရွေးချယ်သောအခါတွင်၊ ကျွန်ုပ်တို့၏ စီမံခန့်ခွဲသူများသည် ဤကုမ္ပဏီ၏ မှတ်ဉာဏ်အား ချီးကျူးဂုဏ်ပြုကာ စနစ်သစ် Sun ဟု အမည်ပေးခဲ့သည်။ ကျွန်ုပ်တို့ကိုယ်တိုင်က သူ့ကို "နေ" ဟုခေါ်သည်။

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

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

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

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

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

ကျွန်ုပ်တို့သည် “Clover” အက်ပ်ကို မကြာသေးမီက စတင်ခဲ့သည်။ ဤအရာသည် တိုက်ရိုက်ထုတ်လွှင့်မှုတွင် အွန်လိုင်းပဟေဋ္ဌိဖြစ်ပြီး၊ အိမ်ရှင်က မေးခွန်းများမေးပြီး အသုံးပြုသူများကို ရွေးချယ်မှုများကို ရွေးချယ်ကာ အချိန်နှင့်တပြေးညီ ဖြေကြားပေးပါသည်။ အပလီကေးရှင်းတွင် အသုံးပြုသူများ ချတ်လုပ်နိုင်သည့် ချတ်တစ်ခုရှိသည်။ တစ်ပြိုင်နက်ထုတ်လွှင့်မှုကို ချိတ်ဆက်နိုင်သည်။ လူ 100 ကျော်. သူတို့အားလုံး ပါဝင်သူအားလုံးထံ ပေးပို့ထားသော မက်ဆေ့ချ်များကို ရေးသားကြပြီး ကိုယ်ပွားတစ်ခုသည် မက်ဆေ့ချ်နှင့်အတူ ပါလာပါသည်။ "နေ" တစ်ခုတည်းတွင် လူပေါင်း 100 တို့သည် "နေ" တစ်ခုတည်း၌ ကိုယ်ပွားတစ်ခုအတွက် လာမည်ဆိုလျှင်၊ တစ်ခါတစ်ရံ တိမ်တိုက်နောက်သို့ လှည့်သွားနိုင်သည်။

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

အတွင်းမှနေရောင်

nginx၊ RAM တွင်ဖြစ်စေ သို့မဟုတ် မြန်ဆန်သော Optane/NVMe ဒစ်များတွင်ဖြစ်စေ ကက်ရှ်တွင် ပြောင်းပြန်ပရောက်စီ။ ဥပမာ- http://sun4-2.userapi.com/c100500/path — စတုတ္ထမြောက်ဒေသ၊ ဒုတိယဆာဗာအုပ်စုတွင်ရှိသော “နေ” သို့ လင့်ခ်တစ်ခု။ ၎င်းသည် ဆာဗာ 100500 တွင် အမှန်တကယ်တည်ရှိသည့် လမ်းကြောင်းဖိုင်ကို ပိတ်သည်။

အဖုံး

ကျွန်ုပ်တို့၏ ဗိသုကာအစီအစဥ်တွင် နောက်ထပ် node တစ်ခုထပ်ထည့်သည် - ကက်ရှ်ပတ်ဝန်းကျင်။

အောက်တွင် layout diagram ဖြစ်သည်။ ဒေသဆိုင်ရာ ကက်ရှ်များအဲဒီအထဲက ၂၀ လောက်ရှိတယ်။ ဤအရာများသည် ကက်ရှ်များနှင့် “နေများ” တည်ရှိရာနေရာများဖြစ်ပြီး ၎င်းတို့မှတဆင့် လမ်းကြောင်းများကို သိမ်းဆည်းထားနိုင်သည်။

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

အသုံးပြုသူ၏ဒေသကိုဆုံးဖြတ်ရန်, ငါတို့သည် ဒေသများတွင် ကြေညာထားသော BGP ကွန်ရက်ရှေ့ဆက်များကို ကျွန်ုပ်တို့ စုဆောင်းပါသည်။. ဆုတ်ယုတ်မှုကိစ္စတွင်၊ ရှေ့ဆက်များဖြင့် IP ကို ​​ရှာမတွေ့ပါက၊ ကျွန်ုပ်တို့သည် Geoip ဒေတာဘေ့စ်ကို ခွဲခြမ်းစိပ်ဖြာရမည်ဖြစ်ပါသည်။ ကျွန်ုပ်တို့သည် အသုံးပြုသူ၏ IP ဖြင့် ဒေသကို ဆုံးဖြတ်ပါသည်။. ကုဒ်တွင်၊ ကျွန်ုပ်တို့သည် အသုံးပြုသူ၏ ပထဝီဝင်နှင့် အနီးစပ်ဆုံးဖြစ်သည့် အဆိုပါအချက်များကို အသုံးပြုသူ၏ တစ်ခု သို့မဟုတ် တစ်ခုထက်ပိုသော ဒေသများကို ကြည့်ရှုနိုင်သည်။

ဘယ်လိုအလုပ်လုပ်သလဲ

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

တစ်ချိန်တည်းမှာပင်၊ ဒေသများရှိ ဝန်ဆောင်မှုများ- နတ်ဆိုးများသည် API ထံ ရံဖန်ရံခါ ရောက်လာပြီး "ငါက ဒီလိုမျိုး၊ ကက်ရှ်တစ်ခု၊ ငါ့ဒေသမှာ မရှိသေးတဲ့ လူကြိုက်အများဆုံး ဖိုင်စာရင်းကို ပေးပါ။ ” API သည် အဆင့်သတ်မှတ်ချက်အလိုက် စီထားသော ဖိုင်များစွာကို ပေးပို့သည်၊ daemon သည် ၎င်းတို့ကို ဒေါင်းလုဒ်လုပ်ကာ ၎င်းတို့ကို ဒေသများသို့ ခေါ်ဆောင်ကာ ထိုနေရာမှ ဖိုင်များကို ပို့ပေးသည်။ ၎င်းသည် ကက်ရှ်မှ pu/pp နှင့် Sun တို့၏ အခြေခံကွာခြားချက်ဖြစ်သည်- ဤဖိုင်သည် ကက်ရှ်တွင်မရှိလျှင်ပင် ၎င်းတို့သည် ဖိုင်ကို ချက်ချင်းပေးကြပြီး၊ ကက်ရှ်သည် ဖိုင်ကို သူ့အလိုလို ဒေါင်းလုဒ်လုပ်ကာ ၎င်းကို ပြန်ပေးသည်။

ဒီကိစ္စမှာ ကျွန်တော်တို့ ရတာပေါ့။ အသုံးပြုသူများနှင့် ပိုမိုနီးစပ်သော အကြောင်းအရာ နှင့် network load ကိုဖြန့်ကြက်။ ဥပမာအားဖြင့်၊ ကျွန်ုပ်တို့သည် အမြင့်ဆုံးနာရီများအတွင်း 1 Tbit/s ထက်ပို၍ ဖြန့်ဝေပါသည်။

ဒါပေမယ့် ပြဿနာတွေ ရှိတယ် - ကက်ရှ်ဆာဗာများသည် ရော်ဘာမဟုတ်ပါ။. လူကြိုက်များသောအကြောင်းအရာအတွက်၊ တစ်ခါတစ်ရံတွင် သီးခြားဆာဗာအတွက် ကွန်ရက်လုံလောက်မှု မရှိပါ။ ကျွန်ုပ်တို့၏ ကက်ရှ်ဆာဗာများသည် 40-50 Gbit/s ဖြစ်သည်၊ သို့သော် ထိုကဲ့သို့သော ချန်နယ်ကို လုံးဝပိတ်ဆို့သည့် အကြောင်းအရာများရှိပါသည်။ ကျွန်ုပ်တို့သည် ဒေသတွင်းရှိ လူကြိုက်များသောဖိုင်များ၏ မိတ္တူတစ်ခုထက်ပိုသော သိုလှောင်မှုကို အကောင်အထည်ဖော်ရန် ကြိုးပမ်းနေပါသည်။ ဒီနှစ်ကုန်မှာ အကောင်အထည်ဖော်နိုင်မယ်လို့ မျှော်လင့်ပါတယ်။

ယေဘူယျ ဗိသုကာပညာကို ကြည့်တယ်။

• တောင်းဆိုချက်များကို လက်ခံသော ရှေ့ဆာဗာများ။
• လုပ်ငန်းစဉ်တောင်းဆိုမှုများကို နောက်ခံထားပေးသည်။
• ပရောက်စီ အမျိုးအစားနှစ်မျိုးဖြင့် ပိတ်ထားသော သိုလှောင်မှုများ။
• ဒေသဆိုင်ရာ ကက်ရှ်များ။

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

ဒေတာဘေ့စ်များ သို့မဟုတ် အင်ဂျင်များ

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

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

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

ဖြေရှင်းချက် အောင်မြင်ခဲ့သည်။. ထိုအချိန်က အခြားသော အတိုင်းအတာများ မရှိသောကြောင့် ၎င်းကို လုပ်ဆောင်ရန် အခွင့်အလမ်းအပြင် အလွန်အမင်း လိုအပ်ချက်တစ်ခုလည်း ရှိခဲ့ပါသည်။ ဒေတာဘေ့စ်များစွာမရှိပါ၊ NoSQL မရှိသေးပါ၊ MySQL၊ Memcache၊ PostrgreSQL သာရှိပါသည် - ဒါပါပဲ။

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

အင်ဂျင်အမျိုးအစားများ

အဖွဲ့သည် အင်ဂျင်အနည်းအကျဉ်း ရေးသားခဲ့သည်။ ၎င်းတို့ထဲမှ အချို့သာဖြစ်သည်- သူငယ်ချင်း၊ အရိပ်အမြွက်များ၊ ပုံ၊ ipdb၊ စာလုံးများ၊ စာရင်းများ၊ မှတ်တမ်းများ၊ memcached၊ meowdb၊ သတင်း၊ nostradamus၊ ဓာတ်ပုံ၊ အစီအစဉ်များ၊ pmemcached၊ sandbox၊ ရှာဖွေမှု၊ သိုလှောင်မှု၊ ကြိုက်နှစ်သက်မှုများ၊ လုပ်ဆောင်စရာများ၊ ...

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

ကျွန်ုပ်တို့တွင် သီးခြားအင်ဂျင်တစ်ခုရှိသည်။ memcacheပုံမှန်တစ်ခုနှင့်ဆင်တူသော်လည်း ကောင်းသောပစ္စည်းများစွာဖြင့် နှေးကွေးခြင်းမရှိပါ။ ClickHouse မဟုတ်ပေမယ့်လည်း အလုပ်လုပ်ပါတယ်။ သီးခြားရရှိနိုင်ပါသည်။ pmemcached - က persistent memcachedပြန်လည်စတင်သည့်အခါ ဒေတာမဆုံးရှုံးစေရန် RAM နှင့် အံဝင်ခွင်ကျဖြစ်သော disk ပေါ်တွင်လည်း ဒေတာသိမ်းဆည်းနိုင်သည်။ လုပ်ငန်းတစ်ခုစီအတွက် အင်ဂျင်အမျိုးမျိုးရှိပါသည်- တန်းစီခြင်း၊ စာရင်းများ၊ အစုံများ - ကျွန်ုပ်တို့ပရောဂျက်လိုအပ်သမျှ။

ပြွတ်

ကုဒ်ရှုထောင့်မှကြည့်လျှင် အင်ဂျင်များ သို့မဟုတ် ဒေတာဘေ့စ်များကို လုပ်ငန်းစဉ်များ၊ အရာဝတ္ထုများ သို့မဟုတ် ဥပမာများအဖြစ် ထည့်သွင်းစဉ်းစားရန် မလိုအပ်ပါ။ ကုဒ်သည် အင်ဂျင်အုပ်စုများနှင့် အထူးသဖြင့် အစုအဝေးများနှင့် အလုပ်လုပ်သည် - အစုတစ်ခုလျှင် အမျိုးအစားတစ်ခု. memcached cluster ရှိတယ်ဆိုပါစို့ - ၎င်းသည် စက်အုပ်စုတစ်ခုမျှသာဖြစ်သည်။

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

၎င်းကိုလုပ်ဆောင်ရန်၊ ကုဒ်နှင့်အင်ဂျင်များကြားတွင်ရှိသော နောက်ထပ်အရာတစ်ခုကို ထပ်ထည့်ရန်လိုအပ်သည်- proxy ကို.

RPC ပရောက်စီ

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

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

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

တိကျသောအကောင်အထည်ဖော်မှုများ

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

ဤနေရာတွင် ကျွန်ုပ်တို့ရှိနေဆဲဖြစ်သည့် MySQL အတွက်၊ ကျွန်ုပ်တို့သည် db-proxy နှင့် ClickHouse အတွက် - ကြောင်အိမ်.

ယေဘူယျအားဖြင့် ဤကဲ့သို့အလုပ်လုပ်သည်။ ဆာဗာတစ်ခုရှိပြီး၊ ၎င်းသည် kPHP၊ Go၊ Python ကိုလုပ်ဆောင်သည် - ယေဘုယျအားဖြင့် ကျွန်ုပ်တို့၏ RPC ပရိုတိုကောကို အသုံးပြုနိုင်သည့် မည်သည့်ကုဒ်မဆို။ ကုဒ်သည် RPC ပရောက်စီပေါ်တွင် စက်တွင်းအလုပ်လုပ်သည် - ကုဒ်တည်ရှိသည့်ဆာဗာတစ်ခုစီသည် ၎င်း၏ကိုယ်ပိုင်ဒေသခံပရောက်စီကို လုပ်ဆောင်သည်။ တောင်းဆိုချက်အရ၊ ပရောက်စီသည် မည်သည့်နေရာသို့သွားရမည်ကို နားလည်သည်။

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

အင်ဂျင်အားလုံးလည်ပတ်သည့် TL-scheme ၏ဥပမာ။

memcache.not_found                                = memcache.Value;
memcache.strvalue	value:string flags:int = memcache.Value;
memcache.addOrIncr key:string flags:int delay:int value:long = memcache.Value;

tasks.task
    fields_mask:#
    flags:int
    tag:%(Vector int)
    data:string
    id:fields_mask.0?long
    retries:fields_mask.1?int
    scheduled_time:fields_mask.2?int
    deadline:fields_mask.3?int
    = tasks.Task;
 
tasks.addTask type_name:string queue_id:%(Vector int) task:%tasks.Task = Long;

၎င်းသည် binary protocol ဖြစ်ပြီး၊ ၎င်းသည် အနီးစပ်ဆုံး analogue ဖြစ်သည်။ protobuf။ schema သည် ရွေးချယ်နိုင်သော အကွက်များ၊ ရှုပ်ထွေးသောအမျိုးအစားများ - built-in scalar များ၏ extensions များနှင့် queries များကို ကြိုတင်ဖော်ပြပါသည်။ အရာအားလုံးသည် ဤပရိုတိုကောအရ အလုပ်လုပ်သည်။

TCP/UDP ထက် TL ကျော် RPC… UDP?

ကျွန်ုပ်တို့တွင် TL အစီအစဉ်၏ထိပ်တွင် လုပ်ဆောင်သည့် အင်ဂျင်တောင်းဆိုမှုများကို လုပ်ဆောင်ရန်အတွက် RPC ပရိုတိုကောတစ်ခုရှိသည်။ ဤအရာအားလုံးသည် TCP/UDP ချိတ်ဆက်မှုမှတဆင့် အလုပ်လုပ်ပါသည်။ TCP ကို ​​နားလည်နိုင်သော်လည်း UDP ကို ​​အဘယ်ကြောင့် မကြာခဏ လိုအပ်သနည်း။

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

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

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

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

အမြဲတမ်းဒေတာသိုလှောင်မှု

အင်ဂျင်များသည် binlogs များကိုရေးသည်။. binlog သည် အခြေအနေ သို့မဟုတ် ဒေတာပြောင်းလဲမှုအတွက် ဖြစ်ရပ်တစ်ခု၏အဆုံးတွင် ဖိုင်တစ်ခုဖြစ်သည်။ မတူညီသောအဖြေများတွင် ၎င်းကို ကွဲပြားစွာခေါ်သည်- binary log၊ Wal, AOFဒါပေမယ့် နိယာမကတော့ အတူတူပါပဲ။

ပြန်လည်စတင်ချိန်တွင် အင်ဂျင်သည် binlog တစ်ခုလုံးကို နှစ်ပေါင်းများစွာ ပြန်လည်ဖတ်ရှုခြင်းမှ ကာကွယ်ရန်၊ အင်ဂျင်များက ရေးပေးသည်။ လျှပ်တစ်ပြက်- လက်ရှိအခြေအနေ. လိုအပ်ပါက ၎င်းတို့သည် ၎င်းကို ဦးစွာဖတ်ပြီးနောက် binlog မှ အပြီးသတ်ဖတ်ပါ။ binlog အားလုံးကို တူညီသော binary ဖော်မတ်ဖြင့် ရေးထားသည် - TL စီမံချက်အရ၊ သို့မှသာ စီမံခန့်ခွဲသူများသည် ၎င်းတို့အား ၎င်းတို့၏ကိရိယာများဖြင့် အညီအမျှ စီမံခန့်ခွဲနိုင်စေရန်။ လျှပ်တစ်ပြက်ရိုက်စရာ မလိုပါဘူး။ မည်သူ၏လျှပ်တစ်ပြက်ရိုက်ချက်သည် int ဖြစ်သည်၊ အင်ဂျင်၏ မှော်ဆန်မှု၊ မည်သည့်ကိုယ်ထည်သည် မည်သူမျှ အရေးမကြီးကြောင်း ဖော်ပြသည့် ယေဘုယျ ခေါင်းစီးတစ်ခုရှိသည်။ ၎င်းသည် လျှပ်တစ်ပြက်ရိုက်ချက်ကို မှတ်တမ်းတင်သည့် အင်ဂျင်တွင် ပြဿနာတစ်ခုဖြစ်သည်။

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

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

တစ်ချိန်ချိန်တွင်၊ အင်ဂျင်ပြန်လည်စတင်သည့်အခါ၊ binlog တစ်ခုနှင့် disk ပေါ်တွင်လျှပ်တစ်ပြက်ပုံနှစ်ခုလုံးရှိလိမ့်မည်။ အင်ဂျင်သည် လျှပ်တစ်ပြက်တစ်ခုလုံးကို ဖတ်ပြီး တစ်ချိန်တည်းတွင် ၎င်း၏အခြေအနေကို မြှင့်တင်ပေးသည်။

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

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

ဒေတာ ကူးယူခြင်း

ထို့ကြောင့် data replication သည် ကျွန်ုပ်တို့အတွက်ဖြစ်သည်။ ထုတ်ပြန်ချက်ကိုအခြေခံသည်။ - ကျွန်ုပ်တို့သည် binlog တွင် စာမျက်နှာပြောင်းလဲမှုမရှိသော်လည်း အဓိပ္ပါယ်ဖွင့်ဆိုထားသည်။ ပြောင်းလဲရန်တောင်းဆိုမှုများ. ကွန်ရက်ပေါ်မှ ရောက်လာသည့်အရာနှင့် အလွန်ဆင်တူသည်၊ အနည်းငယ်သာ ပြုပြင်ထားသည်။

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

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

ဤနေရာတွင် ပြတ်တောက်မှုသည် အလွန်သေးငယ်ပြီး ပုံစံတူသည် သခင်နောက်၌ မည်မျှ နောက်ကျကျန်နေမည်ကို သိရှိနိုင်သည်။

RPC ပရောက်စီတွင် ဒေတာခွဲဝေမှု

Sharing က ဘယ်လိုအလုပ်လုပ်သလဲ။ proxy သည် မည်သည့် cluster shard ကိုပေးပို့ရမည်ကို မည်သို့နားလည်သနည်း။ ကုဒ်တွင် "15 shards ပို့ပါ!" - မဟုတ်ဘူး၊ ဒါကို proxy က လုပ်ဆောင်ပါတယ်။

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

get(photo100_500) => 100 % N.

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

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

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

hash(photo100_500) => 3539886280 % N

ကျွန်ုပ်တို့သည် hash ၊ အပိုင်း၏အကြွင်းနှင့် shard နံပါတ်ကိုလည်းရရှိသည်။

ဤရွေးချယ်မှုနှစ်ခုလုံးသည် အစုအစည်းအရွယ်အစားကို တိုးမြှင့်သည့်အခါ ၎င်းကို ခွဲခြမ်းရန် သို့မဟုတ် အကြိမ်များစွာ တိုးမြှင့်မည်ဟူသောအချက်အတွက် ပြင်ဆင်ထားမှသာ အလုပ်လုပ်ပါသည်။ ဥပမာအားဖြင့်၊ ကျွန်ုပ်တို့တွင် 16 shards ရှိသည်၊ ကျွန်ုပ်တို့တွင် မလုံလောက်ပါ၊ ကျွန်ုပ်တို့ ပို၍လိုချင်သည် - အချိန်မဆွဲဘဲ 32 ကို လုံခြုံစွာရနိုင်သည်။ ကျွန်ုပ်တို့သည် အဆမများဘဲ တိုးလိုပါက အရှုံးမရှိဘဲ အရာအားလုံးကို တိကျစွာ မခွဲနိုင်သောကြောင့် စက်ရပ်သွားမည်ဖြစ်သည်။ ဤရွေးချယ်မှုများသည် အသုံးဝင်သော်လည်း အမြဲတမ်းမဟုတ်ပါ။

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

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

မှတ်တမ်းများ

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

ring-buffer: prefix.idx = line

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

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

ယုံကြည်စိတ်ချရသော သစ်လုံးများကို သိမ်းဆည်းရန်အတွက် ကျွန်ုပ်တို့တွင် အင်ဂျင်တစ်လုံးရှိသည်။ သစ်လုံး-အင်ဂျင်. ဤသည်မှာ တိကျစွာ ဖန်တီးထားခြင်းဖြစ်ပြီး အစုအဝေးများစွာတွင် တွင်ကျယ်စွာ အသုံးပြုထားသည်။ ထုပ်ပိုးထားသော မှတ်တမ်းများ 600 TB ကို ကျွန်ုပ်သိသော အကြီးဆုံးအစုအဝေးဖြစ်သည်။

အင်ဂျင်က အရမ်းဟောင်းနေပြီ၊ 6-7 နှစ်လောက်ရှိနေပြီဖြစ်တဲ့ ပြွတ်တွေရှိတယ်။ ကျွန်ုပ်တို့ဖြေရှင်းရန်ကြိုးစားနေသည့် ပြဿနာများရှိသည်၊ ဥပမာ၊ ကျွန်ုပ်တို့သည် မှတ်တမ်းများသိမ်းဆည်းရန် ClickHouse ကိုတက်ကြွစွာအသုံးပြုလာသည်။

ClickHouse တွင် မှတ်တမ်းများ စုဆောင်းခြင်း။

ဤပုံကြမ်းသည် ကျွန်ုပ်တို့၏အင်ဂျင်အတွင်းသို့ ကျွန်ုပ်တို့ မည်သို့လျှောက်လှမ်းသည်ကို ပြသသည်။

RPC မှတဆင့် RPC-proxy သို့ပြည်တွင်းတွင်သွားသောကုဒ်ရှိပြီး၎င်းသည်အင်ဂျင်သို့သွားရမည့်နေရာကိုနားလည်သည်။ ClickHouse တွင် မှတ်တမ်းများရေးလိုပါက၊ ဤအစီအစဉ်တွင် အပိုင်းနှစ်ပိုင်းကို ပြောင်းလဲရန် လိုအပ်သည်-

• အင်ဂျင်အချို့ကို ClickHouse ဖြင့် အစားထိုးပါ။
• ClickHouse သို့ဝင်ရောက်၍မရသော RPC ပရောက်စီကို အစားထိုးနိုင်သော ဖြေရှင်းချက်အချို့နှင့် RPC မှတဆင့် အစားထိုးပါ။

အင်ဂျင်သည် ရိုးရှင်းသည် - ကျွန်ုပ်တို့ ၎င်းကို ဆာဗာတစ်ခု သို့မဟုတ် ClickHouse ဖြင့် ဆာဗာအစုအဝေးတစ်ခုဖြင့် အစားထိုးပါသည်။

ပြီးတော့ ClickHouse ကိုသွားဖို့၊ ငါတို့လုပ်ခဲ့တယ်။ KittenHouse. KittenHouse မှ ClickHouse သို့ တိုက်ရိုက်သွားပါက၊ ၎င်းသည် ထိန်းကျောင်းနိုင်မည်မဟုတ်ပေ။ တောင်းဆိုမှုများမရှိသော်လည်း၊ ၎င်းသည် စက်အများအပြား၏ HTTP ချိတ်ဆက်မှုများမှ ပေါင်းထည့်သည်။ အစီအစဥ်ကိုလုပ်ဆောင်ရန်အတွက် ClickHouse ပါရှိသောဆာဗာတစ်ခုပေါ်တွင် local reverse proxy ကိုမြှင့်ထားသည်။လိုအပ်သော ချိတ်ဆက်မှုပမာဏများကို ခံနိုင်ရည်ရှိစေမည့် နည်းလမ်းဖြင့် ရေးသားထားသည်။ ၎င်းသည် သူ့အလိုလိုအတွင်း ဒေတာကြားခံများကိုလည်း စိတ်ချယုံကြည်စွာ လုပ်ဆောင်နိုင်သည်။

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

မှတ်တမ်းများကို ပေးပို့သူနှင့် လက်ခံသူသည် တူညီသောစက်တွင် အလုပ်လုပ်ပါက၊ local host အတွင်းရှိ UDP packet ဆုံးရှုံးနိုင်ခြေမှာ အလွန်နည်းပါးပါသည်။ ပြင်ပအဖွဲ့အစည်းဖြေရှင်းချက်နှင့် ယုံကြည်စိတ်ချရမှုတွင် RPC အကောင်အထည်ဖော်ရန် လိုအပ်မှုအကြား အပေးအယူတစ်ခုအနေဖြင့် ကျွန်ုပ်တို့သည် UDP ပေးပို့ခြင်းကို ရိုးရိုးရှင်းရှင်းအသုံးပြုပါသည်။ ဤအစီအစဉ်ကို နောက်မှ ပြန်သွားပါမည်။

စောင့်ကြည့်လေ့လာခြင်း

ကျွန်ုပ်တို့တွင် မှတ်တမ်းအမျိုးအစား နှစ်မျိုးရှိသည်- ၎င်းတို့၏ ဆာဗာများတွင် စီမံခန့်ခွဲသူများမှ စုဆောင်းထားသော မှတ်တမ်းများနှင့် ကုဒ်မှ ဆော့ဖ်ဝဲရေးသားသူများမှ ရေးသားသော မှတ်တမ်းများ။ ၎င်းတို့သည် မက်ထရစ်အမျိုးအစားနှစ်မျိုးနှင့် သက်ဆိုင်သည်- စနစ်နှင့်ထုတ်ကုန်.

စနစ်တိုင်းတာမှုများ

၎င်းသည် ကျွန်ုပ်တို့၏ ဆာဗာများအားလုံးတွင် အလုပ်လုပ်ပါသည်။ netdataစာရင်းဇယားများကို စုဆောင်းပြီး ၎င်းတို့ထံ ပေးပို့ပေးသော၊ Graphite ကာဗွန်. ထို့ကြောင့် ClickHouse ကို သိုလှောင်မှုစနစ်အဖြစ် အသုံးပြုသည်၊ ဥပမာ Whisper မဟုတ်ပါ။ လိုအပ်ပါက ClickHouse မှ တိုက်ရိုက်ဖတ်နိုင်သည် သို့မဟုတ် အသုံးပြုပါ။ Grafana မက်ထရစ်များ၊ ဂရပ်များနှင့် အစီရင်ခံစာများအတွက်။ ဆော့ဖ်ဝဲရေးသားသူများအနေဖြင့် ကျွန်ုပ်တို့သည် Netdata နှင့် Grafana သို့ လုံလောက်သောဝင်ရောက်ခွင့်ရှိသည်။

ထုတ်ကုန်မက်ထရစ်များ

အဆင်ပြေစေရန်အတွက်၊ ကျွန်ုပ်တို့သည် များစွာသောအကြောင်းအရာများကို ရေးသားခဲ့ပြီးဖြစ်သည်။ ဥပမာအားဖြင့်၊ သင့်အား ကိန်းဂဏန်းများ၊ UniqueCounts တန်ဖိုးများကို စာရင်းအင်းများအဖြစ် ရေးနိုင်စေမည့် သာမန်လုပ်ဆောင်မှုအစုတစ်ခု ရှိပါသည်။

statlogsCountEvent   ( ‘stat_name’,            $key1, $key2, …)
statlogsUniqueCount ( ‘stat_name’, $uid,    $key1, $key2, …)
statlogsValuetEvent  ( ‘stat_name’, $value, $key1, $key2, …)

$stats = statlogsStatData($params)

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

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

ဤမက်ထရစ်များကိုရေးရန် ကျွန်ုပ်တို့တွင် လုပ်ဆောင်ချက်များရှိသည်။ local memcache သို့ဝင်ခွင့်အရေအတွက်ကို လျှော့ချရန်။ အချိန်တိုအတွင်း ပြည်တွင်း၌ တစ်ကြိမ်သာ ထွက်ရှိသည်။ ကိန်းဂဏန်းများ- daemon မှတ်တမ်းအားလုံးကို စုဆောင်းသည်။ ထို့နောက် နတ်ဆိုးသည် မက်ထရစ်များကို ဆာဗာအလွှာနှစ်ခုသို့ ပေါင်းထည့်သည်။ မှတ်တမ်းစုဆောင်းသူများ၎င်းတို့နောက်ကွယ်ရှိ အလွှာမသေစေရန် ကျွန်ုပ်တို့၏ စက်များစွာမှ စာရင်းအင်းများကို စုစည်းပေးသည်။

လိုအပ်ပါက မှတ်တမ်းစုဆောင်းသူများထံ တိုက်ရိုက်စာရေးနိုင်ပါသည်။

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

ထို့နောက်၊ မှတ်တမ်းစုဆောင်းသူများသည် စာရင်းအင်းများထဲသို့ ပေါင်းထည့်ပါ။ meowDB - ဤသည်မှာ ကျွန်ုပ်တို့၏ဒေတာဘေ့စ်ဖြစ်ပြီး၊ မက်ထရစ်များကို သိမ်းဆည်းနိုင်သည်။

ထို့နောက် ကျွန်ုပ်တို့သည် ကုဒ်မှ binary “near-SQL” ရွေးချယ်မှုများကို ပြုလုပ်နိုင်သည်။

စမ်းသပ်မှု

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

KittenHouse မှတဆင့် မှတ်တမ်းများရေးသားသည့် အစီအစဉ်တစ်ခုရှိသည်။

ငါတို့ဆုံးဖြတ်ခဲ့တယ်။ ပုံတွင် အခြားသော “*House” ကို ထည့်ပါ။ကျွန်ုပ်တို့၏ကုဒ်သည် UDP မှတစ်ဆင့် ၎င်းတို့ကို ရေးပေးသောကြောင့် ဖော်မတ်ရှိ မက်ထရစ်များကို အတိအကျလက်ခံရရှိမည်ဖြစ်သည်။ ထို့နောက် ဤအိမ်သည် ၎င်းတို့ကို KittenHouse နားလည်သော သစ်လုံးများကဲ့သို့ ထည့်သွင်းပေးသည်။ သူသည် ဤမှတ်တမ်းများကို ClickHouse သို့ စုံလင်စွာပေးပို့နိုင်ပြီး ၎င်းတို့ကိုဖတ်ရှုနိုင်သင့်သည်။

memcache၊ stats-daemon နှင့် logs-collectors ဒေတာဘေ့စ်ပါသော အစီအစဉ်ကို ဤတစ်ခုနှင့် အစားထိုးထားသည်။

memcache၊ stats-daemon နှင့် logs-collectors ဒေတာဘေ့စ်ပါသော အစီအစဉ်ကို ဤတစ်ခုနှင့် အစားထိုးထားသည်။

• StatsHouse တွင် ပြည်တွင်း၌ ရေးသားထားသည့် ကုဒ်မှ ပေးပို့မှုတစ်ခု ရှိပါသည်။
• StatsHouse သည် UDP မက်ထရစ်များကို SQL ထည့်သွင်းမှုများအဖြစ် ပြောင်းလဲပြီးဖြစ်သော KittenHouse သို့ အတွဲလိုက်ဖြင့် ရေးသားသည်။
• KittenHouse သည် ၎င်းတို့ကို ClickHouse သို့ ပို့ပေးသည်။
• ၎င်းတို့ကိုဖတ်လိုပါက၊ ပုံမှန် SQL ကိုသုံး၍ ClickHouse မှ တိုက်ရိုက် StatsHouse ကိုကျော်ဖြတ်၍ ၎င်းတို့ကိုဖတ်ပါသည်။

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

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

ချထားပေးပါ။

အရင်ဆုံး PHP deployment ကို ကြည့်ရအောင်။ ကျွန်တော်တို့ ဖွံ့ဖြိုးတိုးတက်နေပါတယ်။ git: သုံးပါ။ GitLab и TeamCity ဖြန့်ကျက်မှုအတွက်။ ဖွံ့ဖြိုးတိုးတက်ရေးအကိုင်းအခက်များကို ပင်မအကိုင်းအခက်အဖြစ် ပေါင်းစည်းကာ စမ်းသပ်ရန်အတွက် မာစတာမှ ၎င်းတို့ကို အဆင့်လိုက်အဖြစ်သို့ ပေါင်းစည်းကာ ထုတ်လုပ်မှုအဆင့်အထိ ပေါင်းစပ်ထားသည်။

ဖြန့်ကျက်ခြင်းမပြုမီ၊ လက်ရှိထုတ်လုပ်ရေးဌာနခွဲနှင့် ယခင်တစ်ခုအား သိမ်းယူပြီး၊ ၎င်းတို့တွင် ကွဲပြားသောဖိုင်များကို ထည့်သွင်းစဉ်းစားသည် - အပြောင်းအလဲများ- ဖန်တီးသည်၊ ဖျက်သည်၊ ပြောင်းလဲသည်။ ဤပြောင်းလဲမှုသည် ကျွန်ုပ်တို့၏ဆာဗာတစ်ခုလုံးသို့ ပြောင်းလဲမှုများကို လျင်မြန်စွာပုံတူပွားနိုင်သည့် အထူး copyfast အင်ဂျင်၏ binlog တွင် မှတ်တမ်းတင်ထားသည်။ ဤနေရာတွင်အသုံးပြုသောအရာသည် တိုက်ရိုက်ကူးယူခြင်းမဟုတ်ပေ။ အတင်းအဖျင်းပုံတူဆာဗာတစ်ခုသည် ၎င်း၏အနီးဆုံးအိမ်နီးချင်းများသို့ ပြောင်းလဲမှုများ၊ ၎င်းတို့၏အိမ်နီးနားချင်းများသို့ စသည်တို့ကို ပေးပို့သည့်အခါ၊ ၎င်းသည် သင်္ဘောတစ်ခုလုံးရှိ ကုဒ်ကို ဆယ်ဂဏန်းနှင့် ယူနစ်များအတွင်း အပ်ဒိတ်လုပ်ခွင့်ပြုသည်။ ပြောင်းလဲမှုတစ်ခုသည် ဒေသဆိုင်ရာပုံစံတူသို့ရောက်ရှိသောအခါ၊ ၎င်းသည် ဤပြင်ဆင်ဖာထေးမှုများကို ၎င်း၏တွင်အသုံးပြုသည်။ ဒေသတွင်းဖိုင်စနစ်. Rollback ကိုလည်း အလားတူအစီအစဥ်အတိုင်း ဆောင်ရွက်ပါသည်။

ကျွန်ုပ်တို့သည်လည်း kPHP အများအပြားကို အသုံးပြုထားပြီး ၎င်းတွင် ၎င်း၏ကိုယ်ပိုင် ဖွံ့ဖြိုးတိုးတက်မှုလည်း ရှိသည်။ git အပေါ်က ပုံကြမ်းအတိုင်း။ ဒီကတည်းက HTTP ဆာဗာ binaryထို့နောက် ကျွန်ုပ်တို့သည် ကွဲပြားမှုကို မထုတ်လုပ်နိုင်ပါ - ထုတ်ဝေမှု binary သည် MB ရာပေါင်းများစွာ အလေးချိန်ရှိသည်။ ထို့ကြောင့်၊ ဤနေရာတွင် အခြားရွေးချယ်စရာတစ်ခုရှိသည် - ဗားရှင်းကို ရေးသားထားသည်။ binlog copyfast. တည်ဆောက်မှုတစ်ခုစီသည် တိုးလာသည်နှင့်အမျှ ပြန်လှည့်လာချိန်တွင်လည်း တိုးလာသည်။ ဗားရှင်း ဆာဗာများသို့ ပုံတူကူးထားသည်။. Local copyfasts များသည် binlog ထဲသို့ ဗားရှင်းအသစ်တစ်ခု ဝင်ရောက်လာသည်ကိုတွေ့မြင်ရပြီး တူညီသော အတင်းအဖျင်းပုံတူကူးချခြင်းဖြင့် ၎င်းတို့သည် ကျွန်ုပ်တို့၏မာစတာဆာဗာကို မပင်ပန်းစေဘဲ ၎င်းတို့၏မာစတာဆာဗာကို မပင်ပန်းစေဘဲ ၎င်းတို့အတွက် နောက်ဆုံးပေါ် binary ဗားရှင်းကို ယူဆောင်သွားကာ ကွန်ရက်တစ်ခုလုံးကို ဂရုတစိုက်ဖြန့်ပေးသည်။ ဘာတွေပါလဲ။ လှပသော ပြန်လည်စတင်ခြင်း ဗားရှင်းအသစ်အတွက်။

အခြေခံအားဖြင့် binaries ဖြစ်သည့် ကျွန်ုပ်တို့၏အင်ဂျင်များအတွက်၊ အစီအစဉ်သည် အလွန်ဆင်တူသည်-

• git မာစတာဌာနခွဲ;
• binary အတွက် deb;
• ဗားရှင်းကို binlog copyfast တွင် ရေးသားထားသည်။
• ဆာဗာများသို့ ပုံတူကူးထားသည်။
• ဆာဗာသည် လတ်ဆတ်သော .dep;
• dpkg -i;
• လှပသော ဗားရှင်းအသစ်သို့ ပြန်လည်စတင်ပါ။

ကွာခြားချက်မှာ ကျွန်ုပ်တို့၏ ဒွိစုံကို မော်ကွန်းတိုက်တွင် ထုပ်ပိုးထားခြင်းဖြစ်သည်။ debပြီးမှ ချပေးတဲ့အခါ သူတို့က ထုတ်တာ။ dpkg -i စနစ်ပေါ်တွင်ထားရှိကြသည်။ kPHP ကို ​​binary အဖြစ် အဘယ်ကြောင့် အသုံးချရသနည်း၊ အင်ဂျင်များကို dpkg အဖြစ် ဖြန့်ကျက်ထားသည်။ အဲဒီလိုဖြစ်သွားတာ။ အလုပ်ဖြစ်တယ် - အဲဒါကို မထိနဲ့။

အသုံးဝင်သော link များ -

• Anton Kiryushkin မှတင်ပြသည်။ "Vkontakte စနစ်စီမံခန့်ခွဲသူ။ ဘယ်လိုလဲ?" copyfast နှင့် အတင်းအဖျင်းအကြောင်းအသေးစိတ်များ။
• Yuri Nasretdinov မှတင်ပြသည်။ "VK သည် သောင်းနှင့်ချီသော ဆာဗာများမှ ClickHouse ထဲသို့ ဒေတာကို ထည့်သွင်းပုံ".
• ငါ့အစီရင်ခံစာ "VKontakte နမူနာကို အသုံးပြု၍ ကြီးထွားလာသော ပရောဂျက်တစ်ခု၏ ဗိသုကာ"ဒါပေမယ့် ဖွံ့ဖြိုးတိုးတက်မှု ရှုထောင့်ကနေကြည့်ရင် Hardware မဟုတ်ဘူး။

Alexey Akulovich သည် ပရိုဂရမ်ကော်မတီ၏ တစ်စိတ်တစ်ပိုင်းအနေဖြင့် ကူညီဆောင်ရွက်ပေးသူဖြစ်သည်။ PHP ရုရှား မေလ 17 ရက်နေ့သည် မကြာသေးမီအချိန်များအတွင်း PHP developer များအတွက် အကြီးဆုံးပွဲဖြစ်လာမည်ဖြစ်သည်။ ငါတို့မှာ ဘယ်လောက်ကောင်းတဲ့ PC တစ်လုံး၊ ဘာလဲ၊ ကြည့်လိုက်စမ်း စပီ (သူတို့ထဲက နှစ်ယောက်က PHP core ကို တီထွင်နေပါတယ်။) - PHP ကို ​​သင်ရေးရင် သင်လက်လွတ်လို့မရတဲ့ အရာတစ်ခုပါ။

source: www.habr.com