Timeout и circuit control

1) რატომ არის ეს აუცილებელი?

სისტემები ეცემა არა ერთი „საბედისწერო“ წარუმატებლობისგან, არამედ შეფერხებების დაგროვებისა და „ტალღური“ რეაგირებისგან. Taimauts ზღუდავს ლოდინის დროს და ათავისუფლებს რესურსებს, ხოლო circuit კონტროლი (breaker + shedding + ადაპტირებული კონკურენცია) არ იძლევა დეგრადაციას დამოკიდებულების ჯაჭვის გასწვრივ. მიზანია p95/p99 შენარჩუნება სამიზნე საზღვრებში და შეინარჩუნოს წვდომა ნაწილობრივი უარი.

2) ძირითადი განმარტებები

2. 1 ტაიმუთის სახეობები (L7/L4)

Connect Timeout არის TCP/TLS კავშირის დამყარება.
TLS/Handshake timeout - TLS/HTTP2 პრეფიქსი.
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 ms,
• დანართი: 120 ms,
• BD: 120 ms,
• PSP: 100 ms,
• რეზერვი: 30 ms.

2. 3 გაუქმება და გაუქმება

'deadline '/' timeout' უნდა გადაეცეს ჯაჭვს (კონტექსტი, სათაურები, gRPC Deadline). ამის შემდეგ - ფონის ოპერაციების გაუქმება (abort/ctx cancel), ბლოკირების/სემფორების გაწმენდა.

3) ტაიმაუტის დაყენების სტრატეგიები

1. ზემოდან ქვემოდან: SLO და p95 საფუძველზე - მიუთითეთ end-to-deadline, შემდეგ დაასხით Timauts.
2. „ძვირადღირებული“ ბილიკების იდენტიფიცირება (ფაილის დატვირთვა, მოხსენებები, გარე PSP) - ცალკეული გრძელი, მაგრამ შეზღუდული.

• idempotent (GET/სტატუსის გამეორება) - მოკლე, უფრო აგრესიული;
• write/ფულადი - ოდნავ გრძელი, მაგრამ ერთჯერადი გამეორებით და იდემპოტენტურობით.

4. დაგეგმეთ გეგმები/ტენანტები (enterprise- ს შეიძლება ჰქონდეს უფრო გრძელი ვიდრე timeout, მაგრამ უფრო მცირე პარალელიზმი).

4) Circuit breaker: მოდელები და პარამეტრები

4. 1 მუშაობის პოლიტიკა

Failure-rate: შეცდომების წილი X% N მოთხოვნის/დროის ფანჯარაში.
Consecutive failures: M ზედიზედ წარუმატებლობაა.
Slow-call: ზარების წილი უფრო გრძელია, ვიდრე T.
Error classes: Timauts/5xx/connection-reset, „ფატალური“, 4xx - არ არის გათვალისწინებული.

4. 2 მდგომარეობა

Closed - გამოტოვებს ყველაფერს, გროვდება სტატისტიკას.
ღია - მყისიერი უარი (დაზოგავს რესურსებს, არ ახდენს დამოკიდებულებას).
Half-Open - მცირე „ნიმუშები“ (N მოთხოვნა) „წყლის შემოწმებისთვის“.

4. 3 სასარგებლო დამატებები

Bulkhead (ჩარჩოები): ნაკადის/ნაერთების აუზი დამოკიდებულებისკენ ისე, რომ ერთმა არ „ჩამოაგდო“ ყველაფერი.
Adaptive currence: პარალელიზმის ავტომატური შეზღუდვა (AIMD/Vegas მსგავსი ალგორითმები) დაკვირვებული ლატენტობის შესაბამისად.
Load Shedding: ადრეული უარი/დეგრადაცია ადგილობრივი რესურსის ნაკლებობით (ხაზი, CPU, GC პაუზები).

5) ურთიერთქმედება: ტაიმაუტები, რეტრაები, ლიმიტები

ჯერ deadline, შემდეგ retrai: თითოეული გამეორება უნდა განთავსდეს საერთო ვადაში.
Backoff + jitter გამეორებისთვის; პატივისცემა 'Retry-After' და retry-budget.
Rate limiting: ღია ყუთით - შეამცირეთ ლიმიტები ისე, რომ არ გაძლიერდეს ქარიშხალი.
Idempotence: სავალდებულოა write ოპერაციებზე (რათა თავიდან აიცილოთ დუბლი „ჩუმად“ ტაიმუთებში).
სად უნდა დახარჯოთ: სასურველია ზღვარზე (კლიენტი/კარიბჭე) და არა ღრმად შიგნით.

6) პრაქტიკული მიზნობრივი მნიშვნელობები (სახელმძღვანელო)

საზოგადოებრივი read API: end-end '200-500 ms', read timeout '100-300 ms'.
კრიტიკული write (გადახდები): '300-800 ms' e2e; გარე PSP '250-400 ms'.
Connect/TLS: '50-150 ms' (უფრო მეტი - ქსელის/ჭრილობის პრობლემა).
Idle: '30-90 s' (მობილური კლიენტები უფრო მოკლეა ბატარეის შესანახად).
შეასწორეთ მნიშვნელობები 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-ფსევდო)

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 ტრეისი

სპანები: ingress - handler - DB/Redis - გარე.
ატრიბუტები: 'timeout _ ms _ target', 'circuit _ state', 'queue _ time _ ms'.
Exemplars: p99 მწვერვალების დაკავშირება კონკრეტულ trace-id- ზე.

8. 3 ალერტა

'p99 _ latency {critical}'> მიზნები X წუთი ზედიზედ.
'Timeout _ rate {dependency}' ნახტომი> Y%.
ხშირი გადასვლები "ღია '/" flapping" breaker- ში.
ზრდა 'shed _ requests _ total' მაღალი CPU/GC- ით.

9) Adaptive Concurrency & Load Shedding

9. 1 იდეა

• AIMD: ნელა გაზრდა, მკვეთრად შემცირება.
• Vegas მსგავსია: მიზნობრივი რიგის შენარჩუნება.
• Token-based: თითოეული მოთხოვნა „იწვის“ ნიშანს; ნიშნები გაიცემა გაზომილი სიჩქარით.

9. 2 განხორციელება

ადგილობრივი per-route სემფორები; მიზანია ბარიერის ქვემოთ „queue _ time“ შენარჩუნება.
გლობალური „დაუკრავენ“ (მაქსიმალური RPS/კონკურენტუნარიანობა) კარიბჭეზე.
CPU/ნაერთების ნაკლებობით - ლოგიკის შესრულების ადრეული უარყოფა (429/503 ერთად 'Retry-After').

10) ტესტირება და ქაოსის სცენარები

Latency injection: ხელოვნურად დაამატეთ 50-300 ms დამოკიდებულებაზე.
Packet loss/dup/drop (tc/tbf, Toxiproxy).
Knob turning: შეამცირეთ ნაერთების აუზები, გაზარდეთ დატვირთვა saturation.
Kill/Degrade ერთი ზონა/საშინელება (ნაწილობრივი მიუწვდომლობა).
შემოწმებები: არის თუ არა რეაგირების ქარიშხალი „ჩავარდნილი“; breaker იხსნება წინასწარ; რიგები იზრდება.

11) ანტიპატერები

ერთი გლობალური „read timeout“ კავშირის/TLS/პლეი-ეტაპის დეტალების გარეშე.
საერთო ვადის არარსებობა SLO- ს სცილდება.
Retrai გარეშე jitter და გარეშე retry-budget.
„მარადიული“ ნაერთები idle Timauts- ის გარეშე - აღწერილობების გაჟონვა.
Breaker 4xx თვლის ფატალურ შეცდომებს.
არ არსებობს გაუქმება/abort, ფონის მუშაობა გრძელდება კლიენტის ტაიმუტის შემდეგ.
ძალიან გრძელი ტაიმაუტები მობილური/არასტაბილური ქსელებისთვის.

12) iGaming/ფინანსების სპეციფიკა

კრიტიკული write (ანაბრები/დასკვნები): ერთი მოკლე განმეორება Idempotency-Key- ით, შემდეგ '202 Accepted' + polling უსასრულო მოლოდინების ნაცვლად.
PSP/ბანკინგი: ცალკეული პროვაიდერის/რეგიონის პოლიტიკოსები (ზოგი უფრო ნელა).
პასუხისმგებელი გადასახადები და შეზღუდვები: დაბლოკვის/გამრავლებისას - სწრაფი „423/409“, არ გაჭიმოთ „ჩამოკიდებული“ ოპერაციები.
ანგარიში/აგრეგაცია - ასინქრონულად გაშვება (batch + სტატუსის რესურსი).

13) მზადყოფნის ჩეკის სია

• განსაზღვრულია კრიტიკული მარშრუტების დასასრული (GET/POST).
• ბიუჯეტი დაიშალა ეტაპზე; ჩართულია ვადა.
• კონფიგურაცია/TLS/read/write/idle timauts კარიბჭეზე და კლიენტებზე.
• Circuit breaker failure-rate და slow-call ბარიერებით; სწორი ჰალფ-ღია ლოგიკა.
• Bulkheads დამოკიდებულია; პარალელიზმის ლიმიტები per-route.
• გადატვირთვის დროს ბიზნესის ლოგიკის შესრულებამდე.
• ინტეგრაცია რეაგირებით: backoff + gitter, retry-budget, პატივისცემა 'Retry-After'.
• write Idempotence, 'Idempotency-Key' და გარე მოვლენები.
• მეტრიკები: timeout/slow-call/breaker/queue time/კონკურენტუნარიანობა.
• ქაოსის ტესტები: შეფერხებების/ზარალის/წარუმატებლობის ინექცია, ზონების დეგრადაცია.
• დოკუმენტაცია მომხმარებლებისთვის: ტაიმინგის მაგალითები, პასუხის კოდები, გამეორების რჩევები.

14) TL; DR

მიეცით თითოეულ თხოვნას მკაცრი ვადა, განათავსეთ იგი ეტაპზე და გააფართოვეთ იგი ჯაჭვზე. აკონტროლეთ უარი circuit breaker + bulkheads + adaptive concurrency + load shedding- ის საშუალებით. განმეორებები - მხოლოდ ვადაზე, ჯიტერითა და ბიუჯეტით; write - მხოლოდ idempotent. გაზომეთ timeout/slow-call, breaker და 'queue _ time' მდგომარეობა, რეგულარულად გაატარეთ ქაოსის ტესტები.