Yandex.Market തിരയൽ എങ്ങനെ പ്രവർത്തിക്കുന്നു, സെർവറുകളിൽ ഒന്ന് പരാജയപ്പെട്ടാൽ എന്ത് സംഭവിക്കും

ഹലോ, എന്റെ പേര് എവ്ജെനി. ഞാൻ Yandex.Market തിരയൽ ഇൻഫ്രാസ്ട്രക്ചറിൽ ജോലി ചെയ്യുന്നു. മാർക്കറ്റിന്റെ ആന്തരിക അടുക്കളയെക്കുറിച്ച് എനിക്ക് ഹബ്ർ സമൂഹത്തോട് പറയാൻ ആഗ്രഹമുണ്ട് - എനിക്ക് ഒരുപാട് കാര്യങ്ങൾ പറയാനുണ്ട്. ഒന്നാമതായി, മാർക്കറ്റ് തിരയൽ എങ്ങനെ പ്രവർത്തിക്കുന്നു, പ്രോസസ്സുകൾ, ആർക്കിടെക്ചർ എന്നിവ. അടിയന്തര സാഹചര്യങ്ങളെ നമ്മൾ എങ്ങനെ കൈകാര്യം ചെയ്യും: ഒരു സെർവർ തകരാറിലായാൽ എന്ത് സംഭവിക്കും? അത്തരം 100 സെർവറുകൾ ഉണ്ടെങ്കിൽ എന്തുചെയ്യും?

ഒരു കൂട്ടം സെർവറുകളിൽ ഞങ്ങൾ എങ്ങനെയാണ് പുതിയ പ്രവർത്തനം നടപ്പിലാക്കുന്നതെന്നും നിങ്ങൾ പഠിക്കും. കൂടാതെ, ഉപയോക്താക്കൾക്ക് ഒരു അസൗകര്യവും ഉണ്ടാക്കാതെ, സങ്കീർണ്ണമായ സേവനങ്ങൾ ഞങ്ങൾ നേരിട്ട് ഉൽപ്പാദനത്തിൽ എങ്ങനെ പരിശോധിക്കുന്നു. പൊതുവേ, മാർക്കറ്റ് തിരയൽ എങ്ങനെ പ്രവർത്തിക്കുന്നു, അങ്ങനെ എല്ലാവർക്കും നല്ല സമയം ലഭിക്കും.

ഞങ്ങളെക്കുറിച്ച് കുറച്ച്: ഞങ്ങൾ എന്ത് പ്രശ്നം പരിഹരിക്കുന്നു

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

ഞങ്ങൾ എല്ലാ തിരയൽ അഭ്യർത്ഥനകളും പ്രോസസ്സ് ചെയ്യുന്നു: site.yandex.ru, beru.ru, Supercheck സേവനം, Yandex.Advisor, മൊബൈൽ ആപ്ലിക്കേഷനുകൾ എന്നിവയിൽ നിന്ന്. yandex.ru-ലെ തിരയൽ ഫലങ്ങളിൽ ഞങ്ങൾ ഉൽപ്പന്ന ഓഫറുകളും ഉൾപ്പെടുത്തുന്നു.

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

എന്താണ്: മാർക്കറ്റ് ആർക്കിടെക്ചർ

മാർക്കറ്റിന്റെ നിലവിലെ വാസ്തുവിദ്യ ഞാൻ ചുരുക്കമായി വിവരിക്കും. ചുവടെയുള്ള ഡയഗ്രം ഉപയോഗിച്ച് ഇത് ഏകദേശം വിവരിക്കാം:

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

ഇത്തരത്തിൽ സേവ് ചെയ്ത നിരവധി xmlകളുണ്ട്. ഈ ഡാറ്റാബേസിൽ നിന്ന് ഒരു തിരയൽ സൂചിക സൃഷ്ടിച്ചിരിക്കുന്നു. ഇൻഡെക്സ് ആന്തരിക ഫോർമാറ്റിൽ സംഭരിച്ചിരിക്കുന്നു. സൂചിക സൃഷ്ടിച്ച ശേഷം, ലേഔട്ട് സേവനം അത് തിരയൽ സെർവറുകളിലേക്ക് അപ്‌ലോഡ് ചെയ്യുന്നു.

തൽഫലമായി, ഒരു സ്‌ക്വീക്കറുള്ള ഒരു കോപാകുലനായ പൂച്ച ഡാറ്റാബേസിൽ പ്രത്യക്ഷപ്പെടുന്നു, പൂച്ചയുടെ സൂചിക സെർവറിൽ ദൃശ്യമാകുന്നു.

സെർച്ച് ആർക്കിടെക്ചറിനെക്കുറിച്ചുള്ള ഭാഗത്ത് ഒരു പൂച്ചയെ എങ്ങനെ തിരയാമെന്ന് ഞാൻ നിങ്ങളോട് പറയും.

മാർക്കറ്റ് സെർച്ച് ആർക്കിടെക്ചർ

മൈക്രോസർവീസുകളുടെ ലോകത്താണ് ഞങ്ങൾ ജീവിക്കുന്നത്: ഓരോ ഇൻകമിംഗ് അഭ്യർത്ഥനയും market.yandex.ru ധാരാളം സബ്ക്വറികൾക്ക് കാരണമാകുന്നു, കൂടാതെ ഡസൻ കണക്കിന് സേവനങ്ങൾ അവയുടെ പ്രോസസ്സിംഗിൽ ഉൾപ്പെട്ടിരിക്കുന്നു. ഡയഗ്രം കുറച്ച് മാത്രം കാണിക്കുന്നു:

ലളിതമായ അഭ്യർത്ഥന പ്രോസസ്സിംഗ് സ്കീം

ഓരോ സേവനത്തിനും അതിമനോഹരമായ ഒരു കാര്യമുണ്ട് - ഒരു അദ്വിതീയ നാമമുള്ള സ്വന്തം ബാലൻസർ:

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

ബാലൻസറിന്റെ തനതായ പേര് ഡാറ്റാ സെന്ററിനെ ആശ്രയിക്കുന്നില്ല. സേവനം A B ലേക്ക് ഒരു അഭ്യർത്ഥന നടത്തുമ്പോൾ, സ്ഥിരസ്ഥിതി ബാലൻസർ B നിലവിലെ ഡാറ്റാ സെന്ററിലേക്ക് അഭ്യർത്ഥന റീഡയറക്‌ട് ചെയ്യുന്നു. സേവനം ലഭ്യമല്ലെങ്കിലോ നിലവിലെ ഡാറ്റാ സെന്ററിൽ നിലവിലില്ലെങ്കിലോ, അഭ്യർത്ഥന മറ്റ് ഡാറ്റാ സെന്ററുകളിലേക്ക് റീഡയറക്‌ടുചെയ്യും.

എല്ലാ ഡാറ്റാ സെന്ററുകൾക്കുമുള്ള ഒരൊറ്റ FQDN, ലൊക്കേഷനുകളിൽ നിന്ന് പൂർണ്ണമായും സംഗ്രഹിക്കാൻ സേവനം A-യെ അനുവദിക്കുന്നു. ബി സേവനത്തിനുള്ള അവന്റെ അഭ്യർത്ഥന എല്ലായ്പ്പോഴും പ്രോസസ്സ് ചെയ്യും. എല്ലാ ഡാറ്റാ സെന്ററുകളിലും സേവനം സ്ഥിതി ചെയ്യുന്ന സാഹചര്യത്തിലാണ് ഒഴിവാക്കൽ.

എന്നാൽ ഈ ബാലൻസറിനൊപ്പം എല്ലാം വളരെ റോസി അല്ല: ഞങ്ങൾക്ക് ഒരു അധിക ഇന്റർമീഡിയറ്റ് ഘടകം ഉണ്ട്. ബാലൻസർ അസ്ഥിരമാകാം, അനാവശ്യ സെർവറുകൾ ഈ പ്രശ്നം പരിഹരിക്കുന്നു. A, B സേവനങ്ങൾക്കിടയിൽ ഒരു അധിക കാലതാമസമുണ്ട്. എന്നാൽ പ്രായോഗികമായി ഇത് 1 ms-ൽ താഴെയാണ്, മിക്ക സേവനങ്ങൾക്കും ഇത് നിർണായകമല്ല.

അപ്രതീക്ഷിതമായി ഇടപെടൽ: സെർച്ച് സർവീസ് ബാലൻസിങ് ആൻഡ് റെസിലിയൻസി

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

സാഹചര്യം ഭയാനകമാണ്, പക്ഷേ ഞങ്ങൾ അതിന് തയ്യാറാണ്. ഞാൻ ക്രമത്തിൽ പറയാം.

തിരയൽ ഇൻഫ്രാസ്ട്രക്ചർ നിരവധി ഡാറ്റാ സെന്ററുകളിലാണ് സ്ഥിതി ചെയ്യുന്നത്:

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

നമുക്ക് ഒരൊറ്റ ഡാറ്റാ സെന്റർ പരിഗണിക്കാം. ഓരോ ഡാറ്റാ സെന്ററിനും ഒരേ ബാലൻസർ ഓപ്പറേഷൻ സ്കീം ഉണ്ട്:

ഒരു ബാലൻസർ കുറഞ്ഞത് മൂന്ന് ഫിസിക്കൽ സെർവറുകളാണ്. ഈ ആവർത്തനം വിശ്വാസ്യതയ്ക്കായി ഉണ്ടാക്കിയതാണ്. ബാലൻസറുകൾ HAProx-ൽ പ്രവർത്തിക്കുന്നു.

ഉയർന്ന പ്രകടനവും കുറഞ്ഞ റിസോഴ്‌സ് ആവശ്യകതകളും വിശാലമായ പ്രവർത്തനവും കാരണം ഞങ്ങൾ HAProx തിരഞ്ഞെടുത്തു. ഞങ്ങളുടെ തിരയൽ സോഫ്‌റ്റ്‌വെയർ ഓരോ സെർവറിലും പ്രവർത്തിക്കുന്നു.

ഒരു സെർവർ പരാജയപ്പെടാനുള്ള സാധ്യത കുറവാണ്. എന്നാൽ നിങ്ങൾക്ക് ധാരാളം സെർവറുകൾ ഉണ്ടെങ്കിൽ, ഒരെണ്ണമെങ്കിലും കുറയാനുള്ള സാധ്യത വർദ്ധിക്കുന്നു.

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

HAProxy-യുടെ മറ്റൊരു സവിശേഷത: എല്ലാ സെർവറുകളും തുല്യമായി ലോഡുചെയ്യാൻ ഏജന്റ്-ചെക്ക് നിങ്ങളെ അനുവദിക്കുന്നു. ഇത് ചെയ്യുന്നതിന്, HAProxy എല്ലാ സെർവറുകളിലേക്കും കണക്റ്റുചെയ്യുന്നു, കൂടാതെ 1 മുതൽ 100 ​​വരെയുള്ള നിലവിലെ ലോഡിനെ ആശ്രയിച്ച് അവർ അവരുടെ ഭാരം തിരികെ നൽകുന്നു. പ്രോസസ്സിംഗിനായി ക്യൂവിലെ അഭ്യർത്ഥനകളുടെ എണ്ണവും പ്രോസസറിലെ ലോഡും അടിസ്ഥാനമാക്കിയാണ് ഭാരം കണക്കാക്കുന്നത്.

ഇപ്പോൾ പൂച്ചയെ കണ്ടെത്തുന്നതിനെക്കുറിച്ച്. ഇതുപോലുള്ള അഭ്യർത്ഥനകളിലെ തിരയൽ ഫലങ്ങൾ: /തിരയണോ?വാചകം=കോപം+പൂച്ച. തിരയൽ വേഗത്തിലാകുന്നതിന്, മുഴുവൻ പൂച്ച സൂചികയും റാമിലേക്ക് യോജിപ്പിക്കണം. എസ്എസ്ഡിയിൽ നിന്നുള്ള വായന പോലും വേണ്ടത്ര വേഗതയുള്ളതല്ല.

ഒരു കാലത്ത്, ഓഫർ ഡാറ്റാബേസ് ചെറുതായിരുന്നു, അതിന് ഒരു സെർവറിന്റെ റാം മതിയായിരുന്നു. ഓഫർ ബേസ് വർദ്ധിച്ചതോടെ, എല്ലാം ഇനി ഈ റാമിലേക്ക് യോജിക്കുന്നില്ല, കൂടാതെ ഡാറ്റ രണ്ട് ഭാഗങ്ങളായി തിരിച്ചിരിക്കുന്നു: ഷാർഡ് 1, ഷാർഡ് 2.

എന്നാൽ ഇത് എല്ലായ്പ്പോഴും സംഭവിക്കുന്നു: ഏത് പരിഹാരവും, നല്ലത് പോലും, മറ്റ് പ്രശ്നങ്ങൾക്ക് കാരണമാകുന്നു.

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

ബാലൻസർ അഭ്യർത്ഥനകൾ തുല്യമായി വിതരണം ചെയ്യുന്നതിനാൽ, എല്ലാ സെർവറുകളും ഡാറ്റ അയയ്‌ക്കുന്നതിൽ മാത്രമല്ല, റീ-റാങ്കിംഗിൽ ഏർപ്പെട്ടിരുന്നു.

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

നിലവിൽ, എട്ട് ഷാർഡുകളുടെ കോൺഫിഗറേഷൻ ഉപയോഗിക്കുന്നു. കൂടാതെ, കൂടുതൽ മെമ്മറി സംരക്ഷിക്കുന്നതിന്, സൂചികയെ ഒരു തിരയൽ ഭാഗമായും (അത് തിരയാൻ ഉപയോഗിക്കുന്നു) ഒരു സ്നിപ്പറ്റ് ഭാഗമായും (തിരച്ചിലിൽ ഉൾപ്പെട്ടിട്ടില്ല) വിഭജിച്ചു.

ഒരു സെർവറിൽ ഒരു ഷാർഡിന്റെ മാത്രം വിവരങ്ങൾ അടങ്ങിയിരിക്കുന്നു. അതിനാൽ, മുഴുവൻ സൂചികയും തിരയുന്നതിന്, വ്യത്യസ്ത ശകലങ്ങൾ അടങ്ങിയ എട്ട് സെർവറുകളിൽ നിങ്ങൾ തിരയേണ്ടതുണ്ട്.

സെർവറുകൾ ക്ലസ്റ്ററുകളായി തിരിച്ചിരിക്കുന്നു. ഓരോ ക്ലസ്റ്ററിലും എട്ട് സെർച്ച് എഞ്ചിനുകളും ഒരു സ്‌നിപ്പറ്റ് സെർവറും അടങ്ങിയിരിക്കുന്നു.

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

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

തിരയൽ തന്നെ ഇനിപ്പറയുന്ന രീതിയിൽ ക്രമീകരിച്ചിരിക്കുന്നു: എട്ട് സെർവറുകളിൽ ഏതെങ്കിലും ഒരു തിരയൽ അഭ്യർത്ഥന വരാം. അവൻ സെർവർ 1-ലേക്ക് വന്നുവെന്ന് നമുക്ക് പറയാം. ഈ സെർവർ എല്ലാ ആർഗ്യുമെന്റുകളും പ്രോസസ്സ് ചെയ്യുകയും എന്താണ്, എങ്ങനെ തിരയണമെന്ന് മനസ്സിലാക്കുകയും ചെയ്യുന്നു. ഇൻകമിംഗ് അഭ്യർത്ഥനയെ ആശ്രയിച്ച്, ആവശ്യമായ വിവരങ്ങൾക്കായി സെർവറിന് ബാഹ്യ സേവനങ്ങളിലേക്ക് അധിക അഭ്യർത്ഥനകൾ നടത്താൻ കഴിയും. ഒരു അഭ്യർത്ഥനയ്ക്ക് ശേഷം ബാഹ്യ സേവനങ്ങളിലേക്ക് പത്ത് അഭ്യർത്ഥനകൾ വരെ വരാം.

ആവശ്യമായ വിവരങ്ങൾ ശേഖരിച്ച ശേഷം, ഓഫർ ഡാറ്റാബേസിൽ ഒരു തിരയൽ ആരംഭിക്കുന്നു. ഇത് ചെയ്യുന്നതിന്, ക്ലസ്റ്ററിലെ എട്ട് സെർവറുകളിലേക്കും സബ്ക്വറികൾ നടത്തുന്നു.

പ്രതികരണങ്ങൾ ലഭിച്ചുകഴിഞ്ഞാൽ, ഫലങ്ങൾ സംയോജിപ്പിക്കുന്നു. അവസാനം, ഫലങ്ങൾ സൃഷ്‌ടിക്കുന്നതിന് സ്‌നിപ്പറ്റ് സെർവറിലേക്ക് നിരവധി സബ്‌ക്വറികൾ ആവശ്യമായി വന്നേക്കാം.

ക്ലസ്റ്ററിനുള്ളിലെ തിരയൽ അന്വേഷണങ്ങൾ ഇതുപോലെ കാണപ്പെടുന്നു: /shard1?text=കോപം+പൂച്ച. കൂടാതെ, ക്ലസ്റ്ററിനുള്ളിലെ എല്ലാ സെർവറുകൾക്കിടയിലും ഒരു സെക്കൻഡിൽ ഒരിക്കൽ ഫോമിന്റെ സബ്ക്വറികൾ നിരന്തരം നിർമ്മിക്കപ്പെടുന്നു: /പദവി.

അഭ്യർത്ഥിക്കുക /പദവി സെർവർ ലഭ്യമല്ലാത്ത ഒരു സാഹചര്യം കണ്ടെത്തുന്നു.

സെർച്ച് എഞ്ചിൻ പതിപ്പും ഇൻഡക്സ് പതിപ്പും എല്ലാ സെർവറുകളിലും ഒരുപോലെയാണെന്നതും ഇത് നിയന്ത്രിക്കുന്നു, അല്ലാത്തപക്ഷം ക്ലസ്റ്ററിനുള്ളിൽ പൊരുത്തമില്ലാത്ത ഡാറ്റ ഉണ്ടാകും.

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

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

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

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

ഭയങ്കരമായ എന്തോ സംഭവിച്ചു: ഒരു സെർവർ ലഭ്യമല്ല

ഒരു സെർവർ ലഭ്യമല്ലെന്ന് നമുക്ക് പറയാം. തുടർന്ന് ക്ലസ്റ്ററിലെ ശേഷിക്കുന്ന സെർവറുകൾക്ക് തുടർന്നും പ്രതികരിക്കാനാകും, പക്ഷേ തിരയൽ ഫലങ്ങൾ അപൂർണ്ണമായിരിക്കും.

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

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

സെർവർ ലഭ്യമാകുമ്പോൾ, അത് പ്രതികരിക്കാൻ തുടങ്ങുന്നു /പിംഗ്. ഡെഡ് സെർവറുകളിൽ നിന്നുള്ള പിംഗുകളിലേക്കുള്ള സാധാരണ പ്രതികരണങ്ങൾ വരാൻ തുടങ്ങുമ്പോൾ, ബാലൻസർമാർ അവിടെ ഉപയോക്തൃ ട്രാഫിക് അയയ്ക്കാൻ തുടങ്ങും. ക്ലസ്റ്റർ പ്രവർത്തനം പുനഃസ്ഥാപിച്ചു, ഹൂറേ.

അതിലും മോശം: പല സെർവറുകളും ലഭ്യമല്ല

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

ഒരു ഡാറ്റാ സെന്ററിലെ നിരവധി സെർവറുകൾ പ്രവർത്തനരഹിതമാകുമ്പോൾ, ഈ ഡാറ്റാ സെന്ററിന് എല്ലാ ട്രാഫിക്കും പ്രോസസ്സ് ചെയ്യാൻ കഴിയില്ലെന്ന് ബാലൻസർ മനസ്സിലാക്കുന്നു.

അധിക ട്രാഫിക് മറ്റ് ഡാറ്റാ സെന്ററുകളിലേക്ക് ക്രമരഹിതമായി വിതരണം ചെയ്യാൻ തുടങ്ങുന്നു. എല്ലാം പ്രവർത്തിക്കുന്നു, എല്ലാവരും സന്തുഷ്ടരാണ്.

ഞങ്ങൾ ഇത് എങ്ങനെ ചെയ്യുന്നു: റിലീസുകൾ പ്രസിദ്ധീകരിക്കുന്നു

സേവനത്തിൽ വരുത്തിയ മാറ്റങ്ങൾ ഞങ്ങൾ എങ്ങനെ പ്രസിദ്ധീകരിക്കുന്നു എന്നതിനെക്കുറിച്ച് ഇപ്പോൾ സംസാരിക്കാം. ഇവിടെ ഞങ്ങൾ പ്രക്രിയകൾ ലളിതമാക്കുന്നതിനുള്ള പാത സ്വീകരിച്ചു: ഒരു പുതിയ പതിപ്പ് പുറത്തിറക്കുന്നത് ഏതാണ്ട് പൂർണ്ണമായും ഓട്ടോമേറ്റഡ് ആണ്.
പ്രോജക്റ്റിൽ ഒരു നിശ്ചിത എണ്ണം മാറ്റങ്ങൾ ശേഖരിക്കപ്പെടുമ്പോൾ, ഒരു പുതിയ റിലീസ് സ്വയമേവ സൃഷ്ടിക്കപ്പെടുകയും അതിന്റെ നിർമ്മാണം ആരംഭിക്കുകയും ചെയ്യുന്നു.

തുടർന്ന് സേവനം ടെസ്റ്റിംഗിലേക്ക് വ്യാപിപ്പിക്കുന്നു, അവിടെ പ്രവർത്തനത്തിന്റെ സ്ഥിരത പരിശോധിക്കുന്നു.

അതേ സമയം, ഓട്ടോമാറ്റിക് പെർഫോമൻസ് ടെസ്റ്റിംഗ് ആരംഭിക്കുന്നു. ഒരു പ്രത്യേക സേവനമാണ് ഇത് കൈകാര്യം ചെയ്യുന്നത്. ഞാൻ അതിനെക്കുറിച്ച് ഇപ്പോൾ സംസാരിക്കില്ല - അതിന്റെ വിവരണം ഒരു പ്രത്യേക ലേഖനത്തിന് യോഗ്യമാണ്.

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

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

ഉപയോക്താവിന് എല്ലാ ആശംസകളും നേരുന്നു: എ/ബി ടെസ്റ്റിംഗ്

ഒരു സേവനത്തിലെ മാറ്റങ്ങൾ യഥാർത്ഥ നേട്ടങ്ങൾ നൽകുമോ എന്നത് എല്ലായ്പ്പോഴും വ്യക്തമല്ല. മാറ്റങ്ങളുടെ പ്രയോജനം അളക്കാൻ, ആളുകൾ എ/ബി ടെസ്റ്റിംഗ് കൊണ്ടുവന്നു. Yandex.Market തിരയലിൽ ഇത് എങ്ങനെ പ്രവർത്തിക്കുന്നു എന്നതിനെക്കുറിച്ച് ഞാൻ നിങ്ങളോട് കുറച്ച് പറയും.

പുതിയ പ്രവർത്തനം പ്രാപ്തമാക്കുന്ന ഒരു പുതിയ CGI പാരാമീറ്റർ ചേർത്താണ് ഇതെല്ലാം ആരംഭിക്കുന്നത്. നമ്മുടെ പരാമീറ്റർ ഇതായിരിക്കട്ടെ: market_new_functionality=1. ഫ്ലാഗ് ഉണ്ടെങ്കിൽ കോഡിൽ ഞങ്ങൾ ഈ പ്രവർത്തനം പ്രവർത്തനക്ഷമമാക്കുന്നു:

If (cgi.experiments.market_new_functionality) {
// enable new functionality
}

പുതിയ പ്രവർത്തനം ഉൽപ്പാദനത്തിലേക്ക് വ്യാപിപ്പിക്കുന്നു.

എ/ബി ടെസ്റ്റിംഗ് ഓട്ടോമേറ്റ് ചെയ്യുന്നതിന്, വിശദമായ വിവരങ്ങൾ നൽകുന്ന ഒരു സമർപ്പിത സേവനമുണ്ട് ഇവിടെ വിവരിച്ചിരിക്കുന്നു. സേവനത്തിൽ ഒരു പരീക്ഷണം സൃഷ്ടിക്കപ്പെടുന്നു. ട്രാഫിക് വിഹിതം സജ്ജീകരിച്ചിരിക്കുന്നു, ഉദാഹരണത്തിന്, 15%. ശതമാനങ്ങൾ സജ്ജീകരിച്ചിരിക്കുന്നത് ചോദ്യങ്ങൾക്കല്ല, ഉപയോക്താക്കൾക്കാണ്. പരീക്ഷണത്തിന്റെ ദൈർഘ്യവും സൂചിപ്പിച്ചിരിക്കുന്നു, ഉദാഹരണത്തിന്, ഒരു ആഴ്ച.

ഒരേസമയം നിരവധി പരീക്ഷണങ്ങൾ നടത്താം. ക്രമീകരണങ്ങളിൽ നിങ്ങൾക്ക് മറ്റ് പരീക്ഷണങ്ങളുമായി കവല സാധ്യമാണോ എന്ന് വ്യക്തമാക്കാം.

തൽഫലമായി, സേവനം യാന്ത്രികമായി ഒരു വാദം ചേർക്കുന്നു market_new_functionality=1 ഉപയോക്താക്കളുടെ 15% വരെ. ഇത് തിരഞ്ഞെടുത്ത മെട്രിക്കുകൾ സ്വയമേവ കണക്കാക്കുകയും ചെയ്യുന്നു. പരീക്ഷണം പൂർത്തിയായ ശേഷം, വിശകലന വിദഗ്ധർ ഫലങ്ങൾ നോക്കുകയും നിഗമനങ്ങളിൽ എത്തിച്ചേരുകയും ചെയ്യുന്നു. കണ്ടെത്തലുകളെ അടിസ്ഥാനമാക്കി, ഉൽപ്പാദനത്തിലോ പരിഷ്കരണത്തിലോ വ്യാപിപ്പിക്കാൻ ഒരു തീരുമാനം എടുക്കുന്നു.

വിപണിയുടെ സമർത്ഥമായ കൈ: ഉൽപ്പാദനത്തിൽ പരീക്ഷണം

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

ഒരു പരിഹാരമുണ്ട്: CGI പാരാമീറ്ററുകളിലെ ഫ്ലാഗുകൾ A/B പരിശോധനയ്ക്ക് മാത്രമല്ല, പുതിയ പ്രവർത്തനക്ഷമത പരിശോധിക്കാനും ഉപയോഗിക്കാം.

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

സേവന ഫ്ലോ ഡയഗ്രം ചുവടെ അവതരിപ്പിച്ചിരിക്കുന്നു:

ഫ്ലാഗ് മൂല്യങ്ങൾ API വഴി സജ്ജീകരിച്ചിരിക്കുന്നു. മാനേജ്മെന്റ് സേവനം ഈ മൂല്യങ്ങൾ ഡാറ്റാബേസിൽ സംഭരിക്കുന്നു. എല്ലാ സെർവറുകളും ഓരോ പത്ത് സെക്കൻഡിലും ഒരിക്കൽ ഡാറ്റാബേസിലേക്ക് പോകുകയും ഫ്ലാഗ് മൂല്യങ്ങൾ പമ്പ് ചെയ്യുകയും ഓരോ അഭ്യർത്ഥനയിലും ഈ മൂല്യങ്ങൾ പ്രയോഗിക്കുകയും ചെയ്യുന്നു.

സ്റ്റോപ്പ് ടാപ്പിൽ നിങ്ങൾക്ക് രണ്ട് തരം മൂല്യങ്ങൾ സജ്ജമാക്കാൻ കഴിയും:

1) സോപാധിക പദപ്രയോഗങ്ങൾ. മൂല്യങ്ങളിലൊന്ന് ശരിയാകുമ്പോൾ പ്രയോഗിക്കുക. ഉദാഹരണത്തിന്:

{
	"condition":"IS_DC1",
	"value":"3",
}, 
{
	"condition": "CLUSTER==2 and IS_BERU", 
	"value": "4!" 
}

DC3 ലൊക്കേഷനിൽ അഭ്യർത്ഥന പ്രോസസ്സ് ചെയ്യുമ്പോൾ "1" മൂല്യം പ്രയോഗിക്കും. beru.ru സൈറ്റിനായുള്ള രണ്ടാമത്തെ ക്ലസ്റ്ററിൽ അഭ്യർത്ഥന പ്രോസസ്സ് ചെയ്യുമ്പോൾ മൂല്യം "4" ആണ്.

2) നിരുപാധിക മൂല്യങ്ങൾ. വ്യവസ്ഥകളൊന്നും പാലിക്കുന്നില്ലെങ്കിൽ ഡിഫോൾട്ടായി അപേക്ഷിക്കുക. ഉദാഹരണത്തിന്:

മൂല്യം, മൂല്യം!

ഒരു മൂല്യം ആശ്ചര്യചിഹ്നത്തിൽ അവസാനിക്കുകയാണെങ്കിൽ, അതിന് ഉയർന്ന മുൻഗണന നൽകും.

CGI പാരാമീറ്റർ പാഴ്‌സർ URL പാഴ്‌സ് ചെയ്യുന്നു. തുടർന്ന് സ്റ്റോപ്പ് ടാപ്പിൽ നിന്നുള്ള മൂല്യങ്ങൾ പ്രയോഗിക്കുന്നു.

ഇനിപ്പറയുന്ന മുൻഗണനകളുള്ള മൂല്യങ്ങൾ പ്രയോഗിക്കുന്നു:

1. സ്റ്റോപ്പ് ടാപ്പിൽ നിന്ന് (ആശ്ചര്യചിഹ്നം) വർദ്ധിച്ച മുൻഗണനയോടെ.
2. അഭ്യർത്ഥനയിൽ നിന്നുള്ള മൂല്യം.
3. സ്റ്റോപ്പ് ടാപ്പിൽ നിന്നുള്ള ഡിഫോൾട്ട് മൂല്യം.
4. കോഡിലെ ഡിഫോൾട്ട് മൂല്യം.

സോപാധിക മൂല്യങ്ങളിൽ സൂചിപ്പിച്ചിരിക്കുന്ന നിരവധി ഫ്ലാഗുകൾ ഉണ്ട് - നമുക്ക് അറിയാവുന്ന എല്ലാ സാഹചര്യങ്ങൾക്കും അവ മതിയാകും:

• ഡാറ്റ കേന്ദ്രം.
• പരിസ്ഥിതി: ഉത്പാദനം, പരിശോധന, നിഴൽ.
• സ്ഥലം: മാർക്കറ്റ്, ബെറു.
• ക്ലസ്റ്റർ നമ്പർ.

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

നിങ്ങൾ ഒരു പ്രശ്‌നം ശ്രദ്ധയിൽപ്പെട്ടാൽ, നിങ്ങൾക്ക് ഫ്ലാഗ് അതിന്റെ മുമ്പത്തെ മൂല്യത്തിലേക്ക് ഉടൻ തിരികെ നൽകാം, മാറ്റങ്ങൾ തിരികെ കൊണ്ടുവരും.

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

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

എന്നിരുന്നാലും, വികസന സമയത്ത് പരിശോധനയ്ക്ക് സ്റ്റോപ്പ് ടാപ്പ് അനുയോജ്യമല്ല. ഡെവലപ്പർമാർക്കായി "ഷാഡോ ക്ലസ്റ്റർ" എന്ന് വിളിക്കപ്പെടുന്ന ഒരു പ്രത്യേക ക്ലസ്റ്റർ ഉണ്ട്.

രഹസ്യ പരിശോധന: ഷാഡോ ക്ലസ്റ്റർ

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

യഥാർത്ഥ "കോംബാറ്റ്" അവസ്ഥയിലുള്ള ഒരു ടെസ്റ്റ് ക്ലസ്റ്റർ നമുക്ക് ലഭിക്കും. സാധാരണ ഉപയോക്തൃ ട്രാഫിക് അവിടെ പോകുന്നു. രണ്ട് ക്ലസ്റ്ററുകളിലെയും ഹാർഡ്‌വെയർ ഒന്നുതന്നെയാണ്, അതിനാൽ പ്രകടനവും പിശകുകളും താരതമ്യം ചെയ്യാം.

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

കണ്ടെത്തലുകൾ

അപ്പോൾ, ഞങ്ങൾ എങ്ങനെയാണ് മാർക്കറ്റ് തിരയൽ നിർമ്മിച്ചത്?

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

ഷാഡോ ക്ലസ്റ്ററും ഞങ്ങളെ സഹായിക്കുന്നു: ഞങ്ങൾക്ക് സേവനങ്ങൾ വികസിപ്പിക്കാനും അവ പ്രോസസ്സിൽ പരിശോധിക്കാനും ഉപയോക്താവിനെ ശല്യപ്പെടുത്താതിരിക്കാനും കഴിയും.

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

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

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