ලාභ:
- වේග සීමාවන් (RPM/ITPM/OTPM) සහ දෝෂ 429 අර්ථ දැක්විය හැක
- ඝාතීය පසුබෑම ක්රියාත්මක කර නැවත උත්සාහ කිරීමෙන් පසු නැවත උත්සාහ කරන්න
- පොදු HTTP දෝෂ කේත (400/401/429/500/529) නිවැරදිව වර්ගීකරණය කර හසුරුවයි
නිෂ්පාදන පරිසරයක් තුළ, කිසිදු API සෑම විටම පරිපූර්ණ ලෙස ප්රතිචාර නොදක්වයි. සමහර විට ඔබ ඉතා ඉක්මනින් ඉල්ලීම් යවා සීමාවට පැමිණේ; සමහර විට සේවාදායකය තාවකාලිකව කාර්යබහුලයි; සමහර විට ඔබේ ඉල්ලීම මුල සිටම වැරදියි. ආධුනික උත්සාහයකින් ශක්තිමත් ඒකාබද්ධතාවයක් වෙන්කර හඳුනා ගන්නේ එය මෙම තත්වයන් පුරෝකථනය කර ස්වයංක්රීයව හැසිරවීමයි. මෙම ඒකකය තුළ ඔබ අනුපාත සීමාවන් (RPM/ITPM/OTPM), 429 දෝෂය, ඝාතීය පසුබෑම සමඟ නැවත උත්සාහ කිරීම සහ පොදු HTTP දෝෂ කේත නිසි ලෙස වර්ගීකරණය ගැන ඉගෙන ගනු ඇත. ඉලක්කය: පරිශීලකයෙකුට කිසිදා නොපෙනෙන තරම් ශක්තිමත් ප්රවාහයක් ගොඩනැගීම.
වේග සීමාවන් මොනවාද?
සපයන්නා විසින් දෙන ලද කාල සීමාවක් තුළ ස්විචයකට කළ හැකි කාර්යය සීමා කරයි. මෙම ආරක්ෂාව; එය හදිසි පිරිවැය පිපිරීම් වලින් යටිතල පහසුකම් සහ ඔබ යන දෙකම ආරක්ෂා කරයි. පොදු සීමාවන් වර්ග තුනක් තිබේ:
- RPM (විනාඩියකට ඉල්ලීම්): විනාඩියකට ඉල්ලීම් ගණන.
- ITPM (විනාඩියකට ආදාන ටෝකන): මිනිත්තුවකට සැකසිය හැකි ආදාන ටෝකනය.
- OTPM (විනාඩියකට ප්රතිදාන ටෝකන): මිනිත්තුවකට නිපදවිය හැකි ප්රතිදාන ටෝකනය.
ඔබ මෙම සීමාවන් කිසිවක් ඉක්මවා ගියහොත්, සැපයුම්කරු ඉල්ලීම ප්රතික්ෂේප කර 429 දෝෂ කේතයක් ලබා දෙයි. සීමාවන් සාමාන්යයෙන් ඔබගේ ගිණුම් මට්ටම (ස්ථරය) අනුව වෙනස් වන අතර කාලයත් සමඟ වැඩි විය හැක.
ඉඟිය: ඔබ ප්රතිචාර ශීර්ෂයෙන් සීමාවට ළඟා වන විට ඔබට නැරඹිය හැක. බොහෝ සැපයුම්කරුවන් x-ratelimit-remaining-* වැනි ශීර්ෂයන් සමඟ ඔබේ ඉතිරි කෝටාව වාර්තා කරයි. මෙම අගයන් අධීක්ෂණය කිරීම සහ ඉදිරියෙන් ඇති ගමනාගමනය අවහිර කිරීම 429 ලබා නොගෙන ගැටලුව වළක්වා ගැනීමට වඩාත්ම පරිණත මාර්ගයයි.
429 සහ ඝාතීය නැවත ලබා ගැනීම
429 (අනුපාත සීමාව) යනු තාවකාලික සහ නැවත උත්සාහ කළ හැකි දෝෂයකි. නිවැරදි ප්රතිචාරය වන්නේ ඉල්ලීම සඳහා ටික වේලාවක් රැඳී සිට නැවත උත්සාහ කිරීමයි. නමුත් නිරන්තර බලා සිටීම ප්රමාණවත් නොවේ; සියලු දෙනාම එකම වේලාවක නැවත උත්සාහ කළහොත්, සීමාව නැවත ළඟා වනු ඇත. විසඳුම ඝාතීය පසුබෑමයි: සෑම අසාර්ථක උත්සාහයක් සමඟම පොරොත්තු කාලය ඝාතීය ලෙස වැඩි කිරීම.
# ඝාතීය පසුබැසීම තාර්කික අත්හදා බැලීම 1 → 429 → රැඳී සිටින්න 1 තත්පර අත්හදා බැලීම 2 → 429 → රැඳී සිටින්න තත්පර 2 අත්හදා බැලීම 3 → 429 → රැඳී සිටින්න තත්පර 4 අත්හදා බැලීම 4 → 429 → තත්පර 8 ක් රැඳී සිටින්න
මෙයට කුඩා අහඹු බවක් (ජිටර්) එකතු කිරීමෙන් එකවර නැවත උත්සාහ කිරීමට උත්සාහ කිරීමේදී ඉල්ලීම් ගැටීම වළක්වයි. මීට අමතරව, 429 ප්රතිචාරය බොහෝ විට 'නැවත උත්සාහ කරන්න' ශීර්ෂයක් දරයි: "මෙතරම් තත්පර කිහිපයකින් නැවත උත්සාහ කරන්න". අන්ධව බලා සිටිනවාට වඩා මෙම මාතෘකාවට ගරු කිරීම වඩාත් නිවැරදිය.
අවවාදයයි: ඔබ 429 ලබා ගත් විට, "තවත් ඉල්ලීම් යැවීමෙන් එය බල කිරීම" තත්වය වඩාත් නරක අතට හැරෙනු ඇත; සීමාව දිගටම පුරවා ඇති අතර කිසිදු ඉල්ලීමක් සිදු නොවේ. නිවැරදි ප්රතිචාරය වන්නේ පසුබැසීම මිස ත්වරණය නොවේ. ශුභාරංචිය: බොහෝ නිල SDKs ස්වයංක්රීයව 429 නැවත උත්සාහ කරන අතර පසුබැසීමක් සමඟ සේවාදායක දෝෂ - එය අතින් ස්ථාපනය කිරීමට පෙර SDK හි මෙම හැසිරීම භාවිතා කරන්න.
HTTP දෝෂ කේත වර්ගීකරණය
සෑම වරදක්ම එක හා සමාන නොවේ. විවේචනාත්මක වෙනස: එය නැවත උත්සාහ කළ හැකිද නැතහොත් එය ඉල්ලීමක්/අනන්යතා ගැටලුවක්ද?
කේතය
අර්ථය
එය නැවත උත්සාහ කළ හැකිද?
නිවැරදි ප්රතිචාරය
400
වලංගු නොවන ඉල්ලීම (ආකෘතිය/පරාමිති දෝෂය)
නැත
ඉල්ලීම නිවැරදි කරන්න; නැවත එයම එවන්න එපා
401
සත්යාපන දෝෂය (යතුර වලංගු නැත/අතුරුදහන්)
නැත
යතුර/මාතෘකාව නිවැරදි කරන්න
403
අවසරයක් නැත (ආකෘතියට/විශේෂාංගයට ප්රවේශයක් නැත)
නැත
අවසර / විෂය පථය පරීක්ෂා කරන්න
404
හමු නොවීය (වැරදි ආදර්ශ හැඳුනුම්පත/අවසන් ලක්ෂ්යය)
නැත
නිවැරදි මාදිලි හැඳුනුම්පත/ලිපිනය
429
වේග සීමාව ඉක්මවා ඇත
ඔව්
පසුබැසීම + නැවත උත්සාහ කරන්න
500
සේවාදායක දෝෂයකි
ඔව්
පසුබැසීම සමඟ නැවත උත්සාහ කරන්න
529
සේවාදායකය අධික ලෙස පටවා ඇත
ඔව්
පසුබැසීම සමඟ නැවත උත්සාහ කරන්න
රන් රීතිය: 429, 500 සහ 529 තාවකාලිකයි; එය ආපසු ගැනීම සමඟ නැවත උත්සාහ කරයි. 400, 401, 403, 404 ඉල්ලීම්/අනන්යතා ගැටළු වේ; නැවත උත්සාහ කිරීමෙන් එය විසඳිය නොහැකි අතර එය උත්සාහය අපතේ යයි. ඔබේ කේතය මෙම කණ්ඩායම් දෙක අතර වෙනස හඳුනාගත යුතුය.
පියවරෙන් පියවර: කල් පවතින ඇමතුම
- ඉල්ලීම ඉදිරිපත් කරන්න. සාර්ථක නම්, දිගටම කරගෙන යන්න.
- දෝෂ කේතය වර්ග කරන්න. එය නැවත උත්සාහ කළ හැකිද?
- උත්සාහ කළ හැකි නම්: නැවත උත්සාහ කරන්න-පසු අනුගමනය කරන්න, ඝාතීය backoff + jitter යොදන්න, සීමිත වාර ගණනක් උත්සාහ කරන්න (උදා. උපරිම 5).
- උත්සාහ නොකළේ නම්: සවි කරන්න (ආකෘතිය / යතුර) සහ නවත්වන්න; ලූපයේ එකම වැරදි ඉල්ලීම නැවත නොකරන්න.
- අත්හැරීම ගැන සලකා බලන්න. n උත්සාහයෙන් පසුවත් අසාර්ථක වුවහොත්, පරිශීලකයාට ආචාරශීලී පණිවිඩයක් පෙන්වා සිද්ධිය ලොග් කරන්න (ලුහුබැඳීමේ ඒකකය 11).
# ශක්තිමත් ඇමතුම pseudo-codedene = 0repeat: response = request_at() if response.success: response.code in [429, 500, 529] උත්සාහ කර < 5: wait = retry_after ?? (2^උත්සාහ ත උත්සාහ කරන්න += 1; [400, 401, 403, 404] හි response.code නම් නැවත git: save_error(response); ආපසු "ඉල්ලීම නිවැරදි කළ යුතුය" ආපසු "ස්ථිර දෝෂයක්, පසුව උත්සාහ කරන්න"
# පරිශීලකයාට ආචාරශීලී ප්රතිපෝෂණය (නැවත උත්සාහයන් අවසන් වූ විට) "මම දැන් කාර්යබහුලයි, මට ඔබේ ඉල්ලීම ක්රියාවට නැංවීමට නොහැකි විය. ඉක්මනින් නැවත උත්සාහ කරන්න, නැතහොත් මම ඔබේ ඉල්ලීම සුරැකුවෙමි, එය සූදානම් වූ විට මම ඔබ වෙත ආපසු එන්නම්."
දුර්වල විමසුම / ශක්තිමත් විමසුම (මෙහි: දෝෂ පණිවිඩ නිර්මාණය)
# WEAK (පරිශීලකයාට අමු දෝෂයක් පෙන්වයි)"දෝෂය 429: අනුපාතය_සීමා_දෝෂය"
# STRONG (පරිශීලක හිතකාමී, සහතික කිරීම, ක්රියා යෝජනා කිරීම) "පද්ධතියේ තාවකාලික තදබදයක් ඇති විය. අපට ඔබගේ ඉල්ලීම ආරක්ෂිතව ලැබී ඇති අතර එය ස්වයංක්රීයව නැවත උත්සාහ කරමින් පවතී. තත්පර කිහිපයකින් ප්රතිඵලයක් නොපෙන්වන්නේ නම්, ඔබට පිටුව නැවුම් කළ හැක."
අවසාන පරිශීලකයාට අමු තාක්ෂණික දෝෂය හෙළිදරව් කිරීම යන දෙකම විශ්වාසය යටපත් කරන අතර ආරක්ෂක අවදානමක් විය හැකිය. අභ්යන්තරව දෝෂ වර්ගීකරණය කර පරිශීලකයාට සන්සුන්, ක්රියාවට නැඹුරු පණිවිඩයක් ලබා දෙන්න; වාර්තාව සඳහා තාක්ෂණික විස්තර ලියන්න.
කුඩා නඩු තුනක්
නඩුව 1 - රථවාහන පිපිරීමකින් බෝට්ටුවක් කඩා වැටුණි. ප්රචාරක දිනයේදී පාරිභෝගික සේවා බොට් එකකට 429ක් ලැබුණි; කේතය තුළ නැවත උත්සාහයක් නොතිබුණි, සෑම දෝෂයක්ම "දෝෂයක්" ලෙස පරිශීලකයාට සෘජුවම පිළිබිඹු විය. ඔවුන් ඝාතීය retracement + නැවත උත්සාහ කළ පසු; එකම ගමනාගමනය සමඟ, ඉල්ලීම් තත්පර කිහිපයක ප්රමාදයකින් සම්මත වූ අතර, පරිශීලකයා කිසිදු දෝෂයක් දුටුවේ නැත.
නඩුව 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 පැහැදිලි කළ හැක.
- [ ] මට ඝාතීය පසුබැසීම + jitter + නැවත උත්සාහ කිරීමේ තර්කය යෙදිය හැක.
- [ ] මට දෝෂ කේත නැවත උත්සාහ කළ හැකි/ස්ථිර ලෙස වර්ග කළ හැක.
- [ ] මම දන්නවා අපි හැම වැරැද්දක්ම උත්සාහ නොකළ යුතු බව.
- [ ] අමු දෝෂයක් වෙනුවට, මට පරිශීලකයාට සන්සුන්, ක්රියාවට නැඹුරු පණිවිඩයක් පෙන්විය හැක.