സ്പീഡ് ലിമിറ്റുകളും റെസിലൻ്റ് എറർ മാനേജ്മെൻ്റും

നേട്ടങ്ങൾ:

• വേഗത പരിധികളും (RPM/ITPM/OTPM) 429 പിശകുകളും വ്യാഖ്യാനിക്കാൻ കഴിയും
• എക്‌സ്‌പോണൻഷ്യൽ ബാക്ക്ഓഫ് നടപ്പിലാക്കുകയും വീണ്ടും ശ്രമിച്ചതിന് ശേഷം വീണ്ടും ശ്രമിക്കുകയും ചെയ്യുന്നു
• സാധാരണ HTTP പിശക് കോഡുകൾ ശരിയായി തരംതിരിക്കുകയും കൈകാര്യം ചെയ്യുകയും ചെയ്യുന്നു (400/401/429/500/529)

ഒരു പ്രൊഡക്ഷൻ പരിതസ്ഥിതിയിൽ, എല്ലാ സമയത്തും ഒരു API പൂർണ്ണമായി പ്രതികരിക്കുന്നില്ല. ചിലപ്പോൾ നിങ്ങൾ അഭ്യർത്ഥനകൾ വളരെ വേഗത്തിൽ അയയ്ക്കുകയും പരിധിയിൽ എത്തുകയും ചെയ്യുന്നു; ചിലപ്പോൾ സെർവർ താൽക്കാലികമായി തിരക്കിലാണ്; ചിലപ്പോൾ നിങ്ങളുടെ അഭ്യർത്ഥന ആദ്യം മുതൽ തെറ്റാണ്. ഒരു അമേച്വർ ശ്രമത്തിൽ നിന്ന് ദൃഢമായ സംയോജനത്തെ വേർതിരിക്കുന്നത് അത് ഈ സാഹചര്യങ്ങളെ പ്രവചനാത്മകമായും യാന്ത്രികമായും കൈകാര്യം ചെയ്യുന്നു എന്നതാണ്. ഈ യൂണിറ്റിൽ നിങ്ങൾ നിരക്ക് പരിധികൾ (RPM/ITPM/OTPM), 429 പിശക്, എക്‌സ്‌പോണൻഷ്യൽ ബാക്ക്ഓഫ് ഉപയോഗിച്ച് വീണ്ടും ശ്രമിക്കുക, സാധാരണ HTTP പിശക് കോഡുകളുടെ ശരിയായ വർഗ്ഗീകരണം എന്നിവയെക്കുറിച്ച് പഠിക്കും. ലക്ഷ്യം: ഒരു ഉപയോക്താവ് ഒരിക്കലും ശ്രദ്ധിക്കാത്ത വിധം ശക്തമായ ഒരു ഒഴുക്ക് നിർമ്മിക്കുക.

എന്താണ് വേഗത പരിധികൾ?

ഒരു നിശ്ചിത കാലയളവിൽ ഒരു സ്വിച്ചിന് എത്രത്തോളം ജോലി ചെയ്യാൻ കഴിയുമെന്ന് ദാതാവ് പരിമിതപ്പെടുത്തുന്നു. ഈ സംരക്ഷണം; ഇത് ഇൻഫ്രാസ്ട്രക്ചറിനെയും നിങ്ങളെയും പെട്ടെന്നുള്ള ചിലവ് സ്ഫോടനങ്ങളിൽ നിന്ന് സംരക്ഷിക്കുന്നു. മൂന്ന് സാധാരണ തരത്തിലുള്ള പരിധികളുണ്ട്:

• ആർപിഎം (മിനിറ്റിലെ അഭ്യർത്ഥനകൾ): മിനിറ്റിലെ അഭ്യർത്ഥനകളുടെ എണ്ണം.
• ITPM (മിനിറ്റിൽ ഇൻപുട്ട് ടോക്കണുകൾ): മിനിറ്റിൽ പ്രോസസ്സ് ചെയ്യാവുന്ന ഇൻപുട്ട് ടോക്കൺ.
• OTPM (ഔട്ട്‌പുട്ട് ടോക്കണുകൾ പെർ മിനിട്ട്): ഒരു മിനിറ്റിൽ നിർമ്മിക്കാൻ കഴിയുന്ന ഔട്ട്‌പുട്ട് ടോക്കൺ.

നിങ്ങൾ ഈ പരിധികളിൽ ഏതെങ്കിലും കവിയുകയാണെങ്കിൽ, ദാതാവ് അഭ്യർത്ഥന നിരസിക്കുകയും 429 പിശക് കോഡ് നൽകുകയും ചെയ്യും. നിങ്ങളുടെ അക്കൗണ്ട് ലെവൽ (ടയർ) അനുസരിച്ച് പരിധികൾ സാധാരണയായി വ്യത്യാസപ്പെടും, കാലക്രമേണ വർദ്ധിച്ചേക്കാം.

നുറുങ്ങ്: പ്രതികരണ തലക്കെട്ടുകളിൽ നിന്ന് നിങ്ങൾ പരിധിയെ സമീപിക്കുമ്പോൾ നിങ്ങൾക്ക് കാണാൻ കഴിയും. മിക്ക ദാതാക്കളും നിങ്ങളുടെ ശേഷിക്കുന്ന ക്വാട്ട x-ratelimit-remaining-* പോലുള്ള തലക്കെട്ടുകൾ ഉപയോഗിച്ച് റിപ്പോർട്ട് ചെയ്യുന്നു. ഈ മൂല്യങ്ങൾ നിരീക്ഷിച്ച് മുന്നിലെ ട്രാഫിക്ക് തടസ്സപ്പെടുത്തുക എന്നതാണ് 429 ലഭിക്കാതെ പ്രശ്നം തടയാനുള്ള ഏറ്റവും പക്വമായ മാർഗം.

429, എക്‌സ്‌പോണൻഷ്യൽ റിട്രേസ്‌മെൻ്റ്

429 (നിരക്ക് പരിധി) താൽക്കാലികവും വീണ്ടും ശ്രമിക്കാവുന്നതുമായ പിശകാണ്. അഭ്യർത്ഥനയ്ക്കായി കുറച്ച് സമയം കാത്തിരുന്ന് വീണ്ടും ശ്രമിക്കുക എന്നതാണ് ശരിയായ പ്രതികരണം. എന്നാൽ നിരന്തരമായ കാത്തിരിപ്പ് മതിയാകില്ല; എല്ലാവരും ഒരേ സമയം വീണ്ടും ശ്രമിച്ചാൽ, പരിധി വീണ്ടും എത്തും. എക്‌സ്‌പോണൻഷ്യൽ ബാക്ക്ഓഫ് ആണ് പരിഹാരം: ഓരോ പരാജയ ശ്രമത്തിലും കാത്തിരിപ്പ് സമയം ക്രമാതീതമായി വർദ്ധിപ്പിക്കുക.

# എക്‌സ്‌പോണൻഷ്യൽ ബാക്ക്ഓഫ് ലോജിക് ട്രയൽ 1 → 429 → കാത്തിരിക്കുക 1 സെക്കൻഡ് ട്രയൽ 2 → 429 → കാത്തിരിക്കുക 2 സെക്കൻഡ് ട്രയൽ 3 → 429 → കാത്തിരിപ്പ് 4 സെക്കൻഡ് ട്രയൽ 4 → 429 → 8 സെക്കൻഡ് കാത്തിരിക്കൂ

ഇതിലേക്ക് ഒരു ചെറിയ ക്രമരഹിതത (വിറയൽ) ചേർക്കുന്നത് ഒരേ സമയം വീണ്ടും ശ്രമിക്കുമ്പോൾ അഭ്യർത്ഥനകൾ കൂട്ടിമുട്ടുന്നത് തടയുന്നു. കൂടാതെ, 429 പ്രതികരണം പലപ്പോഴും `വീണ്ടും ശ്രമിക്കുക` എന്ന തലക്കെട്ട് നൽകുന്നു: "ഇത്രയും നിമിഷങ്ങൾക്കുള്ളിൽ വീണ്ടും ശ്രമിക്കുക". അന്ധമായി കാത്തിരിക്കുന്നതിനേക്കാൾ ഈ തലക്കെട്ടിനെ ബഹുമാനിക്കുന്നത് കൂടുതൽ കൃത്യമാണ്.

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

HTTP പിശക് കോഡുകൾ വർഗ്ഗീകരിക്കുന്നു

എല്ലാ തെറ്റുകളും ഒരുപോലെയല്ല. നിർണായകമായ വ്യത്യാസം: ഇത് വീണ്ടും ശ്രമിക്കാമോ അതോ അഭ്യർത്ഥന/ഐഡൻ്റിറ്റി പ്രശ്‌നമാണോ?

കോഡ്

അർത്ഥം

വീണ്ടും ശ്രമിക്കാമോ?

ശരിയായ പ്രതികരണം

400

അസാധുവായ അഭ്യർത്ഥന (ഫോർമാറ്റ്/പാരാമീറ്റർ പിശക്)

ഇല്ല

അഭ്യർത്ഥന ശരിയാക്കുക; വീണ്ടും അയക്കരുത്

401

പ്രാമാണീകരണ പിശക് (കീ അസാധുവാണ്/നഷ്‌ടമായി)

ഇല്ല

കീ/ശീർഷകം പരിഹരിക്കുക

403

അംഗീകാരമില്ല (മോഡൽ/ഫീച്ചറിലേക്ക് പ്രവേശനമില്ല)

ഇല്ല

അനുമതികൾ/സ്കോപ്പ് പരിശോധിക്കുക

404

കണ്ടെത്തിയില്ല (തെറ്റായ മോഡൽ ഐഡി/എൻഡ് പോയിൻ്റ്)

ഇല്ല

ശരിയായ മോഡൽ ഐഡി/വിലാസം

429

വേഗത പരിധി കവിഞ്ഞു

അതെ

പിൻവാങ്ങൽ + വീണ്ടും ശ്രമിക്കുക

500

സെർവർ പിശക്

അതെ

പിൻവാങ്ങലിനൊപ്പം വീണ്ടും ശ്രമിക്കുക

529

സെർവർ ഓവർലോഡ് ചെയ്തു

അതെ

പിൻവാങ്ങലിനൊപ്പം വീണ്ടും ശ്രമിക്കുക

സുവർണ്ണ നിയമം: 429, 500, 529 എന്നിവ താൽക്കാലികമാണ്; പിൻവലിച്ചതോടെ വീണ്ടും ശ്രമിക്കുന്നു. 400, 401, 403, 404 എന്നിവ അഭ്യർത്ഥന/ഐഡൻ്റിറ്റി പ്രശ്‌നങ്ങളാണ്; വീണ്ടും ശ്രമിക്കുന്നത് അത് പരിഹരിക്കില്ല, അത് പരിശ്രമം പാഴാക്കും. നിങ്ങളുടെ കോഡ് ഈ രണ്ട് ഗ്രൂപ്പുകളും തമ്മിൽ വേർതിരിച്ചറിയണം.

ഘട്ടം ഘട്ടമായി: ഡ്യൂറബിൾ കോൾ

1. അപേക്ഷ സമർപ്പിക്കുക. വിജയിച്ചാൽ, തുടരുക.
2. പിശക് കോഡ് തരംതിരിക്കുക. വീണ്ടും ശ്രമിക്കാമോ?
3. ശ്രമിക്കാനാകുമെങ്കിൽ: വീണ്ടും ശ്രമിക്കുക-ശേഷം, എക്‌സ്‌പോണൻഷ്യൽ ബാക്ക്ഓഫ് + ജിറ്റർ പ്രയോഗിക്കുക, പരിമിതമായ എണ്ണം തവണ ശ്രമിക്കുക (ഉദാ. പരമാവധി 5).
4. ശ്രമിച്ചില്ലെങ്കിൽ: (ഫോർമാറ്റ്/കീ) ശരിയാക്കി നിർത്തുക; ലൂപ്പിൽ ഒരേ തെറ്റായ അഭ്യർത്ഥന ആവർത്തിക്കരുത്.
5. ഉപേക്ഷിക്കുന്നത് പരിഗണിക്കുക. n ശ്രമങ്ങൾക്ക് ശേഷവും വിജയിച്ചില്ലെങ്കിൽ, ഉപയോക്താവിന് മാന്യമായ ഒരു സന്ദേശം കാണിച്ച് ഇവൻ്റ് ലോഗ് ചെയ്യുക (ട്രാക്കിംഗ് യൂണിറ്റ് 11).

# ശക്തമായ കോൾ pseudo-codedene = 0repeat: response = request_at() if response.success: response.code ൽ [429, 500, 529] എന്നതിൽ പ്രതികരണം നൽകുകയും < 5: wait = retry_after ?? (2^സെക്കൻഡ് + വിറയൽ) ഉറങ്ങുക(കാത്തിരിക്കുക); ശ്രമിക്കുക += 1; [400, 401, 403, 404] ൽ response.code എങ്കിൽ വീണ്ടും git: save_error(response); റിട്ടേൺ "അഭ്യർത്ഥന പരിഹരിച്ചിരിക്കണം" റിട്ടേൺ "ശാശ്വത പിശക്, പിന്നീട് ശ്രമിക്കുക"

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

ദുർബലമായ പ്രോംപ്റ്റ് / ശക്തമായ പ്രോംപ്റ്റ് (ഇവിടെ: പിശക് സന്ദേശ രൂപകൽപ്പന)

# WEAK (ഉപയോക്താവിന് അസംസ്‌കൃത പിശക് കാണിക്കുന്നു)"പിശക് 429: നിരക്ക്_പരിധി_പിശക്"

# STRONG (ഉപയോക്തൃ-സൗഹൃദ, ഉറപ്പുനൽകുന്ന, പ്രവർത്തന-നിർദ്ദേശം) "സിസ്റ്റത്തിൽ ഒരു താൽക്കാലിക തിരക്ക് ഉണ്ടായിരുന്നു. ഞങ്ങൾക്ക് നിങ്ങളുടെ അഭ്യർത്ഥന സുരക്ഷിതമായി ലഭിച്ചു, അത് സ്വയമേവ വീണ്ടും ശ്രമിക്കുന്നുണ്ട്. കുറച്ച് നിമിഷങ്ങൾക്കുള്ളിൽ ഫലം ദൃശ്യമാകുന്നില്ലെങ്കിൽ, നിങ്ങൾക്ക് പേജ് പുതുക്കാവുന്നതാണ്."

അന്തിമ ഉപയോക്താവിന് അസംസ്‌കൃത സാങ്കേതിക പിശക് വെളിപ്പെടുത്തുന്നത് വിശ്വാസത്തെ ദുർബലപ്പെടുത്തുകയും സുരക്ഷാ അപകടസാധ്യതയാകുകയും ചെയ്യും. ആന്തരികമായി പിശകുകൾ തരംതിരിച്ച് ഉപയോക്താവിന് ശാന്തവും പ്രവർത്തനപരവുമായ സന്ദേശം നൽകുക; റെക്കോർഡിനായി സാങ്കേതിക വിശദാംശങ്ങൾ എഴുതുക.

മൂന്ന് മിനി കേസുകൾ

കേസ് 1 - ഗതാഗത സ്ഫോടനത്തിൽ ബോട്ട് തകർന്നു. പ്രചാരണ ദിനത്തിൽ ഒരു കസ്റ്റമർ സർവീസ് ബോട്ടിന് 429 എണ്ണം വർദ്ധിച്ചു; കോഡിൽ വീണ്ടും ശ്രമിച്ചില്ല, എല്ലാ പിശകുകളും ഒരു "പിശക്" ആയി ഉപയോക്താവിന് നേരിട്ട് പ്രതിഫലിച്ചു. അവർ എക്‌സ്‌പോണൻഷ്യൽ റിട്രേസ്‌മെൻ്റ് + വീണ്ടും ശ്രമിച്ചതിന് ശേഷം; ഒരേ ട്രാഫിക്കിൽ, അഭ്യർത്ഥനകൾ കുറച്ച് സെക്കൻഡ് കാലതാമസത്തോടെ കടന്നുപോയി, ഉപയോക്താവിന് പിശകുകളൊന്നും കണ്ടില്ല.

കേസ് 2 - ലൂപ്പിൽ 400 ശ്രമിക്കുന്നു. ഒരു അസാധുവായ മോഡൽ ഐഡി കാരണം ഒരു ഏകീകരണത്തിന് 404 ലഭിച്ചു, എന്നാൽ എല്ലാ പിശകുകളും "ക്ഷണികം" ആയി കണക്കാക്കുകയും അനന്തമായ ലൂപ്പിൽ വീണ്ടും ശ്രമിക്കുകയും ചെയ്തു; ലോഗ് വീർക്കുകയും അനാവശ്യമായ ലോഡ് സൃഷ്ടിക്കുകയും ചെയ്തു. അവർ പിശക് വർഗ്ഗീകരണം ചേർത്തു: 404 ശാശ്വതമായി കണക്കാക്കുന്നു, ലൂപ്പ് നിർത്തുകയും മോഡൽ ഐഡി ശരിയാക്കുകയും ചെയ്യുന്നു. പാഠം: ഓരോ തെറ്റും വീണ്ടും ശ്രമിക്കരുത്.

കേസ് 3 - മുന്നിൽ നിന്ന് പരിധി നിയന്ത്രിക്കുന്നു. 429 പരിധിയിൽ ഒരു ഡാറ്റ എൻറിച്ച്‌മെൻ്റ് ജോലി നിരന്തരം പ്രവർത്തിക്കുന്നു. അവർ x-ratelimit-അവശേഷിച്ച തലക്കെട്ട് പിന്തുടരുകയും ക്വാട്ട അനുസരിച്ച് ട്രാഫിക്കിനെ നിയന്ത്രിക്കുകയും ചെയ്തു. അതിനാൽ 429 റൺസ് എടുക്കാതെ അവർ പരിധിക്ക് താഴെ ഒരു സ്ഥിരത നിലനിർത്തി; ജോലി കൂടുതൽ പ്രവചനാതീതമായും വേഗത്തിലും ചെയ്തു.

സാധാരണ തെറ്റുകൾ

• 429-ൽ വേഗത വർദ്ധിക്കുന്നു: സ്ഥിതി കൂടുതൽ വഷളാക്കുന്നു; പിൻവാങ്ങലിലേക്ക് മാറുക.
• ഓരോ പിശകും വീണ്ടും ശ്രമിക്കുന്നു: 400/401/404 ശാശ്വതമാണ്; വീണ്ടും ശ്രമിക്കുന്നത് പാഴായിപ്പോകും.
• നിശ്ചിത കാത്തിരിപ്പ് ഉപയോഗിക്കുന്നു: കൂട്ടിയിടി സൃഷ്ടിക്കുന്നു; എക്‌സ്‌പോണൻഷ്യൽ + ജിറ്റർ ഉപയോഗിക്കുക.
• 'വീണ്ടും ശ്രമിക്കുക' അവഗണിക്കുന്നു: ദാതാവ് വ്യക്തമാക്കിയ സമയത്തിന് അനുസൃതമായി പ്രവർത്തിക്കുന്നത് ഏറ്റവും കൃത്യമാണ്.
• ഉപയോക്താവിന് അസംസ്‌കൃത പിശക് വെളിപ്പെടുത്തുന്നു: വിശ്വാസത്തെ കുലുക്കുന്നു, കേടുപാടുകൾ സൃഷ്ടിക്കുന്നു; ഉള്ളിൽ തരംതിരിക്കുക.
• അൺലിമിറ്റഡ് ആവർത്തനങ്ങൾ: ഉയർന്ന പരിധി സജ്ജീകരിക്കുക (ഉദാ. 5 ആവർത്തനങ്ങൾ); എന്നിട്ട് മാന്യമായി ഉപേക്ഷിക്കുക.

ആഴത്തിൽ: ക്യൂയിംഗ്, കൺകറൻസി, സർക്യൂട്ട് ബ്രേക്കറുകൾ

ഒരൊറ്റ ആഗ്രഹത്തിൻ്റെ സഹിഷ്ണുതയാണ് ആദ്യപടി; വലിയ അളവിലുള്ള അഭ്യർത്ഥനകൾ പരിധി ലംഘിക്കാതെ കൈകാര്യം ചെയ്യുക എന്നതാണ് യഥാർത്ഥ പക്വത. മൂന്ന് ആശയങ്ങൾ ഇവിടെ പ്രവർത്തിക്കുന്നു.

ക്യൂ: അഭ്യർത്ഥനകൾ ഉടനടി അയയ്‌ക്കുന്നതിന് പകരം നിയന്ത്രിത വേഗതയിൽ അയയ്‌ക്കാൻ നിങ്ങൾ ഒരു ക്യൂവിൽ ഇടുന്നു. ക്യൂ നിൽക്കുന്നത് പെട്ടെന്നുള്ള ഗതാഗതക്കുരുക്കിനെ സുഗമമാക്കുന്നു: 1,000 അഭ്യർത്ഥനകൾ ഒരേസമയം വന്നാലും, പരിധിക്ക് താഴെയുള്ള നിരക്കിൽ ക്യൂ അവ റിലീസ് ചെയ്യും. ഇതുവഴി നിങ്ങൾ 429 തടയുന്നു, തുടർന്ന് അത് പരിഹരിക്കുന്നതിനെക്കുറിച്ച് നിങ്ങൾ വിഷമിക്കേണ്ടതില്ല.

കൺകറൻസി പരിധി: ഒരേ സമയം "വായുവിൽ" എത്ര അഭ്യർത്ഥനകൾ ഉണ്ടെന്ന് നിങ്ങൾ പരിമിതപ്പെടുത്തുന്നു. അൺലിമിറ്റഡ് പാരലൽ അഭ്യർത്ഥനകൾ RPM, TPM പരിധികൾ വേഗത്തിൽ പൂരിപ്പിക്കുന്നു. ഒരു ന്യായമായ കൺകറൻസി സീലിംഗ് (ഉദാ. 10 കൺകറൻ്റ് അഭ്യർത്ഥനകളിൽ കൂടരുത്) രണ്ടും പരിധികൾ നിലനിർത്തുകയും സിസ്റ്റത്തെ പ്രവചിക്കാവുന്നതാക്കുകയും ചെയ്യുന്നു.

സർക്യൂട്ട് ബ്രേക്കർ: ദാതാവ് 500/529 തിരികെ നൽകുന്നത് തുടരുകയാണെങ്കിൽ, എല്ലാ അഭ്യർത്ഥനകളും മുറുകെ പിടിക്കുന്നതിനുപകരം, നിങ്ങൾ "സർക്യൂട്ട് തകർക്കുക", അഭ്യർത്ഥന ഒരിക്കലും അയയ്‌ക്കാതെ തന്നെ പരാജയപ്പെടുത്തുക. ഒരു കാത്തിരിപ്പിന് ശേഷം, നിങ്ങൾ സർക്യൂട്ട് വീണ്ടും ഓണാക്കി ശ്രമിക്കുക. ഒരു താൽക്കാലിക ദാതാവ് പരാജയപ്പെടുമ്പോൾ നിങ്ങളുടെ സിസ്റ്റത്തെ ക്രാഷുചെയ്യുന്നതിൽ നിന്ന് ഈ പാറ്റേൺ തടയുന്നു.

ഇവ മൂന്നും ചേർന്ന്, ഒരൊറ്റ കോളിൻ്റെ റീട്രി ലോജിക്കിന് അപ്പുറം സിസ്റ്റം-ലെവൽ റെസിലൻസി സ്ഥാപിക്കുന്നു. ചെറിയ തോതിൽ, SDK-യുടെ സ്വയമേവ വീണ്ടും ശ്രമിച്ചാൽ മതിയാകും; സ്കെയിൽ വളരുമ്പോൾ, ക്യൂയിംഗ്, കൺകറൻസി, സർക്യൂട്ട് ബ്രേക്കർ എന്നിവ ഒഴിച്ചുകൂടാനാവാത്തതാകുന്നു. അവയ്‌ക്കെല്ലാം ഒരേ പൊതുലക്ഷ്യമുണ്ട്: ഉപയോക്താവിന് ഒരു താൽക്കാലിക പ്രശ്‌നം പ്രതിഫലിപ്പിക്കുന്നത് ക്രാഷായിട്ടല്ല, മറിച്ച് കുറച്ച് നിമിഷങ്ങളുടെ അദൃശ്യമായ കാലതാമസമായി.

ചുരുക്കത്തിൽ

വേഗപരിധി (RPM/ITPM/OTPM) കവിയുമ്പോൾ 429 മടങ്ങ്; ഇതൊരു താൽക്കാലിക പിശകാണ്, വീണ്ടും ശ്രമിച്ചതിന് ശേഷം, എക്‌സ്‌പോണൻഷ്യൽ ബാക്ക്ഓഫ് + ജിറ്റർ എന്നിവ ഉപയോഗിച്ച് വീണ്ടും ശ്രമിക്കും. 500, 529 എന്നിവയും താൽക്കാലികമാണ്; 400/401/403/404 ഒരു അഭ്യർത്ഥന/ഐഡൻ്റിറ്റി പ്രശ്‌നമാണ്, വീണ്ടും ശ്രമിച്ചുകൊണ്ട് പരിഹരിക്കാനാകില്ല. ശക്തമായ ഒഴുക്ക് ഈ രണ്ട് ഗ്രൂപ്പുകളിലേക്കും പിശകുകളെ വേർതിരിക്കുന്നു, പരിമിതമായ എണ്ണം തവണ ശ്രമിക്കുന്നു, മുന്നിൽ നിന്ന് പരിധി നിരീക്ഷിക്കുകയും ഉപയോക്താവിന് ശാന്തമായ സന്ദേശങ്ങൾ കാണിക്കുകയും ചെയ്യുന്നു.

ആപ്ലിക്കേഷൻ ടാസ്ക്

നിങ്ങളുടെ ഏകീകരണം പരിഗണിക്കുക. (1) നിങ്ങൾ നേരിട്ടേക്കാവുന്ന പിശക് കോഡുകൾ ലിസ്റ്റുചെയ്യുകയും അവയെ "വീണ്ടും ശ്രമിക്കാവുന്ന / സ്ഥിരം" എന്ന് വേർതിരിക്കുകയും ചെയ്യുക. (2) നിങ്ങളുടെ എക്‌സ്‌പോണൻഷ്യൽ പുൾബാക്ക് പ്ലാൻ (പ്രാരംഭ ഹോൾഡ്, കോഫിഫിഷ്യൻ്റ്, ക്യാപ്, ജിറ്റർ) എഴുതുക. (3) വീണ്ടും ശ്രമിക്കുന്നതിന് ശേഷമുള്ള തലക്കെട്ട് എങ്ങനെ ഉപയോഗിക്കണമെന്ന് വ്യക്തമാക്കുക. (4) വീണ്ടും ശ്രമങ്ങൾ തീരുമ്പോൾ ഉപയോക്താവിന് പ്രദർശിപ്പിക്കേണ്ട മാന്യമായ സന്ദേശം എഴുതുക.

ചെക്ക്ലിസ്റ്റ്

• [ ] എനിക്ക് RPM/ITPM/OTPM പരിധികളും 429 ഉം വിശദീകരിക്കാൻ കഴിയും.
• [ ] എനിക്ക് എക്‌സ്‌പോണൻഷ്യൽ റിട്രീറ്റ് + വിറയൽ + വീണ്ടും ശ്രമിക്കാനുള്ള യുക്തി പ്രയോഗിക്കാൻ കഴിയും.
• [ ] എനിക്ക് പിശക് കോഡുകൾ വീണ്ടും ശ്രമിക്കാവുന്നത്/ശാശ്വതമായി തരംതിരിക്കാം.
• [ ] ഓരോ തെറ്റും നമ്മൾ ശ്രമിക്കരുതെന്ന് എനിക്കറിയാം.
• [ ] ഒരു അസംസ്‌കൃത പിശകിന് പകരം, എനിക്ക് ഉപയോക്താവിനെ ശാന്തവും പ്രവർത്തന-അധിഷ്‌ഠിതവുമായ ഒരു സന്ദേശം കാണിക്കാൻ കഴിയും.