VKontakte-ന്റെ വാസ്തുവിദ്യയെയും പ്രവർത്തനത്തെയും കുറിച്ചുള്ള പതിവ് ചോദ്യങ്ങൾ

VKontakte ന്റെ സൃഷ്ടിയുടെ ചരിത്രം വിക്കിപീഡിയയിലാണ്; ഇത് പവൽ തന്നെ പറഞ്ഞു. എല്ലാവർക്കും അവളെ ഇതിനകം അറിയാമെന്ന് തോന്നുന്നു. HighLoad++ Pavel-ലെ സൈറ്റിന്റെ ഇന്റേണലുകൾ, വാസ്തുവിദ്യ, ഘടന എന്നിവയെക്കുറിച്ച് 2010ൽ എന്നോട് പറഞ്ഞു. അതിനുശേഷം നിരവധി സെർവറുകൾ ചോർന്നു, അതിനാൽ ഞങ്ങൾ വിവരങ്ങൾ അപ്‌ഡേറ്റ് ചെയ്യും: ഞങ്ങൾ അത് വിച്ഛേദിക്കുകയും ഇൻസൈഡുകൾ പുറത്തെടുക്കുകയും തൂക്കുകയും സാങ്കേതിക വീക്ഷണകോണിൽ നിന്ന് വികെ ഉപകരണത്തെ നോക്കുകയും ചെയ്യും.

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

നാല് വർഷത്തിലേറെയായി ഞാൻ ബാക്കെൻഡുമായി ബന്ധപ്പെട്ട എല്ലാത്തരം ജോലികളും കൈകാര്യം ചെയ്യുന്നു.

• മീഡിയ അപ്‌ലോഡ് ചെയ്യുക, സംഭരിക്കുക, പ്രോസസ്സ് ചെയ്യുക, വിതരണം ചെയ്യുക: വീഡിയോ, ലൈവ് സ്ട്രീമിംഗ്, ഓഡിയോ, ഫോട്ടോകൾ, ഡോക്യുമെന്റുകൾ.
• ഇൻഫ്രാസ്ട്രക്ചർ, പ്ലാറ്റ്ഫോം, ഡെവലപ്പർ മോണിറ്ററിംഗ്, ലോഗുകൾ, റീജിയണൽ കാഷെകൾ, CDN, പ്രൊപ്രൈറ്ററി RPC പ്രോട്ടോക്കോൾ.
• ബാഹ്യ സേവനങ്ങളുമായുള്ള സംയോജനം: പുഷ് അറിയിപ്പുകൾ, ബാഹ്യ ലിങ്ക് പാഴ്‌സിംഗ്, RSS ഫീഡ്.
• വിവിധ ചോദ്യങ്ങളിൽ സഹപ്രവർത്തകരെ സഹായിക്കുന്നു, അതിനുള്ള ഉത്തരങ്ങൾ അജ്ഞാത കോഡിലേക്ക് ഡൈവിംഗ് ആവശ്യമാണ്.

ഈ സമയത്ത്, സൈറ്റിന്റെ പല ഘടകങ്ങളിലും എനിക്ക് ഒരു കൈ ഉണ്ടായിരുന്നു. ഈ അനുഭവം പങ്കിടാൻ ഞാൻ ആഗ്രഹിക്കുന്നു.

പൊതു വാസ്തുവിദ്യ

എല്ലാം, പതിവുപോലെ, അഭ്യർത്ഥനകൾ സ്വീകരിക്കുന്ന ഒരു സെർവർ അല്ലെങ്കിൽ സെർവറുകളുടെ കൂട്ടത്തിൽ ആരംഭിക്കുന്നു.

ഫ്രണ്ട് സെർവർ

ഫ്രണ്ട് സെർവർ HTTPS, RTMP, WSS എന്നിവ വഴിയുള്ള അഭ്യർത്ഥനകൾ സ്വീകരിക്കുന്നു.

എച്ച്ടിടിപിഎസ് - ഇവ സൈറ്റിന്റെ പ്രധാന, മൊബൈൽ വെബ് പതിപ്പുകൾക്കായുള്ള അഭ്യർത്ഥനകളാണ്: vk.com, m.vk.com, കൂടാതെ ഞങ്ങളുടെ API-യുടെ മറ്റ് ഔദ്യോഗിക, അനൗദ്യോഗിക ക്ലയന്റുകൾ: മൊബൈൽ ക്ലയന്റുകൾ, മെസഞ്ചർമാർ. ഞങ്ങൾക്ക് സ്വീകരണം ഉണ്ട് RTMP-പ്രത്യേക ഫ്രണ്ട് സെർവറുകളുള്ള തത്സമയ പ്രക്ഷേപണങ്ങൾക്കായുള്ള ട്രാഫിക്ക് WSS- സ്ട്രീമിംഗ് API-യ്ക്കുള്ള കണക്ഷനുകൾ.

സെർവറുകളിലെ HTTPS, WSS എന്നിവയ്‌ക്ക് ഇത് വിലമതിക്കുന്നു nginx. RTMP പ്രക്ഷേപണങ്ങൾക്കായി, ഞങ്ങൾ അടുത്തിടെ ഞങ്ങളുടെ സ്വന്തം പരിഹാരത്തിലേക്ക് മാറി കിവ്, എന്നാൽ ഇത് റിപ്പോർട്ടിന്റെ പരിധിക്കപ്പുറമാണ്. തെറ്റ് സഹിഷ്ണുതയ്ക്കായി, ഈ സെർവറുകൾ പൊതുവായ IP വിലാസങ്ങൾ പരസ്യപ്പെടുത്തുകയും ഗ്രൂപ്പുകളായി പ്രവർത്തിക്കുകയും ചെയ്യുന്നു, അതിലൂടെ സെർവറുകളിൽ ഒന്നിൽ എന്തെങ്കിലും പ്രശ്നമുണ്ടെങ്കിൽ, ഉപയോക്തൃ അഭ്യർത്ഥനകൾ നഷ്‌ടപ്പെടില്ല. HTTPS, WSS എന്നിവയ്‌ക്കായി, ഇതേ സെർവറുകൾ സിപിയു ലോഡിന്റെ ഭാഗമാകാൻ ട്രാഫിക് എൻക്രിപ്റ്റ് ചെയ്യുന്നു.

ഞങ്ങൾ WSS, RTMP എന്നിവയെ കുറിച്ച് കൂടുതൽ സംസാരിക്കില്ല, സാധാരണ ഒരു വെബ് പ്രോജക്റ്റുമായി ബന്ധപ്പെട്ടിരിക്കുന്ന സാധാരണ HTTPS അഭ്യർത്ഥനകളെ കുറിച്ച് മാത്രം.

ബാക്കെൻഡ്

മുൻവശത്ത് സാധാരണയായി ബാക്കെൻഡ് സെർവറുകൾ ഉണ്ട്. ക്ലയന്റുകളിൽ നിന്ന് ഫ്രണ്ട് സെർവറിന് ലഭിക്കുന്ന അഭ്യർത്ഥനകൾ അവർ പ്രോസസ്സ് ചെയ്യുന്നു.

ഈ kPHP സെർവറുകൾ, ഇതിൽ HTTP ഡെമൺ പ്രവർത്തിക്കുന്നു, കാരണം HTTPS ഇതിനകം ഡീക്രിപ്റ്റ് ചെയ്തിരിക്കുന്നു. kPHP ഓൺ ചെയ്യുന്ന ഒരു സെർവറാണ് പ്രീഫോർക്ക് മോഡലുകൾ: ഒരു മാസ്റ്റർ പ്രക്രിയ ആരംഭിക്കുന്നു, ഒരു കൂട്ടം ചൈൽഡ് പ്രോസസ്സുകൾ, അവർക്ക് ലിസണിംഗ് സോക്കറ്റുകൾ കൈമാറുന്നു, അവർ അവരുടെ അഭ്യർത്ഥനകൾ പ്രോസസ്സ് ചെയ്യുന്നു. ഈ സാഹചര്യത്തിൽ, ഉപയോക്താവിൽ നിന്നുള്ള ഓരോ അഭ്യർത്ഥനയ്‌ക്കിടയിലും പ്രോസസ്സുകൾ പുനരാരംഭിക്കില്ല, പക്ഷേ അവയുടെ അവസ്ഥ യഥാർത്ഥ പൂജ്യം മൂല്യത്തിലേക്ക് പുനഃസജ്ജമാക്കുക - പുനരാരംഭിക്കുന്നതിന് പകരം അഭ്യർത്ഥനയ്ക്ക് ശേഷം അഭ്യർത്ഥിക്കുക.

വിതരണം ലോഡുചെയ്യുക

ഞങ്ങളുടെ എല്ലാ ബാക്കെൻഡുകളും ഏത് അഭ്യർത്ഥനയും പ്രോസസ്സ് ചെയ്യാൻ കഴിയുന്ന ഒരു വലിയ മെഷീനുകളല്ല. ഞങ്ങൾ അവരെ പ്രത്യേക ഗ്രൂപ്പുകളായി തിരിച്ചിരിക്കുന്നു: പൊതുവായത്, മൊബൈൽ, എപിഐ, വീഡിയോ, സ്‌റ്റേജിംഗ്... ഒരു പ്രത്യേക ഗ്രൂപ്പ് മെഷീനുകളിലെ പ്രശ്‌നം മറ്റെല്ലാവരെയും ബാധിക്കില്ല. വീഡിയോയിൽ പ്രശ്‌നങ്ങളുണ്ടെങ്കിൽ, സംഗീതം കേൾക്കുന്ന ഉപയോക്താവിന് പ്രശ്‌നങ്ങളെക്കുറിച്ച് പോലും അറിയില്ല. ഏത് ബാക്കെൻഡിലേക്കാണ് അഭ്യർത്ഥന അയയ്‌ക്കേണ്ടതെന്ന് കോൺഫിഗറേഷൻ അനുസരിച്ച് മുൻവശത്തുള്ള nginx തീരുമാനിക്കുന്നു.

മെട്രിക് ശേഖരണവും പുനഃസന്തുലനവും

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

ഞങ്ങൾക്ക് അത്തരം ആയിരക്കണക്കിന് സെർവറുകൾ ഉണ്ട്. ഓരോ ഫിസിക്കൽ സെർവറും എല്ലാ കോറുകളും റീസൈക്കിൾ ചെയ്യുന്നതിനായി ഒരു kPHP ഗ്രൂപ്പ് പ്രവർത്തിപ്പിക്കുന്നു (കാരണം kPHP ഒറ്റ ത്രെഡാണ്).

ഉള്ളടക്ക സെർവർ

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

ഫയലുകൾ സംഭരിക്കുന്ന പതിനായിരക്കണക്കിന് ഫിസിക്കൽ സെർവറുകൾ ഞങ്ങളുടെ പക്കലുണ്ട്. ഉപയോക്താക്കൾ ഫയലുകൾ അപ്‌ലോഡ് ചെയ്യാൻ ഇഷ്ടപ്പെടുന്നു, അവ സംഭരിക്കാനും പങ്കിടാനും ഞങ്ങൾ ഇഷ്ടപ്പെടുന്നു. ഈ സെർവറുകളിൽ ചിലത് പ്രത്യേക pu/pp സെർവറുകൾ വഴി അടച്ചിരിക്കുന്നു.

pu/pp

നിങ്ങൾ VK-യിലെ നെറ്റ്‌വർക്ക് ടാബ് തുറന്നാൽ, നിങ്ങൾ pu/pp എന്ന് കണ്ടു.

എന്താണ് pu/pp? ഞങ്ങൾ ഒരു സെർവർ ഒന്നിനുപുറകെ ഒന്നായി അടയ്ക്കുകയാണെങ്കിൽ, അടച്ച സെർവറിലേക്ക് ഒരു ഫയൽ അപ്‌ലോഡ് ചെയ്യുന്നതിനും ഡൗൺലോഡ് ചെയ്യുന്നതിനും രണ്ട് ഓപ്ഷനുകൾ ഉണ്ട്: നേരിട്ട് മുഖാന്തിരം http://cs100500.userapi.com/path അഥവാ ഇന്റർമീഡിയറ്റ് സെർവർ വഴി - http://pu.vk.com/c100500/path.

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

ഈ സെർവറുകൾ HTTPS സെഷനുകൾ അവസാനിപ്പിക്കുകസ്റ്റോറേജിൽ നിന്ന് പ്രോസസ്സർ ലോഡ് നീക്കം ചെയ്യാൻ. കൂടാതെ, ഈ സെർവറുകളിൽ ഉപയോക്തൃ ഫയലുകൾ പ്രോസസ്സ് ചെയ്യുന്നതിനാൽ, ഈ മെഷീനുകളിൽ സംഭരിച്ചിരിക്കുന്ന സെൻസിറ്റീവ് വിവരങ്ങൾ കുറവാണ്, നല്ലത്. ഉദാഹരണത്തിന്, HTTPS എൻക്രിപ്ഷൻ കീകൾ.

മെഷീനുകൾ ഞങ്ങളുടെ മറ്റ് മെഷീനുകൾ അടച്ചിരിക്കുന്നതിനാൽ, അവയ്ക്ക് "വെളുത്ത" ബാഹ്യ ഐപികൾ നൽകാതിരിക്കാൻ ഞങ്ങൾക്ക് കഴിയും, കൂടാതെ "ചാര" നൽകുക. ഈ രീതിയിൽ ഞങ്ങൾ ഐപി പൂളിൽ സംരക്ഷിക്കുകയും മെഷീനുകളെ പുറത്തുള്ള ആക്‌സസ്സിൽ നിന്ന് സംരക്ഷിക്കുമെന്ന് ഉറപ്പ് നൽകുകയും ചെയ്തു - അതിൽ പ്രവേശിക്കാൻ ഐപി ഇല്ല.

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

ഈ സാഹചര്യത്തിലാണ് വിവാദമായത് ക്ലയന്റ് കുറച്ച് കണക്ഷനുകൾ സൂക്ഷിക്കുന്നു. നിരവധി മെഷീനുകൾക്ക് ഒരേ ഐപി ഉണ്ടെങ്കിൽ - ഒരേ ഹോസ്റ്റിൽ: pu.vk.com അല്ലെങ്കിൽ pp.vk.com, ക്ലയന്റ് ബ്രൗസറിന് ഒരു ഹോസ്റ്റിന് ഒരേസമയം അഭ്യർത്ഥനകളുടെ എണ്ണത്തിൽ പരിധിയുണ്ട്. എന്നാൽ സർവ്വവ്യാപിയായ HTTP/2 ന്റെ കാലത്ത് ഇത് അത്ര പ്രസക്തമല്ലെന്ന് ഞാൻ വിശ്വസിക്കുന്നു.

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

അധികം താമസിയാതെ ഞങ്ങൾക്ക് പ്രോക്സിയുടെ ഒരു മെച്ചപ്പെട്ട പതിപ്പ് ലഭിച്ചു. അവ സാധാരണക്കാരിൽ നിന്ന് എങ്ങനെ വ്യത്യാസപ്പെട്ടിരിക്കുന്നുവെന്നും ഇത് എന്തുകൊണ്ട് ആവശ്യമാണെന്നും ഇപ്പോൾ ഞാൻ നിങ്ങളോട് പറയും.

സൂര്യൻ

2017 സെപ്റ്റംബറിൽ, മുമ്പ് സൺ വാങ്ങിയ ഒറാക്കിൾ, ധാരാളം സൺ ജീവനക്കാരെ പിരിച്ചുവിട്ടു. ഈ നിമിഷം കമ്പനി ഇല്ലാതായി എന്ന് നമുക്ക് പറയാം. പുതിയ സിസ്റ്റത്തിനായി ഒരു പേര് തിരഞ്ഞെടുക്കുമ്പോൾ, ഞങ്ങളുടെ അഡ്മിനിസ്ട്രേറ്റർമാർ ഈ കമ്പനിയുടെ ഓർമ്മയ്ക്ക് ആദരാഞ്ജലി അർപ്പിക്കാൻ തീരുമാനിക്കുകയും പുതിയ സിസ്റ്റത്തിന് സൺ എന്ന് പേരിടുകയും ചെയ്തു. നമുക്കിടയിൽ നമ്മൾ അവളെ "സൂര്യന്മാർ" എന്ന് വിളിക്കുന്നു.

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

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

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

ഭാരം പിന്തുണ. ഇപ്പോൾ നമുക്ക് ആവശ്യാനുസരണം വ്യത്യസ്ത പവർ മെഷീനുകൾ ഇൻസ്റ്റാൾ ചെയ്യാൻ കഴിയും, കൂടാതെ, താൽക്കാലിക പ്രശ്‌നങ്ങളുണ്ടെങ്കിൽ, പ്രവർത്തിക്കുന്ന “സൂര്യന്മാരുടെ” ഭാരം മാറ്റുകയും അവയിലെ ലോഡ് കുറയ്ക്കുകയും ചെയ്യുന്നു, അങ്ങനെ അവ “വിശ്രമിച്ച്” വീണ്ടും പ്രവർത്തിക്കാൻ തുടങ്ങും.

ഉള്ളടക്ക ഐഡി പ്രകാരം പങ്കിടൽ. ഷാർഡിംഗിനെക്കുറിച്ചുള്ള രസകരമായ ഒരു കാര്യം: ഞങ്ങൾ സാധാരണയായി ഉള്ളടക്കം ഷാർഡ് ചെയ്യുന്നു, അങ്ങനെ വ്യത്യസ്ത ഉപയോക്താക്കൾ ഒരേ "സൂര്യൻ" വഴി ഒരേ ഫയലിലേക്ക് പോകും, ​​അങ്ങനെ അവർക്ക് ഒരു പൊതു കാഷെ ലഭിക്കും.

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

ഒരേ ഫയലിനായുള്ള അഭ്യർത്ഥനകളുടെ പൊട്ടിത്തെറിയെ ചെറുക്കുന്നതിന്, ഒരു പ്രത്യേക തരം ഉള്ളടക്കത്തിനായാണ് ഞങ്ങൾ ഈ പ്രദേശത്ത് ലഭ്യമായ എല്ലാ "സൂര്യന്മാരിലും" ഫയലുകൾ പ്രചരിപ്പിക്കുന്ന ഒരു മണ്ടൻ സ്കീം ഓണാക്കുന്നത്.

ഉള്ളിൽ നിന്ന് സൂര്യൻ

nginx-ൽ റിവേഴ്സ് പ്രോക്സി, റാമിൽ അല്ലെങ്കിൽ ഫാസ്റ്റ് Optane/NVMe ഡിസ്കുകളിൽ കാഷെ. ഉദാഹരണം: http://sun4-2.userapi.com/c100500/path - രണ്ടാമത്തെ സെർവർ ഗ്രൂപ്പായ നാലാമത്തെ മേഖലയിൽ സ്ഥിതി ചെയ്യുന്ന "സൂര്യൻ" എന്നതിലേക്കുള്ള ഒരു ലിങ്ക്. ഭൗതികമായി സെർവർ 100500-ൽ കിടക്കുന്ന പാത്ത് ഫയൽ ഇത് ക്ലോസ് ചെയ്യുന്നു.

മൂടി

ഞങ്ങളുടെ ആർക്കിടെക്ചറൽ സ്കീമിലേക്ക് ഞങ്ങൾ ഒരു നോഡ് കൂടി ചേർക്കുന്നു - കാഷിംഗ് എൻവയോൺമെന്റ്.

ലേഔട്ട് ഡയഗ്രം ചുവടെയുണ്ട് പ്രാദേശിക കാഷെകൾ, അവയിൽ ഏകദേശം 20 എണ്ണം ഉണ്ട്. കാഷെകളും "സൂര്യന്മാരും" സ്ഥിതി ചെയ്യുന്ന സ്ഥലങ്ങളാണിവ, അവയിലൂടെ ട്രാഫിക്ക് കാഷെ ചെയ്യാൻ കഴിയും.

ഇത് മൾട്ടിമീഡിയ ഉള്ളടക്കത്തിന്റെ കാഷിംഗ് ആണ്; ഉപയോക്തൃ ഡാറ്റയൊന്നും ഇവിടെ സംഭരിക്കില്ല - സംഗീതം, വീഡിയോ, ഫോട്ടോകൾ മാത്രം.

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

ഇത് എങ്ങനെ പ്രവർത്തിക്കുന്നു?

പ്രദേശം അനുസരിച്ച് ഫയലുകളുടെ ജനപ്രീതി ഞങ്ങൾ കണക്കാക്കുന്നു. ഉപയോക്താവ് സ്ഥിതിചെയ്യുന്ന പ്രാദേശിക കാഷെയുടെ എണ്ണവും ഫയൽ ഐഡന്റിഫയറും ഉണ്ട് - ഞങ്ങൾ ഈ ജോഡി എടുത്ത് ഓരോ ഡൗൺലോഡിലും റേറ്റിംഗ് വർദ്ധിപ്പിക്കും.

അതേ സമയം, പിശാചുക്കൾ - പ്രദേശങ്ങളിലെ സേവനങ്ങൾ - കാലാകാലങ്ങളിൽ API- യിൽ വന്ന് ഇങ്ങനെ പറയുന്നു: “ഞാൻ അത്തരമൊരു കാഷെയാണ്, എന്റെ പ്രദേശത്തെ ഏറ്റവും ജനപ്രിയമായ ഫയലുകളുടെ ഒരു ലിസ്റ്റ് എനിക്ക് തരൂ. ” റേറ്റിംഗ് പ്രകാരം അടുക്കിയ ഒരു കൂട്ടം ഫയലുകൾ API ഡെലിവർ ചെയ്യുന്നു, ഡെമൺ അവ ഡൗൺലോഡ് ചെയ്യുകയും പ്രദേശങ്ങളിലേക്ക് കൊണ്ടുപോകുകയും അവിടെ നിന്ന് ഫയലുകൾ ഡെലിവർ ചെയ്യുകയും ചെയ്യുന്നു. കാഷെകളിൽ നിന്ന് pu/pp ഉം Sun ഉം തമ്മിലുള്ള അടിസ്ഥാന വ്യത്യാസം ഇതാണ്: ഈ ഫയൽ കാഷെയിൽ ഇല്ലെങ്കിൽ പോലും, അവർ തങ്ങൾ വഴി ഫയൽ ഉടനടി നൽകുന്നു, കാഷെ ആദ്യം ഫയൽ സ്വയം ഡൗൺലോഡ് ചെയ്യുന്നു, തുടർന്ന് അത് തിരികെ നൽകാൻ തുടങ്ങുന്നു.

ഈ സാഹചര്യത്തിൽ നമുക്ക് ലഭിക്കും ഉള്ളടക്കം ഉപയോക്താക്കൾക്ക് കൂടുതൽ അടുത്തു നെറ്റ്‌വർക്ക് ലോഡ് വ്യാപിപ്പിക്കുകയും ചെയ്യുന്നു. ഉദാഹരണത്തിന്, മോസ്കോ കാഷെയിൽ നിന്ന് മാത്രം ഞങ്ങൾ തിരക്കുള്ള സമയങ്ങളിൽ 1 Tbit/s-ൽ കൂടുതൽ വിതരണം ചെയ്യുന്നു.

എന്നാൽ പ്രശ്നങ്ങളുണ്ട് - കാഷെ സെർവറുകൾ റബ്ബർ അല്ല. വളരെ ജനപ്രിയമായ ഉള്ളടക്കത്തിന്, ചിലപ്പോൾ ഒരു പ്രത്യേക സെർവറിന് മതിയായ നെറ്റ്‌വർക്ക് ഇല്ല. ഞങ്ങളുടെ കാഷെ സെർവറുകൾ 40-50 Gbit/s ആണ്, എന്നാൽ അത്തരമൊരു ചാനലിനെ പൂർണ്ണമായും തടസ്സപ്പെടുത്തുന്ന ഉള്ളടക്കമുണ്ട്. മേഖലയിലെ ജനപ്രിയ ഫയലുകളുടെ ഒന്നിലധികം പകർപ്പുകളുടെ സംഭരണം നടപ്പിലാക്കുന്നതിലേക്ക് ഞങ്ങൾ നീങ്ങുകയാണ്. വർഷാവസാനത്തോടെ ഞങ്ങൾ ഇത് നടപ്പിലാക്കുമെന്ന് ഞാൻ പ്രതീക്ഷിക്കുന്നു.

ഞങ്ങൾ പൊതു വാസ്തുവിദ്യ നോക്കി.

• അഭ്യർത്ഥനകൾ സ്വീകരിക്കുന്ന ഫ്രണ്ട് സെർവറുകൾ.
• അഭ്യർത്ഥനകൾ പ്രോസസ്സ് ചെയ്യുന്ന ബാക്കൻഡുകൾ.
• രണ്ട് തരം പ്രോക്സികൾ ഉപയോഗിച്ച് അടച്ച സ്റ്റോറേജുകൾ.
• പ്രാദേശിക കാഷെകൾ.

ഈ ഡയഗ്രാമിൽ എന്താണ് നഷ്ടമായത്? തീർച്ചയായും, ഞങ്ങൾ ഡാറ്റ സംഭരിക്കുന്ന ഡാറ്റാബേസുകൾ.

ഡാറ്റാബേസുകൾ അല്ലെങ്കിൽ എഞ്ചിനുകൾ

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

ഇത് ആവശ്യമായ നടപടിയാണ്. ഇത് സംഭവിച്ചത് 2008-2009 ൽ, വികെയ്ക്ക് ജനപ്രീതിയിൽ സ്ഫോടനാത്മകമായ വളർച്ചയുണ്ടായപ്പോൾ, പദ്ധതി പൂർണ്ണമായും MySQL, Memcache എന്നിവയിൽ പ്രവർത്തിക്കുകയും പ്രശ്‌നങ്ങൾ ഉണ്ടാകുകയും ചെയ്തു. MySQL ക്രാഷ് ചെയ്യാനും ഫയലുകൾ കേടാക്കാനും ഇഷ്ടപ്പെട്ടു, അതിനുശേഷം അത് വീണ്ടെടുക്കില്ല, കൂടാതെ മെംകാഷെ ക്രമേണ പ്രകടനത്തിൽ കുറയുകയും പുനരാരംഭിക്കുകയും ചെയ്തു.

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

പരിഹാരം വിജയകരമായിരുന്നു. അക്കാലത്ത് സ്കെയിലിംഗിന്റെ മറ്റ് മാർഗങ്ങൾ നിലവിലില്ല എന്നതിനാൽ ഇത് ചെയ്യാനുള്ള അവസരവും അങ്ങേയറ്റത്തെ ആവശ്യകതയും ഉണ്ടായിരുന്നു. ഒരു കൂട്ടം ഡാറ്റാബേസുകൾ ഉണ്ടായിരുന്നില്ല, NoSQL ഇതുവരെ നിലവിലില്ല, MySQL, Memcache, PostrgreSQL എന്നിവ മാത്രമേ ഉണ്ടായിരുന്നുള്ളൂ - അത്രമാത്രം.

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

എഞ്ചിനുകളുടെ തരങ്ങൾ

ടീം കുറച്ച് എഞ്ചിനുകൾ എഴുതി. അവയിൽ ചിലത് ഇവിടെയുണ്ട്: സുഹൃത്ത്, സൂചനകൾ, ചിത്രം, ipdb, അക്ഷരങ്ങൾ, ലിസ്റ്റുകൾ, ലോഗുകൾ, memcached, meowdb, news, nostradamus, ഫോട്ടോ, പ്ലേലിസ്റ്റുകൾ, pmemcached, sandbox, തിരയൽ, സംഭരണം, ലൈക്കുകൾ, ടാസ്ക്കുകൾ, ...

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

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

ക്ലസ്റ്ററുകൾ

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

കോഡിന് ഫിസിക്കൽ ലൊക്കേഷനോ വലുപ്പമോ സെർവറുകളുടെ എണ്ണമോ അറിയേണ്ടതില്ല. ഒരു പ്രത്യേക ഐഡന്റിഫയർ ഉപയോഗിച്ച് അവൻ ക്ലസ്റ്ററിലേക്ക് പോകുന്നു.

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

RPC പ്രോക്സി

പ്രോക്സി ബന്ധിപ്പിക്കുന്ന ബസ്, അതിൽ ഏതാണ്ട് മുഴുവൻ സൈറ്റും പ്രവർത്തിക്കുന്നു. അതേ സമയം നമുക്കുണ്ട് സേവന കണ്ടെത്തലുകളൊന്നുമില്ല - പകരം, ഈ പ്രോക്സിക്കായി ഒരു കോൺഫിഗറേഷൻ ഉണ്ട്, അത് ഈ ക്ലസ്റ്ററിന്റെ എല്ലാ ക്ലസ്റ്ററുകളുടെയും എല്ലാ ഭാഗങ്ങളുടെയും സ്ഥാനം അറിയുന്നു. ഇതാണ് അഡ്മിൻമാർ ചെയ്യുന്നത്.

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

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

നിർദ്ദിഷ്ട നടപ്പാക്കലുകൾ

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

ഇപ്പോഴും അവിടെയും ഇവിടെയുമുള്ള MySQL-ന്, ഞങ്ങൾ db-proxy ഉപയോഗിക്കുന്നു, കൂടാതെ ClickHouse-ന് - പൂച്ചക്കുട്ടി.

ഇത് പൊതുവെ ഇതുപോലെയാണ് പ്രവർത്തിക്കുന്നത്. ഒരു നിശ്ചിത സെർവർ ഉണ്ട്, അത് kPHP, Go, Python - പൊതുവേ, ഞങ്ങളുടെ RPC പ്രോട്ടോക്കോൾ ഉപയോഗിക്കാനാകുന്ന ഏത് കോഡും പ്രവർത്തിക്കുന്നു. കോഡ് പ്രാദേശികമായി ഒരു RPC പ്രോക്സിയിൽ പ്രവർത്തിക്കുന്നു - കോഡ് സ്ഥിതി ചെയ്യുന്ന ഓരോ സെർവറും അതിന്റേതായ പ്രാദേശിക പ്രോക്സി പ്രവർത്തിപ്പിക്കുന്നു. അഭ്യർത്ഥന പ്രകാരം, എവിടെ പോകണമെന്ന് പ്രോക്സി മനസ്സിലാക്കുന്നു.

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

എല്ലാ എഞ്ചിനുകളും പ്രവർത്തിക്കുന്ന ഒരു ടിഎൽ-സ്കീമിന്റെ ഉദാഹരണം.

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

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

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

ടിസിപി/യുഡിപി...

TL സ്കീമിന് മുകളിൽ പ്രവർത്തിക്കുന്ന എഞ്ചിൻ അഭ്യർത്ഥനകൾ നടപ്പിലാക്കുന്നതിനായി ഞങ്ങൾക്ക് ഒരു RPC പ്രോട്ടോക്കോൾ ഉണ്ട്. ഇതെല്ലാം TCP/UDP കണക്ഷനിലൂടെ പ്രവർത്തിക്കുന്നു. ടിസിപി മനസ്സിലാക്കാവുന്നതേയുള്ളൂ, പക്ഷേ നമുക്ക് പലപ്പോഴും യുഡിപി ആവശ്യമായി വരുന്നത് എന്തുകൊണ്ട്?

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

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

അതെ, എല്ലാം പ്രവർത്തിക്കുന്നു പാക്കറ്റ് നഷ്ടത്തിന്റെ വളരെ ചെറിയ ശതമാനം. റീട്രാൻസ്മിറ്റുകൾക്കും ടൈംഔട്ടുകൾക്കും പ്രോട്ടോക്കോളിന് പിന്തുണയുണ്ട്, എന്നാൽ നമുക്ക് ഒരുപാട് നഷ്ടപ്പെട്ടാൽ, നമുക്ക് ഏതാണ്ട് TCP ലഭിക്കും, അത് പ്രയോജനകരമല്ല. ഞങ്ങൾ UDP-യെ സമുദ്രങ്ങളിലൂടെ നയിക്കില്ല.

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

സ്ഥിരമായ ഡാറ്റ സംഭരണം

എഞ്ചിനുകൾ ബിൻലോഗുകൾ എഴുതുന്നു. ബിൻലോഗ് എന്നത് ഒരു ഫയലാണ്, അതിന്റെ അവസാനത്തിൽ സ്ഥിതിയിലോ ഡാറ്റയിലോ മാറ്റത്തിനായി ഒരു ഇവന്റ് ചേർക്കുന്നു. വ്യത്യസ്ത പരിഹാരങ്ങളിൽ ഇതിനെ വ്യത്യസ്തമായി വിളിക്കുന്നു: ബൈനറി ലോഗ്, വാൾ, AOF, എന്നാൽ തത്വം ഒന്നുതന്നെയാണ്.

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

പ്രവർത്തന തത്വം ഞാൻ വേഗത്തിൽ വിവരിക്കും. എഞ്ചിൻ പ്രവർത്തിക്കുന്ന ഒരു സെർവർ ഉണ്ട്. അവൻ എഴുതുന്നതിനായി ഒരു പുതിയ ശൂന്യമായ ബിൻലോഗ് തുറക്കുകയും അതിൽ മാറ്റത്തിനായി ഒരു ഇവന്റ് എഴുതുകയും ചെയ്യുന്നു.

ചില ഘട്ടങ്ങളിൽ, അവൻ ഒന്നുകിൽ സ്വയം ഒരു സ്നാപ്പ്ഷോട്ട് എടുക്കാൻ തീരുമാനിക്കുന്നു, അല്ലെങ്കിൽ അയാൾക്ക് ഒരു സിഗ്നൽ ലഭിക്കും. സെർവർ ഒരു പുതിയ ഫയൽ സൃഷ്ടിക്കുന്നു, അതിന്റെ മുഴുവൻ അവസ്ഥയും അതിൽ എഴുതുന്നു, നിലവിലെ ബിൻലോഗ് വലുപ്പം - ഓഫ്സെറ്റ് - ഫയലിന്റെ അവസാനം കൂട്ടിച്ചേർക്കുന്നു, തുടർന്ന് എഴുതുന്നത് തുടരുന്നു. ഒരു പുതിയ ബിൻലോഗ് സൃഷ്‌ടിച്ചിട്ടില്ല.

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

സ്‌നാപ്പ്‌ഷോട്ട് സൃഷ്‌ടിച്ച സമയത്തുണ്ടായിരുന്ന സ്ഥാനവും ബിൻലോഗിന്റെ വലുപ്പവും വായിക്കുന്നു.

നിലവിലെ അവസ്ഥ ലഭിക്കാൻ ബിൻലോഗിന്റെ അവസാനം വായിക്കുകയും കൂടുതൽ ഇവന്റുകൾ എഴുതുന്നത് തുടരുകയും ചെയ്യുന്നു. ഇതൊരു ലളിതമായ സ്കീമാണ്; ഞങ്ങളുടെ എല്ലാ എഞ്ചിനുകളും അതിനനുസരിച്ച് പ്രവർത്തിക്കുന്നു.

ഡാറ്റ റെപ്ലിക്കേഷൻ

തൽഫലമായി, ഞങ്ങളുടെ ഡാറ്റയുടെ പകർപ്പ് പ്രസ്താവന അടിസ്ഥാനമാക്കിയുള്ളത് — ഞങ്ങൾ ബിൻലോഗിൽ എഴുതുന്നത് പേജ് മാറ്റങ്ങളല്ല, മറിച്ച് അഭ്യർത്ഥനകൾ മാറ്റുക. നെറ്റ്‌വർക്കിൽ വരുന്നതുമായി വളരെ സാമ്യമുണ്ട്, ചെറുതായി പരിഷ്‌ക്കരിച്ചു.

അതേ സ്കീം തനിപ്പകർപ്പിനായി മാത്രമല്ല, മാത്രമല്ല ഉപയോഗിക്കുന്നത് ബാക്കപ്പുകൾ സൃഷ്ടിക്കാൻ. ഞങ്ങൾക്ക് ഒരു എഞ്ചിൻ ഉണ്ട് - ബിൻലോഗിലേക്ക് എഴുതുന്ന ഒരു റൈറ്റിംഗ് മാസ്റ്റർ. അഡ്‌മിനുകൾ ഇത് സജ്ജീകരിച്ച മറ്റേതെങ്കിലും സ്ഥലത്ത്, ഈ ബിൻലോഗ് പകർത്തി, അത്രമാത്രം - ഞങ്ങൾക്ക് ഒരു ബാക്കപ്പ് ഉണ്ട്.

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

ഇവിടെയുള്ള കാലതാമസം വളരെ ചെറുതാണ്, കൂടാതെ പകർപ്പ് മാസ്റ്ററിന് എത്രമാത്രം പിന്നിലാണെന്ന് കണ്ടെത്താൻ കഴിയും.

RPC പ്രോക്‌സിയിൽ ഡാറ്റ പങ്കിടൽ

ഷാർഡിംഗ് എങ്ങനെയാണ് പ്രവർത്തിക്കുന്നത്? ഏത് ക്ലസ്റ്റർ ഷാർഡിലേക്കാണ് അയയ്ക്കേണ്ടതെന്ന് പ്രോക്സി എങ്ങനെ മനസ്സിലാക്കും? കോഡ് പറയുന്നില്ല: "15 കഷ്ണങ്ങൾക്കായി അയയ്ക്കുക!" - ഇല്ല, ഇത് ചെയ്യുന്നത് പ്രോക്സിയാണ്.

ഏറ്റവും ലളിതമായ സ്കീം ഫസ്റ്റ്ഇന്റ് ആണ് - അഭ്യർത്ഥനയിലെ ആദ്യ നമ്പർ.

get(photo100_500) => 100 % N.

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

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

ക്ലസ്റ്ററിലുടനീളം അഭ്യർത്ഥനകൾ എങ്ങനെ വ്യാപിക്കുന്നുവെന്ന് ഞങ്ങൾ ശ്രദ്ധിക്കുന്നില്ലെങ്കിൽ, മറ്റൊരു ഓപ്ഷൻ ഉണ്ട് - മുഴുവൻ ഷാർഡും ഹാഷ് ചെയ്യുന്നു.

hash(photo100_500) => 3539886280 % N

നമുക്ക് ഹാഷ്, ഡിവിഷന്റെ ബാക്കി ഭാഗം, ഷാർഡ് നമ്പർ എന്നിവയും ലഭിക്കും.

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

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

സൂപ്പർ-നിർദ്ദിഷ്ട അഭ്യർത്ഥനകളുണ്ട്. ഇത് ഇതുപോലെ കാണപ്പെടുന്നു: RPC പ്രോക്സി അഭ്യർത്ഥന സ്വീകരിക്കുന്നു, ഏത് ക്ലസ്റ്ററിലേക്കാണ് പോകേണ്ടതെന്ന് നിർണ്ണയിക്കുകയും ഷാർഡ് നിർണ്ണയിക്കുകയും ചെയ്യുന്നു. തുടർന്ന് ഒന്നുകിൽ റൈറ്റിംഗ് മാസ്റ്റേഴ്സ് ഉണ്ട്, അല്ലെങ്കിൽ, ക്ലസ്റ്ററിന് പകർപ്പ് പിന്തുണയുണ്ടെങ്കിൽ, അത് ആവശ്യാനുസരണം ഒരു പകർപ്പിലേക്ക് അയയ്ക്കുന്നു. പ്രോക്സിയാണ് ഇതെല്ലാം ചെയ്യുന്നത്.

രേഖകൾ

ഞങ്ങൾ പല തരത്തിൽ ലോഗുകൾ എഴുതുന്നു. ഏറ്റവും വ്യക്തവും ലളിതവുമായ ഒന്ന് മെംകാഷിലേക്ക് ലോഗുകൾ എഴുതുക.

ring-buffer: prefix.idx = line

ഒരു കീ പ്രിഫിക്‌സ് ഉണ്ട് - ലോഗിന്റെ പേര്, ഒരു വരി, ഈ ലോഗിന്റെ വലുപ്പമുണ്ട് - വരികളുടെ എണ്ണം. 0 മുതൽ വരികളുടെ എണ്ണം മൈനസ് 1 വരെയുള്ള ഒരു ക്രമരഹിത സംഖ്യ ഞങ്ങൾ എടുക്കുന്നു. ഈ ക്രമരഹിത സംഖ്യയുമായി സംയോജിപ്പിച്ചിരിക്കുന്ന ഒരു പ്രിഫിക്സാണ് മെംകാഷിലെ കീ. ഞങ്ങൾ ലോഗ് ലൈനും നിലവിലെ സമയവും മൂല്യത്തിലേക്ക് സംരക്ഷിക്കുന്നു.

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

ലോഗുകളുടെ വിശ്വസനീയമായ സംഭരണത്തിനായി ഞങ്ങൾക്ക് ഒരു എഞ്ചിൻ ഉണ്ട് ലോഗ്സ്-എഞ്ചിൻ. അതുകൊണ്ടാണ് ഇത് സൃഷ്ടിക്കപ്പെട്ടതും ധാരാളം ക്ലസ്റ്ററുകളിൽ വ്യാപകമായി ഉപയോഗിക്കുന്നതും. എനിക്കറിയാവുന്ന ഏറ്റവും വലിയ ക്ലസ്റ്ററിൽ 600 TB പായ്ക്ക് ചെയ്ത ലോഗുകൾ ഉണ്ട്.

എഞ്ചിൻ വളരെ പഴയതാണ്, ഇതിനകം 6-7 വർഷം പഴക്കമുള്ള ക്ലസ്റ്ററുകളുണ്ട്. ഞങ്ങൾ പരിഹരിക്കാൻ ശ്രമിക്കുന്ന പ്രശ്‌നങ്ങളുണ്ട്, ഉദാഹരണത്തിന്, ലോഗുകൾ സംഭരിക്കുന്നതിന് ഞങ്ങൾ ക്ലിക്ക്ഹൗസ് സജീവമായി ഉപയോഗിക്കാൻ തുടങ്ങി.

ClickHouse-ൽ ലോഗുകൾ ശേഖരിക്കുന്നു

ഈ ഡയഗ്രം നമ്മുടെ എഞ്ചിനുകളിലേക്ക് എങ്ങനെ നടക്കുന്നു എന്ന് കാണിക്കുന്നു.

ആർപിസി വഴി പ്രാദേശികമായി ആർപിസി-പ്രോക്സിയിലേക്ക് പോകുന്ന കോഡ് ഉണ്ട്, എഞ്ചിനിലേക്ക് എവിടെ പോകണമെന്ന് അത് മനസ്സിലാക്കുന്നു. ക്ലിക്ക്ഹൗസിൽ ലോഗുകൾ എഴുതണമെങ്കിൽ, ഈ സ്കീമിൽ രണ്ട് ഭാഗങ്ങൾ മാറ്റേണ്ടതുണ്ട്:

• ക്ലിക്ക്ഹൗസ് ഉപയോഗിച്ച് കുറച്ച് എഞ്ചിൻ മാറ്റിസ്ഥാപിക്കുക;
• ClickHouse-ലേക്ക് ആക്‌സസ് ചെയ്യാൻ കഴിയാത്ത RPC പ്രോക്‌സി മാറ്റി പകരം RPC വഴിയും സാധ്യമായ ചില പരിഹാരങ്ങൾ നൽകുക.

എഞ്ചിൻ ലളിതമാണ് - ഞങ്ങൾ അതിനെ ഒരു സെർവർ അല്ലെങ്കിൽ ക്ലിക്ക്ഹൗസ് ഉപയോഗിച്ച് സെർവറുകളുടെ ഒരു ക്ലസ്റ്റർ ഉപയോഗിച്ച് മാറ്റിസ്ഥാപിക്കുന്നു.

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

ചിലപ്പോൾ ഞങ്ങൾ RPC സ്കീം നിലവാരമില്ലാത്ത പരിഹാരങ്ങളിൽ നടപ്പിലാക്കാൻ ആഗ്രഹിക്കുന്നില്ല, ഉദാഹരണത്തിന്, nginx-ൽ. അതിനാൽ, UDP വഴി ലോഗുകൾ സ്വീകരിക്കാനുള്ള കഴിവ് KittenHouse-ന് ഉണ്ട്.

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

നിരീക്ഷിക്കുന്നു

ഞങ്ങൾക്ക് രണ്ട് തരം ലോഗുകൾ ഉണ്ട്: അഡ്മിനിസ്ട്രേറ്റർമാർ അവരുടെ സെർവറുകളിൽ ശേഖരിക്കുന്നതും ഡെവലപ്പർമാർ കോഡിൽ നിന്ന് എഴുതിയതും. അവ രണ്ട് തരം അളവുകളുമായി പൊരുത്തപ്പെടുന്നു: സംവിധാനവും ഉൽപ്പന്നവും.

സിസ്റ്റം അളവുകൾ

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

ഉൽപ്പന്ന അളവുകൾ

സൗകര്യാർത്ഥം ഞങ്ങൾ ഒരുപാട് കാര്യങ്ങൾ എഴുതിയിട്ടുണ്ട്. ഉദാഹരണത്തിന്, കണക്കുകൾ, യുണീക്ക് കൗണ്ട്സ് മൂല്യങ്ങൾ എന്നിവ സ്ഥിതിവിവരക്കണക്കുകളിലേക്ക് എഴുതാൻ നിങ്ങളെ അനുവദിക്കുന്ന ഒരു കൂട്ടം സാധാരണ ഫംഗ്ഷനുകൾ ഉണ്ട്, അവ എവിടെയെങ്കിലും അയയ്ക്കുന്നു.

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

$stats = statlogsStatData($params)

തുടർന്ന്, നമുക്ക് സോർട്ടിംഗും ഗ്രൂപ്പിംഗ് ഫിൽട്ടറുകളും ഉപയോഗിക്കാനും സ്ഥിതിവിവരക്കണക്കുകളിൽ നിന്ന് ആവശ്യമുള്ളതെല്ലാം ചെയ്യാനും കഴിയും - ഗ്രാഫുകൾ നിർമ്മിക്കുക, വാച്ച്ഡോഗുകൾ കോൺഫിഗർ ചെയ്യുക.

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

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

ആവശ്യമെങ്കിൽ, നമുക്ക് ലോഗുകൾ-കളക്ടർമാർക്ക് നേരിട്ട് എഴുതാം.

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

അടുത്തതായി, ലോഗുകൾ-കളക്ടർമാർ സ്ഥിതിവിവരക്കണക്കുകൾ ലയിപ്പിക്കുന്നു meowDB - ഇതാണ് ഞങ്ങളുടെ ഡാറ്റാബേസ്, ഇതിന് മെട്രിക്‌സും സംഭരിക്കാനാകും.

അപ്പോൾ നമുക്ക് കോഡിൽ നിന്ന് ബൈനറി "Near-SQL" തിരഞ്ഞെടുക്കാം.

പരീക്ഷണം

2018-ലെ വേനൽക്കാലത്ത്, ഞങ്ങൾക്ക് ഒരു ഇന്റേണൽ ഹാക്കത്തോൺ ഉണ്ടായിരുന്നു, കൂടാതെ ക്ലിക്ക്ഹൗസിൽ മെട്രിക്‌സ് സംഭരിക്കാൻ കഴിയുന്ന എന്തെങ്കിലും ഉപയോഗിച്ച് ഡയഗ്രാമിന്റെ ചുവന്ന ഭാഗം മാറ്റിസ്ഥാപിക്കാൻ ശ്രമിക്കുക എന്ന ആശയം ഉയർന്നുവന്നു. ClickHouse-ൽ ഞങ്ങൾക്ക് ലോഗുകൾ ഉണ്ട് - എന്തുകൊണ്ട് ഇത് പരീക്ഷിച്ചുകൂടാ?

KittenHouse വഴി ലോഗുകൾ എഴുതുന്ന ഒരു സ്കീം ഞങ്ങൾക്കുണ്ടായിരുന്നു.

ഞങ്ങൾ തീരുമാനിച്ചു ഡയഗ്രാമിലേക്ക് മറ്റൊരു "* വീട്" ചേർക്കുക, ഞങ്ങളുടെ കോഡ് UDP വഴി എഴുതുന്ന ഫോർമാറ്റിലുള്ള മെട്രിക്‌സ് കൃത്യമായി സ്വീകരിക്കും. അപ്പോൾ ഈ *ഹൗസ് അവയെ ലോഗുകൾ പോലെയുള്ള ഇൻസെർട്ടുകളാക്കി മാറ്റുന്നു, അത് കിറ്റൻഹൗസ് മനസ്സിലാക്കുന്നു. ഈ ലോഗുകൾ ക്ലിക്ക്ഹൗസിലേക്ക് കൃത്യമായി എത്തിക്കാൻ അദ്ദേഹത്തിന് കഴിയും, അവ വായിക്കാൻ കഴിയും.

memcache, stats-demon, logs-collectors ഡാറ്റാബേസ് എന്നിവയുള്ള സ്‌കീമിന് പകരം ഇത് മാറ്റി.

memcache, stats-demon, logs-collectors ഡാറ്റാബേസ് എന്നിവയുള്ള സ്‌കീമിന് പകരം ഇത് മാറ്റി.

• ഇവിടെ കോഡിൽ നിന്ന് ഒരു ഡിസ്പാച്ച് ഉണ്ട്, അത് StatsHouse-ൽ പ്രാദേശികമായി എഴുതിയിരിക്കുന്നു.
• സ്റ്റാറ്റ്‌ഹൗസ് യുഡിപി മെട്രിക്‌സ് എഴുതുന്നു, ഇതിനകം തന്നെ എസ്‌ക്യുഎൽ ഇൻസെർട്ടുകളായി പരിവർത്തനം ചെയ്‌തു, ബാച്ചുകളായി കിറ്റൻഹൗസിലേക്ക്.
• KittenHouse അവരെ ClickHouse-ലേക്ക് അയയ്ക്കുന്നു.
• ഞങ്ങൾക്ക് അവ വായിക്കണമെങ്കിൽ, സ്റ്റാറ്റ്‌ഹൗസ് മറികടന്ന് ഞങ്ങൾ അവ വായിക്കുന്നു - സാധാരണ SQL ഉപയോഗിച്ച് ClickHouse-ൽ നിന്ന് നേരിട്ട്.

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

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

വിന്യസിക്കുക

ആദ്യം, നമുക്ക് PHP വിന്യാസം നോക്കാം. ഞങ്ങൾ വികസിച്ചുകൊണ്ടിരിക്കുകയാണ് ജിറ്റിനെ: ഉപയോഗിക്കുക GitLab и ടീംസിറ്റി വിന്യാസത്തിനായി. വികസന ശാഖകൾ മാസ്റ്റർ ബ്രാഞ്ചിലേക്ക് ലയിപ്പിക്കുന്നു, മാസ്റ്ററിൽ നിന്ന് ടെസ്റ്റിംഗിനായി അവ സ്റ്റേജിംഗിലേക്കും സ്റ്റേജിൽ നിന്ന് ഉൽപാദനത്തിലേക്കും ലയിപ്പിക്കുന്നു.

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

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

അടിസ്ഥാനപരമായി ബൈനറികളായ ഞങ്ങളുടെ എഞ്ചിനുകൾക്ക്, സ്കീം വളരെ സമാനമാണ്:

• git മാസ്റ്റർ ബ്രാഞ്ച്;
• ബൈനറി ഇൻ .deb;
• പതിപ്പ് ബിൻലോഗ് കോപ്പിഫാസ്റ്റിനായി എഴുതിയിരിക്കുന്നു;
• സെർവറുകളിലേക്ക് പകർത്തി;
• സെർവർ ഒരു പുതിയ .dep പുറത്തെടുക്കുന്നു;
• dpkg -i;
• പുതിയ പതിപ്പിലേക്ക് മനോഹരമായി വീണ്ടും സമാരംഭിക്കുക.

ഞങ്ങളുടെ ബൈനറി ആർക്കൈവുകളിൽ പാക്കേജുചെയ്തിരിക്കുന്നു എന്നതാണ് വ്യത്യാസം .deb, അവ പമ്പ് ചെയ്യുമ്പോൾ dpkg -i സിസ്റ്റത്തിൽ സ്ഥാപിച്ചിരിക്കുന്നു. എന്തുകൊണ്ടാണ് kPHP ബൈനറി ആയി വിന്യസിച്ചിരിക്കുന്നത്, എഞ്ചിനുകൾ dpkg ആയി വിന്യസിച്ചിരിക്കുന്നത് എന്തുകൊണ്ട്? അത് അങ്ങനെ സംഭവിച്ചു. ഇത് പ്രവർത്തിക്കുന്നു - അതിൽ തൊടരുത്.

പ്രയോജനപ്രദമായ ലിങ്കുകൾ:

• ആന്റൺ കിർയുഷ്കിൻ റിപ്പോർട്ട് "Vkontakte സിസ്റ്റം അഡ്മിനിസ്ട്രേറ്റർ. എങ്ങനെ?" കോപ്പിഫാസ്റ്റിനെയും ഗോസിപ്പിനെയും കുറിച്ചുള്ള വിശദാംശങ്ങൾക്കൊപ്പം.
• യൂറി നസ്രെറ്റ്ഡിനോവിന്റെ റിപ്പോർട്ട് "പതിനായിരക്കണക്കിന് സെർവറുകളിൽ നിന്ന് VK എങ്ങനെയാണ് CLickHouse-ലേക്ക് ഡാറ്റ ചേർക്കുന്നത്".
• എന്റെ റിപ്പോർട്ട് "VKontakte ന്റെ ഉദാഹരണം ഉപയോഗിച്ച് വളരുന്ന പ്രോജക്റ്റിന്റെ വാസ്തുവിദ്യ", എന്നാൽ ഒരു വികസന കാഴ്ചപ്പാടിൽ നിന്ന്, ഹാർഡ്വെയർ അല്ല.

പ്രോഗ്രാം കമ്മിറ്റിയുടെ ഭാഗമായി സഹായിക്കുന്നവരിൽ ഒരാളാണ് അലക്സി അകുലോവിച്ച് PHP റഷ്യ മെയ് 17-ന് PHP ഡെവലപ്പർമാർക്ക് സമീപകാലത്തെ ഏറ്റവും വലിയ ഇവന്റായി മാറും. നോക്കൂ, എന്തൊരു അടിപൊളി പിസിയാണ് നമുക്കുള്ളത് സ്പീക്കറുകൾ (അവയിൽ രണ്ടെണ്ണം PHP കോർ വികസിപ്പിച്ചുകൊണ്ടിരിക്കുന്നു!) - നിങ്ങൾ PHP എഴുതുകയാണെങ്കിൽ നിങ്ങൾക്ക് നഷ്‌ടപ്പെടുത്താൻ കഴിയാത്തത് പോലെ തോന്നുന്നു.

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