Circuit breaker — masofaviy xizmat yoki resurs ketma-ket xato qilganda yangi chaqiruvlarni vaqtincha to‘xtatib, tizimni ortiqcha kutish va cascading failure’dan himoyalaydigan resilience patterni. Nomi elektr zanjiri uzgichidan olingan. U xatoni tuzatmaydi; callerga tez failure yoki fallback berib, dependencyga tiklanish uchun vaqt beradi.
Holatlar
Circuit breaker odatda uch holatga ega:
- Closed: chaqiruvlar o‘tadi, natijalar kuzatiladi.
- Open: chaqiruvlar dependencyga yuborilmaydi va darhol rad etiladi.
- Half-open: kutish davridan keyin cheklangan probe chaqiruvlar o‘tkaziladi.
Half-open probe’lar muvaffaqiyatli bo‘lsa breaker closedga qaytadi. Xato davom etsa yana open bo‘ladi. Bir vaqtda ko‘p instance probe yubormasligi uchun ruxsat soni cheklanadi.
Failure hisoblash
Threshold faqat ketma-ket xato soni yoki rolling windowdagi failure rate bo‘lishi mumkin. Minimal request volume kerak: ikki requestdan bittasi xato bo‘lsa 50 foiz ko‘rinsa-da sample kichik. Slow-call rate ham dependency timeoutga yaqin ishlayotganini ko‘rsatishi mumkin.
Qaysi natija failure ekanini contract belgilaydi. Network timeout va 503 system failure, biznesdagi 404 yoki validatsiya 400 esa breaker ochishi shart emas. Aks holda oddiy client xatosi service outage sifatida talqin qilinadi.
Timeout va retry bilan tartibi
Circuit breaker har chaqiruv uchun deadline o‘rnini bosmaydi. Timeout uzoq osilib qolishni cheklaydi, retry vaqtinchalik xatoni qayta sinaydi, breaker esa umumiy nosozlikda urinishlarni to‘xtatadi. Ularning wrapping tartibi metrikaga ta’sir qiladi: breaker har retry attemptni yoki yakuniy operationni sanashi mumkin.
Retry stormni oldini olish uchun exponential backoff va jitter ishlatiladi. Non-idempotent commandni qayta yuborish duplicate side effect yaratishi mumkin. Breaker open bo‘lishidan oldingi timeoutlar connection/thread poolni band qilib qo‘ymasligi uchun bulkhead ham kerak.
Fallback
Fallback cache’dagi eski qiymat, default response yoki navbatga yozish bo‘lishi mumkin. Noto‘g‘ri fallback xatoni yashirib, semantik jihatdan yolg‘on ma’lumot beradi. Masalan, payment tekshiruvi ishlamasa “muvaffaqiyatli” deb qabul qilish xavfli. Ba’zi operatsiyada tez aniq xato eng to‘g‘ri javobdir.
Fallback ishlatilgani metric va response metadata’da ko‘rinadi. Aks holda xizmat sog‘lom ko‘rinib, asl dependency uzoq vaqt nosoz qolishi mumkin.
Scope
Breaker barcha downstream uchun bitta global bo‘lsa, bir endpointdagi xato boshqalarini ham to‘xtatadi. Odatda service/endpoint yoki failure domain bo‘yicha ajratiladi. Juda mayda breakerlar esa state va monitoring sonini oshiradi.
Har application instance lokal breaker saqlasa, ularning holati turli bo‘ladi. Bu odatda qabul qilinadi va markaziy sinxronlashdan sodda. Load balancer nosoz endpointni health check bilan pooldan chiqarishi breakerga qo‘shimcha himoya beradi.
Monitoring
State transition, rejected call, failure/slow rate va half-open natijalari metrikaga chiqadi. Open holat alert sababi emas, simptom; downstream availability va caller impact bilan bog‘lanadi. Threshold production latency taqsimoti va SLOga mos tanlanadi.
Cold start va recovery
Dependency qayta ishga tushganda cache va connection pool hali sovuq bo‘lishi mumkin. Breaker half-openda birdan to‘liq trafikni ochsa service yana yiqiladi. Cheklangan probe va asta-sekin ramp-up recoveryni tekshiradi. Probe oddiy health endpoint emas, caller ishlatadigan muhim operatsiyaga yaqin bo‘lishi kerak.
Persistent holat
Breaker state odatda process xotirasida saqlanadi va restartda closed bo‘ladi. Bu sodda, lekin barcha replica bir vaqtda restart qilsa nosoz dependencyga trafik qaytadi. Startup jitter va load-balancer health bu burstni kamaytiradi. Markaziy breaker state sinxronlash murakkabligi va yangi failure domain sabab kamroq qo‘llanadi.
Bog‘liq tushunchalar
Timeout, Retry, Bulkhead, Fallback, Cascading failure, Resilience