GH GambleHub

Timeout и circuit control

1) Niyə lazımdır

Sistemlər bir «ölümcül» uğursuzluqdan deyil, gecikmələrin və «dalğa» retrajlarının toplanmasından düşür. Taymautlar gözləmə müddətini məhdudlaşdırır və resursları buraxır və circuit control (breaker + shedding + adaptiv rəqabət) deqradasiyanın asılılıq zəncirinə yayılmasına imkan vermir. Məqsəd p95/p99-u hədəf sərhədlərində saxlamaq və qismən uğursuzluqlar zamanı mövcudluğunu qorumaqdır.


2) Əsas təriflər

2. 1 Taymaut növləri (L7/L4)

Connect timeout - TCP/TLS bağlantısının qurulması.
TLS/Handshake timeout - preface TLS/HTTP2 əl sıxmaq.
Write timeout - sorğu göndərilməsi (bədən daxil olmaqla).
Read timeout - cavabın və/və ya bütün bədənin ilk baytını gözləmək.
Idle/Keep-Alive timeout - aktiv olmayan əlaqə.
Overall deadline - bütün sorğu üçün «sərt» müddət (end-to-end).

2. 2 Taymaut büdcəsi (deadline budget)

Hədəf 'deadline _ total' seçilir və mərhələlərə bölünür:
  • `ingress (gateway) + authZ + app + DB/cache + outbound PSP`.
payments 'POST' üçün nümunə (məqsəd 400 ms):
  • şluz: 30 ms,
  • əlavə: 120 ms,
  • BD: 120 ms,
  • PSP: 100 ms,
  • ehtiyatı: 30 ms.

2. 3 Propagation və ləğv

'deadline '/' timeout' zəncirdən aşağı ötürülməlidir (kontekst, başlıqlar, gRPC Deadline). Bitdikdə - fon əməliyyatlarının ləğvi (abort/ctx cancel), blokların/semaforların təmizlənməsi.


3) Taymaut quraşdırma strategiyaları

1. Yuxarıdan aşağıya: SLO və p95 əsaslanaraq - end-to-end deadline təyin edin, sonra alt-taymautlara bölün.
2. «Bahalı» yolları müəyyən etmək (fayl yükləmə, hesabatlar, xarici PSP) - ayrı-ayrı daha uzun, lakin məhdud.

3. Idempotent vs write:
  • idempotent (GET/status təkrarları) - qısa, daha aqressiv;
  • write/pul - bir az daha uzun, lakin bir dəfə təkrar və idempotent ilə.
  • 4. Planlara/tenantlara görə dərəcə (enterprise daha uzun vaxt ola bilər, lakin daha az paralellik).


4) Circuit breaker: modelləri və parametrləri

4. 1 işləmə siyasəti

Failure-rate: N istək/vaxt pəncərəsində X% ≥ səhv payı.
Consecutive failures: M ardıcıl uğursuzluqlar.
Slow-call rate: T. həddindən uzun zənglərin payı.
Error classes: vaxt/5xx/connection-reset → «ölümcül», 4xx - nəzərə alınmır.

4. 2 Hallar

Closed - hər şeyi qaçırır, statistika yığır.
Açıq - ani uğursuzluq (resurslara qənaət edir, asılılığa təzyiq etmir).
Half-open - «suyun yoxlanılması» üçün kiçik «testlər» (N sorğular).

4. 3 Faydalı əlavələr

Bulkhead (shpangouts): asılılıq üçün axınlar/bağlantılar hovuzu, bir bütün «sormaq» deyil.
Adaptive concurrency: parallelizmin avtomatik məhdudlaşdırılması (AIMD/Vegas oxşar alqoritmlər).
Load Shedding: lokal resurs (növbə, CPU, GC-fasilə) çatışmazlığı zamanı erkən uğursuzluq/deqradasiya.


5) Qarşılıqlı əlaqə: taymautlar, retrajlar, limitlər

Əvvəlcə deadline, sonra retralar: hər təkrarlama ümumi bir son tarixə sığmalıdır.
Təkrarlamalar üçün Backoff + jitter; hörmət 'Retry-After' və retry-budget.
Rate limiting: açıq breaker ilə - fırtınanı gücləndirməmək üçün limitləri azaltın.
Idempotency: write əməliyyatlarında tələb olunur («səssiz» taymautlarda dublların qarşısını almaq üçün).
Harada retraj: daha çox kənarda (müştəri/şlyuz), dərin deyil.


6) Praktiki məqsədli dəyərlər

Public read API: end-to-end '200-500 ms', read timeout '100-300 ms'.
Kritik write (ödənişlər): '300-800 ms' e2e; xarici PSP ≤ '250-400 ms'.
Connect/TLS: '50-150 ms' (daha çox - şəbəkə/həll problemi).
Idle: '30-90 s' (mobil müştərilər batareyaya qənaət etmək üçün qısadır).
Dəyərləri p95/p99 və bölgələrə görə düzəldin.


7) Konfiqilər və nümunələr

7. 1 Envoy (cluster + route, psevdo)

yaml clusters:
- name: payments_psp connect_timeout: 100ms type: STRICT_DNS lb_policy: ROUND_ROBIN circuit_breakers:
thresholds:
- priority: DEFAULT max_connections: 2000 max_requests: 2000 max_retries: 50 outlier_detection:
consecutive_5xx: 5 interval: 5s base_ejection_time: 30s max_ejection_percent: 50

routes:
- match: { prefix: "/api/v1/payments" }
route:
cluster: payments_psp timeout: 350ms        # per-request deadline idle_timeout: 30s retry_policy:
retry_on: "reset,connect-failure,refused-stream,5xx,gateways"
num_retries: 1 per_try_timeout: 200ms

7. 2 NGINX (perimetr)

nginx proxy_connect_timeout 100ms;
proxy_send_timeout  200ms;  # write proxy_read_timeout  300ms;  # read (первый байт/все тело)
keepalive_timeout   30s;
send_timeout     15s;

Быстрый отказ при перегрузке limit_conn_zone $binary_remote_addr zone=addr:10m;
limit_conn addr 50;

7. 3 gRPC (müştəri, Go-psevdo)

go ctx, cancel:= context.WithTimeout(context.Background(), 350time.Millisecond)
defer cancel()
resp, err:= client.Pay(ctx, req) // Deadline передается вниз

7. 4 HTTP müştəri (Go)

go client:= &http.Client{
Timeout: 350 time.Millisecond, // общий дедлайн на запрос
Transport: &http.Transport{
TLSHandshakeTimeout: 100 time.Millisecond,
ResponseHeaderTimeout: 250 time.Millisecond,
IdleConnTimeout: 30 time.Second,
MaxIdleConnsPerHost: 100,
},
}

7. 5 Resilience4j (Java, psevdo)

yaml resilience4j.circuitbreaker.instances.psp:
slidingWindowType: TIME_BASED slidingWindowSize: 60 failureRateThreshold: 50 slowCallDurationThreshold: 200ms slowCallRateThreshold: 30 permittedNumberOfCallsInHalfOpenState: 5 waitDurationInOpenState: 30s

resilience4j.timelimiter.instances.psp:
timeoutDuration: 350ms

8) Müşahidə və alertinqlər

8. 1 Metrika

`http_client_requests{endpoint, status}`, `client_latency_bucket`

`timeouts_total{stage=connectreadwritedeadline}`
`circuit_state{dependency}`: 0/1/2 (closed/half/open)
`slow_call_rate`, `failure_rate`
`active_concurrency{route, dependency}`
`shed_requests_total{reason}` (load shedding)
`retry_total{reason}`, `retry_budget_used`

8. 2 Treys

Span: ingress → handler → DB/Redis → xarici.
'timeout _ ms _ target', 'circuit _ state', 'queue _ time _ ms' atributları.
Exemplar: p99 zirvələrini xüsusi trace-id-ə bağlayın.

8. 3 Alertlər

'p99 _ latency {critical}'> ardıcıl X dəqiqə hədəfləri.
'timeout _ rate {dependency}' sıçrayışlı> Y%.
Tez-tez 'open '/' flapping' breaker.
Yüksək CPU/GC ilə 'shed _ requests _ total' artımı.


9) Adaptive Concurrency & Load Shedding

9. 1 Fikir

Avtomatika latentlik quyruqlarının böyüməsi ilə paralelliyi azaldır:
  • AIMD: yavaş artırmaq, kəskin azaltmaq.
  • Vegas kimi: hədəf növbə saxlamaq (queue time).
  • Token-based: hər sorğu «yandırır» token; tokenlər ölçülmüş sürətə görə verilir.

9. 2 Realizasiya

Yerli semaforlar per-route; məqsəd 'queue _ time' eşikdən aşağı tutmaqdır.
Şlyuzda qlobal «qoruyucu» (limit RPS/rəqabət).
CPU/qoşulma çatışmazlığı olduqda - məntiq yerinə yetirilməzdən əvvəl erkən uğursuzluq (429/503 c 'Retry-After').


10) Test və xaos ssenariləri

Latency injection: süni asılılıq üçün 50-300 ms əlavə.
Packet loss/dup/drop (tc/tbf, Toxiproxy).
Knob turning: bağlantı hovuzları azaltmaq, yükü saturation qədər artırmaq.
Kill/Degrade bir zona/şard (qismən əlçatmazlıq).
Yoxlamalar: retraj fırtınası «uğursuz» deyil; breaker proqnozlaşdırıla bilər; növbə artır?


11) Antipattern

Bir qlobal «read timeout» heç bir detal connect/TLS/per-stage.
Ümumi müddətin olmaması → retralar SLO-dan kənara çıxır.
Jittersiz və retry-budget olmadan retrai.
İdle-taymautlar olmadan «əbədi» bağlantılar → deskriptorların sızması.
Breaker 4xx ölümcül səhvlər hesab edir.
Heç bir ləğv/abort → arxa plan işləri müştərinin vaxtından sonra davam edir.
Mobil/qeyri-sabit şəbəkələr üçün çox uzun müddət.


12) iGaming/Maliyyə Xüsusiyyətləri

Kritik write (depozitlər/nəticələr): Idempotency-Key ilə bir qısa təkrar, sonra '202 Accepted' + sonsuz gözləntilər əvəzinə polling.
PSP/bankçılıq: provayder/region üzrə ayrı siyasətlər (bəziləri daha yavaş).
Məsuliyyətli ödənişlər və limitlər: bloklama/revyu zamanı - sürətli '423/409', «asılı» əməliyyatları uzatmayın.
Hesabat/aqreqasiya - asenkron (batch + status-resurs) işə salmaq.


13) Prod hazırlıq yoxlama siyahısı

  • Kritik marşrutlar (GET/POST) üzrə end-to-end deadline müəyyən edilmişdir.
  • Büdcə mərhələlərə bölünür; aktiv propagation müddəti.
  • Connect/TLS/read/write/idle şlüzdə və müştərilərdə vaxt.
  • failure-rate və slow-call eşikləri ilə circuit breaker; düzgün half-open məntiq.
  • asılılıq Bulkheads; per-route paralellik limitləri.
  • Həddindən artıq yükləmə zamanı iş məntiqi yerinə yetirilməzdən əvvəl yükləmə.
  • Retrajlarla inteqrasiya: backoff + jitter, retry-budget, hörmət 'Retry-After'.
  • Idempotentlik write, 'Idempotency-Key' və hadisələr üçün outbox.
  • Metrik: timeout/slow-call/breaker state/queue time/rəqabət.
  • Xaos testləri: gecikmələr/itkilər/nasazlıqlar, zonaların deqradasiyası.
  • Müştəri sənədləri: tayming nümunələri, cavab kodları, təkrarlama məsləhətləri.

14) TL; DR

Hər bir sorğuya sərt bir son tarix verin, mərhələlərə bölün və zəncirdən aşağı yayın. circuit breaker + bulkheads + adaptive concurrency + load shedding vasitəsilə uğursuzluqları idarə edin. Təkrarlamalar - yalnız son tarix çərçivəsində, jitter və büdcə ilə; write - yalnız idempotent. Timeout/slow-call, breaker vəziyyəti və 'queue _ time' ölçün, müntəzəm olaraq xaos testlərini təqib edin.

Contact

Bizimlə əlaqə

Hər hansı sualınız və ya dəstək ehtiyacınız varsa — bizimlə əlaqə saxlayın.Həmişə köməyə hazırıq!

İnteqrasiyaya başla

Email — məcburidir. Telegram və ya WhatsApp — istəyə bağlıdır.

Adınız istəyə bağlı
Email istəyə bağlı
Mövzu istəyə bağlı
Mesaj istəyə bağlı
Telegram istəyə bağlı
@
Əgər Telegram daxil etsəniz — Email ilə yanaşı orada da cavab verəcəyik.
WhatsApp istəyə bağlı
Format: ölkə kodu + nömrə (məsələn, +994XXXXXXXXX).

Düyməyə basmaqla məlumatların işlənməsinə razılıq vermiş olursunuz.