გამეორების პოლიტიკოსები და ბაჩოფი

გამეორება (გამეორება) ხელს უწყობს დროებითი გაუმართაობის გადარჩენას, მაგრამ თუ არასწორი რეგულირება იწვევს ტრაფიკის ზვავს, ოპერაციების დუბლებს და კასკადის ვარდნას. Retrais- ის საიმედო პოლიტიკა ყოველთვის იწყება ვადაზე ადრე/Timauts- ით, ითვალისწინებს idempotence- ს და იყენებს backoff + gitter- ს.

1) ძირითადი პრინციპები

1. ჯერ ტაიმუთი/ვადა, შემდეგ retray. გამეორება დროის ზღვრის გარეშე მხოლოდ უარყოფას აგრძელებს.
2. Retray - მხოლოდ უსაფრთხო/idempotent ოპერაციებისთვის. უსაფრთხოებისთვის - idempotence-keys- ით და გარიგების გარანტიით.
3. Backoff სავალდებულოა. ექსპონენციალური ან GCRA- ს მსგავსი ჯიტერი ტალღების გასაფორმებლად.
4. შეზღუდეთ მცდელობების რაოდენობა და საერთო ბიუჯეტის დრო. ნუ წახვალ მომხმარებლის SLO- სთვის.
5. პატივს სცემთ ინფრასტრუქტურის სიგნალებს. '429/503' + 'Retry-After', circuit breaker- ის მდგომარეობა, რიგების ლიმიტები.

2) ტაიმაუტები და ვადები (deadline propagation)

მოთხოვნის ტაიმუტი <SLO მომსახურება, ვადა ვრცელდება ჯაჭვზე (HTTP სათაურები/gRPC Context).
ტაიმაუთების შემადგენლობა: ჯამში (პირველი მცდელობა + backoff + შემდგომი) - მომხმარებლის ვადა.
სხვადასხვა დრო კითხვისთვის/ჩანაწერებისთვის: ჩანაწერები უფრო მოკლე და მკაცრია; წაიკითხეთ hedging.

3) Idempotence და უსაფრთხო გამეორება

კითხვები (GET/idempotent RPC): უსაფრთხოდ განმეორება „5xx“, „UNAVAILABLE“, ქსელის ტაიმუთებში.

• გამოიყენეთ 'idempotency-Key' (HTTP) ან request-ID საზღვარზე; სერვერმა უნდა შეწყვიტოს.
• დაწერეთ idempotent დამამზადებლები: „upsert“, „at-least-once“ + კომპენსაცია (საგა).
• გარე გადახდები/ურთიერთგამომრიცხავი ანგარიშები - მხოლოდ იდემპოტენტური კლავიშებით და ოპერაციების ჟურნალით.

4) backoff ალგორითმები

Exponential: 'base 2 ^ attempt', შეზღუდული 'max _ backoff'.
Decorrelated Jitter (full/equal jitter): უბედური შემთხვევა მომხმარებლების დეინქრონიზაციის დიაპაზონში.
GCRA/Token-Bucket მსგავსი შეფერხებები: შეთანხმებულია სახელმწიფო ლიმიტებთან.
საზღვრები: 'initial _ backoff' (50-200 კითხვის ms; 200-500 ms ჩაწერა), 'max _ backoff' (1-5 ს), 'max _ elapsed' (მაგალითად, 3-10 ს).

რეკომენდებული შაბლონი: ექსპონენციალური backoff + full jitter.

5) გადაწყვეტილების პოლიტიკის გამეორება/გამეორება

• ქსელის შეცდომები/ტაიმაუტები, '429' (პატივისცემით 'Retry-After'), „რბილი“ '5xx' ('502/503/504'), gRPC 'UNAVAILABLE/DEADLINE E E A A A.

• '4xx' (გარდა "409/429/408" ზოგიერთ სცენარში), ბიზნეს შეცდომები, '401/403 ", მოქმედი შეცდომები, აშკარად' DoNotRetry 'დროშა.

• '409 Conflict' - ზოგჯერ გამეორება შეფერხების შემდეგ კონსენსუსის/ლოყების შემდეგ.
• „404“ ღონისძიების საკონსულტაციო კითხვებისთვის - ერთი ან ორჯერადი ჭრილობა მცირე ბაჩოფით.

6) Concurrence caps და „ქარიშხლის ქარიშხალი“

შეზღუდეთ ერთდროული ჭრილობები per-client/per-tenant/per-endpoint.
მოთხოვნის მცდელობების საერთო ლიმიტი (მაგალითად, 2-3).
შეანელეთ „ცხელი“ ენდოინტები admission Controll- ის საშუალებით, რათა არ მოხდეს რიგები.

7) ურთიერთქმედება Circuit Breaker- თან და ლიმიტებთან

თუ CB Open, პირდაპირ არ შეასრულოთ retrais - წადი fallback ან დაელოდე „half Open“ ნიმუშებს.
„429“ -ში - პატივი სცეთ 'Retry-After'; მისი არყოფნის შემთხვევაში - გამოიყენეთ „რბილი“ backoff.
Retrai- ს შეუძლია გაზარდოს დატვირთვა; გამოიყენეთ ადაპტირებული ბარიერები (შეამცირეთ 'max _ attempts' ინციდენტის დროს).

8) ოქმები და კონტრაქტები

HTTP

კოდები: '408/429/5xx'.
სათაურები: 'Retry-After', ოჯახი 'RateLimit-', 'Idempotency-Key', 'Request-Id'.
კლიენტმა უნდა გადასცეს 'X-Request-Timeout '/' Deadline-At' (თუ ასე მიიღებთ).

gRPC

გამოიყენეთ კონტექსტი ვადაზე; პატივისცემა 'UNAVAILABLE', 'DEADLINE _ EXCEEDED', მეთოდის მიმღები პოლიტიკა.
Idempotent RPC- სთვის - ჩართეთ retrai; მუტაციებისთვის - მხოლოდ იდემპოტენტურობის მხარდაჭერით.

9) რიგები, ფონური დავალებები და ინტეგრაცია

At-least-once დამამზადებლები - იდემპოტენტური მოქმედებები, გასაღები.
Delay queue for backoff მცდელობებს შორის (მაგალითად, 5s/30s/2m).
Dead-letter queue (DLQ) მცდელობებისა და სახელმძღვანელო დამუშავების ლიმიტით.
Outbox/CDC - ისე, რომ გამეორებებმა არ დაარღვიოს გარიგების მთლიანობა.

10) Hedging vs Retries

Hedging (სარკის მოთხოვნა) სასარგებლოა კუდის ლატენტობის დროს მაღალი კრიტიკული კითხვებისთვის.
შეზღუდეთ: არა უმეტეს X% მოთხოვნა, „დაწყების გრეის“ შეფერხება (მაგალითად, p95 ლატენტობა), დამარცხებულთა გაუქმება.
ნუ გამოიყენებთ hedging- ს ჩაწერის ოპერაციებზე ძლიერი idempotent- ის გარეშე.

11) ტელემეტრია და დაკვირვება

Теги: `tenant_id`, `endpoint`, `attempt`, `decision` (retry/skip), `reason`, `backoff_ms`, `deadline_ms`, `idempotency_key`.
მეტრიკა: ჭიდაობის წილი, წარმატების მიღწევა ჭიდაობის შემდეგ, p95/p99 „end-end“, გადალახული ვადების რაოდენობა, CB მოქმედება.
აუდიტის ლოგოები: ზედა N „ხმაურიანი“ გასაღებები/endpoints, კორელაცია 429/503.

12) ტესტირება და ქაოსი

პროფილები: „დალია“, „ქარიშხალი“ (მასობრივი ტაიმაუტები), „წებოვანი“ შეცდომები (თითოეული N), ლატენტობის კუდები.
შეზღუდვის/ქეშის/რიგის, კლოკის ციკლის უკმარისობა.
შემოწმება, რომ მთლიანი ხანგრძლივობა (attempts + backoff) ჯდება SLO- ში.

13) პოლიტიკის ფსევდო კოდექსი

pseudo handle(req, deadline):
attempt = 0 backoff = initial()
while attempt < MAX_ATTEMPTS and now() < deadline:
attempt += 1 with timeout(per_attempt_timeout(deadline, attempt)):
try:
resp = call(req)
if isRetryableStatus(resp): raise Retryable(resp. status)
return resp except Retryable as e:
if circuit. isOpen(dep) or! isIdempotent(req): break sleep(jitter(backoff))
backoff = min(exp(backoff), MAX_BACKOFF)
except NonRetryable:
break return fail_or_fallback(req)

14) კონფიგურაციის შაბლონი (მაგალითი)

yaml retries:
default:
max_attempts: 3 initial_backoff_ms: 150 max_backoff_ms: 2000 strategy: exponential_full_jitter respect_retry_after: true per_attempt_timeout_fraction: 0. 4 # 40% of remaining deadline hedging:
enabled: false read_heavy:
max_attempts: 4 initial_backoff_ms: 80 max_backoff_ms: 1200 hedging:
enabled: true start_after_p95_ms: 300 max_extra_requests_ratio: 0. 05 write_strict:
max_attempts: 2 initial_backoff_ms: 250 max_backoff_ms: 1000 idempotency_required: true

limits:
concurrent_retries_per_tenant: 100 concurrent_retries_per_endpoint: 20

15) ჩეკის სია გაყიდვამდე

• ვადები ვრცელდება ზარების საშუალებით; მთლიანი ხანგრძლივობა SLO.
• backoff ალგორითმი ჯიტერთან; პარამეტრები შეესაბამება დატვირთვის ტესტს.
• Idempotence: გასაღებები/ჟურნალები/ჩანაწერების ანაზღაურება.
• რეტრაის პოლიტიკა განსხვავდება კითხვისა და ჩანაწერებისთვის; respect `Retry-After`.
• კონკურენტუნარიანობა და მცდელობების საერთო რაოდენობა შეზღუდულია.
• ინტეგრაცია circuit breaker- თან და rate limits- თან.
• ტელემეტრია: ჭდეები, მეტრიკა, მიზეზების ლოგოები; დაშბორდები p95/p99, წარმატების წილი ჭიდაობის შემდეგ.
• ტესტები „ქარიშხლები“ და ლატენტობის კუდები, DLQ დავალებებისთვის.
• დოკუმენტაცია მომხმარებლებისთვის: კოდები/სათაურები, backoff- ის მაგალითები და გაუქმება.

16) ტიპიური შეცდომები

განმეორებები ტაიმუთის/ვადების გარეშე - „მარადიული მოლოდინი“.
ფიქსირებული პაუზები ჯიტერის გარეშე - სინქრონული ტალღები და DDoS თვითგამორკვევა.
Idempotence- ის გარეშე უსაფრთხო ჩანაწერების აღდგენა არის დუბლირება და რასინქრონიზაცია.
„Retry-After“ და CB სიგნალების უგულებელყოფა ინციდენტის ესკალაციაა.
რიგებში ვიწრო ადგილები caps- ის არარსებობისა და ადმისიის კონტროლის გამო.
Retray- ის მიზეზების/გადაწყვეტილებების ტელემეტრიის არარსებობა არის „ბრმა ფრენა“.

17) სწრაფი რეცეპტები

API- ს საჯარო კითხვები: 3 მცდელობა, 'initial = 100ms', 'max = 1s', full jitter, hedging 5% ტრაფიკი.
კრიტიკული ჩანაწერები (გადახდა): 1-2 მაქსის მცდელობა, მკაცრი ტაიმუტი, სავალდებულო „Idempotency-Key“, hedging გარეშე.
გარე ინტეგრაცია: პატივისცემა '429/Retry-After', 'max _ attempts = 3', 'max _ backoff = 2-5s', გამავალი ნაკადის ლიმიტები.
ფონის დავალებები: delay-backoff (5s-30s-2m), DLQ, idempotent დამამზადებლები.

დასკვნა

გამეორების კარგი პოლიტიკა არის ბალანსი სწრაფი აღდგენასა და კონტროლირებად უარს შორის. ვადები, idempotence, ექსპონენციალური backoff ერთად ჯიტერი, კონკურენციის შეზღუდვა და ინფრასტრუქტურული სიგნალების პატივისცემა „ქარიშხლიდან“ გადაქცევას აქცევს SLO საიმედოობისა და შენარჩუნების გაზრდის ინსტრუმენტად.