Automatic retry — operatsiya yoki test muvaffaqiyatsiz bo‘lganda uni oldindan belgilangan shartlar asosida avtomatik qayta bajarish mexanizmidir. U vaqtinchalik network uzilishi, service overload yoki distributed tizimdagi qisqa nosozlikdan tiklanishga yordam beradi. Retry doim xavfsiz emas: qayta bajarish duplicate side effect, qo‘shimcha yuk va asl xatoni yashirishga olib kelishi mumkin.
Xatoni tasniflash
Timeout, connection reset va 503 kabi holatlar vaqtinchalik bo‘lishi mumkin. Validation error, authentication failure yoki mavjud bo‘lmagan resource ko‘pincha aynan shu request bilan tuzalmaydi. Faqat retryable deb tasniflangan xatolar qayta uriniladi.
HTTP 429 yoki 503 javobidagi Retry-After server tavsiya qilgan kutish vaqtini berishi mumkin. Barcha 5xx xatoni bir xil talqin qilish noto‘g‘ri: server amaliyotni bajargan, ammo javob yo‘qolgan bo‘lishi ehtimol. Client natijaning noaniqligini hisobga oladi.
Backoff va jitter
Darhol ketma-ket retry nosoz dependencyga yanada ko‘p yuk beradi. Exponential backoff kutish vaqtini har urinishda oshiradi. Jitter clientlarning bir xil vaqtda qayta urinishini tarqatib, thundering herd holatini kamaytiradi.
Maksimal urinish, umumiy deadline va har attempt timeouti alohida tushunchalardir. Besh urinishning har biri 30 soniya kutsa foydalanuvchi request deadlineidan oshib ketishi mumkin. Retry budget servisdagi qo‘shimcha trafikni ham cheklaydi.
Idempotency
GET kabi read amali odatda takrorlashga xavfsiz, ammo barcha endpoint semantikasi method nomidan kelib chiqmaydi. Payment yaratish requesti ikki marta bajarilsa ikki to‘lov yuz berishi mumkin. Idempotency key serverga bir mantiqiy amaliyotning takroriy requestlarini tanish imkonini beradi.
Consumer processingda message ID va natija bitta transactionda qayd etilishi mumkin. Tashqi email yoki webhook transactionga kirmasa outbox va deduplication kerak bo‘ladi. Retry idempotency o‘rnini bosmaydi; ikkalasi birga loyihalanadi.
Retry qatlamlari
SDK, service mesh, application va queue consumer bir xil requestni mustaqil retry qilsa urinishlar ko‘paytma bo‘ladi. Har qatlam uch marta urinsa downstreamga to‘qqiz yoki undan ko‘p chaqiriq borishi mumkin. Ownership va maksimal umumiy deadline hujjatlashtiriladi.
Circuit breaker dependency uzoq nosoz bo‘lsa yangi urinishni vaqtincha to‘xtatadi. Bulkhead bir dependencydagi kutish barcha workerlarni band qilmasligini ta’minlaydi. Retry bu mexanizmlar bilan muvofiqlashadi.
Test runnerdagi retry
Test retry flaky environment sabab birinchi failuredan keyin qayta run qiladi. Yakunda o‘tgan test ham “flaky” sifatida ajratiladi va dastlabki trace saqlanadi. Retry sonini oshirish assertion race, shared data yoki mahsulot bugini tuzatmaydi.
Testning o‘zi side effectli bo‘lsa retry yangi user, order yoki fayl yaratishi mumkin. Har urinish mustaqil fixture va cleanupga ega bo‘ladi. Failure faqat ma’lum infrastructure signalida retry qilinishi yoki barcha failure diagnostika uchun qayta bajarilishi runner siyosatiga bog‘liq.
Kuzatuv
Attempt count, final result, xato turi va backoff vaqti metric hamda traceda ko‘rinadi. Faqat yakuniy successni yozish dependency beqarorligini yashiradi. Retry rate oshishi incidentning erta signali bo‘lishi mumkin.
Hedging bilan farqi
Hedged request birinchi urinish tugashini kutmasdan kechikayotgan read uchun ikkinchi parallel so‘rov yuboradi. Bu tail latencyni kamaytirishi mumkin, ammo normal retrydan ko‘proq bir vaqtdagi yuk yaratadi. Faqat idempotent va yetarli capacityli operatsiyada, qat’iy delay hamda budget bilan ishlatiladi.
Retry storm incidentni kuchaytiradi: ko‘p client timeoutdan keyin qayta urinib, tiklanayotgan serverni yana band qiladi. Server load shedding, client jitter va global retry budget birga qo‘llanadi. Successga yetgan retry ham qo‘shimcha load metricida hisoblanadi.
Bog‘liq tushunchalar
Exponential backoff, Jitter, Idempotency, Circuit breaker, Timeout, Flaky test, Retry budget