ഇസ്തിയോ സർക്യൂട്ട് ബ്രേക്കർ: തെറ്റായ പാത്രങ്ങൾ പ്രവർത്തനരഹിതമാക്കുന്നു

അവധിക്കാലം കഴിഞ്ഞു, ഇസ്തിയോ സർവീസ് മെഷ് സീരീസിലെ രണ്ടാമത്തെ പോസ്റ്റുമായി ഞങ്ങൾ തിരിച്ചെത്തി.

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

ഇത് എങ്ങനെ മികച്ച രീതിയിൽ പ്രവർത്തിക്കണം

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

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

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

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

ഇസ്തിയോയിലെ പൂൾ എജക്ഷൻ എന്താണ്

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

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

ഓപ്പൺഷിഫ്റ്റ് പ്ലാറ്റ്‌ഫോമിലെ കുബർനെറ്റസിൽ ഇത് എങ്ങനെ പ്രവർത്തിക്കുന്നുവെന്ന് കാണിക്കാൻ, റിപ്പോസിറ്ററിയിലെ ഉദാഹരണത്തിൽ നിന്ന് സാധാരണയായി പ്രവർത്തിക്കുന്ന മൈക്രോസർവീസുകളുടെ സ്‌ക്രീൻഷോട്ട് ഉപയോഗിച്ച് നമുക്ക് ആരംഭിക്കാം. Red Hat ഡെവലപ്പർ ഡെമോകൾ. ഇവിടെ നമുക്ക് രണ്ട് പോഡുകൾ ഉണ്ട്, v1, v2, ഓരോന്നിനും ഒരു കണ്ടെയ്നർ പ്രവർത്തിക്കുന്നു. ഇസ്റ്റിയോ റൂട്ടിംഗ് നിയമങ്ങൾ ഉപയോഗിക്കാത്തപ്പോൾ, സമതുലിതമായ റൗണ്ട്-റോബിൻ റൂട്ടിംഗിലേക്ക് Kubernetes ഡിഫോൾട്ട് ചെയ്യുന്നു:

ഒരു തകർച്ചയ്ക്ക് തയ്യാറെടുക്കുന്നു

പൂൾ എജക്ഷൻ ചെയ്യുന്നതിന് മുമ്പ്, നിങ്ങൾ ഒരു ഇസ്റ്റിയോ റൂട്ടിംഗ് റൂൾ സൃഷ്ടിക്കേണ്ടതുണ്ട്. 50/50 അനുപാതത്തിൽ പോഡുകൾക്കിടയിൽ അഭ്യർത്ഥനകൾ വിതരണം ചെയ്യാൻ ഞങ്ങൾ ആഗ്രഹിക്കുന്നുവെന്ന് പറയാം. കൂടാതെ, ഞങ്ങൾ v2 കണ്ടെയ്‌നറുകളുടെ എണ്ണം ഒന്നിൽ നിന്ന് രണ്ടായി വർദ്ധിപ്പിക്കും, ഇതുപോലെ:

oc scale deployment recommendation-v2 --replicas=2 -n tutorial

50/50 അനുപാതത്തിൽ പോഡുകൾക്കിടയിൽ ട്രാഫിക് വിതരണം ചെയ്യുന്നതിനായി ഞങ്ങൾ ഇപ്പോൾ ഒരു റൂട്ടിംഗ് നിയമം സജ്ജമാക്കുന്നു.

ഈ നിയമത്തിന്റെ ഫലം ഇങ്ങനെയാണ്:

ഈ സ്ക്രീൻ 50/50 അല്ല, 14: 9 ആണെന്ന വസ്തുതയിൽ നിങ്ങൾക്ക് തെറ്റ് കണ്ടെത്താം, എന്നാൽ കാലക്രമേണ സ്ഥിതി മെച്ചപ്പെടും.

ഒരു തകരാർ ഉണ്ടാക്കുന്നു

ഇപ്പോൾ നമുക്ക് രണ്ട് v2 കണ്ടെയ്‌നറുകളിൽ ഒന്ന് പ്രവർത്തനരഹിതമാക്കാം, അതിലൂടെ നമുക്ക് ആരോഗ്യമുള്ള ഒരു v1 കണ്ടെയ്‌നറും ഒരു ആരോഗ്യകരമായ v2 കണ്ടെയ്‌നറും ഒരു തെറ്റായ v2 കണ്ടെയ്‌നറും ലഭിക്കും:

തകരാർ പരിഹരിക്കുന്നു

അതിനാൽ, ഞങ്ങൾക്ക് ഒരു തെറ്റായ കണ്ടെയ്നർ ഉണ്ട്, ഇത് പൂൾ എജക്ഷനുള്ള സമയമാണ്. വളരെ ലളിതമായ ഒരു കോൺഫിഗറേഷൻ ഉപയോഗിച്ച്, ഏതെങ്കിലും റൂട്ടിംഗ് സ്കീമിൽ നിന്ന് ഈ പരാജയപ്പെട്ട കണ്ടെയ്നർ ആരോഗ്യകരമായ അവസ്ഥയിലേക്ക് മടങ്ങുമെന്ന പ്രതീക്ഷയിൽ 15 സെക്കൻഡ് നേരത്തേക്ക് ഞങ്ങൾ ഒഴിവാക്കും (ഒന്നുകിൽ പ്രകടനം പുനരാരംഭിക്കുക അല്ലെങ്കിൽ പുനഃസ്ഥാപിക്കുക). ഈ കോൺഫിഗറേഷൻ ഇങ്ങനെയാണ് കാണപ്പെടുന്നത്, അതിന്റെ പ്രവർത്തനഫലങ്ങൾ:

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

നമുക്ക് വാസ്തുവിദ്യയുടെ നിർമ്മാണം ആരംഭിക്കാം

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

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

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

സിദ്ധാന്തത്തിൽ സർക്യൂട്ട് ബ്രേക്കർ

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

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

പ്രയോഗത്തിൽ സർക്യൂട്ട് ബ്രേക്കർ

ഉദാഹരണത്തിന്, OpenShift-ൽ ഞങ്ങൾ ശുപാർശ ചെയ്യുന്ന മൈക്രോസർവീസിന്റെ രണ്ട് പതിപ്പുകൾ പ്രവർത്തിപ്പിക്കും. പതിപ്പ് 1 നന്നായി പ്രവർത്തിക്കും, എന്നാൽ v2-ൽ സെർവറിലെ സ്ലോഡൗൺ അനുകരിക്കാൻ ഞങ്ങൾ കാലതാമസം വരുത്തും. ഫലങ്ങൾ കാണുന്നതിന്, ഉപകരണം ഉപയോഗിക്കുക ഉപരോധം:

siege -r 2 -c 20 -v customer-tutorial.$(minishift ip).nip.io

എല്ലാം പ്രവർത്തിക്കുന്നതായി തോന്നുന്നു, എന്നാൽ എന്ത് വിലയ്ക്ക്? ഒറ്റനോട്ടത്തിൽ, ഞങ്ങൾക്ക് 100% ലഭ്യതയുണ്ട്, എന്നാൽ സൂക്ഷ്മമായി പരിശോധിക്കുക - പരമാവധി ഇടപാട് ദൈർഘ്യം 12 സെക്കൻഡ് ആണ്. ഇത് വ്യക്തമായും ഒരു തടസ്സമാണ്, അത് വിപുലീകരിക്കേണ്ടതുണ്ട്.

ഇത് ചെയ്യുന്നതിന്, സ്ലോ കണ്ടെയ്നറുകളിലേക്കുള്ള കോളുകൾ ഇല്ലാതാക്കാൻ ഞങ്ങൾ ഇസ്തിയോ ഉപയോഗിക്കും. സർക്യൂട്ട് ബ്രേക്കർ ഉപയോഗിച്ച് അനുബന്ധ കോൺഫിഗറേഷൻ ഇങ്ങനെയാണ് കാണപ്പെടുന്നത്:

httpMaxRequestsPerConnection പാരാമീറ്റർ ഉള്ള അവസാന വരി, നിലവിലുള്ളതിന് പുറമെ മറ്റൊന്ന് - രണ്ടാമത്തെ - കണക്ഷൻ സൃഷ്ടിക്കാൻ ശ്രമിക്കുമ്പോൾ കണക്ഷൻ വിച്ഛേദിക്കണമെന്ന് സിഗ്നലുകൾ നൽകുന്നു. ഞങ്ങളുടെ കണ്ടെയ്നർ വേഗത കുറഞ്ഞ സേവനത്തെ അനുകരിക്കുന്നതിനാൽ, അത്തരം സാഹചര്യങ്ങൾ ഇടയ്ക്കിടെ ഉണ്ടാകാം, തുടർന്ന് ഇസ്തിയോ 503 പിശക് നൽകും, എന്നാൽ ഉപരോധം കാണിക്കുന്നത് ഇതാണ്:

ശരി, ഞങ്ങൾക്ക് സർക്യൂട്ട് ബ്രേക്കർ ഉണ്ട്, അടുത്തത് എന്താണ്?

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

503 പിശകിനോട് പ്രതികരിക്കാനുള്ള ഒരു ആപ്ലിക്കേഷന്റെ കഴിവ് ഇപ്പോഴും സോഴ്സ് കോഡ് തലത്തിൽ സജ്ജീകരിച്ചിട്ടുണ്ടെന്ന കാര്യം ശ്രദ്ധിക്കുക. സാഹചര്യത്തിനനുസരിച്ച് സർക്യൂട്ട് ബ്രേക്കർ ഉപയോഗിക്കുന്നതിന് നിരവധി തന്ത്രങ്ങളുണ്ട്.

അടുത്ത പോസ്റ്റിൽ: ഇതിനകം തന്നെ ബിൽറ്റ്-ഇൻ ചെയ്‌തിരിക്കുന്നതോ അല്ലെങ്കിൽ ഇസ്തിയോയിൽ എളുപ്പത്തിൽ ചേർത്തതോ ആയ ട്രെയ്‌സിംഗിനെയും നിരീക്ഷണത്തെയും കുറിച്ചും സിസ്റ്റത്തിൽ മനഃപൂർവം പിശകുകൾ എങ്ങനെ അവതരിപ്പിക്കാമെന്നതിനെക്കുറിച്ചും ഞങ്ങൾ സംസാരിക്കും.

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