Badoo တွင် ဓာတ်ပုံများ သိမ်းဆည်းခြင်းနှင့် မျှဝေခြင်းအတွက် ဗိသုကာပညာ

Artem Denisov ( bo0rsh201, Badoo)

Badoo သည် ကမ္ဘာ့အကြီးဆုံးချိန်းတွေ့သည့်ဆိုက်ဖြစ်သည်။ လက်ရှိတွင် ကျွန်ုပ်တို့သည် ကမ္ဘာတစ်ဝှမ်းတွင် စာရင်းသွင်းအသုံးပြုသူ သန်း 330 ခန့်ရှိသည်။ သို့သော် ယနေ့ကျွန်ုပ်တို့၏စကားဝိုင်းတွင် ပို၍အရေးကြီးသည်မှာ ကျွန်ုပ်တို့သည် သုံးစွဲသူဓာတ်ပုံများ၏ 3 petabytes ခန့်ကို သိမ်းဆည်းထားခြင်းဖြစ်သည်။ ကျွန်ုပ်တို့၏အသုံးပြုသူများသည် နေ့တိုင်း ဓာတ်ပုံအသစ် ၃.၅ သန်းခန့် အပ်လုဒ်လုပ်ကြပြီး စာဖတ်နှုန်းမှာ နီးပါးဖြစ်သည်။ တစ်စက္ကန့်လျှင် ၈၀,ဝဝဝ တောင်းဆိုသည်။. ၎င်းသည် ကျွန်ုပ်တို့၏ ကျောထောက်နောက်ခံအတွက် အလွန်များပြားပြီး တစ်ခါတစ်ရံတွင် ၎င်းအတွက် အခက်အခဲများရှိသည်။

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

ကဲ စလိုက်ကြရအောင်။

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

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

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

Badoo သည် သမိုင်းကြောင်းအရ - ယခုရော ထိုအချိန် (၎င်း၏ နို့စို့အရွယ်တွင်ရှိစဉ်) - ကျွန်ုပ်တို့၏ကိုယ်ပိုင် DC များအတွင်းတွင် ၎င်း၏ကိုယ်ပိုင်ဆာဗာများပေါ်တွင် နေထိုင်ပါသည်။ ထို့ကြောင့်၊ ဤရွေးချယ်မှုသည် ကျွန်ုပ်တို့အတွက် အကောင်းဆုံးဖြစ်သည်။

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

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

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

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

အဲဒါက ငါတို့အတွက် အချိန်အတော်ကြာခဲ့ပြီ။

ဒါက ၂၀၀၉ လောက်ကပါ။ ကားတွေ လာပို့ကြတယ်...

တစ်ချိန်ချိန်မှာတော့ ဒီအစီအစဉ်မှာ အားနည်းချက်အချို့ရှိနေတာကို သတိပြုမိလာတယ်။ အားနည်းချက်တွေက ဘာတွေလဲ။

ပထမအချက်မှာ အကန့်အသတ်ရှိသော စွမ်းရည်ရှိသည်။ ကျွန်ုပ်တို့ လိုချင်သလောက် ဟာ့ဒ်ဒရိုက်များ အများအပြားကို ရုပ်ပိုင်းဆိုင်ရာ ဆာဗာတစ်ခုပေါ်တွင် ကျွန်ုပ်တို့ အလိုရှိသလောက် စုစည်း၍ မရပါ။ ၎င်းသည် အချိန်ကြာလာသည်နှင့်အမျှ dataset ကြီးထွားလာသည်နှင့်အမျှ ၎င်းသည် အချို့သောပြဿနာတစ်ခုဖြစ်လာသည်။

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

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

နောက်ဆုံးအချက်ကတော့ ဈေးနှုန်းပါ။

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

အဆုံးမှာတော့ Storage Area Network လို့ခေါ်ပါတယ်။

၎င်းတို့သည် ဒေတာအများအပြားကို သိမ်းဆည်းရန်အတွက် အထူးဒီဇိုင်းထုတ်ထားသည့် ကြီးမားသော SHD များဖြစ်သည်။ ၎င်းတို့သည် နောက်ဆုံး optical output စက်များတွင် တပ်ဆင်ထားသော disk များပါရှိသော စင်များဖြစ်သည်။ အဲဒါ။ ကျွန်ုပ်တို့တွင် သေးငယ်သော စက်များရှိပြီး ကျွန်ုပ်တို့၏ ပေးပို့ခြင်းဆိုင်ရာ ယုတ္တိဗေဒအရ ပွင့်လင်းမြင်သာမှုရှိသော ဤ SHD များရှိသည်။ ကျွန်ုပ်တို့၏ nginx သို့မဟုတ် အခြားမည်သူမဆိုအတွက် ဤဓာတ်ပုံများအတွက် တောင်းဆိုချက်များကို ဆောင်ရွက်ပေးပါသည်။

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

ဒုတိယ အပေါင်း။

ဒါက စွမ်းရည်တွေ အများကြီး ပိုကြီးလာတယ်၊ i.e. ပိုမိုသေးငယ်သောပမာဏတွင် သိုလှောင်မှုပိုမိုထားရှိနိုင်ပါသည်။

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

ကျွန်ုပ်တို့၏ဓာတ်ပုံများကဲ့သို့ပင်၊ ဓာတ်ပုံများကို တသမတ်တည်းတောင်းဆိုထားသောကြောင့်၊ ၎င်းသည် ၎င်းတို့၏စွမ်းဆောင်ရည်ကို များစွာထိခိုက်စေပါသည်။

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

ပိုကောင်းအောင်လုပ်ဖို့၊ ဝန်ပရိုဖိုင်ကိုကြည့်ဖို့၊ ယေဘုယျအားဖြင့် ဘာတွေဖြစ်နေလဲ၊ အကောင်းဆုံးဖြစ်အောင်လုပ်ဖို့ လိုအပ်တယ်ဆိုတာကို အဲဒီတုန်းက ဆုံးဖြတ်ခဲ့တယ်။

ပြီးတော့ ဒီမှာ အရာအားလုံးက ငါတို့လက်ထဲကို ရောက်နေတယ်။

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

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

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

LRU ပါသော ကက်ရှ်တစ်ခုသည် ကျွန်ုပ်တို့၏ ပြဿနာအားလုံးကို ဖြေရှင်းပေးလိမ့်မည်။ ငါတို့ဘာလုပ်နေတာလဲ?

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

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

၎င်းသည် မြန်ဆန်သော ရုပ်ပိုင်းဆိုင်ရာ စက်တွင်းဒစ်ပါရှိသော စက်တစ်ခုသာဖြစ်သည်။ ဒါက ဥပမာ SSD နဲ့ပါ။ အချို့သော local cache များကို ဤ disk တွင် သိမ်းဆည်းထားသည်။

ဘယ်လိုပုံလဲ။ အသုံးပြုသူက ဓာတ်ပုံတစ်ပုံအတွက် တောင်းဆိုချက်တစ်ခု ပေးပို့သည်။ NGINX သည် ၎င်းကို local cache တွင် ဦးစွာရှာဖွေသည်။ မဟုတ်ပါက၊ ကျွန်ုပ်တို့၏သိုလှောင်ခန်းသို့ proxy_pass ၊ ဓာတ်ပုံကို ဒေါင်းလုဒ်လုပ်ပြီး အသုံးပြုသူအား ပေးလိုက်ပါ။

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

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

1. ဤသည်မှာ ပရောက်စီတစ်ခုမှ ဒေါင်းလုဒ်လုပ်ထားသည့် ဓာတ်ပုံများသွားနေသည့် ကြားခံတစ်ခုဖြစ်သည်။
2. ၎င်းသည် လက်ရှိတွင် တောင်းဆိုထားသော ဓာတ်ပုံများကို သိမ်းဆည်းပေးသည့် hot cache ဖြစ်သည်။
3. ၎င်းတို့ထံ တောင်းဆိုမှုနည်းပါးလာသောအခါ ပူသောကက်ရှ်မှ ဓာတ်ပုံများကို တဖြည်းဖြည်းတွန်းထုတ်သည့် အအေးခန်းတစ်ခု။

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

Nginx သည် တောင်းဆိုချက်တစ်ခုစီအတွက် RAMDisk access.log သို့ ရိုးရိုးရှင်းရှင်းရေးသားပြီး ၎င်းသည် လက်ရှိအသုံးပြုနေသော ဓာတ်ပုံဆီသို့ လမ်းကြောင်း (ဟုတ်ပါတယ် ဆွေမျိုးလမ်းကြောင်း) နှင့် မည်သည့်အပိုင်းကို လုပ်ဆောင်ခဲ့သည်ကို ဖော်ပြသည်။ အဲဒါတွေ။ ၎င်းသည် "ဓာတ်ပုံ 1" ဟုပြောနိုင်ပြီး ထို့နောက် ကြားခံတစ်ခု၊ သို့မဟုတ် ပူသောကက်ရှ် သို့မဟုတ် အအေးမိသောကက်ရှ် သို့မဟုတ် ပရောက်စီတစ်ခုဟု ဆိုနိုင်သည်။

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

ကျွန်ုပ်တို့တွင် ဤမှတ်တမ်းကို အဆက်မပြတ်ဖတ်ရှုပြီး ၎င်း၏မှတ်ဉာဏ်ထဲတွင် ဓာတ်ပုံအချို့အသုံးပြုမှုနှင့်ပတ်သက်သော စာရင်းအင်းများကို သိမ်းဆည်းထားသည့် စက်တစ်ခုစီတွင် သေးငယ်သော daemon တစ်ခုရှိသည်။

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

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

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

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

ကျန်မေးခွန်းမှာ ဤဆာဗာများတစ်လျှောက် တောင်းဆိုမှုများကို မည်ကဲ့သို့ ဖြန့်ဝေမည်နည်း။

သိုလှောင်မှုစက် အလုံးနှစ်ဆယ်နှင့် ကက်ရှ်ဆာဗာ သုံးခုပါရှိသည် (ဤသည်မှာ မည်သို့ပင်ဖြစ်လေသည်)။

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

အသုံးအများဆုံးရွေးချယ်မှုမှာ Round Robin ဖြစ်သည်။ ဒါမှမဟုတ် မတော်တဆ လုပ်တာလား။

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

မည်သည့်ဆာဗာကို တောင်းဆိုမည်ကို တစ်စုံတစ်ရာ ယောင်ဝါးဝါးဖြင့် ဆုံးဖြတ်ရန် လိုအပ်သည်။

တားမြစ်နည်းတစ်ခုရှိပါတယ်။ ကျွန်ုပ်တို့သည် URL မှ hash သို့မဟုတ် hash ကို URL တွင်ပါရှိသော ကျွန်ုပ်တို့၏ sharding key မှရယူပြီး ဆာဗာအရေအတွက်ဖြင့် ပိုင်းခြားပါ။ အလုပ်လုပ်မှာလား? ပေးမည်။

အဲဒါတွေ။ ကျွန်ုပ်တို့တွင် 2% တောင်းဆိုချက်တစ်ခုရှိသည်၊ ဥပမာ၊ အချို့သော “example_url” အတွက် ၎င်းသည် အညွှန်း “XNUMX” ဖြင့် ဆာဗာပေါ်တွင် အမြဲတမ်းရောက်ရှိနေမည်ဖြစ်ပြီး၊ ကက်ရှ်ကို အတတ်နိုင်ဆုံး အဆက်မပြတ်ဖယ်ရှားသွားမည်ဖြစ်သည်။

သို့သော် ထိုသို့သောအစီအစဉ်တွင် ပြန်လည်ထည့်သွင်းခြင်းတွင် ပြဿနာတစ်ခုရှိသည်။ ပြန်လည်မျှဝေခြင်း - ကျွန်ုပ်ဆိုလိုသည်မှာ ဆာဗာအရေအတွက်ကို ပြောင်းလဲခြင်းဖြစ်သည်။

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

ထည့်ကြည့်ရအောင်။

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

ဤရွေးချယ်မှုသည် ကျွန်ုပ်တို့နှင့်လည်း မကိုက်ညီပါ။

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

ဘယ်လိုကြည့်ရှုသနည်း?

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

ဆာဗာတစ်ခုစီကို အချက်တစ်ခုတည်းဖြင့် သတ်မှတ်ပြီး ၎င်းနှင့်လျော်ညီစွာ နာရီလက်တံအတိုင်းသွားသည့်ကဏ္ဍကို ဤအိမ်ရှင်မှ ဆောင်ရွက်ပေးပါသည်။ ကျွန်ုပ်တို့ထံ တောင်းဆိုမှုများလာသောအခါ၊ ဥပမာ၊ တောင်းဆိုချက် A - ၎င်းတွင် hash ပါရှိသည် - ၎င်းကို ဆာဗာ 2 မှ ဆောင်ရွက်ပေးပါသည်။ Request B - ဆာဗာ 3 မှ တောင်းဆိုပါသည်။ အစရှိသည်ဖြင့်။

ပြန်လည်မျှဝေစဉ်တွင် ဤအခြေအနေတွင် ဘာဖြစ်သွားသနည်း။

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

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

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

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

ဒါက caching စနစ်အကြောင်းပါ။ ရလဒ်တွေကို ကြည့်ရအောင်။

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

ကျွန်ုပ်တို့သည် ဤဆာဗာများကို ကျွန်ုပ်တို့၏ DC သုံးခုတွင် ထားရှိခဲ့ပြီး ပရာ့ဂ်၊ မိုင်ယာမီနှင့် ဟောင်ကောင်တို့တွင် တည်ရှိမှုသုံးမှတ်ကို ရရှိခဲ့သည်။

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

ပြီးတော့ ကောင်းမွန်တဲ့ အပိုဆုတစ်ခုအနေနဲ့၊ အကြောင်းအရာကို ဆောင်ရွက်ပေးဖို့ သိပ်မလိုအပ်တာကြောင့် CPU ဟာ တကယ်ကို ဘာမှမလုပ်ဘဲ ဒီ caching proxy ကို ရရှိခဲ့ပါတယ်။ ထိုနေရာတွင် NGINX+ Lua ကိုအသုံးပြု၍ ကျွန်ုပ်တို့သည် အသုံးဝင်သောယုတ္တိများစွာကို အကောင်အထည်ဖော်ခဲ့သည်။

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

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

စကားမစပ်၊ ကျွန်ုပ်တို့သည် high-load စနစ်များကို developer များ၏ ကွန်ဖရင့်၏ နောက်ဆုံးငါးနှစ်အတွင်း လူသိရှင်ကြားရရှိနိုင်သော ဗီဒီယိုမှတ်တမ်းများကို ပြုလုပ်ထားပါသည်။ HighLoad++. ကြည့်ရှုပါ၊ လေ့လာပါ၊ မျှဝေပါ၊ စာရင်းသွင်းပါ။ ယူကျု့ချန်နယ်.

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

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

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

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

ပထမအချက်က ဓာတ်ပုံတွေပါ။

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

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

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

ပြီး​တော့ အရင်​တစ်​ခုက​နေ ​အောက်​ပါအချက်​​တွေပါ။

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

ဤအချက်က အဘယ်အရာကို အကြံပြုသနည်း။ ကျွန်ုပ်တို့၏အခြေအနေတွင် CDN သည် အလွန်ကောင်းမွန်သောရွေးချယ်မှုမဟုတ်ပါ။

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

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

ပြီးတော့ ခေတ်မီ CDN တွေမှာ အခုငါပြောထားတဲ့အရာအားလုံးနီးပါးရှိတယ်။ အပေါင်း သို့မဟုတ် အနုတ်လက္ခဏာအချို့မှလွဲ၍

ဒါက ဓါတ်ပုံတွေ ပေးရတဲ့ အကြောင်းပါ။

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

2013 က ဆုံးသွားတာ။

ကက်ရှ်ဆာဗာများကို ထည့်လိုက်သည်၊ စွမ်းဆောင်ရည်ပြဿနာများ ပျောက်သွားပါသည်။ အားလုံးအဆင်ပြေတယ်။ Dataset ကြီးထွားလာသည်။ 2013 ခုနှစ်အထိ၊ ကျွန်ုပ်တို့တွင် သိုလှောင်မှုသို့ ချိတ်ဆက်ထားသော ဆာဗာ 80 ခန့်နှင့် DC တစ်ခုစီတွင် caching 40 ခန့်ရှိသည်။ ၎င်းသည် DC တစ်ခုစီရှိ ဒေတာ 560 terabytes ဖြစ်သည်၊ ဆိုလိုသည်မှာ၊ စုစုပေါင်း petabyte ခန့်။

dataset တိုးတက်မှုနှင့်အတူ၊ လည်ပတ်မှုကုန်ကျစရိတ်များ သိသိသာသာမြင့်တက်လာသည်။ ဒါက ဘာကို ဆိုလိုတာလဲ။

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

ပထမဦးစွာ Storage Area Network (SAN) ကိုယ်တိုင်က ကျရှုံးနိုင်ပါတယ်။

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

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

နောက်တစ်ခုကတော့ Storage နဲ့ ချိတ်ဆက်ထားတဲ့ စက်ကိုယ်တိုင်ပါပဲ။ ပျက်သွားနိုင်သည်။

စုစုပေါင်း ရှုံးပွဲသုံးမှတ် ရှိတယ်။

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

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

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

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

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

ဤသည်မှာ ကျွန်ုပ်တို့၏ဆာဗာကို ယခင်က သိုလှောင်ခန်းသို့ ချိတ်ဆက်ထားသောအခါတွင် မည်ကဲ့သို့ပင်ဖြစ်သနည်း။ ဤသည်မှာ အဓိကကဏ္ဍတစ်ခုဖြစ်သည်၊ ၎င်းသည် optics မှတစ်ဆင့် အဝေးထိန်းသိုလှောင်မှုအတွက် mount တစ်ခုကို ကိုယ်စားပြုသည့် ပိတ်ဆို့ကိရိယာတစ်ခုမျှသာဖြစ်သည်။

ကျွန်တော်တို့က ဒုတိယအပိုင်းကို ထပ်ထည့်လိုက်ပါတယ်။

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

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

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

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

ဒါ​ပေမယ့်​ အဲ့ဒါ​ကြောင့်​ စာဖတ်​ချိန်​က အရမ်းတိုး​နေလို့... ပင်မကဏ္ဍမှဖတ်ရှုသောဖောက်သည်များအပြင်၊ အဲဒီမှာဓာတ်ပုံကိုအရင်ကြည့်တဲ့အတွက် (အဲဒါကပိုပြီးမကြာသေးပါဘူး)၊ ပြီးတော့အဲဒါကိုရှာမတွေ့ဘူးဆိုရင်၊ Backup မှာရှာပါ (ဒါပေမယ့် NGINX ကဒီလိုလုပ်တာပါပဲ)၊ ကျွန်ုပ်တို့၏စနစ်သည် ပင်မအခန်းကန့်မှ ယခုဖတ်နေသည့် အပေါင်းအရန်တစ်ခုလည်းဖြစ်သည်။ ဒါက တစ်ဆို့နေတာကြောင့် မဟုတ်ဘူး၊ ဒါပေမယ့် ဝန်ကို တိုးမပေးချင်ခဲ့ဘူး၊ အခြေခံအားဖြင့်တော့ အဲဒီအတိုင်းပါပဲ။

သေးငယ်သော SSD ဖြစ်သည့် တတိယဒစ်ကို ကျွန်ုပ်တို့ ပေါင်းထည့်ကာ ၎င်းအား ကြားခံဟု ခေါ်သည်။

အခု ဘယ်လိုအလုပ်လုပ်လဲ။

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

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

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

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

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

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

ပြီးတော့ တတိယဗားရှင်း (တကယ်တော့ ဒုတိယဗားရှင်း) - ကြိုတင်မှာယူမှုဗားရှင်းကို ကျွန်တော်တို့ လုပ်ခဲ့ပါတယ်။ ဘယ်လိုပုံစံလဲ။

ဒါက-

ကျွန်ုပ်တို့၏အဓိကပြဿနာမှာ ဤအရာသည် ရုပ်ပိုင်းဆိုင်ရာအိမ်ရှင်ဖြစ်သည်ဟူသောအချက်ကြောင့်ဖြစ်သည်။

ပထမဦးစွာ၊ ကျွန်ုပ်တို့သည် စမ်းသပ်လိုသောကြောင့်၊ ကျွန်ုပ်တို့သည် local hard drives များကိုသာ စမ်းကြည့်ချင်သောကြောင့် SAN များကို ဖယ်ရှားနေပါသည်။

ဤသည်မှာ 2014-2015 ဖြစ်နေပြီဖြစ်ပြီး ထိုအချိန်တွင် disk များနှင့် host တစ်ခုတည်းတွင် ၎င်းတို့၏စွမ်းရည်များ ပိုမို ကောင်းမွန်လာသည်။ ဘာကြောင့် မကြိုးစားရဘူးလို့ ဆုံးဖြတ်ထားလဲ။

ထို့နောက် ကျွန်ုပ်တို့သည် ကျွန်ုပ်တို့၏ backup partition ကို ရိုးရိုးရှင်းရှင်းယူ၍ သီးခြားစက်သို့ လွှဲပြောင်းပေးပါသည်။

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

ဘာ့ကြောင့်ကောင်းလဲဆိုတော့ ကျွန်တော်တို့မှာ မှတ်တမ်းအနည်းငယ်ရှိလို့ပါပဲ။ အဲဒါတွေ။ စာအရေးအသားသည် စာဖတ်ခြင်းနှင့် ယှဉ်ပါက၊ ကျွန်ုပ်တို့တွင် ကွန်ရက်ပေါ်မှ ပြဿနာများနှင့် ပြဿနာအချို့ ရှိကောင်းရှိပေမည်။ စာရေးနည်း၊ စာဖတ်တာများတယ် - ဒီနည်းလမ်းက ကောင်းကောင်းအလုပ်လုပ်တယ်၊ i.e. ဤဆာဗာနှစ်ခုကြားရှိ ဓာတ်ပုံများကို ကျွန်ုပ်တို့ ကူးယူခဲပါသည်။

အသေးစိတ်ကို နည်းနည်းလောက်ကြည့်မယ်ဆိုရင် ဒီအလုပ်က ဘယ်လိုလဲ။

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

အလုပ်က နည်းနည်းပိုခက်တယ်။

Lua သည် vanilla NGINX တွင် ထိုသို့သောယုတ္တိဗေဒပြုလုပ်ရန် ခက်ခဲနိုင်သောကြောင့်၊ ကျွန်ုပ်တို့သည် ပထမဆာဗာထံ တောင်းဆိုချက်တစ်ခုပြုလုပ်သည်၊ အကြောင်းမှာ ဓာတ်ပုံရှိမရှိကိုကြည့်ပါ၊ ဥပမာ၊ အိမ်နီးချင်းတစ်ဦးထံ အပ်လုဒ်လုပ်ထားနိုင်သော်လည်း ဤနေရာသို့ မရောက်သေးပါ။ ဓာတ်ပုံရှိရင် ကောင်းတယ်။ ကျွန်ုပ်တို့သည် ၎င်းကို ဖောက်သည်အား ချက်ချင်းပေး၍ ဖြစ်နိုင်ပါက ကက်ရှ်လုပ်ပါ။

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

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

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

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

ဒါဆို တကယ်ကို မိုက်တာ ငါတို့ ဘာရှိသေးလဲ။

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

ယခု ကျွန်ုပ်တို့သည် စက်နှစ်လုံးမှ တစ်ပြိုင်နက် စာဖတ်ခြင်းကို အသုံးပြုသည်။ Round Robin ကို အသုံးပြု၍ တောင်းဆိုမှုများကို ဖြန့်ဝေပါသည်။ ရာခိုင်နှုန်းအနည်းငယ်တွင် ကျွန်ုပ်တို့သည် တောင်းဆိုမှုနှစ်ခုပြုလုပ်သည်။ သို့သော် ခြုံငုံကြည့်လျှင် ကျွန်ုပ်တို့သည် ယခင်ကထက်စာဖတ်ခြင်းစတော့ (၂)ဆပိုများသည်။ ပြီးတော့ ပို့တဲ့စက်တွေမှာရော အဲဒီတုန်းက ကျွန်တော်တို့မှာပါရှိတဲ့ သိုလှောင်စက်တွေပေါ်မှာရော ဝန်အား အလွန်အမင်းလျော့သွားတယ်။

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

ကားတစ်စီး ပျက်သွားတယ်။

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

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

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

ဤအထပ်ထပ်အစီအစဥ်မှ မည်သို့ကောက်ချက်ချနိုင်မည်နည်း။

ကျွန်ုပ်တို့သည် အမှားခံနိုင်ရည်ရှိသည်။

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

ကျွန်ုပ်တို့သည် နှစ်ဆစာဖတ်ခွင့်ကို ရရှိခဲ့ပါသည်။

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

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

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

ဤနေရာတွင် ပဋိပက္ခအချို့ ဖြစ်ပေါ်လာပြန်သည်။

local hard drive တွေမှာ အားလုံးကို သိမ်းတာ မကောင်းဘူးလို့ အစမှာ ပြောခဲ့တယ်။ အခု ကျွန်တော် သဘောကျတယ်လို့ ပြောလိုက်တယ်။

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

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

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

ဒါပေမယ့် အားနည်းချက်တွေလည်း ရှိပါတယ်။

၎င်းသည် ယနေ့ခေတ်စျေးနှုန်းများတွင်ပင် SANs အသုံးပြုခြင်းထက် 1,5 ဆ ပိုမိုစျေးကြီးသည်။ ထို့ကြောင့်၊ ကျွန်ုပ်တို့သည် ကျွန်ုပ်တို့၏ကြီးမားသောအစုအဝေးတစ်ခုလုံးကို ဒေသတွင်း hard drives များဖြင့် ကားများအဖြစ်သို့ ရဲရဲဝံ့ဝံ့မပြောင်းရန် ဆုံးဖြတ်ပြီး ဟိုက်ဘရစ်ဖြေရှင်းချက်တစ်ခုကို ထားခဲ့ရန် ဆုံးဖြတ်ခဲ့သည်။

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

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

ပြီးမြောက်ခဲ့တာတွေ၊ ဘာအတွက် တိုက်ပွဲဝင်ခဲ့သလဲ၊ အောင်မြင်သလားဆိုတာကို အကျဉ်းချုပ်ကြည့်ရအောင်။

ရလဒ်များကို

ကျွန်ုပ်တို့တွင် သုံးစွဲသူ ၃၃ သန်းရှိသည်။

ကျွန်ုပ်တို့တွင် ပရာ့ဂ်၊ မိုင်ယာမီ၊ ဟောင်ကောင်တို့၌ ရှိနေသည့် သုံးမှတ်ရှိသည်။

၎င်းတို့တွင် NGINX မှ ရိုးရှင်းသော စက်ယန္တရားများ၊ ၎င်း၏ access.log နှင့် Python daemons လည်ပတ်သည့် မြန်ဆန်သော local disks (SSDs) များပါရှိသော ကက်ရှ်အလွှာတစ်ခုပါရှိသည်။

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

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

ထို့အပြင်၊ အချို့သောစက်များသည် local hard drive များနှင့်အလုပ်လုပ်သည်။

ဤစက်အချို့ကို SAN နှင့် ချိတ်ဆက်ထားသည်။

တစ်ဖက်တွင်၊ ၎င်းသည် အသုံးပြုရပိုအဆင်ပြေပြီး အနည်းငယ်ပို၍ ဖြစ်ထွန်းသည်၊ အခြားတစ်ဖက်တွင်၊ နေရာချထားမှုသိပ်သည်းမှုနှင့် gigabyte တစ်ခုလျှင် ဈေးနှုန်းအရ အဆင်ပြေသည်။

ဤသည်မှာ ကျွန်ုပ်တို့ရရှိသည့်အရာများ၏ ဗိသုကာပညာ၏ အကျဉ်းချုပ်ဖြစ်ပြီး ၎င်းသည် မည်သို့မည်ပုံ ဖွံ့ဖြိုးတိုးတက်လာသနည်း။

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

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

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

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

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

အရင်ဆုံး တိုင်းတာပြီးတော့ ပိုမိုကောင်းမွန်အောင် လုပ်တယ်။

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

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

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

နောက်တစ်ခုအချက်။ ပျံသန်းမှုတွင်အရွယ်အစားပြောင်းခြင်းအကြောင်း။

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

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

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

နှင့် တိုးမြင့်သော အပြိုင်အဆိုင် အရန်သိမ်းခြင်းသည် ကောင်းမွန်သည်။

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

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

အဆက်အသွယ်

» bo0rsh201
» Badoo Blog

ဤအစီရင်ခံစာသည် high-load စနစ်များကို developer များ၏ကွန်ဖရင့်တွင်အကောင်းဆုံးမိန့်ခွန်းများထဲမှတစ်ခုဖြစ်သည်။ HighLoad++. HighLoad++ 2017 ကွန်ဖရင့်အထိ တစ်လမပြည့်သေးပါ။

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

ယခုနှစ်တွင် ကျွန်ုပ်တို့သည် ဗိသုကာပညာနှင့် အတိုင်းအတာ၏ ခေါင်းစဉ်ကို ဆက်လက်လေ့လာမည်

• သုံးစွဲသူတစ်ဘီလီယံကို ဝန်ဆောင်မှုပေးပြီး လမ်းကြောင်းအသွားအလာကို အတိုင်းအတာတစ်ခုအထိ ပံ့ပိုးပေးနိုင်ပုံ / Igor Vasiliev
• VKontakte ကိုယ်ရေးကိုယ်တာမက်ဆေ့ချ်များဒေတာဘေ့စ်ကို အစမှပြန်ရေးပြီး အချိန်မဆွဲဘဲ ၎င်းသို့ ပြောင်းရွှေ့နည်း / Dmitry Egorov
• ရောင်းချခြင်းဖြင့် သေဆုံးခြင်း- Yandex.Money သည် Black Friday သို့ အရှိန်မြှင့်ပြီး ရှင်သန်ရန် ကြိုးစားပုံ / Anatoly Plaskovsky
• ဘဏ်၏ ရှေ့ဆုံးစနစ်၏ အမှား-ခံနိုင်ရည်ရှိသော တည်ဆောက်မှု / Roman Shekhovtsov, Alexey Gromatchikov
• ငွေပေးချေမှုစနစ်တည်ဆောက်ပုံ- လုပ်ငန်းနီးပါး / Philip Delgado

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

source: www.habr.com