નફો:
- ઝડપ મર્યાદા (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 સેકન્ડ (+ નાનું રેન્ડમ "જીટર")... છોડી દો અને સૌથી વધુ N ટ્રાયલ પછી જાણ કરો
આમાં થોડી અવ્યવસ્થિતતા (જીટર) ઉમેરવાથી તે જ સમયે પુનઃપ્રયાસ કરવાનો પ્રયાસ કરતી વખતે વિનંતીઓને અથડાતી અટકાવે છે. વધુમાં, 429 પ્રતિસાદ ઘણીવાર `ફરીથી પ્રયાસ-પછી` હેડર ધરાવે છે: "આટલી સેકન્ડમાં ફરી પ્રયાસ કરો". આ શીર્ષકને માન આપવું એ આંખ બંધ કરીને રાહ જોવા કરતાં વધુ સચોટ છે.
સાવધાન: જ્યારે તમને 429 મળે છે, ત્યારે "વધુ વિનંતીઓ મોકલીને તેને દબાણ કરવું" પરિસ્થિતિને વધુ ખરાબ કરશે; મર્યાદા ભરવાનું ચાલુ રહે છે અને કોઈ વિનંતીઓ પસાર થતી નથી. સાચો પ્રતિભાવ એ પીછેહઠ છે, પ્રવેગક નથી. સારા સમાચાર: મોટાભાગના અધિકૃત SDK 429 ને આપમેળે ફરીથી પ્રયાસ કરે છે અને બેકઓફ સાથે સર્વર ભૂલો — SDK ની આ વર્તણૂકને મેન્યુઅલી ઇન્સ્ટોલ કરતા પહેલા તેનો ઉપયોગ કરો.
HTTP ભૂલ કોડનું વર્ગીકરણ
દરેક ભૂલ સરખી હોતી નથી. જટિલ ભેદ: શું તેનો ફરીથી પ્રયાસ કરી શકાય છે અથવા તે વિનંતી/ઓળખનો મુદ્દો છે?
કોડ
અર્થ
શું તે ફરીથી પ્રયાસ કરી શકાય છે?
સાચો પ્રતિભાવ
400
અમાન્ય વિનંતી (ફોર્મેટ/પેરામીટર ભૂલ)
ના
વિનંતીને ઠીક કરો; તે જ ફરીથી મોકલશો નહીં
401
પ્રમાણીકરણ ભૂલ (કી અમાન્ય/ખુટતી)
ના
કી/શીર્ષક ઠીક કરો
403
કોઈ અધિકૃતતા નથી (મોડેલ/સુવિધાનો કોઈ ઍક્સેસ નથી)
ના
પરવાનગીઓ/સ્કોપ તપાસો
404
મળ્યું નથી (ખોટો મોડલ ID/અંતિમ બિંદુ)
ના
સાચો મોડલ ID/સરનામું
429
ઝડપ મર્યાદા ઓળંગી
હા
રીટ્રીટ + પુનઃપ્રયાસ પછી
500
સર્વર ભૂલ
હા
પીછેહઠ સાથે ફરી પ્રયાસ કરો
529
સર્વર ઓવરલોડ
હા
પીછેહઠ સાથે ફરી પ્રયાસ કરો
સુવર્ણ નિયમ: 429, 500 અને 529 અસ્થાયી છે; તે ઉપાડ સાથે ફરીથી પ્રયાસ કરવામાં આવે છે. 400, 401, 403, 404 એ વિનંતી/ઓળખની સમસ્યાઓ છે; ફરીથી પ્રયાસ કરવાથી તે હલ થશે નહીં, અને તે પ્રયત્નોને વેડફશે. તમારો કોડ આ બે જૂથો વચ્ચેનો તફાવત હોવો જોઈએ.
પગલું દ્વારા પગલું: ટકાઉ કૉલ
- વિનંતી સબમિટ કરો. જો સફળ થાય, તો ચાલુ રાખો.
- ભૂલ કોડનું વર્ગીકરણ કરો. શું તે ફરીથી પ્રયાસ કરી શકાય છે?
- જો પ્રયાસ કરવા યોગ્ય હોય તો: પુનઃપ્રયાસ પછી અનુસરો, ઘાતાંકીય બેકઓફ + જીટર લાગુ કરો, મર્યાદિત સંખ્યામાં વખત પ્રયાસ કરો (દા.ત. મહત્તમ 5).
- જો પ્રયાસ ન કર્યો હોય તો: ઠીક કરો (ફોર્મેટ/કી) અને બંધ કરો; લૂપમાં સમાન ભૂલભરેલી વિનંતીનું પુનરાવર્તન કરશો નહીં.
- છોડી દેવાનો વિચાર કરો. જો n પ્રયાસો પછી પણ અસફળ હોય, તો વપરાશકર્તાને નમ્ર સંદેશ બતાવો અને ઇવેન્ટને લોગ કરો (ટ્રેકિંગ યુનિટ 11).
# મજબૂત કૉલ સ્યુડો-કોડેન = 0 પુનરાવર્તિત: પ્રતિભાવ = request_at() જો response.success: પ્રતિસાદ પરત કરો જો response.code [429, 500, 529] માં અને < 5: wait = retry_after ?? (2^પ્રયાસ સેકન્ડ + જીટર) ઊંઘ (રાહ જુઓ); પ્રયાસ કરો += 1; git ફરીથી જો [400, 401, 403, 404] માં response.code: save_error(response); પરત કરો "વિનંતી નિશ્ચિત હોવી આવશ્યક છે" પરત કરો "કાયમી ભૂલ, પછીથી પ્રયાસ કરો"
# વપરાશકર્તાને નમ્ર પ્રતિસાદ (જ્યારે પુનઃ પ્રયાસો સમાપ્ત થાય છે) "હું અત્યારે વ્યસ્ત છું, હું તમારી વિનંતી પર પ્રક્રિયા કરી શક્યો નથી. ટૂંક સમયમાં ફરી પ્રયાસ કરો, અથવા મેં તમારી વિનંતી સાચવી લીધી છે, જ્યારે તે તૈયાર થશે ત્યારે હું તમારી પાસે પાછો આવીશ."
નબળા પ્રોમ્પ્ટ / સ્ટ્રોંગ પ્રોમ્પ્ટ (અહીં: ભૂલ સંદેશ ડિઝાઇન)
# નબળું (વપરાશકર્તાને કાચી ભૂલ દર્શાવે છે)"ભૂલ 429: દર_મર્યાદા_ભૂલ"
# સ્ટ્રોંગ (વપરાશકર્તા-મૈત્રીપૂર્ણ, આશ્વાસન આપનાર, ક્રિયા-સૂચન) "સિસ્ટમમાં અસ્થાયી ભીડ હતી. અમને તમારી વિનંતી સુરક્ષિત રીતે પ્રાપ્ત થઈ છે અને તે આપમેળે ફરી પ્રયાસ કરવામાં આવી રહી છે. જો પરિણામ થોડીક સેકંડમાં દેખાતું નથી, તો તમે પૃષ્ઠને તાજું કરી શકો છો."
અંતિમ વપરાશકર્તાને કાચી ટેકનિકલ ભૂલ જાહેર કરવી એ વિશ્વાસને નબળો પાડે છે અને સુરક્ષાની નબળાઈ હોઈ શકે છે. ભૂલોને આંતરિક રીતે વર્ગીકૃત કરો અને વપરાશકર્તાને શાંત, ક્રિયા-લક્ષી સંદેશ આપો; ફક્ત રેકોર્ડ માટે તકનીકી વિગતો લખો.
ત્રણ મિની કેસ
કેસ 1 - ટ્રાફિક વિસ્ફોટમાં બોટ ક્રેશ થઈ. ઝુંબેશના દિવસે ગ્રાહક સેવા બૉટને 429નો વધારો ટ્રાફિક મળ્યો; કોડમાં કોઈ પુનઃપ્રયાસ કરવામાં આવ્યો ન હતો, દરેક ભૂલ સીધી વપરાશકર્તાને "ભૂલ" તરીકે પ્રતિબિંબિત થતી હતી. તેઓએ ઘાતાંકીય રીટ્રેસમેન્ટ + પુનઃપ્રયાસ-આફ્ટર ઉમેર્યું; સમાન ટ્રાફિક સાથે, વિનંતીઓ ઘણી સેકંડના વિલંબ સાથે પસાર થઈ, વપરાશકર્તાને કોઈ ભૂલ દેખાઈ નહીં.
કેસ 2 — લૂપમાં 400 અજમાવી રહ્યાં છીએ. અમાન્ય મોડલ ID ને કારણે એકીકરણને 404 મળી રહ્યું હતું, પરંતુ તે બધી ભૂલોને "ક્ષણિક" માની રહ્યું હતું અને અનંત લૂપમાં ફરી પ્રયાસ કરી રહ્યું હતું; લોગ સોજો બની ગયો અને બિનજરૂરી લોડ બનાવવામાં આવ્યો. તેઓએ ભૂલ વર્ગીકરણ ઉમેર્યું: 404 કાયમી ગણવામાં આવે છે, લૂપ બંધ કરવામાં આવે છે અને મોડેલ ID સુધારેલ છે. પાઠ: દરેક ભૂલ ફરીથી કરવાનો પ્રયાસ કરશો નહીં.
કેસ 3 - આગળથી મર્યાદાનું સંચાલન કરવું. ડેટા સંવર્ધન કાર્ય સતત 429ની મર્યાદામાં ચાલી રહ્યું હતું. તેઓ એક્સ-રેટલિમિટ-બાકી હેડરને અનુસરે છે અને ક્વોટા અનુસાર ટ્રાફિકને થ્રોટલ કરે છે. તેથી તેઓએ કોઈ 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 સમજાવી શકું છું.
- [ ] હું ઘાતાંકીય રીટ્રીટ + જીટર + રીટ્રી-આફ્ટરનો તર્ક લાગુ કરી શકું છું.
- [ ] હું ભૂલ કોડને ફરીથી પ્રયાસ કરવા યોગ્ય/કાયમી તરીકે વર્ગીકૃત કરી શકું છું.
- [ ] હું જાણું છું કે આપણે દરેક ભૂલનો પ્રયાસ ન કરવો જોઈએ.
- [ ] કાચી ભૂલને બદલે, હું વપરાશકર્તાને શાંત, ક્રિયા-લક્ષી સંદેશ બતાવી શકું છું.