Кайталоо жана backoff саясаты

Кайталануулар (retries) убактылуу мүчүлүштүктөрдү аман жардам берет, бирок туура эмес орнотулса, жол көчкү, эки операция жана каскаддык түшүүлөргө алып келет. Ишенимдүү retrains саясаты ар дайым мөөнөт/убакыт менен башталат, демпотенттикти эске алат жана backoff + Jitters колдонот.

1) Негизги принциптер

1. Биринчи тайм/мөөнөт, андан кийин кайра. Убакыттын чеги жок кайталоо баш тартууну гана узартат.
2. Retrai - коопсуз/демпотенттик иш үчүн гана. Кооптуу үчүн - idempotency-keys жана транзакциялык кепилдиктер аркылуу.
3. Backoff милдеттүү. экспоненциалдуу же GCRA-сыяктуу толкундарды синхрондоштуруу үчүн Jitter менен.
4. Аракеттердин санын жана жалпы бюджет-убакытты чектеңиз. Колдонуучунун SLOсунан чыкпаңыз.
5. Инфраструктуралык сигналдарды урматтаңыз. '429/503' + 'Retry-After', circuit breaker абалы, кезек чектери.

2) Убакыт жана мөөнөт (deadline propagation)

суроо-убакыт <SLO кызматы, мөөнөтү чынжыр боюнча жайылып жатат (HTTP аталыштары/gRPC context).
Таймауттардын курамы: бардыгы болуп (биринчи аракет + backoff + кийинки) ≤ колдонуучунун мөөнөтү.
Окуу/жазуу үчүн ар кандай таймауттар: жазуулар кыска жана катуураак; окуулар hedging жол.

3) Идемпотенттүүлүк жана коопсуз кайталоо

Окуулар (GET/Idempotent RPC): '5xx', 'UNAVAILABLE', тармактык таймауттарда коопсуз кайталоо.

• Чек арада 'Idempotency-Key' (HTTP) же request-ID колдонуңуз; Server дедуплицирлөө керек.
• "Upsert", "at-least-once" + компенсация (сага).
• Тышкы төлөмдөр/өз ара эсептешүүлөр - операциялардын демпотенттик ачкычтары жана журналы менен гана.

4) backoff алгоритмдери

Exponential: 'base 2 ^ attempt', чектелген 'max _ backoff'.
Decorrelated Jitter (full/equal jitter): кардарларды синхрондоштуруу үчүн бир катар кокустук.
GCRA/Token-Bucket сыяктуу кечигүүлөр: rate limits менен макулдашылган.
Чектери: '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 _ EXCEEDED'.

• '4xx' (кээ бир жагдайларда '409/429/408' башка), бизнес каталар, '401/403', тастыктоо каталар, ачык 'DoNotRetry' желеги.

• '409 Conflict' - кээде консенсус/блоктордон кийин кечигүү менен кайталоо.
• eventually consistent окуулар үчүн '404' - кичинекей backoff менен бир-эки жолу retray.

6) Concurrency caps жана "бороон retrais"

per-client/per-tenant/per-endpoint бир эле учурда retra чектөө.
Суроо-талаптын жалпы лимити (мисалы, 2-3).
кезектерди күчөтүү үчүн эмес, admission control аркылуу "ысык" EndPoint.

7) Circuit Breaker жана лимиттер менен өз ара

Эгерде CB ачык болсо, түздөн-түз ретрацияны аткарбаңыз - fallbackге барыңыз же 'half-open' сыноолорун күтүңүз.
Качан '429' - урмат 'Retry-After'; жок болсо - "жумшак" backoff колдонуу.
Retrains жүктү жогорулатуу мүмкүн; адаптивдүү босоголорду колдонуу (окуя болгон учурда 'max _ attempts' төмөндөтүү).

8) Протоколдор жана контракттар

HTTP

коддору: '408/429/5xx'.
Аталыштар: 'Retry-After', үй-бүлө 'RateLimit-', 'Idempotency-Key', 'Request-Id'.
Кардар 'X-Request-Timeout '/' Deadline-At' өткөрүп бериши керек (эгер сиз ушундай кылсаңыз).

gRPC

мөөнөт менен контекстин колдонуу; урматтоо 'UNAVAILABLE', 'DEADLINE _ EXCEEDED', ыкмасы боюнча retrains саясат.
Демпотенттик RPC үчүн - ретраларды күйгүзүү; мутациялар үчүн - демпотенттиктин колдоосу менен гана.

9) Кезектер, фон милдеттери жана интеграция

At-least-once иштетүүчүлөр → демпотенттик иш-аракеттер, ачкыч боюнча дедупликация.
аракет ортосунда backoff үчүн Delay queue (мисалы, 5s/30s/2m).
Dead-letter queue (DLQ) аракет чеги жана кол менен иштетүү менен.
Outbox/CDC - кайталоо бүтүмдөрдүн бүтүндүгүн бузбайт.

10) Hedging vs Retries

Hedging (күзгү өтүнүчү) куйрук жашыруун жогорку сын окуу үчүн пайдалуу.
Чектөө: көп эмес X% суроо-талап, кечигүү "start-grace" (мисалы, p95-жашыруун), жоготкон жокко чыгаруу.
Катуу демпотенттиги жок жаздыруу операцияларына hedging колдонбоңуз.

11) Телеметрия жана байкоо

Теги: `tenant_id`, `endpoint`, `attempt`, `decision` (retry/skip), `reason`, `backoff_ms`, `deadline_ms`, `idempotency_key`.
Метрика: retrains үлүшү, retrains кийин ийгилик, p95/p99 "end-to-end", мөөнөтү ашкан саны, CB ишке киргизүү.
Аудит Logs: жогорку N "ызы-чуу" ачкычтары/EndPoints, 429/503 менен байланыш.

12) сыноо жана башаламандык

Профилдер: "араа" (бурст-тынч), "бороон" (массалык таймауттар), "жабышчаак" каталар (ар бир N-чи), латенттүүлүктүн куйруктары.
Лимитердин/кэштин/кезектин каталары, clock-skew.
Жалпы узактыгын текшерүү (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 алгоритми; параметрлери жүктөө сыноо менен тастыкталган.
• Idempotentity: ачкычтар/журналдар/жазуулар үчүн ордун толтуруу.
• Ретрай саясатчылар окуу жана жазуу үчүн ар кандай; respect `Retry-After`.
• Retrains атаандаштык жана аракеттердин жалпы саны чектелген.
• circuit breaker жана rate limits менен интеграция орнотулган.
• Телеметрия: теги, метрика, себептери; дашборддор p95/p99, ретрадан кийин ийгиликтин үлүшү.
• Сыноолор "бороон-чапкын" жана жашыруун куйруктары, тапшырмалар үчүн DLQ.
• кардарлар үчүн документтер: коддору/аталыштары, backoff жана жокко чыгаруу мисалдар.

16) типтүү каталар

Таймаут/мөөнөтсүз кайталоо - "түбөлүк күтүүлөр".
Життерсиз туруктуу тыныгуулар - синхрондуу толкундар жана DDoS-өзүн-өзү иштетүү.
Идемпотенттүүлүгү жок кооптуу жазуулардын ретрайлери - дубль жана рассинхронизация.
'Retry-After' жана CB сигналдарын четке кагуу - окуянын күчөшү.
Капс жана admission control жоктугунан улам кезек тар.
Телеметрия себептеринин/чечимдердин жоктугу - "сокур учуу".

17) Тез Recipes

Коомдук окуу API: 3 аракет, 'initial = 100ms', 'max = 1s', толук 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 иштеп чыгуучулар.

Корутунду

Жакшы кайталоо саясаты - бул тез калыбына келтирүү менен көзөмөлгө алынган баш тартуунун ортосундагы тең салмактуулук. Deadline, ыктымалдуулук, Jitter менен экспоненциалдык backoff, атаандаштыкты чектөө жана инфраструктуралык сигналдарды урматтоо ретраларды "бороондон" ишенимдүүлүктү жогорулатуу жана SLO кармап туруу куралына айландырат.