ബദൂവിൽ ഫോട്ടോകൾ സംഭരിക്കുന്നതിനും പങ്കിടുന്നതിനുമുള്ള വാസ്തുവിദ്യ

ആർടെം ഡെനിസോവ് ( bo0rsh201, ബാദു)

ലോകത്തിലെ ഏറ്റവും വലിയ ഡേറ്റിംഗ് സൈറ്റാണ് ബദൂ. ഞങ്ങൾക്ക് നിലവിൽ ലോകമെമ്പാടുമായി ഏകദേശം 330 ദശലക്ഷം രജിസ്റ്റർ ചെയ്ത ഉപയോക്താക്കളുണ്ട്. എന്നാൽ ഇന്നത്തെ നമ്മുടെ സംഭാഷണത്തിന്റെ പശ്ചാത്തലത്തിൽ വളരെ പ്രധാനപ്പെട്ട കാര്യം, ഞങ്ങൾ ഏകദേശം 3 പെറ്റാബൈറ്റ് ഉപയോക്തൃ ഫോട്ടോകൾ സംഭരിക്കുന്നു എന്നതാണ്. ഓരോ ദിവസവും ഞങ്ങളുടെ ഉപയോക്താക്കൾ ഏകദേശം 3,5 മില്യൺ പുതിയ ഫോട്ടോകൾ അപ്‌ലോഡ് ചെയ്യുന്നു, വായനാ ലോഡും ഏകദേശം സെക്കൻഡിൽ 80 ആയിരം അഭ്യർത്ഥനകൾ. ഇത് ഞങ്ങളുടെ ബാക്കെൻഡിന് വളരെ കൂടുതലാണ്, ചിലപ്പോൾ ഇതിൽ ബുദ്ധിമുട്ടുകൾ ഉണ്ടാകാം.

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

ഇനി നമുക്ക് തുടങ്ങാം.

ഞാൻ പറഞ്ഞതുപോലെ, ഇത് ഒരു മുൻകാലാവസ്ഥയായിരിക്കും, എവിടെയെങ്കിലും ഇത് ആരംഭിക്കുന്നതിന്, നമുക്ക് ഏറ്റവും സാധാരണമായ ഉദാഹരണം എടുക്കാം.

ഞങ്ങൾക്ക് ഒരു പൊതു ചുമതലയുണ്ട്, ഉപയോക്തൃ ഫോട്ടോകൾ സ്വീകരിക്കുകയും സംഭരിക്കുകയും അയയ്ക്കുകയും വേണം. ഈ രൂപത്തിൽ, ചുമതല പൊതുവായതാണ്, നമുക്ക് എന്തും ഉപയോഗിക്കാം:

• ആധുനിക ക്ലൗഡ് സംഭരണം,
• ഒരു പെട്ടിയിലുള്ള പരിഹാരം, അതിൽ ഇപ്പോൾ ധാരാളം ഉണ്ട്;
• നമ്മുടെ ഡാറ്റാ സെന്ററിൽ നിരവധി മെഷീനുകൾ സ്ഥാപിക്കുകയും അവയിൽ വലിയ ഹാർഡ് ഡ്രൈവുകൾ സ്ഥാപിക്കുകയും ഫോട്ടോകൾ അവിടെ സൂക്ഷിക്കുകയും ചെയ്യാം.

Badoo ചരിത്രപരമായി - ഇപ്പോഴെങ്കിലും (അത് അതിന്റെ ശൈശവാവസ്ഥയിലായിരുന്ന സമയത്ത്) - സ്വന്തം സെർവറുകളിൽ, നമ്മുടെ സ്വന്തം ഡിസികൾക്കുള്ളിൽ ജീവിക്കുന്നു. അതിനാൽ, ഈ ഓപ്ഷൻ ഞങ്ങൾക്ക് അനുയോജ്യമാണ്.

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

ഉപയോക്താക്കളെക്കുറിച്ചുള്ള വിവരങ്ങളോടൊപ്പം ഞങ്ങളുടെ സ്റ്റോറേജിലേക്ക് ഞങ്ങൾ കുറച്ച് ഫീൽഡ് ചേർക്കുന്നു. ഇത് ഷാർഡിംഗ് കീ ആയിരിക്കും. ഞങ്ങളുടെ കാര്യത്തിൽ, ഞങ്ങൾ ഇതിനെ place_id എന്ന് വിളിക്കുന്നു, ഈ സ്ഥല ഐഡി ഉപയോക്തൃ ഫോട്ടോകൾ സംഭരിച്ചിരിക്കുന്ന സ്ഥലത്തേക്ക് ചൂണ്ടിക്കാണിക്കുന്നു. ഞങ്ങൾ മാപ്പുകൾ ഉണ്ടാക്കുന്നു.

ആദ്യ ഘട്ടത്തിൽ, ഇത് സ്വമേധയാ ചെയ്യാൻ പോലും കഴിയും - അത്തരമൊരു സ്ഥലമുള്ള ഈ ഉപയോക്താവിന്റെ ഫോട്ടോ അത്തരമൊരു സെർവറിൽ ഇറങ്ങുമെന്ന് ഞങ്ങൾ പറയുന്നു. ഈ മാപ്പിന് നന്ദി, ഒരു ഉപയോക്താവ് ഒരു ഫോട്ടോ അപ്‌ലോഡ് ചെയ്യുമ്പോൾ, അത് എവിടെ സംരക്ഷിക്കണം, അത് എവിടെ നിന്ന് നൽകണമെന്ന് ഞങ്ങൾക്കറിയാം.

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

കുറച്ചു കാലം ഞങ്ങൾക്കും അങ്ങനെയായിരുന്നു.

ഇത് ഏകദേശം 2009 ആയിരുന്നു. അവർ കാറുകൾ എത്തിച്ചു, എത്തിച്ചു...

ചില ഘട്ടങ്ങളിൽ ഈ സ്കീമിന് ചില ദോഷങ്ങളുണ്ടെന്ന് ഞങ്ങൾ ശ്രദ്ധിക്കാൻ തുടങ്ങി. ദോഷങ്ങൾ എന്തൊക്കെയാണ്?

ഒന്നാമതായി, പരിമിതമായ ശേഷി ഉണ്ട്. ഒരു ഫിസിക്കൽ സെർവറിലേക്ക് നമ്മൾ ആഗ്രഹിക്കുന്നത്രയും ഹാർഡ് ഡ്രൈവുകൾ ക്രാം ചെയ്യാൻ കഴിയില്ല. കാലക്രമേണ, ഡാറ്റാസെറ്റിന്റെ വളർച്ചയ്‌ക്കൊപ്പം ഇത് ഒരു പ്രത്യേക പ്രശ്‌നമായി മാറിയിരിക്കുന്നു.

രണ്ടാമത്തേതും. ഇത് മെഷീനുകളുടെ ഒരു വിഭിന്ന കോൺഫിഗറേഷനാണ്, കാരണം അത്തരം മെഷീനുകൾ മറ്റ് ചില ക്ലസ്റ്ററുകളിൽ വീണ്ടും ഉപയോഗിക്കാൻ പ്രയാസമാണ്; അവ തികച്ചും നിർദ്ദിഷ്ടമാണ്, അതായത്. അവ പ്രകടനത്തിൽ ദുർബലമായിരിക്കണം, എന്നാൽ അതേ സമയം ഒരു വലിയ ഹാർഡ് ഡ്രൈവ്.

ഇതെല്ലാം 2009-ലായിരുന്നു, പക്ഷേ, തത്വത്തിൽ, ഈ ആവശ്യകതകൾ ഇന്നും പ്രസക്തമാണ്. ഞങ്ങൾക്ക് ഒരു റിട്രോസ്പെക്റ്റീവ് ഉണ്ട്, അതിനാൽ 2009 ൽ എല്ലാം ഇതോടെ പൂർണ്ണമായും മോശമായിരുന്നു.

അവസാന പോയിന്റ് വിലയാണ്.

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

അവസാനം, ഞങ്ങൾ സ്റ്റോറേജ് ഏരിയ നെറ്റ്‌വർക്ക് എന്ന് വിളിക്കപ്പെടുന്നതുമായി ബന്ധപ്പെട്ടു.

വലിയ അളവിലുള്ള ഡാറ്റ സംഭരിക്കുന്നതിനായി പ്രത്യേകം രൂപകൽപ്പന ചെയ്ത വലിയ എസ്എച്ച്ഡികളാണിവ. അവസാന ഒപ്റ്റിക്കൽ ഔട്ട്പുട്ട് മെഷീനുകളിൽ ഘടിപ്പിച്ചിരിക്കുന്ന ഡിസ്കുകളുള്ള ഷെൽഫുകളാണ് അവ. അത്. ഞങ്ങളുടെ അയയ്‌ക്കുന്നതിനുള്ള യുക്തിക്ക് സുതാര്യമായ ചിലതരം മെഷീനുകൾ ഉണ്ട്, വളരെ ചെറുതാണ്, ഈ SHD-കൾ, അതായത്. ഞങ്ങളുടെ nginx അല്ലെങ്കിൽ മറ്റാരെങ്കിലും ഈ ഫോട്ടോകൾക്കായുള്ള അഭ്യർത്ഥനകൾ നൽകുന്നതിന്.

ഈ തീരുമാനത്തിന് വ്യക്തമായ നേട്ടങ്ങളുണ്ടായിരുന്നു. ഇത് SHD ആണ്. ഇത് ഫോട്ടോകൾ സൂക്ഷിക്കാൻ ലക്ഷ്യമിടുന്നു. ഹാർഡ് ഡ്രൈവുകൾ ഉപയോഗിച്ച് മെഷീനുകൾ സജ്ജീകരിക്കുന്നതിനേക്കാൾ ഇത് വിലകുറഞ്ഞതാണ്.

രണ്ടാമത്തെ പ്ലസ്.

ഇതാണ് ശേഷി വളരെ വലുതായിത്തീർന്നത്, അതായത്. വളരെ ചെറിയ വോള്യത്തിൽ നമുക്ക് കൂടുതൽ സംഭരണം ഉൾക്കൊള്ളാൻ കഴിയും.

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

ഞങ്ങളുടെ ഫോട്ടോകളുടെ കാര്യത്തിലെന്നപോലെ, ഫോട്ടോകൾ പൊരുത്തമില്ലാതെ അഭ്യർത്ഥിക്കുന്നു, ഇത് അവരുടെ പ്രകടനത്തെ വളരെയധികം ബാധിക്കും.

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

ഒപ്റ്റിമൈസ് ചെയ്യുന്നതിനായി, ആ സമയത്ത്, ലോഡ് പ്രൊഫൈൽ നോക്കാൻ ഞങ്ങൾ തീരുമാനിച്ചു - പൊതുവേ, എന്താണ് സംഭവിക്കുന്നത്, എന്താണ് ഒപ്റ്റിമൈസ് ചെയ്യേണ്ടത്.

ഇവിടെ എല്ലാം നമ്മുടെ കൈകളിൽ കളിക്കുന്നു.

ആദ്യ സ്ലൈഡിൽ ഞാൻ ഇതിനകം പറഞ്ഞു: ഞങ്ങൾക്ക് സെക്കൻഡിൽ 80 ആയിരം വായനാ അഭ്യർത്ഥനകളുണ്ട്, പ്രതിദിനം 3,5 ദശലക്ഷം അപ്‌ലോഡുകൾ മാത്രം. അതായത്, ഇത് മാഗ്നിറ്റ്യൂഡിന്റെ മൂന്ന് ഓർഡറുകളുടെ വ്യത്യാസമാണ്. വായന ഒപ്റ്റിമൈസ് ചെയ്യേണ്ടതുണ്ടെന്ന് വ്യക്തമാണ്, അത് എങ്ങനെയെന്ന് പ്രായോഗികമായി വ്യക്തമാണ്.

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

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

LRU ഉള്ള ഒരു കാഷെ നമ്മുടെ എല്ലാ പ്രശ്നങ്ങളും പരിഹരിക്കും. നമ്മള് എന്താണ് ചെയ്യുന്നത്?

സംഭരണത്തോടുകൂടിയ ഞങ്ങളുടെ വലിയ ക്ലസ്റ്ററിന് മുന്നിൽ താരതമ്യേന ചെറിയ മറ്റൊന്ന് ഞങ്ങൾ ചേർക്കുന്നു, അതിനെ ഫോട്ടോകാഷുകൾ എന്ന് വിളിക്കുന്നു. ഇത് അടിസ്ഥാനപരമായി ഒരു കാഷിംഗ് പ്രോക്സി മാത്രമാണ്.

ഉള്ളിൽ നിന്ന് എങ്ങനെ പ്രവർത്തിക്കും? ഇതാ ഞങ്ങളുടെ ഉപയോക്താവ്, ഇതാ സംഭരണം. എല്ലാം പഴയതുപോലെ തന്നെ. അതിനിടയിൽ നമ്മൾ എന്താണ് ചേർക്കുന്നത്?

ഇത് ഫിസിക്കൽ ലോക്കൽ ഡിസ്കുള്ള ഒരു യന്ത്രം മാത്രമാണ്, അത് വേഗതയേറിയതാണ്. ഇത് ഒരു SSD ഉപയോഗിച്ചാണ്, ഉദാഹരണത്തിന്. ഈ ഡിസ്കിൽ ചില തരത്തിലുള്ള പ്രാദേശിക കാഷെ സംഭരിച്ചിരിക്കുന്നു.

അത് കാഴ്ച്ചയ്ക് എന്ത് പോലെയിരിക്കും? ഉപയോക്താവ് ഫോട്ടോയ്‌ക്കായി ഒരു അഭ്യർത്ഥന അയയ്‌ക്കുന്നു. ലോക്കൽ കാഷെയിൽ NGINX അത് ആദ്യം തിരയുന്നു. ഇല്ലെങ്കിൽ, ഞങ്ങളുടെ സ്റ്റോറേജിലേക്ക് പ്രോക്‌സി_പാസ് ചെയ്യുക, അവിടെ നിന്ന് ഫോട്ടോ ഡൗൺലോഡ് ചെയ്‌ത് ഉപയോക്താവിന് നൽകുക.

എന്നാൽ ഇത് വളരെ നിസ്സാരമാണ്, ഉള്ളിൽ എന്താണ് സംഭവിക്കുന്നതെന്ന് വ്യക്തമല്ല. ഇത് ഇതുപോലെ പ്രവർത്തിക്കുന്നു.

കാഷെ യുക്തിപരമായി മൂന്ന് ലെയറുകളായി തിരിച്ചിരിക്കുന്നു. ഞാൻ "മൂന്ന് ലെയറുകൾ" എന്ന് പറയുമ്പോൾ, ഏതെങ്കിലും തരത്തിലുള്ള സങ്കീർണ്ണമായ സംവിധാനമുണ്ടെന്ന് ഇതിനർത്ഥമില്ല. ഇല്ല, ഇവ സോപാധികമായി ഫയൽ സിസ്റ്റത്തിലെ മൂന്ന് ഡയറക്ടറികൾ മാത്രമാണ്:

1. ഒരു പ്രോക്‌സിയിൽ നിന്ന് ഡൗൺലോഡ് ചെയ്‌ത ഫോട്ടോകൾ പോകുന്ന ഒരു ബഫറാണിത്.
2. നിലവിൽ സജീവമായി അഭ്യർത്ഥിച്ച ഫോട്ടോകൾ സംഭരിക്കുന്ന ഒരു ഹോട്ട് കാഷെയാണിത്.
3. കൂടാതെ ഒരു തണുത്ത കാഷെ, കുറച്ച് അഭ്യർത്ഥനകൾ വരുമ്പോൾ ഫോട്ടോകൾ ഹോട്ട് കാഷെയിൽ നിന്ന് ക്രമേണ പുറത്തേക്ക് തള്ളപ്പെടും.

ഇത് പ്രവർത്തിക്കുന്നതിന്, ഞങ്ങൾ എങ്ങനെയെങ്കിലും ഈ കാഷെ നിയന്ത്രിക്കേണ്ടതുണ്ട്, അതിലെ ഫോട്ടോകൾ പുനഃക്രമീകരിക്കേണ്ടതുണ്ട്. ഇതും വളരെ പ്രാകൃതമായ ഒരു പ്രക്രിയയാണ്.

Nginx ഓരോ അഭ്യർത്ഥനയ്ക്കും വേണ്ടി RAMDisk access.log-ലേക്ക് എഴുതുന്നു, അതിൽ അത് നിലവിൽ നൽകിയ ഫോട്ടോയിലേക്കുള്ള പാതയെ സൂചിപ്പിക്കുന്നു (ആപേക്ഷിക പാത്ത്, തീർച്ചയായും), ഏത് പാർട്ടീഷനാണ് അത് നൽകിയത്. ആ. അത് "ഫോട്ടോ 1" എന്ന് പറഞ്ഞേക്കാം, തുടർന്ന് ഒരു ബഫർ, അല്ലെങ്കിൽ ഒരു ഹോട്ട് കാഷെ, അല്ലെങ്കിൽ ഒരു തണുത്ത കാഷെ, അല്ലെങ്കിൽ ഒരു പ്രോക്സി.

ഇതിനെ ആശ്രയിച്ച്, ഫോട്ടോ ഉപയോഗിച്ച് എന്തുചെയ്യണമെന്ന് എങ്ങനെയെങ്കിലും തീരുമാനിക്കേണ്ടതുണ്ട്.

ഓരോ മെഷീനിലും ഒരു ചെറിയ ഡെമൺ പ്രവർത്തിക്കുന്നു, അത് ഈ ലോഗ് നിരന്തരം വായിക്കുകയും അതിന്റെ മെമ്മറിയിൽ ചില ഫോട്ടോഗ്രാഫുകളുടെ ഉപയോഗത്തെക്കുറിച്ചുള്ള സ്ഥിതിവിവരക്കണക്കുകൾ സൂക്ഷിക്കുകയും ചെയ്യുന്നു.

അവൻ അവിടെ ശേഖരിക്കുകയും കൗണ്ടറുകൾ സൂക്ഷിക്കുകയും ഇടയ്ക്കിടെ ഇനിപ്പറയുന്നവ ചെയ്യുകയും ചെയ്യുന്നു. സജീവമായി അഭ്യർത്ഥിച്ച ഫോട്ടോകൾ, അവയ്‌ക്കായി നിരവധി അഭ്യർത്ഥനകൾ ഉണ്ട്, അവ എവിടെയായിരുന്നാലും ഹോട്ട് കാഷെയിലേക്ക് അവൻ നീക്കുന്നു.

അപൂർവ്വമായി അഭ്യർത്ഥിക്കുന്നതും കുറച്ച് തവണ അഭ്യർത്ഥിക്കുന്നതുമായ ഫോട്ടോകൾ ചൂടുള്ള കാഷെയിൽ നിന്ന് ക്രമേണ തണുത്ത ഒന്നിലേക്ക് തള്ളപ്പെടും.

കാഷെയിൽ സ്ഥലമില്ലെങ്കിൽ, തണുത്ത കാഷെയിൽ നിന്ന് വിവേചനരഹിതമായി എല്ലാം ഇല്ലാതാക്കാൻ ഞങ്ങൾ തുടങ്ങുന്നു. കൂടാതെ, ഇത് നന്നായി പ്രവർത്തിക്കുന്നു.

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

ഈ സെർവറുകളിലുടനീളം അഭ്യർത്ഥനകൾ എങ്ങനെ വിതരണം ചെയ്യാം എന്നതാണ് അവശേഷിക്കുന്ന ചോദ്യം.

ഇരുപത് സ്റ്റോറേജ് മെഷീനുകളും മൂന്ന് കാഷിംഗ് സെർവറുകളും അടങ്ങിയ ഒരു ക്ലസ്റ്റർ ഉണ്ടെന്ന് നമുക്ക് പറയാം (ഇങ്ങനെയാണ് സംഭവിച്ചത്).

ഏതൊക്കെ ഫോട്ടോകൾക്കായുള്ള അഭ്യർത്ഥനകളാണെന്നും അവ എവിടെ ഇറക്കണമെന്നും ഞങ്ങൾ എങ്ങനെയെങ്കിലും നിർണ്ണയിക്കേണ്ടതുണ്ട്.

ഏറ്റവും സാധാരണമായ ഓപ്ഷൻ റൗണ്ട് റോബിൻ ആണ്. അതോ ആകസ്മികമായി ചെയ്തതാണോ?

ഇതിന് വ്യക്തമായും നിരവധി ദോഷങ്ങളുണ്ട്, കാരണം അത്തരം ഒരു സാഹചര്യത്തിൽ ഞങ്ങൾ കാഷെ വളരെ കാര്യക്ഷമമായി ഉപയോഗിക്കും. ചില ക്രമരഹിതമായ മെഷീനുകളിൽ അഭ്യർത്ഥനകൾ ഇറങ്ങും: ഇവിടെ അത് കാഷെ ചെയ്‌തു, എന്നാൽ അടുത്തതിൽ അത് ഇനി ഇല്ല. കൂടാതെ, ഇതെല്ലാം പ്രവർത്തിക്കുകയാണെങ്കിൽ, അത് വളരെ മോശമായിരിക്കും. ക്ലസ്റ്ററിൽ ചെറിയ എണ്ണം മെഷീനുകൾ ഉണ്ടെങ്കിലും.

ഏത് സെർവറാണ് ഏത് അഭ്യർത്ഥന ഇറക്കേണ്ടതെന്ന് ഞങ്ങൾ എങ്ങനെയെങ്കിലും സംശയരഹിതമായി നിർണ്ണയിക്കേണ്ടതുണ്ട്.

നിസ്സാരമായ ഒരു വഴിയുണ്ട്. ഞങ്ങൾ URL-ൽ നിന്ന് ഹാഷ് അല്ലെങ്കിൽ URL-ൽ ഉള്ള ഞങ്ങളുടെ ഷാർഡിംഗ് കീയിൽ നിന്ന് ഹാഷ് എടുത്ത് സെർവറുകളുടെ എണ്ണം കൊണ്ട് ഹരിക്കുന്നു. പ്രവർത്തിക്കുമോ? ഇഷ്ടം.

ആ. ഞങ്ങൾക്ക് ഒരു 2% അഭ്യർത്ഥനയുണ്ട്, ഉദാഹരണത്തിന്, ചില "example_url" എന്നതിനായി അത് എല്ലായ്‌പ്പോഴും "XNUMX" സൂചികയുള്ള സെർവറിൽ ലാൻഡ് ചെയ്യും, കൂടാതെ കാഷെ കഴിയുന്നത്ര മികച്ച രീതിയിൽ നീക്കംചെയ്യുകയും ചെയ്യും.

എന്നാൽ അത്തരമൊരു സ്കീമിൽ പുനർനിർമ്മിക്കുന്നതിൽ ഒരു പ്രശ്നമുണ്ട്. റീഷാർഡിംഗ് - സെർവറുകളുടെ എണ്ണം മാറ്റുക എന്നാണ് ഞാൻ ഉദ്ദേശിക്കുന്നത്.

ഞങ്ങളുടെ കാഷിംഗ് ക്ലസ്റ്ററിന് ഇനി നേരിടാൻ കഴിയില്ലെന്നും മറ്റൊരു മെഷീൻ ചേർക്കാൻ ഞങ്ങൾ തീരുമാനിക്കുമെന്നും നമുക്ക് അനുമാനിക്കാം.

നമുക്ക് കൂട്ടിച്ചേർക്കാം.

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

ഈ ഓപ്ഷൻ ഞങ്ങൾക്ക് അനുയോജ്യമല്ല.

അത്. നാം എന്തു ചെയ്യണം? ഞങ്ങൾ എങ്ങനെയെങ്കിലും കാഷെ കാര്യക്ഷമമായി ഉപയോഗിക്കണം, ഒരേ സെർവറിൽ ഒരേ അഭ്യർത്ഥന വീണ്ടും വീണ്ടും നൽകണം, പക്ഷേ വീണ്ടും ഷാർഡിംഗിനെ പ്രതിരോധിക്കണം. അത്തരമൊരു പരിഹാരമുണ്ട്, അത് അത്ര സങ്കീർണ്ണമല്ല. ഇതിനെ സ്ഥിരമായ ഹാഷിംഗ് എന്ന് വിളിക്കുന്നു.

ഇത് എങ്ങനെയിരിക്കും?

ഞങ്ങൾ ഷാർഡിംഗ് കീയിൽ നിന്ന് കുറച്ച് ഫംഗ്ഷൻ എടുക്കുകയും അതിന്റെ എല്ലാ മൂല്യങ്ങളും സർക്കിളിൽ പ്രചരിപ്പിക്കുകയും ചെയ്യുന്നു. ആ. പോയിന്റ് 0-ൽ, അതിന്റെ ഏറ്റവും കുറഞ്ഞതും കൂടിയതുമായ മൂല്യങ്ങൾ ഒത്തുചേരുന്നു. അടുത്തതായി, ഞങ്ങളുടെ എല്ലാ സെർവറുകളും ഏകദേശം ഈ രീതിയിൽ ഒരേ സർക്കിളിൽ സ്ഥാപിക്കുന്നു:

ഓരോ സെർവറും ഒരു പോയിന്റ് കൊണ്ട് നിർവചിച്ചിരിക്കുന്നു, അതിലേക്ക് ഘടികാരദിശയിൽ പോകുന്ന സെക്ടർ, അതനുസരിച്ച്, ഈ ഹോസ്റ്റ് നൽകുന്നു. അഭ്യർത്ഥനകൾ ഞങ്ങൾക്ക് വരുമ്പോൾ, ഞങ്ങൾ ഉടനടി കാണും, ഉദാഹരണത്തിന്, എ അഭ്യർത്ഥിക്കുക - അതിന് അവിടെ ഒരു ഹാഷ് ഉണ്ട് - അത് സെർവർ 2. അഭ്യർത്ഥന ബി - സെർവർ 3. എന്നിങ്ങനെ.

റീഷാർഡിംഗ് സമയത്ത് ഈ സാഹചര്യത്തിൽ എന്താണ് സംഭവിക്കുന്നത്?

മുമ്പത്തെപ്പോലെ ഞങ്ങൾ മുഴുവൻ കാഷെയും അസാധുവാക്കുന്നില്ല, എല്ലാ കീകളും മാറ്റുന്നില്ല, എന്നാൽ ഞങ്ങൾ ഓരോ സെക്ടറും ഒരു ചെറിയ ദൂരത്തേക്ക് മാറ്റുന്നു, അങ്ങനെ താരതമ്യേന പറഞ്ഞാൽ, ഞങ്ങൾ ചേർക്കാൻ ആഗ്രഹിക്കുന്ന ഞങ്ങളുടെ ആറാമത്തെ സെർവർ ശൂന്യമായ സ്ഥലത്തേക്ക് യോജിക്കുന്നു, കൂടാതെ ഞങ്ങൾ അത് അവിടെ ചേർക്കുന്നു.

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

നിഷേധങ്ങൾ മാത്രം ബാക്കി. ഏതെങ്കിലും തരത്തിലുള്ള കാർ പ്രവർത്തനരഹിതമാണെന്ന് നമുക്ക് അനുമാനിക്കാം.

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

ഇത് കാഷിംഗ് സിസ്റ്റത്തെക്കുറിച്ചാണ്. ഫലങ്ങൾ നോക്കാം.

ഇവിടെ സങ്കീർണ്ണമായ ഒന്നും തന്നെയില്ലെന്ന് തോന്നുന്നു. എന്നാൽ കാഷെ കൈകാര്യം ചെയ്യുന്നതിനുള്ള ഈ രീതി ഞങ്ങൾക്ക് ഏകദേശം 98% ട്രിക്ക് നിരക്ക് നൽകി. ആ. സെക്കൻഡിൽ ഈ 80 ആയിരം അഭ്യർത്ഥനകളിൽ, 1600 എണ്ണം മാത്രമേ സംഭരണത്തിലെത്തൂ, ഇത് തികച്ചും സാധാരണ ലോഡാണ്, അവർ അത് ശാന്തമായി സഹിക്കുന്നു, ഞങ്ങൾക്ക് എല്ലായ്പ്പോഴും ഒരു കരുതൽ ഉണ്ട്.

ഞങ്ങൾ ഈ സെർവറുകൾ ഞങ്ങളുടെ മൂന്ന് ഡിസികളിൽ സ്ഥാപിച്ചു, കൂടാതെ പ്രാഗ്, മിയാമി, ഹോങ്കോംഗ് എന്നീ മൂന്ന് പോയിന്റുകൾ ലഭിച്ചു.

അത്. നമ്മുടെ ഓരോ ലക്ഷ്യ വിപണിയിലും അവ ഏറിയും കുറഞ്ഞും പ്രാദേശികമായി സ്ഥിതിചെയ്യുന്നു.

ഒരു നല്ല ബോണസ് എന്ന നിലയിൽ, ഞങ്ങൾക്ക് ഈ കാഷിംഗ് പ്രോക്സി ലഭിച്ചു, അതിൽ CPU യഥാർത്ഥത്തിൽ നിഷ്‌ക്രിയമാണ്, കാരണം ഉള്ളടക്കം നൽകുന്നതിന് ഇത് അത്ര ആവശ്യമില്ല. അവിടെ, NGINX+ Lua ഉപയോഗിച്ച്, ഞങ്ങൾ ധാരാളം ഉപയോഗപ്രദമായ യുക്തികൾ നടപ്പിലാക്കി.

ഉദാഹരണത്തിന്, നമുക്ക് webp അല്ലെങ്കിൽ പുരോഗമന jpeg ഉപയോഗിച്ച് പരീക്ഷിക്കാം (ഇവ ഫലപ്രദമായ ആധുനിക ഫോർമാറ്റുകളാണ്), അത് ട്രാഫിക്കിനെ എങ്ങനെ ബാധിക്കുന്നുവെന്നത് കാണുക, ചില തീരുമാനങ്ങൾ എടുക്കുക, ചില രാജ്യങ്ങളിൽ ഇത് പ്രാപ്തമാക്കുക തുടങ്ങിയവ. ഡൈനാമിക് വലുപ്പം മാറ്റുക അല്ലെങ്കിൽ ഈച്ചയിൽ ഫോട്ടോകൾ ക്രോപ്പ് ചെയ്യുക.

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

ഹൈ-ലോഡ് സിസ്റ്റങ്ങളുടെ ഡെവലപ്പർമാരുടെ കോൺഫറൻസിന്റെ കഴിഞ്ഞ അഞ്ച് വർഷത്തെ വീഡിയോ റെക്കോർഡിംഗുകൾ ഞങ്ങൾ പൊതുവായി ലഭ്യമാക്കിയിട്ടുണ്ട്. ഹൈലോഡ്++. കാണുക, പഠിക്കുക, പങ്കിടുക, സബ്‌സ്‌ക്രൈബ് ചെയ്യുക YouTube ചാനൽ.

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

നമുക്ക് എന്താണ് ലഭിച്ചത്? ഞങ്ങൾക്ക് മൂന്ന് പോയിന്റ് സാന്നിധ്യം ലഭിച്ചു, ഒരു നല്ല ട്രിക്ക് നിരക്ക്, അതേ സമയം ഈ മെഷീനുകളിൽ ഞങ്ങൾക്ക് നിഷ്‌ക്രിയ സിപിയു ഇല്ല. അവൻ ഇപ്പോൾ, തീർച്ചയായും, മുമ്പത്തേക്കാൾ കൂടുതൽ പ്രാധാന്യം നേടിയിരിക്കുന്നു. നമുക്ക് ശക്തമായ കാറുകൾ നൽകേണ്ടതുണ്ട്, പക്ഷേ അത് വിലമതിക്കുന്നു.

ഇത് ഫോട്ടോഗ്രാഫുകളുടെ തിരിച്ചുവരവിനെ ബാധിക്കുന്നു. ഇവിടെ എല്ലാം വളരെ വ്യക്തവും വ്യക്തവുമാണ്. ഞാൻ അമേരിക്ക കണ്ടെത്തിയിട്ടില്ലെന്ന് ഞാൻ കരുതുന്നു, മിക്കവാറും എല്ലാ CDN-ഉം ഈ രീതിയിൽ പ്രവർത്തിക്കുന്നു.

കൂടാതെ, മിക്കവാറും, ഒരു സങ്കീർണ്ണമായ ശ്രോതാവിന് ഒരു ചോദ്യം ഉണ്ടായിരിക്കാം: എന്തുകൊണ്ട് എല്ലാം CDN-ലേക്ക് മാറ്റിക്കൂടാ? ഇത് ഏതാണ്ട് സമാനമായിരിക്കും; എല്ലാ ആധുനിക CDN-കൾക്കും ഇത് ചെയ്യാൻ കഴിയും. കൂടാതെ നിരവധി കാരണങ്ങളുണ്ട്.

ആദ്യത്തേത് ഫോട്ടോഗ്രാഫുകളാണ്.

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

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

രണ്ടാമത്തെ നിഗമനം ചരിത്രപരമാണ്, കാരണം സിസ്റ്റം വളരെക്കാലമായി വികസിച്ചുകൊണ്ടിരിക്കുന്നു, കൂടാതെ വ്യത്യസ്ത ഘട്ടങ്ങളിൽ നിരവധി വ്യത്യസ്ത ബിസിനസ്സ് ആവശ്യകതകൾ ഉണ്ടായിരുന്നു, അവ എല്ലായ്പ്പോഴും സിഡിഎൻ ആശയവുമായി പൊരുത്തപ്പെടുന്നില്ല.

മുമ്പത്തേതിൽ നിന്ന് പിന്തുടരുന്ന പോയിന്റ് ഇതാണ്

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

ഇത് എന്ത് നിഗമനമാണ് നിർദ്ദേശിക്കുന്നത്? ഞങ്ങളുടെ കാര്യത്തിൽ, CDN വളരെ നല്ല ബദലല്ല.

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

എന്നാൽ നിങ്ങൾക്ക് ഏതെങ്കിലും തരത്തിലുള്ള പൊതുവായ പരിഹാരമുണ്ടെങ്കിൽ, ചുമതല വളരെ നിർദ്ദിഷ്ടമല്ലെങ്കിൽ, നിങ്ങൾക്ക് തികച്ചും സുരക്ഷിതമായി ഒരു CDN എടുക്കാം. അല്ലെങ്കിൽ സമയവും വിഭവങ്ങളും നിങ്ങൾക്ക് നിയന്ത്രണത്തേക്കാൾ പ്രധാനമാണെങ്കിൽ.

ആധുനിക CDN-കളിൽ ഞാൻ ഇപ്പോൾ നിങ്ങളോട് പറഞ്ഞ എല്ലാ കാര്യങ്ങളും ഉണ്ട്. ചില സവിശേഷതകൾ പ്ലസ് അല്ലെങ്കിൽ മൈനസ് ഒഴികെ.

ഇത് ഫോട്ടോകൾ സമ്മാനിക്കുന്നതിനെക്കുറിച്ചാണ്.

നമുക്ക് ഇപ്പോൾ നമ്മുടെ മുൻകാലഘട്ടത്തിൽ കുറച്ച് മുന്നോട്ട് പോയി സംഭരണത്തെക്കുറിച്ച് സംസാരിക്കാം.

2013 കടന്നുപോയി.

കാഷിംഗ് സെർവറുകൾ ചേർത്തു, പ്രകടന പ്രശ്നങ്ങൾ ഇല്ലാതായി. എല്ലാം നന്നായിട്ടുണ്ട്. ഡാറ്റാസെറ്റ് വളരുകയാണ്. 2013-ലെ കണക്കനുസരിച്ച്, ഞങ്ങൾക്ക് ഏകദേശം 80 സെർവറുകൾ സംഭരണവുമായി ബന്ധിപ്പിച്ചിരുന്നു, കൂടാതെ ഓരോ ഡിസിയിലും ഏകദേശം 40 കാഷിംഗ് സെർവറുകളും ഉണ്ടായിരുന്നു. ഇത് ഓരോ ഡിസിയിലും 560 ടെറാബൈറ്റ് ഡാറ്റയാണ്, അതായത്. ആകെ ഒരു പെറ്റാബൈറ്റ്.

ഡാറ്റാസെറ്റിന്റെ വളർച്ചയോടെ, പ്രവർത്തന ചെലവ് ഗണ്യമായി ഉയരാൻ തുടങ്ങി. ഇത് എന്താണ് അർത്ഥമാക്കിയത്?

വരച്ചിരിക്കുന്ന ഈ ഡയഗ്രാമിൽ - ഒരു SAN ഉപയോഗിച്ച്, മെഷീനുകളും കാഷെകളും ബന്ധിപ്പിച്ച് - പരാജയത്തിന്റെ ഒരുപാട് പോയിന്റുകൾ ഉണ്ട്. കാഷിംഗ് സെർവറുകളുടെ പരാജയം ഞങ്ങൾ മുമ്പ് കൈകാര്യം ചെയ്തിരുന്നെങ്കിൽ, എല്ലാം കൂടുതലോ കുറവോ പ്രവചിക്കാവുന്നതും മനസ്സിലാക്കാവുന്നതുമാണ്, എന്നാൽ സ്റ്റോറേജ് വശത്ത് എല്ലാം വളരെ മോശമായിരുന്നു.

ഒന്നാമതായി, പരാജയപ്പെടാവുന്ന സ്റ്റോറേജ് ഏരിയ നെറ്റ്‌വർക്ക് (SAN) തന്നെ.

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

തീർച്ചയായും, SAN-ൽ ഉള്ളതുപോലെ അവയിൽ പലതും ഇല്ല, എന്നിരുന്നാലും, ഇവയും പരാജയത്തിന്റെ പോയിന്റുകളാണ്.

അടുത്തത് സംഭരണവുമായി ബന്ധിപ്പിച്ചിരിക്കുന്ന യന്ത്രം തന്നെയാണ്. അതും പരാജയപ്പെടാം.

മൊത്തത്തിൽ, ഞങ്ങൾക്ക് പരാജയത്തിന്റെ മൂന്ന് പോയിന്റുകൾ ഉണ്ട്.

കൂടാതെ, പരാജയത്തിന്റെ പോയിന്റുകൾക്ക് പുറമേ, സംഭരണത്തിന്റെ തന്നെ കനത്ത അറ്റകുറ്റപ്പണികൾ ഉണ്ട്.

ഇതൊരു സങ്കീർണ്ണമായ മൾട്ടി-ഘടക സംവിധാനമാണ്, കൂടാതെ സിസ്റ്റം എഞ്ചിനീയർമാർക്ക് ഇത് ഉപയോഗിച്ച് പ്രവർത്തിക്കാൻ ബുദ്ധിമുട്ടായിരിക്കും.

അവസാനത്തെ, ഏറ്റവും പ്രധാനപ്പെട്ട പോയിന്റ്. ഈ മൂന്ന് പോയിന്റുകളിൽ ഏതെങ്കിലും ഒരു പരാജയം സംഭവിക്കുകയാണെങ്കിൽ, ഫയൽ സിസ്റ്റം തകരാറിലായതിനാൽ ഉപയോക്തൃ ഡാറ്റ നഷ്‌ടപ്പെടാനുള്ള സാധ്യത പൂജ്യമല്ല.

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

ഇക്കാര്യത്തിൽ എന്തെങ്കിലും ചെയ്യണമായിരുന്നു. ഡാറ്റ ബാക്കപ്പ് ചെയ്യേണ്ടതുണ്ടെന്ന് ഞങ്ങൾ തീരുമാനിച്ചു. ഇത് യഥാർത്ഥത്തിൽ വ്യക്തമായ ഒരു പരിഹാരവും നല്ലതുമാണ്. നമ്മൾ എന്താണ് ചെയ്തത്?

ഞങ്ങളുടെ സെർവർ മുമ്പ് സ്‌റ്റോറേജിലേക്ക് കണക്‌റ്റ് ചെയ്‌തപ്പോൾ ഇങ്ങനെയായിരുന്നു. ഇത് ഒരു പ്രധാന വിഭാഗമാണ്, ഇത് യഥാർത്ഥത്തിൽ ഒപ്റ്റിക്സ് വഴിയുള്ള റിമോട്ട് സ്റ്റോറേജിനുള്ള മൗണ്ടിനെ പ്രതിനിധീകരിക്കുന്ന ഒരു ബ്ലോക്ക് ഉപകരണം മാത്രമാണ്.

ഞങ്ങൾ രണ്ടാമത്തെ വിഭാഗം ചേർത്തു.

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

ഇവിടെ ഞങ്ങൾ അടുത്തുള്ള ഒരു അസിൻക്രണസ് ക്യൂ ഉണ്ടാക്കുന്നു.

അവൾ വളരെ തിരക്കിലല്ല. ഞങ്ങൾക്ക് മതിയായ റെക്കോർഡുകളില്ലെന്ന് ഞങ്ങൾക്കറിയാം. ഒരു ക്യൂ എന്നത് MySQL-ലെ ഒരു പട്ടിക മാത്രമാണ്, അതിൽ "നിങ്ങൾ ഈ ഫോട്ടോ ബാക്കപ്പ് ചെയ്യണം" എന്നതുപോലുള്ള വരികൾ എഴുതിയിരിക്കുന്നു. എന്തെങ്കിലും മാറ്റം വരുത്തുകയോ അപ്‌ലോഡ് ചെയ്യുകയോ ചെയ്താൽ, ഒരു അസിൻക്രണസ് അല്ലെങ്കിൽ ഏതെങ്കിലും തരത്തിലുള്ള പശ്ചാത്തല വർക്കർ ഉപയോഗിച്ച് ഞങ്ങൾ പ്രധാന പാർട്ടീഷനിൽ നിന്ന് ബാക്കപ്പിലേക്ക് പകർത്തുന്നു.

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

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

ഞങ്ങൾ മൂന്നാമത്തെ ഡിസ്ക് ചേർത്തു, അത് ഒരു ചെറിയ SSD ആണ്, അതിനെ ഒരു ബഫർ എന്ന് വിളിച്ചു.

ഇപ്പോൾ എങ്ങനെ പ്രവർത്തിക്കുന്നു.

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

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

നന്നായി, ഏറ്റവും പ്രധാനമായി: ഞങ്ങൾ ഡാറ്റ നഷ്‌ടപ്പെടുന്നത് നിർത്തി.

നിർത്തിയെന്നു പറയാം സാധ്യതയുള്ള ഡാറ്റ നഷ്‌ടപ്പെടുക, കാരണം ഞങ്ങൾക്ക് അത് ശരിക്കും നഷ്‌ടമായില്ല. എന്നാൽ അപകടമുണ്ടായി. ഈ പരിഹാരം തീർച്ചയായും നല്ലതാണെന്ന് ഞങ്ങൾ കാണുന്നു, പക്ഷേ ഇത് പൂർണ്ണമായും പരിഹരിക്കുന്നതിനുപകരം പ്രശ്നത്തിന്റെ ലക്ഷണങ്ങളെ സുഗമമാക്കുന്നത് പോലെയാണ്. കൂടാതെ ചില പ്രശ്നങ്ങൾ ഇവിടെ അവശേഷിക്കുന്നു.

ഒന്നാമതായി, ഈ യന്ത്രങ്ങളെല്ലാം പ്രവർത്തിക്കുന്ന ഫിസിക്കൽ ഹോസ്റ്റിന്റെ രൂപത്തിൽ തന്നെ ഇത് പരാജയത്തിന്റെ ഒരു പോയിന്റാണ്; അത് പോയിട്ടില്ല.

രണ്ടാമതായി, SAN-കളിൽ ഇപ്പോഴും പ്രശ്നങ്ങൾ ഉണ്ട്, അവയുടെ കനത്ത അറ്റകുറ്റപ്പണികൾ മുതലായവ അവശേഷിക്കുന്നു. ഇത് ഒരു നിർണായക ഘടകമായിരുന്നില്ല, പക്ഷേ അതില്ലാതെ എങ്ങനെയെങ്കിലും ജീവിക്കാൻ ഞാൻ ആഗ്രഹിച്ചു.

ഞങ്ങൾ മൂന്നാമത്തെ പതിപ്പ് ഉണ്ടാക്കി (വാസ്തവത്തിൽ, രണ്ടാമത്തേത് യഥാർത്ഥത്തിൽ) - റിസർവേഷൻ പതിപ്പ്. അത് എങ്ങനെയുണ്ടായിരുന്നു?

ഇതായിരുന്നു അത് -

ഇത് ഒരു ഫിസിക്കൽ ഹോസ്റ്റാണ് എന്നതാണ് ഞങ്ങളുടെ പ്രധാന പ്രശ്നങ്ങൾ.

ആദ്യം, ഞങ്ങൾ SAN-കൾ നീക്കംചെയ്യുന്നു, കാരണം ഞങ്ങൾ പരീക്ഷണം നടത്താൻ ആഗ്രഹിക്കുന്നു, പ്രാദേശിക ഹാർഡ് ഡ്രൈവുകൾ മാത്രം പരീക്ഷിക്കാൻ ഞങ്ങൾ ആഗ്രഹിക്കുന്നു.

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

തുടർന്ന് ഞങ്ങൾ ഞങ്ങളുടെ ബാക്കപ്പ് പാർട്ടീഷൻ എടുത്ത് ഭൗതികമായി ഒരു പ്രത്യേക മെഷീനിലേക്ക് മാറ്റുന്നു.

അങ്ങനെ, നമുക്ക് ഈ ഡയഗ്രം ലഭിക്കും. ഒരേ ഡാറ്റാസെറ്റുകൾ സംഭരിക്കുന്ന രണ്ട് കാറുകൾ ഞങ്ങളുടെ പക്കലുണ്ട്. അവർ പരസ്പരം പൂർണ്ണമായി ബാക്കപ്പ് ചെയ്യുകയും അതേ MySQL-ലെ ഒരു അസിൻക്രണസ് ക്യൂ വഴി നെറ്റ്‌വർക്കിലൂടെ ഡാറ്റ സമന്വയിപ്പിക്കുകയും ചെയ്യുന്നു.

എന്തുകൊണ്ടാണ് ഇത് നന്നായി പ്രവർത്തിക്കുന്നത്, കാരണം ഞങ്ങൾക്ക് കുറച്ച് റെക്കോർഡുകൾ മാത്രമേയുള്ളൂ. ആ. എഴുത്ത് വായനയുമായി താരതമ്യപ്പെടുത്താവുന്നതാണെങ്കിൽ, ഒരുപക്ഷേ നമുക്ക് ഏതെങ്കിലും തരത്തിലുള്ള നെറ്റ്‌വർക്ക് ഓവർഹെഡും പ്രശ്നങ്ങളും ഉണ്ടാകാം. എഴുത്ത് കുറവാണ്, ധാരാളം വായനയുണ്ട് - ഈ രീതി നന്നായി പ്രവർത്തിക്കുന്നു, അതായത്. ഈ രണ്ട് സെർവറുകൾക്കിടയിൽ ഞങ്ങൾ അപൂർവ്വമായി ഫോട്ടോകൾ പകർത്തുന്നു.

ഇത് എങ്ങനെ പ്രവർത്തിക്കും, നിങ്ങൾ കുറച്ചുകൂടി വിശദമായി നോക്കിയാൽ.

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

ചുമതല കുറച്ചുകൂടി ബുദ്ധിമുട്ടാണ്.

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

അത് അവിടെ ഇല്ലെങ്കിൽ, ഞങ്ങൾ ഞങ്ങളുടെ അയൽക്കാരനോട് ഒരു അഭ്യർത്ഥന നടത്തുകയും അവിടെ നിന്ന് അത് സ്വീകരിക്കുമെന്ന് ഉറപ്പ് നൽകുകയും ചെയ്യുന്നു.

അത്. വീണ്ടും നമുക്ക് പറയാം: പ്രകടനത്തിൽ പ്രശ്നങ്ങൾ ഉണ്ടാകാം, കാരണം നിരന്തരമായ റൗണ്ട് ട്രിപ്പുകൾ ഉണ്ട് - ഫോട്ടോ അപ്ലോഡ് ചെയ്തു, അത് ഇവിടെ ഇല്ല, ഞങ്ങൾ ഒന്നിന് പകരം രണ്ട് അഭ്യർത്ഥനകൾ നടത്തുന്നു, ഇത് സാവധാനത്തിൽ പ്രവർത്തിക്കണം.

ഞങ്ങളുടെ സാഹചര്യത്തിൽ, ഇത് സാവധാനത്തിൽ പ്രവർത്തിക്കില്ല.

ഈ സിസ്റ്റത്തിൽ ഞങ്ങൾ ഒരു കൂട്ടം അളവുകൾ ശേഖരിക്കുന്നു, അത്തരമൊരു മെക്കാനിസത്തിന്റെ സോപാധികമായ സ്മാർട്ട് നിരക്ക് ഏകദേശം 95% ആണ്. ആ. ഈ ബാക്കപ്പിന്റെ കാലതാമസം ചെറുതാണ്, ഇതുമൂലം ഞങ്ങൾക്ക് ഏതാണ്ട് ഉറപ്പുണ്ട്, ഫോട്ടോ അപ്‌ലോഡ് ചെയ്‌ത ശേഷം, ഞങ്ങൾ അത് ആദ്യമായി എടുക്കും, രണ്ട് തവണ എവിടെയും പോകേണ്ടതില്ല.

അപ്പോൾ ശരിക്കും രസകരമായ മറ്റെന്താണ് നമുക്ക് ലഭിച്ചത്?

മുമ്പ്, ഞങ്ങൾക്ക് പ്രധാന ബാക്കപ്പ് പാർട്ടീഷൻ ഉണ്ടായിരുന്നു, അവയിൽ നിന്ന് ഞങ്ങൾ തുടർച്ചയായി വായിക്കുന്നു. ആ. ഞങ്ങൾ എല്ലായ്‌പ്പോഴും ആദ്യം പ്രധാനമായതിൽ തിരഞ്ഞു, തുടർന്ന് ബാക്കപ്പിലും. അതൊരു നീക്കമായിരുന്നു.

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

തെറ്റ് സഹിഷ്ണുതയെ സംബന്ധിച്ചിടത്തോളം. വാസ്തവത്തിൽ, ഞങ്ങൾ പ്രധാനമായും പോരാടിയത് ഇതിനുവേണ്ടിയാണ്. തെറ്റ് സഹിഷ്ണുതയോടെ, എല്ലാം ഇവിടെ മികച്ചതായി മാറി.

ഒരു കാർ തകരുന്നു.

ഒരു പ്രശ്നവുമില്ല! ഒരു സിസ്റ്റം എഞ്ചിനീയർ രാത്രിയിൽ പോലും ഉണരില്ല, അവൻ രാവിലെ വരെ കാത്തിരിക്കും, മോശമായ ഒന്നും സംഭവിക്കില്ല.

ഈ മെഷീൻ പരാജയപ്പെടുകയാണെങ്കിൽപ്പോലും, ക്യൂ പ്രവർത്തനരഹിതമാണെങ്കിൽ, പ്രശ്‌നങ്ങളൊന്നുമില്ല, ലോഗ് ആദ്യം ലിവിംഗ് മെഷീനിൽ അടിഞ്ഞുകൂടും, തുടർന്ന് അത് ക്യൂവിലേക്ക് ചേർക്കും, തുടർന്ന് കാറിലേക്ക് പോകും. കുറച്ച് സമയത്തിന് ശേഷം പ്രവർത്തനത്തിലേക്ക് പോകുക.

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

ഈ റിഡൻഡൻസി സ്കീമിൽ നിന്ന് എന്ത് നിഗമനങ്ങളിൽ എത്തിച്ചേരാനാകും?

ഞങ്ങൾക്ക് തെറ്റ് സഹിഷ്ണുത ലഭിച്ചു.

ഉപയോഗിക്കാൻ എളുപ്പമാണ്. മെഷീനുകൾക്ക് പ്രാദേശിക ഹാർഡ് ഡ്രൈവുകൾ ഉള്ളതിനാൽ, ഇത് ഉപയോഗിച്ച് പ്രവർത്തിക്കുന്ന എഞ്ചിനീയർമാർക്ക് പ്രവർത്തന വീക്ഷണകോണിൽ നിന്ന് ഇത് കൂടുതൽ സൗകര്യപ്രദമാണ്.

ഞങ്ങൾക്ക് ഇരട്ട വായന അലവൻസ് ലഭിച്ചു.

തെറ്റ് സഹിഷ്ണുത കൂടാതെ ഇത് വളരെ നല്ല ബോണസാണ്.

എന്നാൽ പ്രശ്നങ്ങളുമുണ്ട്. ഇപ്പോൾ ഞങ്ങൾക്ക് ഇതുമായി ബന്ധപ്പെട്ട ചില സവിശേഷതകളുടെ കൂടുതൽ സങ്കീർണ്ണമായ വികസനം ഉണ്ട്, കാരണം സിസ്റ്റം 100% ഒടുവിൽ സ്ഥിരതയുള്ളതായി മാറിയിരിക്കുന്നു.

ചില പശ്ചാത്തല ജോലികളിൽ നമ്മൾ നിരന്തരം ചിന്തിക്കണം: "നാം ഇപ്പോൾ ഏത് സെർവറിലാണ് പ്രവർത്തിക്കുന്നത്?", "ഇവിടെ ശരിക്കും ഒരു ഫോട്ടോ ഉണ്ടോ?" തുടങ്ങിയവ. ഇത് തീർച്ചയായും എല്ലാം പൊതിഞ്ഞതാണ്, ബിസിനസ്സ് ലോജിക് എഴുതുന്ന പ്രോഗ്രാമർക്ക് ഇത് സുതാര്യമാണ്. എന്നിരുന്നാലും, ഈ വലിയ സങ്കീർണ്ണ പാളി പ്രത്യക്ഷപ്പെട്ടു. എന്നാൽ അതിൽ നിന്ന് ലഭിച്ച നന്മകൾക്ക് പകരമായി ഇത് സഹിക്കാൻ ഞങ്ങൾ തയ്യാറാണ്.

ഇവിടെ വീണ്ടും ചില സംഘർഷങ്ങൾ ഉടലെടുക്കുന്നു.

ലോക്കൽ ഹാർഡ് ഡ്രൈവുകളിൽ എല്ലാം സൂക്ഷിക്കുന്നത് മോശമാണെന്ന് ഞാൻ തുടക്കത്തിൽ പറഞ്ഞു. ഇപ്പോൾ ഞാൻ പറയുന്നു, ഞങ്ങൾക്കിത് ഇഷ്ടപ്പെട്ടു.

അതെ, വാസ്തവത്തിൽ, കാലക്രമേണ സ്ഥിതി വളരെയധികം മാറി, ഇപ്പോൾ ഈ സമീപനത്തിന് ധാരാളം ഗുണങ്ങളുണ്ട്. ഒന്നാമതായി, നമുക്ക് കൂടുതൽ ലളിതമായ പ്രവർത്തനം ലഭിക്കും.

രണ്ടാമതായി, ഇത് കൂടുതൽ ഉൽപ്പാദനക്ഷമമാണ്, കാരണം ഞങ്ങൾക്ക് ഈ ഓട്ടോമാറ്റിക് കൺട്രോളറുകളോ ഡിസ്ക് ഷെൽഫുകളിലേക്കുള്ള കണക്ഷനുകളോ ഇല്ല.

അവിടെ ഒരു വലിയ അളവിലുള്ള യന്ത്രസാമഗ്രികൾ ഉണ്ട്, ഇവ ഒരു റെയ്ഡിനായി ഇവിടെ മെഷീനിൽ കൂട്ടിച്ചേർത്ത ഏതാനും ഡിസ്കുകൾ മാത്രമാണ്.

എന്നാൽ ദോഷങ്ങളുമുണ്ട്.

ഇന്നത്തെ വിലയിൽ പോലും SAN ഉപയോഗിക്കുന്നതിനേക്കാൾ ഏകദേശം 1,5 മടങ്ങ് കൂടുതലാണിത്. അതിനാൽ, ഞങ്ങളുടെ മുഴുവൻ വലിയ ക്ലസ്റ്ററും പ്രാദേശിക ഹാർഡ് ഡ്രൈവുകളുള്ള കാറുകളാക്കി മാറ്റേണ്ടതില്ലെന്ന് ഞങ്ങൾ തീരുമാനിക്കുകയും ഒരു ഹൈബ്രിഡ് പരിഹാരം ഉപേക്ഷിക്കാൻ തീരുമാനിക്കുകയും ചെയ്തു.

ഞങ്ങളുടെ മെഷീനുകളിൽ പകുതിയും ഹാർഡ് ഡ്രൈവുകളിൽ പ്രവർത്തിക്കുന്നു (നന്നായി, പകുതിയല്ല - ഒരുപക്ഷേ 30 ശതമാനം). ബാക്കിയുള്ളവ ആദ്യ റിസർവേഷൻ സ്കീം ഉണ്ടായിരുന്ന പഴയ കാറുകളാണ്. ഞങ്ങൾക്ക് പുതിയ ഡാറ്റയോ മറ്റെന്തെങ്കിലുമോ ആവശ്യമില്ലാത്തതിനാൽ ഞങ്ങൾ അവ റീമൗണ്ട് ചെയ്തു, ഒരു ഫിസിക്കൽ ഹോസ്റ്റിൽ നിന്ന് രണ്ടിലേക്ക് ഞങ്ങൾ മൗണ്ടുകൾ നീക്കി.

ഇപ്പോൾ ഞങ്ങൾക്ക് വായനയുടെ ഒരു വലിയ സ്റ്റോക്ക് ഉണ്ട്, ഞങ്ങൾ അത് വിപുലീകരിച്ചു. മുമ്പ് ഞങ്ങൾ ഒരു മെഷീനിൽ ഒരു സ്റ്റോറേജ് മൌണ്ട് ചെയ്തിരുന്നെങ്കിൽ, ഇപ്പോൾ നമ്മൾ നാല് മൌണ്ട് ചെയ്യുന്നു, ഉദാഹരണത്തിന്, ഒരു ജോഡിയിൽ. അത് നന്നായി പ്രവർത്തിക്കുന്നു.

നമ്മൾ എന്താണ് നേടിയത്, എന്തിന് വേണ്ടി പോരാടി, വിജയിച്ചോ എന്നതിന്റെ ഒരു ഹ്രസ്വ സംഗ്രഹം എടുക്കാം.

ഫലങ്ങൾ

ഞങ്ങൾക്ക് ഉപയോക്താക്കളുണ്ട് - 33 ദശലക്ഷം.

ഞങ്ങൾക്ക് മൂന്ന് സാന്നിധ്യമുണ്ട് - പ്രാഗ്, മിയാമി, ഹോങ്കോംഗ്.

അവയിൽ ഒരു കാഷിംഗ് ലെയർ അടങ്ങിയിരിക്കുന്നു, അതിൽ ഫാസ്റ്റ് ലോക്കൽ ഡിസ്കുകളുള്ള (എസ്എസ്ഡി) കാറുകൾ ഉൾപ്പെടുന്നു, അതിൽ NGINX-ൽ നിന്നുള്ള ലളിതമായ മെഷിനറികൾ, അതിന്റെ ആക്സസ്.ലോഗ്, പൈത്തൺ ഡെമണുകൾ എന്നിവ പ്രവർത്തിക്കുന്നു, ഇതെല്ലാം പ്രോസസ്സ് ചെയ്യുകയും കാഷെ നിയന്ത്രിക്കുകയും ചെയ്യുന്നു.

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

അടുത്തതായി വരുന്നത് സ്റ്റോറേജ് ലെയറാണ്, അതിൽ നമുക്ക് പരസ്പരം ബാക്കപ്പ് ചെയ്യുന്ന മെഷീനുകളുടെ ജോഡി ക്ലസ്റ്ററുകൾ ഉണ്ട്, അവ മാറുമ്പോഴെല്ലാം ഫയലുകൾ ഒന്നിൽ നിന്ന് മറ്റൊന്നിലേക്ക് അസമന്വിതമായി പകർത്തുന്നു.

കൂടാതെ, ഈ മെഷീനുകളിൽ ചിലത് പ്രാദേശിക ഹാർഡ് ഡ്രൈവുകളിൽ പ്രവർത്തിക്കുന്നു.

ഈ മെഷീനുകളിൽ ചിലത് SAN-കളുമായി ബന്ധിപ്പിച്ചിരിക്കുന്നു.

കൂടാതെ, ഒരു വശത്ത്, ഇത് ഉപയോഗിക്കാൻ കൂടുതൽ സൗകര്യപ്രദവും കുറച്ചുകൂടി ഉൽപ്പാദനക്ഷമതയുള്ളതുമാണ്, മറുവശത്ത്, പ്ലേസ്മെന്റ് സാന്ദ്രതയും ഒരു ജിഗാബൈറ്റിന്റെ വിലയും കണക്കിലെടുക്കുമ്പോൾ ഇത് സൗകര്യപ്രദമാണ്.

നമുക്ക് ലഭിച്ചതിന്റെയും അതെല്ലാം എങ്ങനെ വികസിച്ചു എന്നതിന്റെയും വാസ്തുവിദ്യയുടെ ഒരു ഹ്രസ്വ അവലോകനമാണിത്.

ക്യാപ്റ്റനിൽ നിന്നുള്ള കുറച്ച് ടിപ്പുകൾ, വളരെ ലളിതമാണ്.

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

ഞാനൊരു ഉദാഹരണം പറയാം. ചാറ്റുകളിലെ അറ്റാച്ച്‌മെന്റുകളിൽ നിന്ന് ഫോട്ടോകൾ അയയ്‌ക്കുന്ന മെഷീനുകളുടെ ഒരു കൂട്ടം ഞങ്ങളുടെ പക്കലുണ്ട്, 2009 മുതൽ ഈ സ്കീം അവിടെ പ്രവർത്തിക്കുന്നു, ആരും അതിൽ നിന്ന് കഷ്ടപ്പെടുന്നില്ല. എല്ലാവരും സുഖമായിരിക്കുന്നു, എല്ലാവർക്കും എല്ലാം ഇഷ്ടമാണ്.

അളക്കുന്നതിന്, ആദ്യം ഒരു കൂട്ടം മെട്രിക്കുകൾ തൂക്കിയിടുക, അവ നോക്കുക, തുടർന്ന് നിങ്ങൾക്ക് എന്താണ് അതൃപ്തിയുള്ളതെന്നും എന്താണ് മെച്ചപ്പെടുത്തേണ്ടതെന്നും തീരുമാനിക്കുക. ഇത് അളക്കാൻ, ഞങ്ങളുടെ പക്കൽ പിൻബ എന്ന ഒരു കൂൾ ടൂൾ ഉണ്ട്.

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

ആദ്യം ഞങ്ങൾ അത് അളന്നു, പിന്നെ ഞങ്ങൾ അത് മെച്ചപ്പെടുത്തി.

കൂടുതൽ. ഞങ്ങൾ കാഷെ ഉപയോഗിച്ച് വായന ഒപ്റ്റിമൈസ് ചെയ്യുന്നു, ഷാർഡിംഗ് ഉപയോഗിച്ച് എഴുതുന്നു, പക്ഷേ ഇത് ഒരു വ്യക്തമായ പോയിന്റാണ്.

കൂടുതൽ. നിങ്ങൾ ഇപ്പോൾ നിങ്ങളുടെ സിസ്റ്റം നിർമ്മിക്കാൻ തുടങ്ങുകയാണെങ്കിൽ, ഫോട്ടോകൾ മാറ്റമില്ലാത്ത ഫയലുകളായി മാറ്റുന്നതാണ് നല്ലത്. കാരണം, കാഷെ അസാധുവാക്കൽ, ഫോട്ടോയുടെ ശരിയായ പതിപ്പ് ലോജിക് എങ്ങനെ കണ്ടെത്തണം തുടങ്ങിയ പ്രശ്‌നങ്ങളുടെ ഒരു ക്ലാസ് നിങ്ങൾക്ക് ഉടനടി നഷ്ടപ്പെടും.

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

അടുത്ത പോയിന്റ്. ഈച്ചയിൽ വലുപ്പം മാറ്റുന്നതിനെക്കുറിച്ച്.

മുമ്പ്, ഉപയോക്താക്കൾ ഒരു ഫോട്ടോ അപ്‌ലോഡ് ചെയ്‌തപ്പോൾ, ഞങ്ങൾ ഉടനടി എല്ലാ അവസരങ്ങൾക്കുമായി, വ്യത്യസ്‌ത ക്ലയന്റുകൾക്കായി ഒരു കൂട്ടം വലുപ്പങ്ങൾ മുറിച്ചു, അവയെല്ലാം ഡിസ്‌കിലുണ്ടായിരുന്നു. ഇപ്പോൾ ഞങ്ങൾ ഇത് ഉപേക്ഷിച്ചു.

ഞങ്ങൾ മൂന്ന് പ്രധാന വലുപ്പങ്ങൾ മാത്രം അവശേഷിപ്പിച്ചു: ചെറുതും ഇടത്തരവും വലുതും. Uport-ൽ ഞങ്ങളോട് ആവശ്യപ്പെട്ടതിന് പിന്നിലുള്ള വലുപ്പത്തിൽ നിന്ന് മറ്റെല്ലാം ഞങ്ങൾ താഴ്ത്തുക, ഞങ്ങൾ അത് താഴ്ത്തി ഉപയോക്താവിന് നൽകുക.

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

കൂടാതെ ഇൻക്രിമെന്റൽ അസിൻക്രണസ് ബാക്കപ്പ് നല്ലതാണ്.

ഞങ്ങളുടെ പ്രാക്ടീസ് കാണിക്കുന്നത് പോലെ, മാറ്റിയ ഫയലുകൾ പകർത്താൻ കാലതാമസം വരുത്തുമ്പോൾ ഈ സ്കീം മികച്ച രീതിയിൽ പ്രവർത്തിക്കുന്നു.

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

ബന്ധങ്ങൾ

» bo0rsh201
» ബദൂ ബ്ലോഗ്

ഉയർന്ന ലോഡ് സിസ്റ്റങ്ങളുടെ ഡെവലപ്പർമാരുടെ കോൺഫറൻസിലെ മികച്ച പ്രസംഗങ്ങളിലൊന്നിന്റെ ട്രാൻസ്ക്രിപ്റ്റാണ് ഈ റിപ്പോർട്ട് ഹൈലോഡ്++. HighLoad++ 2017 കോൺഫറൻസിന് ഒരു മാസത്തിൽ താഴെ മാത്രമേ അവശേഷിക്കുന്നുള്ളൂ.

ഞങ്ങൾ ഇതിനകം അത് തയ്യാറാണ് കോൺഫറൻസ് പ്രോഗ്രാം, ഷെഡ്യൂൾ ഇപ്പോൾ സജീവമായി രൂപീകരിക്കുന്നു.

ഈ വർഷം ഞങ്ങൾ ആർക്കിടെക്ചറുകളുടെയും സ്കെയിലിംഗിന്റെയും വിഷയം പര്യവേക്ഷണം ചെയ്യുന്നത് തുടരുന്നു:

• ഒരു ബില്യൺ ഉപയോക്താക്കൾക്ക് എങ്ങനെ സേവനം നൽകാം, ട്രാഫിക്ക് ഒരു ടെറാബിറ്റ് നൽകാം / ഇഗോർ വാസിലീവ്
• VKontakte വ്യക്തിഗത സന്ദേശ ഡാറ്റാബേസ് ആദ്യം മുതൽ വീണ്ടും എഴുതുകയും പ്രവർത്തനരഹിതമാക്കാതെ അതിലേക്ക് മൈഗ്രേറ്റ് ചെയ്യുകയും ചെയ്യുന്നതെങ്ങനെ / ദിമിത്രി എഗോറോവ്
• വിൽപ്പനയിലൂടെയുള്ള മരണം: എങ്ങനെയാണ് Yandex.Money ബ്ലാക്ക് ഫ്രൈഡേയിലേക്ക് വേഗത്തിലാക്കാനും അതിജീവിക്കാനും ശ്രമിച്ചത് / അനറ്റോലി പ്ലാസ്കോവ്സ്കി
• ബാങ്കിന്റെ ഫ്രണ്ട്-എൻഡ് സിസ്റ്റത്തിന്റെ തെറ്റ്-സഹിഷ്ണുത ആർക്കിടെക്ചർ / റോമൻ ഷെഖോവ്ത്സോവ്, അലക്സി ഗ്രോമാച്ചിക്കോവ്
• പേയ്‌മെന്റ് സിസ്റ്റം ആർക്കിടെക്ചർ: ഏതാണ്ട് എന്റർപ്രൈസ് / ഫിലിപ്പ് ഡെൽഗാഡോ

ഉയർന്ന ലോഡ് സംവിധാനങ്ങൾ വികസിപ്പിക്കുന്നതിനുള്ള ഞങ്ങളുടെ ഓൺലൈൻ പരിശീലന കോഴ്‌സിലും ഞങ്ങൾ ഈ മെറ്റീരിയലുകളിൽ ചിലത് ഉപയോഗിക്കുന്നു ഹൈലോഡ്.ഗൈഡ് പ്രത്യേകം തിരഞ്ഞെടുത്ത അക്ഷരങ്ങൾ, ലേഖനങ്ങൾ, മെറ്റീരിയലുകൾ, വീഡിയോകൾ എന്നിവയുടെ ഒരു ശൃംഖലയാണ്. ഞങ്ങളുടെ പാഠപുസ്തകത്തിൽ ഇതിനകം 30-ലധികം അദ്വിതീയ മെറ്റീരിയലുകൾ അടങ്ങിയിരിക്കുന്നു. ബന്ധിപ്പിക്കുക!

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