Timeout и circuit control

1) Бұл не үшін қажет

Жүйелер бір ғана «өлім-жітімнен» емес, кідірістер мен «толқынды» ретрациялардың жиналуынан құлдырады. Таймауттар күту уақытын шектейді және ресурстарды босатады, ал circuit control (breaker + shedding + бейімделген бәсекелестік) тәуелділік тізбегі бойынша таралып кетуге жол бермейді. Мақсаты - p95/p99-ды мақсатты шектерде ұстау және ішінара істен шыққан кезде қол жетімділікті сақтау.

2) Базалық анықтамалар

2. 1 Таймауттар түрлері (L7/L4)

Connect timeout - TCP/TLS қосылымдарын орнату.
TLS/Handshake timeout - TLS/HTTP2 preface қол алысу.
Write timeout - сұрау жіберу (денені қоса алғанда).
Read timeout - жауаптың бірінші байтын және/немесе бүкіл денені күту.
Idle/Keep-Alive timeout - белсенді емес қосылым.
Overall deadline - бүкіл сұрау салуға (end-to-end) «қатаң» мерзім.

2. 2 Таймауттың бюджеті (deadline budget)

• `ingress (gateway) + authZ + app + DB/cache + outbound PSP`.

• шлюз: 30 мс,
• қосымша: 120 мс,
• БД: 120 мс,
• PSP: 100 мс,
• қор: 30 мс.

2. 3 Propagation және күшін жою

'deadline '/' timeout' тізбегі бойынша (контексті, тақырыптары, gRPC Deadline) жіберілуі керек. Аяқталғанда - фондық операцияларды жою (abort/ctx cancel), блоктауларды/семафорларды тазалау.

3) Таймауттарды орнату стратегиялары

1. Жоғарыдан төмен: SLO және p95 негізінде - end-to-end deadline, содан кейін төменгі таймауттарға бөлу.
2. «Қымбат» жолдарды сәйкестендіру (файлды жүктеу, есептер, сыртқы PSP) - жеке ұзын, бірақ шектелген.

• idempotent (GET/мәртебені қайталау) - қысқа, агрессивті;
• write/ақшалай - сәл ұзын, бірақ бір рет қайталануы және іспеттілігі бар.

4. Жоспарлар/тенанттар бойынша градуирлеу (enterprise timeout ұзын, бірақ аз параллелизмге ие болуы мүмкін).

4) Circuit breaker: модельдері мен параметрлері

4. 1 Іске қосу саясаты

Failure-rate: N сұраулар/уақыт терезесінде X% ≥ қателер үлесі.
Consecutive failures: M қатарынан сәтсіздіктер.
Slow-call rate: T. шегінен ұзақ шақыру үлесі.
Error classes: таймауттар/5xx/connection-reset → «өлім», 4xx - ескермейміз.

4. 2 күй- жайы

Closed - бәрін өткізіп жібереді, статистиканы жинақтайды.
Open - жылдам істен шығу (ресурстарды үнемдейді, тәуелділікті қысмайды).
Half-open - «суды тексеру» үшін шағын «сынамалар» (сұрау N).

4. 3 Пайдалы толықтырулар

Bulkhead (шпангоуттар): бір адам бәрін «сорып алмайтындай» тәуелділік үшін ағындар/қосылымдар пулы.
Adaptive concurrency: бақыланатын латенттілік бойынша параллелизмді автоматты шектеу (AIMD/Vegas-ұқсас алгоритмдер).
Load Shedding: жергілікті ресурс (кезек, CPU, GC-үзіліс) жетіспеген кезде ерте істен шығу/тозу.

5) Өзара іс-қимыл: таймауттар, ретрациялар, лимиттер

Алдымен deadline, содан кейін ретра: әрбір қайталау ортақ мерзімге сыйуы керек.
Backoff + jitter қайталау үшін; 'Retry-After' және retry-budget.
Rate limiting: ашық breaker кезінде - дауылды күшейтпеу үшін лимиттерді төмендетіңіз.
Idempotency: write-операцияларында міндетті («үнсіз» таймауттар кезінде дубльдерді болдырмау үшін).
Қайда ретрациялауға болады: ішкі жағында емес, шетінде (клиент/шлюз).

6) Практикалық нысаналы мәндер (бағдарлар)

Көпшілік оқыған API: end-to-end '200-500 мс', read timeout '100-300 мс'.
Сындарлы write (төлемдер): '300-800 мс' e2e; сыртқы PSP ≤ '250-400 мс'.
Connect/TLS: '50-150 мс' (көп - желі/шешу проблемасы).
Idle: '30-90 с' (мобильді клиенттер батареяны үнемдеу үшін қысқа).
Мәндерді p95/p99 және өңірлер бойынша түзетіңіз.

7) Конфиги және мысалдар

7. 1 Envoy (cluster + route, псевдо)

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 (периметр)

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 (клиент, Go-psevdo)

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

7. 4 HTTP-клиент (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, псевдо)

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) Бақылау және алертингтер

8. 1 Өлшемдері

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

8. 2 Трейдерлер

Spanes: ingress → handler → DB/Redis → сыртқы.
'timeout _ ms _ target', 'circuit _ state', 'queue _ time _ ms' төлсипаттары.
Экземпларлар: p99 шыңдарын нақты trace-id-ге байлау.

8. 3 Алерттар

'p99 _ latency {critical}'> мақсаттары қатарынан X минут.
'timeout _ rate {dependency}' секірмелі> Y%.
'open '/' flapping' breaker.
Жоғары CPU/GC кезінде 'shed _ requests _ total' өсуі.

9) Adaptive Concurrency & Load Shedding

9. 1 Идея

• AIMD: баяу ұлғайту, күрт төмендету.
• Vegas-ұқсас: мақсатты кезек (queue time).
• Token-based: әрбір сұрау токенді «жағады»; токендер өлшенген жылдамдық бойынша беріледі.

9. 2 Іске асыру

per-route жергілікті семафорлары; мақсат - 'queue _ time' шегінен төмен ұстап тұру.
Шлюздегі жаһандық «сақтандырғыш» (шекті RPS/бәсекелестік).
CPU/қосылыстар жетіспеген жағдайда - логика орындалғанға дейін ерте істен шығу (429/503 с 'Retry-After').

10) Тестілеу және хаос-сценарийлер

Latency injection: тәуелділікке 50-300 мс жасанды қосу.
Packet loss/dup/drop (tc/tbf, Toxiproxy).
Knob turning: қосу пулдарын азайту, жүктемені saturation дейін арттыру.
Kill/Degrade бір аймақ/шард (ішінара қол жетімсіздік).
Тексерулер: ретрай-дауыл «сәтсіз» бола ма; breaker болжамды түрде ашылады; кезек өсіп келе ме?

11) Антипаттерндер

Бір жаһандық «read timeout» егжей-тегжейлі connect/TLS/per-stage.
Ортақ мерзім жоқтығы → ретра SLO шеңберінен шығып кетеді.
Ретраи джиттерсіз және retry-budget жоқ.
idle-таймауттары жоқ «мәңгілік» қосылыстар → дескрипторлардың ағуы.
Breaker 4xx өлімге әкелетін қателер деп есептейді.
Болдырмау/abort → фон жұмыстары клиент таймауттан кейін жалғасады.
Ұялы/тұрақсыз желілер үшін тым ұзақ уақыт.

12) iGaming/Қаржы ерекшелігі

Сыни write (депозиттер/қорытындылар): Idempotency-Key-тен бір қысқа қайталау, содан кейін шексіз күтулердің орнына '202 Accepted' + polling.
PSP/банкинг: провайдер/өңір бойынша бөлек саясат (кейбіреулері баяу).
Жауапты төлемдер мен лимиттер: бұғаттау/ревю кезінде - жылдам '423/409', «ілініп тұрған» операцияларды созуға болмайды.
Есептілік/агрегациялар - асинхронды түрде іске қосу (batch + статус-ресурс).

13) Prod-дайындық чек-парағы

• Критикалық бағыттар (GET/POST) бойынша end-to-end deadline анықталған.
• Бюджет сатыға бөлінген; мерзімі ұзартылған propagation қосылды.
• Connect/TLS/read/write/idle шлюздегі және клиенттердегі таймауттар.
• failure-rate және slow-call табалдырықтарымен Circuit breaker; half-open логикасы дұрыс.
• Bulkheads тәуелділікте; per-route параллелизмінің лимиттері.
• Жүктеу кезінде бизнес-логиканы орындағанға дейін жүктеу.
• Ретралармен интеграциялау: backoff + джиттер, retry-budget, құрмет 'Retry-After'.
• Оқиғалар үшін write, 'Idempotency-Key' және outbox сәйкестігі.
• Өлшемдер: timeout/slow-call/breaker/queue time/бәсекелестік жағдайы.
• Хаос-тесттер: кідірістер/шығындар/іркілістер инъекциясы, аймақтардың тозуы.
• Клиенттерге арналған құжаттама: тайминг мысалдары, жауап кодтары, қайталау кеңестері.

14) TL; DR

Әрбір сұрауға қатаң мерзім беріңіз, оны сатыға бөліп, тізбекті төмен таратыңыз. Істен шығуларды circuit breaker + bulkheads + adaptive concurrency + load shedding арқылы басқарыңыз. Қайталаулар - тек мерзім шегінде, джиттермен және бюджетпен; write - тек іспеттес. Timeout/slow-call, breaker және 'queue _ time' күйін өлшеңіз, үнемі хаос сынақтарын жүргізіңіз.