പല സ്റ്റാർട്ടപ്പുകളും ഇതിലൂടെ കടന്നുപോയി: പുതിയ ഉപയോക്താക്കളുടെ ജനക്കൂട്ടം എല്ലാ ദിവസവും രജിസ്റ്റർ ചെയ്യുന്നു, കൂടാതെ സേവനം പ്രവർത്തിപ്പിക്കാൻ വികസന ടീം പാടുപെടുന്നു.

ഇത് ഒരു നല്ല പ്രശ്‌നമാണ്, എന്നാൽ ഒരു വെബ് ആപ്ലിക്കേഷൻ എങ്ങനെ ശ്രദ്ധാപൂർവ്വം സ്കെയിൽ ചെയ്യാം എന്നതിനെക്കുറിച്ച് വെബിൽ വ്യക്തമായ വിവരങ്ങൾ ഇല്ല. സാധാരണഗതിയിൽ ഒന്നുകിൽ അഗ്നി പരിഹാരങ്ങൾ അല്ലെങ്കിൽ തടസ്സ പരിഹാരങ്ങൾ (പലപ്പോഴും രണ്ടും) ഉണ്ട്. അതിനാൽ, ആളുകൾ അവരുടെ അമേച്വർ പ്രോജക്റ്റിനെ ശരിക്കും ഗൗരവമുള്ള ഒന്നിലേക്ക് സ്കെയിൽ ചെയ്യാൻ പകരം ക്ലിക്ക് ടെക്നിക്കുകൾ ഉപയോഗിക്കുന്നു.

വിവരങ്ങൾ ഫിൽട്ടർ ചെയ്യാനും അടിസ്ഥാന ഫോർമുല എഴുതാനും ശ്രമിക്കാം. ഞങ്ങളുടെ പുതിയ ഫോട്ടോ പങ്കിടൽ സൈറ്റ് ഗ്രാമിൻസ്റ്റയെ 1 മുതൽ 100 ഉപയോക്താക്കളിലേക്ക് ഘട്ടം ഘട്ടമായി സ്കെയിൽ ചെയ്യാൻ ഞങ്ങൾ പോകുന്നു.

പ്രേക്ഷകർ 10, 100, 1000, 10, 000 എന്നിങ്ങനെ വർധിക്കുമ്പോൾ എന്തെല്ലാം പ്രത്യേക പ്രവർത്തനങ്ങൾ നടത്തണം എന്ന് എഴുതാം.

1 ഉപയോക്താവ്: 1 മെഷീൻ

മിക്കവാറും എല്ലാ ആപ്ലിക്കേഷനും, അത് ഒരു വെബ്‌സൈറ്റോ മൊബൈൽ ആപ്ലിക്കേഷനോ ആകട്ടെ, മൂന്ന് പ്രധാന ഘടകങ്ങൾ ഉണ്ട്:

• എപിഐ
• ഒരു ഡാറ്റാബേസ്
• ക്ലയന്റ് (മൊബൈൽ ആപ്ലിക്കേഷൻ തന്നെ അല്ലെങ്കിൽ വെബ്സൈറ്റ്)

ഡാറ്റാബേസ് സ്ഥിരമായ ഡാറ്റ സംഭരിക്കുന്നു. ഈ ഡാറ്റയിലേക്കും ചുറ്റുമുള്ള അഭ്യർത്ഥനകളും API നൽകുന്നു. ക്ലയന്റ് ഉപയോക്താവിന് ഡാറ്റ കൈമാറുന്നു.

ഒരു വാസ്തുവിദ്യാ വീക്ഷണകോണിൽ നിന്ന്, ക്ലയന്റും API എന്റിറ്റികളും പൂർണ്ണമായും വേർതിരിക്കുകയാണെങ്കിൽ, ഒരു ആപ്ലിക്കേഷൻ സ്കെയിൽ ചെയ്യുന്നതിനെക്കുറിച്ച് സംസാരിക്കുന്നത് വളരെ എളുപ്പമാണെന്ന് ഞാൻ നിഗമനത്തിലെത്തി.

ഞങ്ങൾ ആദ്യം ഒരു ആപ്ലിക്കേഷൻ നിർമ്മിക്കാൻ തുടങ്ങുമ്പോൾ, മൂന്ന് ഘടകങ്ങളും ഒരേ സെർവറിൽ പ്രവർത്തിപ്പിക്കാൻ കഴിയും. ചില തരത്തിൽ, ഇത് ഞങ്ങളുടെ വികസന പരിതസ്ഥിതിക്ക് സമാനമാണ്: ഒരു എഞ്ചിനീയർ ഡാറ്റാബേസ്, API, ക്ലയന്റ് എന്നിവ ഒരേ മെഷീനിൽ പ്രവർത്തിപ്പിക്കുന്നു.

സിദ്ധാന്തത്തിൽ, താഴെ കാണിച്ചിരിക്കുന്നതുപോലെ, ഒരു ഡിജിറ്റൽ ഓഷ്യൻ ഡ്രോപ്ലെറ്റിലോ AWS EC2 സന്ദർഭത്തിലോ നമുക്ക് അത് ക്ലൗഡിൽ വിന്യസിക്കാം:

അതോടൊപ്പം, ഒരു സൈറ്റിൽ ഒന്നിലധികം ഉപയോക്താക്കൾ ഉണ്ടെങ്കിൽ, ഒരു ഡാറ്റാബേസ് ലെയർ സമർപ്പിക്കുന്നത് മിക്കവാറും അർത്ഥമാക്കുന്നു.

10 ഉപയോക്താക്കൾ: ഡാറ്റാബേസ് ഒരു പ്രത്യേക തലത്തിലേക്ക് നീക്കുന്നു

ആമസോൺ ആർ‌ഡി‌എസ് അല്ലെങ്കിൽ ഡിജിറ്റൽ ഓഷ്യൻ മാനേജ്‌ഡ് ഡാറ്റാബേസ് പോലുള്ള നിയന്ത്രിത സേവനങ്ങളായി ഡാറ്റാബേസിനെ വിഭജിക്കുന്നത് വളരെക്കാലം നമ്മെ നന്നായി സേവിക്കും. ഒരൊറ്റ മെഷീനിലോ EC2 സന്ദർഭത്തിലോ സ്വയം ഹോസ്റ്റുചെയ്യുന്നതിനേക്കാൾ ഇത് അൽപ്പം ചെലവേറിയതാണ്, എന്നാൽ ഈ സേവനങ്ങൾ ഉപയോഗിച്ച് നിങ്ങൾക്ക് ബോക്സിൽ നിന്ന് ധാരാളം ഉപയോഗപ്രദമായ വിപുലീകരണങ്ങൾ ലഭിക്കും, അത് ഭാവിയിൽ ഉപയോഗപ്രദമാകും: മൾട്ടി-റീജിയൻ ബാക്കപ്പ്, റീഡ് പകർപ്പുകൾ, ഓട്ടോമാറ്റിക് ബാക്കപ്പുകളും മറ്റും.

സിസ്റ്റം ഇപ്പോൾ ഇങ്ങനെയാണ് കാണപ്പെടുന്നത്:

100 ഉപയോക്താക്കൾ: ക്ലയന്റിനെ ഒരു പ്രത്യേക തലത്തിലേക്ക് മാറ്റുന്നു

ഭാഗ്യവശാൽ, ഞങ്ങളുടെ ആദ്യ ഉപയോക്താക്കൾക്ക് ഞങ്ങളുടെ ആപ്ലിക്കേഷൻ ശരിക്കും ഇഷ്ടപ്പെട്ടു. ട്രാഫിക് കൂടുതൽ സ്ഥിരത കൈവരിക്കുന്നു, അതിനാൽ ക്ലയന്റിനെ ഒരു പ്രത്യേക തലത്തിലേക്ക് മാറ്റാനുള്ള സമയമാണിത്. എന്നത് ശ്രദ്ധിക്കേണ്ടതാണ് വേർപിരിയൽ സ്കെയിലബിൾ ആപ്ലിക്കേഷൻ നിർമ്മിക്കുന്നതിനുള്ള പ്രധാന വശമാണ് എന്റിറ്റികൾ. സിസ്റ്റത്തിന്റെ ഒരു ഭാഗത്തിന് കൂടുതൽ ട്രാഫിക് ലഭിക്കുന്നതിനാൽ, നിർദ്ദിഷ്ട ട്രാഫിക് പാറ്റേണുകളെ അടിസ്ഥാനമാക്കിയുള്ള സേവന സ്കെയിലുകൾ നിയന്ത്രിക്കുന്നതിന് നമുക്ക് അത് വിഭജിക്കാം.

അതുകൊണ്ടാണ് ക്ലയന്റ് എപിഐയിൽ നിന്ന് വേറിട്ടതായി കരുതാൻ ഞാൻ ഇഷ്ടപ്പെടുന്നത്. ഒന്നിലധികം പ്ലാറ്റ്‌ഫോമുകൾക്കായി വികസിപ്പിക്കുന്നതിനെക്കുറിച്ച് ചിന്തിക്കുന്നത് ഇത് വളരെ എളുപ്പമാക്കുന്നു: വെബ്, മൊബൈൽ വെബ്, iOS, Android, ഡെസ്‌ക്‌ടോപ്പ് ആപ്ലിക്കേഷനുകൾ, മൂന്നാം കക്ഷി സേവനങ്ങൾ മുതലായവ. അവരെല്ലാം ഒരേ API ഉപയോഗിക്കുന്ന ക്ലയന്റുകളാണ്.

ഉദാഹരണത്തിന്, ഇപ്പോൾ ഞങ്ങളുടെ ഉപയോക്താക്കൾ മിക്കപ്പോഴും ഒരു മൊബൈൽ ആപ്ലിക്കേഷൻ റിലീസ് ചെയ്യാൻ ആവശ്യപ്പെടുന്നു. നിങ്ങൾ ക്ലയന്റിനെയും API എന്റിറ്റികളെയും വേർതിരിക്കുകയാണെങ്കിൽ, ഇത് എളുപ്പമാകും.

അത്തരമൊരു സംവിധാനം ഇതുപോലെ കാണപ്പെടുന്നു:

1000 ഉപയോക്താക്കൾ: ലോഡ് ബാലൻസർ ചേർക്കുക

കാര്യങ്ങൾ ഉറ്റുനോക്കുന്നു. ഗ്രാമിൻസ്റ്റ ഉപയോക്താക്കൾ കൂടുതൽ കൂടുതൽ ഫോട്ടോകൾ അപ്‌ലോഡ് ചെയ്യുന്നു. രജിസ്‌ട്രേഷനുകളുടെ എണ്ണവും വർധിച്ചുവരികയാണ്. ഞങ്ങളുടെ ഏക API സെർവറിന് എല്ലാ ട്രാഫിക്കും നിലനിർത്താൻ ബുദ്ധിമുട്ടാണ്. കൂടുതൽ ഇരുമ്പ് വേണം!

ലോഡ് ബാലൻസർ വളരെ ശക്തമായ ഒരു ആശയമാണ്. പ്രധാന ആശയം, ഞങ്ങൾ API-ക്ക് മുന്നിൽ ഒരു ലോഡ് ബാലൻസർ ഇടുന്നു, ഇത് വ്യക്തിഗത സേവന സന്ദർഭങ്ങളിലേക്ക് ട്രാഫിക് വിതരണം ചെയ്യുന്നു. ഇങ്ങനെയാണ് ഞങ്ങൾ തിരശ്ചീനമായി സ്കെയിൽ ചെയ്യുന്നത്, അതായത് ഒരേ കോഡ് ഉപയോഗിച്ച് കൂടുതൽ സെർവറുകൾ ഞങ്ങൾ ചേർക്കുന്നു, ഞങ്ങൾക്ക് പ്രോസസ്സ് ചെയ്യാൻ കഴിയുന്ന അഭ്യർത്ഥനകളുടെ എണ്ണം വർദ്ധിപ്പിക്കുന്നു.

വെബ് ക്ലയന്റിനു മുന്നിലും API യുടെ മുന്നിലും ഞങ്ങൾ പ്രത്യേക ലോഡ് ബാലൻസറുകൾ സ്ഥാപിക്കാൻ പോകുന്നു. API കോഡും വെബ് ക്ലയന്റ് കോഡും പ്രവർത്തിക്കുന്ന ഒന്നിലധികം സന്ദർഭങ്ങൾ നിങ്ങൾക്ക് പ്രവർത്തിപ്പിക്കാൻ കഴിയുമെന്നാണ് ഇതിനർത്ഥം. ലോഡ് ബാലൻസർ കുറവ് ലോഡുള്ള സെർവറിലേക്ക് അഭ്യർത്ഥനകൾ നയിക്കും.

ഇവിടെ നമുക്ക് മറ്റൊരു പ്രധാന നേട്ടം ലഭിക്കുന്നു - ആവർത്തനം. ഒരു സന്ദർഭം പരാജയപ്പെടുമ്പോൾ (ഒരുപക്ഷേ ഓവർലോഡ് അല്ലെങ്കിൽ ക്രാഷ്), ഇൻകമിംഗ് അഭ്യർത്ഥനകളോട് പ്രതികരിക്കുന്നത് തുടരുന്ന മറ്റുള്ളവരുമായി ഞങ്ങൾ അവശേഷിക്കുന്നു. ഒരു സന്ദർഭം മാത്രമേ പ്രവർത്തിച്ചിരുന്നുള്ളൂവെങ്കിൽ, പരാജയപ്പെടുകയാണെങ്കിൽ മുഴുവൻ സിസ്റ്റവും തകരാറിലാകും.

ലോഡ് ബാലൻസറും ഓട്ടോമാറ്റിക് സ്കെയിലിംഗ് നൽകുന്നു. പീക്ക് ലോഡിന് മുമ്പുള്ള സന്ദർഭങ്ങളുടെ എണ്ണം വർദ്ധിപ്പിക്കുന്നതിനും എല്ലാ ഉപയോക്താക്കളും ഉറങ്ങുമ്പോൾ അത് കുറയ്ക്കുന്നതിനും ഞങ്ങൾക്ക് ഇത് കോൺഫിഗർ ചെയ്യാം.

ഒരു ലോഡ് ബാലൻസർ ഉപയോഗിച്ച്, അഭ്യർത്ഥനകളുടെ എണ്ണം കൂടുന്നതിനനുസരിച്ച് പുതിയ സന്ദർഭങ്ങൾ ചേർത്ത് API ലെവൽ ഏതാണ്ട് അനിശ്ചിതമായി സ്കെയിൽ ചെയ്യാൻ കഴിയും.

കുറിപ്പ്. AWS-ലെ Heroku അല്ലെങ്കിൽ Elastic Beanstalk പോലുള്ള PaaS കമ്പനികൾ ഓഫർ ചെയ്യുന്നതിനോട് വളരെ സാമ്യമുള്ളതാണ് ഇപ്പോൾ ഞങ്ങളുടെ സിസ്റ്റം (അതുകൊണ്ടാണ് അവ വളരെ ജനപ്രിയമായത്). Heroku ഒരു പ്രത്യേക ഹോസ്റ്റിൽ ഡാറ്റാബേസ് സ്ഥാപിക്കുന്നു, ഒരു ഓട്ടോ-സ്കെയിലിംഗ് ലോഡ് ബാലൻസറിനെ നിയന്ത്രിക്കുന്നു, കൂടാതെ API-യിൽ നിന്ന് വെവ്വേറെ വെബ് ക്ലയന്റ് ഹോസ്റ്റുചെയ്യാൻ നിങ്ങളെ അനുവദിക്കുന്നു. പ്രാരംഭ ഘട്ട പ്രോജക്റ്റുകൾക്കോ ​​സ്റ്റാർട്ടപ്പുകൾക്കോ ​​വേണ്ടി Heroku ഉപയോഗിക്കുന്നതിനുള്ള ഒരു മികച്ച കാരണമാണിത് - നിങ്ങൾക്ക് എല്ലാ അടിസ്ഥാന സേവനങ്ങളും ബോക്സിൽ നിന്ന് ലഭിക്കും.

10 ഉപയോക്താക്കൾ: CDN

ഒരുപക്ഷേ നമ്മൾ ആദ്യം മുതൽ ഇത് ചെയ്യണമായിരുന്നു. അഭ്യർത്ഥനകൾ പ്രോസസ്സ് ചെയ്യുന്നതും പുതിയ ഫോട്ടോകൾ സ്വീകരിക്കുന്നതും ഞങ്ങളുടെ സെർവറുകളിൽ വളരെയധികം സമ്മർദ്ദം ചെലുത്താൻ തുടങ്ങിയിരിക്കുന്നു.

ഈ ഘട്ടത്തിൽ, സ്റ്റാറ്റിക് ഉള്ളടക്കം സംഭരിക്കുന്നതിന് നിങ്ങൾ ഒരു ക്ലൗഡ് സേവനം ഉപയോഗിക്കേണ്ടതുണ്ട് - ചിത്രങ്ങൾ, വീഡിയോകൾ എന്നിവയും അതിലേറെയും (AWS S3 അല്ലെങ്കിൽ ഡിജിറ്റൽ ഓഷ്യൻ സ്പേസുകൾ). പൊതുവേ, ഇമേജുകൾ സെർവുചെയ്യുന്നതും സെർവറിലേക്ക് ചിത്രങ്ങൾ അപ്‌ലോഡ് ചെയ്യുന്നതും പോലുള്ള കാര്യങ്ങൾ കൈകാര്യം ചെയ്യുന്നത് ഞങ്ങളുടെ API ഒഴിവാക്കണം.

ക്ലൗഡ് ഹോസ്റ്റിംഗിന്റെ മറ്റൊരു നേട്ടം CDN ആണ് (AWS ഇതിനെ ആഡ്-ഓൺ Cloudfront എന്ന് വിളിക്കുന്നു, എന്നാൽ പല ക്ലൗഡ് സ്റ്റോറേജ് ദാതാക്കളും ഇത് ബോക്‌സിന് പുറത്ത് വാഗ്ദാനം ചെയ്യുന്നു). ലോകമെമ്പാടുമുള്ള വിവിധ ഡാറ്റാ സെന്ററുകളിൽ CDN നമ്മുടെ ചിത്രങ്ങൾ സ്വയമേവ കാഷെ ചെയ്യുന്നു.

ഞങ്ങളുടെ പ്രധാന ഡാറ്റാ സെന്റർ ഒഹായോയിലായിരിക്കാമെങ്കിലും, ആരെങ്കിലും ജപ്പാനിൽ നിന്ന് ഒരു ചിത്രം അഭ്യർത്ഥിച്ചാൽ, ക്ലൗഡ് ദാതാവ് ഒരു പകർപ്പ് ഉണ്ടാക്കി അവരുടെ ജാപ്പനീസ് ഡാറ്റാ സെന്ററിൽ സംഭരിക്കും. ജപ്പാനിൽ ഈ ചിത്രം അഭ്യർത്ഥിക്കുന്ന അടുത്ത വ്യക്തിക്ക് അത് വളരെ വേഗത്തിൽ ലഭിക്കും. ഫോട്ടോകളോ വീഡിയോകളോ പോലുള്ള വലിയ ഫയലുകൾ ഉപയോഗിച്ച് ഞങ്ങൾ പ്രവർത്തിക്കുമ്പോൾ ഇത് വളരെ പ്രധാനമാണ്, അത് ഡൗൺലോഡ് ചെയ്യാനും ഗ്രഹത്തിൽ ഉടനീളം കൈമാറാനും വളരെ സമയമെടുക്കും.

100 ഉപയോക്താക്കൾ: ഡാറ്റ ലെയർ സ്കെയിൽ ചെയ്യുന്നു

CDN വളരെയധികം സഹായിച്ചിട്ടുണ്ട്: ട്രാഫിക് പൂർണ്ണ വേഗതയിൽ വളരുകയാണ്. പ്രശസ്ത വീഡിയോ ബ്ലോഗർ മാവിഡ് മൊബ്രിക്ക് ഞങ്ങളിൽ രജിസ്റ്റർ ചെയ്യുകയും അവർ പറയുന്നതുപോലെ തന്റെ “കഥ” പോസ്റ്റ് ചെയ്യുകയും ചെയ്തു. ലോഡ് ബാലൻസറിന് നന്ദി, എപിഐ സെർവറുകളിലെ സിപിയു, മെമ്മറി ഉപയോഗം കുറവാണ് (പത്ത് എപിഐ സംഭവങ്ങൾ പ്രവർത്തിക്കുന്നു), എന്നാൽ അഭ്യർത്ഥനകളിൽ ഞങ്ങൾക്ക് ധാരാളം ടൈംഔട്ടുകൾ ലഭിക്കാൻ തുടങ്ങിയിരിക്കുന്നു... ഈ കാലതാമസം എവിടെ നിന്ന് വരുന്നു?

മെട്രിക്സിലേക്ക് അൽപ്പം കുഴിച്ചെടുക്കുമ്പോൾ, ഡാറ്റാബേസ് സെർവറിലെ സിപിയു 80-90% ലോഡ് ചെയ്തതായി ഞങ്ങൾ കാണുന്നു. ഞങ്ങൾ പരിധിയിലാണ്.

ഡാറ്റ ലെയർ സ്കെയിൽ ചെയ്യുന്നത് ഒരുപക്ഷേ സമവാക്യത്തിന്റെ ഏറ്റവും ബുദ്ധിമുട്ടുള്ള ഭാഗമാണ്. API സെർവറുകൾ സ്‌റ്റേറ്റ്‌ലെസ് അഭ്യർത്ഥനകൾ നൽകുന്നു, അതിനാൽ ഞങ്ങൾ കൂടുതൽ API സംഭവങ്ങൾ ചേർക്കുന്നു. മൂക്ക് ഭൂരിപക്ഷം ഡാറ്റാബേസിന് ഇത് ചെയ്യാൻ കഴിയില്ല. നമ്മൾ ജനപ്രിയമായ റിലേഷണൽ ഡാറ്റാബേസ് മാനേജ്മെന്റ് സിസ്റ്റങ്ങളെക്കുറിച്ച് സംസാരിക്കും (PostgreSQL, MySQL, മുതലായവ).

കാഷിംഗ്

ഞങ്ങളുടെ ഡാറ്റാബേസിന്റെ പ്രകടനം വർദ്ധിപ്പിക്കുന്നതിനുള്ള ഏറ്റവും എളുപ്പമുള്ള മാർഗ്ഗം ഒരു പുതിയ ഘടകം അവതരിപ്പിക്കുക എന്നതാണ്: കാഷെ ലെയർ. Redis അല്ലെങ്കിൽ Memcached പോലുള്ള ഇൻ-മെമ്മറി കീ-വാല്യൂ റെക്കോർഡ് സ്റ്റോറാണ് ഏറ്റവും സാധാരണമായ കാഷിംഗ് രീതി. മിക്ക ക്ലൗഡുകൾക്കും ഈ സേവനങ്ങളുടെ ഒരു നിയന്ത്രിത പതിപ്പുണ്ട്: AWS-ലെ ഇലാസ്റ്റിക്ക്, Google ക്ലൗഡിലെ മെമ്മറിസ്റ്റോർ.

ഒരേ വിവരങ്ങൾ വീണ്ടെടുക്കാൻ ഒരു സേവനം ഡാറ്റാബേസിലേക്ക് ആവർത്തിച്ച് കോളുകൾ ചെയ്യുമ്പോൾ ഒരു കാഷെ ഉപയോഗപ്രദമാണ്. അടിസ്ഥാനപരമായി, ഞങ്ങൾ ഒരു തവണ മാത്രമേ ഡാറ്റാബേസ് ആക്‌സസ്സുചെയ്യുകയുള്ളൂ, വിവരങ്ങൾ കാഷെയിൽ സംഭരിക്കുക, വീണ്ടും തൊടരുത്.

ഉദാഹരണത്തിന്, ഞങ്ങളുടെ Graminsta സേവനത്തിൽ, Mobrik എന്ന നക്ഷത്രത്തിന്റെ പ്രൊഫൈൽ പേജിലേക്ക് ആരെങ്കിലും പോകുമ്പോഴെല്ലാം, API സെർവർ അവന്റെ പ്രൊഫൈലിൽ നിന്നുള്ള വിവരങ്ങൾക്കായി ഡാറ്റാബേസിൽ അന്വേഷിക്കുന്നു. ഇത് വീണ്ടും വീണ്ടും സംഭവിക്കുന്നു. Mobrik-ന്റെ പ്രൊഫൈൽ വിവരങ്ങൾ ഓരോ അഭ്യർത്ഥനയ്‌ക്കൊപ്പവും മാറാത്തതിനാൽ, അത് കാഷെ ചെയ്യാൻ മികച്ചതാണ്.

റെഡിസിലെ ഡാറ്റാബേസിൽ നിന്നുള്ള ഫലങ്ങൾ കീ ഉപയോഗിച്ച് ഞങ്ങൾ കാഷെ ചെയ്യും user:id 30 സെക്കൻഡ് സാധുതയുള്ള കാലയളവിൽ. ഇപ്പോൾ, ആരെങ്കിലും Mobrik-ന്റെ പ്രൊഫൈലിലേക്ക് പോകുമ്പോൾ, ഞങ്ങൾ ആദ്യം Redis പരിശോധിക്കുക, ഡാറ്റ അവിടെ ഉണ്ടെങ്കിൽ, ഞങ്ങൾ അത് Redis-ൽ നിന്ന് നേരിട്ട് കൈമാറുക. ഇപ്പോൾ സൈറ്റിലെ ഏറ്റവും ജനപ്രിയമായ പ്രൊഫൈലിലേക്കുള്ള അഭ്യർത്ഥനകൾ പ്രായോഗികമായി ഞങ്ങളുടെ ഡാറ്റാബേസ് ലോഡ് ചെയ്യുന്നില്ല.

മിക്ക കാഷിംഗ് സേവനങ്ങളുടെയും മറ്റൊരു നേട്ടം, ഡാറ്റാബേസ് സെർവറുകളേക്കാൾ അവ സ്കെയിൽ ചെയ്യാൻ എളുപ്പമാണ് എന്നതാണ്. റെഡിസിന് ഒരു ബിൽറ്റ്-ഇൻ റെഡിസ് ക്ലസ്റ്റർ മോഡ് ഉണ്ട്. ഒരു ലോഡ് ബാലൻസറിന് സമാനമാണ്1, ഒന്നിലധികം മെഷീനുകളിൽ (ആവശ്യമെങ്കിൽ ആയിരക്കണക്കിന് സെർവറുകളിലുടനീളം) നിങ്ങളുടെ Redis കാഷെ വിതരണം ചെയ്യാൻ ഇത് നിങ്ങളെ അനുവദിക്കുന്നു.

മിക്കവാറും എല്ലാ വലിയ തോതിലുള്ള ആപ്ലിക്കേഷനുകളും കാഷിംഗ് ഉപയോഗിക്കുന്നു; ഇത് ഒരു ഫാസ്റ്റ് എപിഐയുടെ തികച്ചും അവിഭാജ്യ ഘടകമാണ്. വേഗത്തിലുള്ള അന്വേഷണ പ്രോസസ്സിംഗും കൂടുതൽ ഉൽപ്പാദനക്ഷമമായ കോഡും എല്ലാം പ്രധാനമാണ്, എന്നാൽ ഒരു കാഷെ കൂടാതെ ദശലക്ഷക്കണക്കിന് ഉപയോക്താക്കൾക്ക് ഒരു സേവനം സ്കെയിൽ ചെയ്യുന്നത് മിക്കവാറും അസാധ്യമാണ്.

റെപ്ലിക്കുകൾ വായിക്കുക

ഡാറ്റാബേസിലേക്കുള്ള അന്വേഷണങ്ങളുടെ എണ്ണം വളരെയധികം വർദ്ധിച്ചപ്പോൾ, നമുക്ക് ചെയ്യാൻ കഴിയുന്ന ഒരു കാര്യം ഡാറ്റാബേസ് മാനേജ്മെന്റ് സിസ്റ്റത്തിൽ റീഡ് റെപ്ലിക്കസ് ചേർക്കുക എന്നതാണ്. മുകളിൽ വിവരിച്ച നിയന്ത്രിത സേവനങ്ങൾ ഉപയോഗിച്ച്, ഇത് ഒറ്റ ക്ലിക്കിൽ ചെയ്യാനാകും. റീഡ് റെപ്ലിക്ക പ്രധാന ഡാറ്റാബേസിൽ നിലവിലുള്ളതായി തുടരും കൂടാതെ SELECT പ്രസ്താവനകൾക്ക് ലഭ്യമാണ്.

ഇപ്പോൾ ഞങ്ങളുടെ സിസ്റ്റം ഇതാ:

അടുത്ത നടപടികൾ

ആപ്ലിക്കേഷൻ സ്കെയിൽ ചെയ്യുന്നത് തുടരുന്നതിനാൽ, സേവനങ്ങളെ സ്വതന്ത്രമായി സ്കെയിൽ ചെയ്യാൻ ഞങ്ങൾ വേർതിരിക്കുന്നത് തുടരും. ഉദാഹരണത്തിന്, ഞങ്ങൾ Websockets ഉപയോഗിക്കാൻ തുടങ്ങിയാൽ, Websockets പ്രോസസ്സിംഗ് കോഡ് ഒരു പ്രത്യേക സേവനത്തിലേക്ക് വലിച്ചിടുന്നത് അർത്ഥമാക്കുന്നു. എച്ച്ടിടിപി അഭ്യർത്ഥനകളുടെ എണ്ണം പരിഗണിക്കാതെ തന്നെ ഓപ്പൺ വെബ്‌സോക്കറ്റ് കണക്ഷനുകളെ അടിസ്ഥാനമാക്കി മുകളിലേക്കും താഴേക്കും സ്കെയിൽ ചെയ്യാൻ കഴിയുന്ന ഞങ്ങളുടെ സ്വന്തം ലോഡ് ബാലൻസറിന് പിന്നിൽ പുതിയ സന്ദർഭങ്ങളിൽ ഇത് സ്ഥാപിക്കാം.

ഡാറ്റാബേസ് തലത്തിലുള്ള നിയന്ത്രണങ്ങൾക്കെതിരെ ഞങ്ങൾ പോരാടുന്നത് തുടരും. ഈ ഘട്ടത്തിലാണ് ഡാറ്റാബേസ് പാർട്ടീഷനിംഗും ഷാർഡിംഗും പഠിക്കാനുള്ള സമയമാണിത്. രണ്ട് സമീപനങ്ങൾക്കും അധിക ഓവർഹെഡ് ആവശ്യമാണ്, എന്നാൽ ഡാറ്റാബേസ് ഏതാണ്ട് അനിശ്ചിതമായി സ്കെയിൽ ചെയ്യാൻ നിങ്ങളെ അനുവദിക്കുന്നു.

ന്യൂ റെലിക്ക് അല്ലെങ്കിൽ ഡാറ്റാഡോഗ് പോലുള്ള ഒരു മോണിറ്ററിംഗ്, അനലിറ്റിക്സ് സേവനവും ഇൻസ്റ്റാൾ ചെയ്യാൻ ഞങ്ങൾ ആഗ്രഹിക്കുന്നു. മന്ദഗതിയിലുള്ള ചോദ്യങ്ങൾ തിരിച്ചറിയാനും എവിടെയാണ് മെച്ചപ്പെടുത്തൽ ആവശ്യമെന്ന് മനസ്സിലാക്കാനും ഇത് നിങ്ങളെ സഹായിക്കും. ഞങ്ങൾ സ്കെയിൽ ചെയ്യുമ്പോൾ, തടസ്സങ്ങൾ കണ്ടെത്തുന്നതിലും അവ ഇല്ലാതാക്കുന്നതിലും ശ്രദ്ധ കേന്ദ്രീകരിക്കാൻ ഞങ്ങൾ ആഗ്രഹിക്കുന്നു-പലപ്പോഴും മുൻ വിഭാഗങ്ങളിൽ നിന്നുള്ള ചില ആശയങ്ങൾ ഉപയോഗിക്കുന്നു.

ഉറവിടങ്ങൾ

ഇതിൽ ഒരാളിൽ നിന്നാണ് ഈ പോസ്റ്റ് പ്രചോദനം ഉൾക്കൊണ്ടിരിക്കുന്നത് ഉയർന്ന സ്കേലബിളിറ്റിയെക്കുറിച്ചുള്ള എന്റെ പ്രിയപ്പെട്ട പോസ്റ്റുകൾ. പ്രോജക്റ്റുകളുടെ പ്രാരംഭ ഘട്ടങ്ങൾക്കായി ലേഖനം കുറച്ചുകൂടി വ്യക്തമാക്കാനും ഒരു വെണ്ടറിൽ നിന്ന് അത് അഴിച്ചുമാറ്റാനും ഞാൻ ആഗ്രഹിച്ചു. നിങ്ങൾക്ക് ഈ വിഷയത്തിൽ താൽപ്പര്യമുണ്ടെങ്കിൽ തീർച്ചയായും വായിക്കുക.

അടിക്കുറിപ്പുകൾ

1. ഒന്നിലധികം സന്ദർഭങ്ങളിൽ ലോഡ് വിതരണത്തിന്റെ കാര്യത്തിൽ സമാനമാണെങ്കിലും, ഒരു ലോഡ് ബാലൻസറിൽ നിന്ന് വളരെ വ്യത്യസ്തമാണ് Redis ക്ലസ്റ്ററിന്റെ അടിസ്ഥാനപരമായ നടപ്പാക്കൽ. [മടങ്ങുക]

അവലംബം: www.habr.com