Retry — muvaffaqiyatsiz amalni xato vaqtinchalik bo‘lishi mumkin degan taxmin bilan qayta bajarish mexanizmi. Tarmoq timeouti, rate limit, leader election yoki qisqa service overload retry bilan tiklanishi mumkin. Noto‘g‘ri validation, ruxsat rad etilishi yoki mavjud bo‘lmagan resurs kabi doimiy xatoni qayta yuborish foyda bermaydi. Retry xatoni yo‘q qilmaydi; u failure semantikasini, vaqt va takroriy side effectni boshqaradi.
Qayta uriniladigan xatolar
HTTP 502, 503, 504 va ayrim 429 javoblari vaqtinchalik bo‘lishi mumkin. Retry-After server qachon qayta urinishni ko‘rsatadi. 400 validation xatosi request o‘zgarmasa takrorlanmaydi. 401 token yangilanishi bilan bir marta qayta bajarilishi mumkin, ammo cheksiz refresh loop bo‘lmaydi.
Database deadlock transactionni qayta boshlashni talab qilishi mumkin. Unique constraint esa ayni yozuvni qayta insert qilish bilan tuzalmaydi. Xato turi typed exception yoki protocol status orqali klassifikatsiya qilinadi; barcha exception’ni tutib retry qilish dastur bugini yashiradi.
Backoff
Darhol va bir xil intervalda retry ko‘p clientni sinxron urinishga olib keladi. Exponential backoff kutish vaqtini har urinishda oshiradi:
delay = min(cap, base × 2^attempt)
Jitter delayga tasodifiylik qo‘shib thundering herdni tarqatadi. Full jitter random(0, calculated_delay) kabi ishlashi mumkin. Maksimal delay va urinish soni request deadline bilan cheklanadi. Parent requestda 2 soniya qolgan bo‘lsa, 10 soniya backoff boshlanmaydi.
Timeout va deadline
Har urinishning connect va response timeouti bor. Timeout juda uzun bo‘lsa thread va connection ushlanadi, juda qisqa bo‘lsa normal tail latency retry stormga aylanadi. End-to-end deadline downstream requestlarga kamaygan remaining time sifatida uzatiladi.
Client timeout olganda server amalni bajarmaganini bilmaydi. Server paymentni commit qilib, javob yo‘lda yo‘qolgan bo‘lishi mumkin. Shu sababli retryable state-changing operation idempotency key bilan bog‘lanadi. Server ayni key uchun avvalgi natijani qaytaradi yoki bir xil amalni takrorlamaydi.
Idempotency
GET, PUT va DELETE HTTP semantikasida idempotent bo‘lishi mumkin, lekin implementatsiya side effectlari, masalan har retryda email jo‘natish, buni buzadi. POST ham idempotency key bilan xavfsiz retry qilinishi mumkin. Key user, endpoint va canonical request hashiga bog‘lanadi; boshqa payload bilan qayta ishlatilsa conflict qaytariladi.
Message consumer at-least-once deliveryda duplicate oladi. Inbox/deduplication table event IDni business transaction bilan birga saqlaydi. Faqat process memorydagi “ko‘rdim” set restartda yo‘qoladi. Tashqi payment yoki email APIning idempotency imkoniyati ham end-to-end chain’da ishlatiladi.
Retry budget
Har layer uch martadan retry qilsa, client, gateway va service zanjirida urinishlar ko‘payib ketadi. Retry responsibility bir qatlamda boshqariladi yoki budget bilan cheklanadi. Masalan, umumiy trafikning faqat ma’lum foizi retry bo‘lishi mumkin. Asosiy request muvaffaqiyat ulushi tushganda retry amplification monitoringda ko‘rinadi.
Circuit breaker failure ko‘paysa dependencyga yangi urinishni vaqtincha to‘xtatadi. Half-open holatda oz sinov requesti yuboriladi. Bulkhead bir dependency uchun thread/connection poolni ajratib, failure boshqa funksiyani yutib yubormasligini ta’minlaydi.
Queue va dead-letter
Background job retry soni va next-attempt vaqtini saqlaydi. Delay queue xabarni darhol consumerga qaytarmaydi. Doimiy xato maksimal urinishdan keyin dead-letter queue’ga o‘tadi. Operator sababni tuzatib replay qiladi; xabar maxfiy data va retention qoidalariga muvofiq saqlanadi.
Poison message butun partition orderingini to‘xtatishi mumkin. Tizim strict ordering, DLQga o‘tkazish yoki entityni bloklash orasida ongli siyosat tanlaydi. Retry metriclari attempt soni, yakuniy success, exhausted va xato turi bo‘yicha ajratiladi.
Bog‘liq tushunchalar
Exponential backoff, Jitter, Idempotency, Timeout, Circuit breaker, Dead-letter queue, Retry budget