Қайталау және backoff саясаты

Қайталаулар (retries) уақытша іркілістерден аман қалуға көмектеседі, бірақ дұрыс орнатылмаған жағдайда трафиктің көшкіні, операциялардың қосарлануы және каскадтық құлдыраулар пайда болады. Ретрациялардың сенімді саясаты әрқашан дедлайндардан/таймауттардан басталады, демпотенттілікті ескереді және backoff + джиттерді пайдаланады.

1) Базалық қағидаттар

1. Алдымен таймаут/мерзім, содан кейін ретрай. Уақыт шегініссіз қайталау істен шығуды ұзартады.
2. Ретрай - тек қауіпсіз/демпотенттік операциялар үшін. Қауіпсіз еместер үшін - idempotency-keys және транзакциялық кепілдіктер арқылы.
3. Backoff міндетті. Толқындарды синхронсыздандыру үшін экспоненциалды немесе GCRA-ұқсас.
4. Әрекеттер санын және жалпы бюджет-уақытты шектеңіз. Пайдаланушының SLO-дан шықпаңыз.
5. Инфрақұрылым сигналдарын құрметтеңіз. '429/503' + 'Retry-After', circuit breaker күйі, кезек шектеулері.

2) Таймауттар мен мерзімдер (deadline propagation)

Таймауттар композициясы: жиынтық (бірінші әрекет + backoff + келесі) ≤ пайдаланушы мерзімі.
Оқу/жазу үшін әртүрлі таймауттар: жазбалар қысқа және қатаңырақ; оқу hedging рұқсат етеді.

3) Теңсіздік және қауіпсіз қайталаулар

Оқу (GET/Idempotent RPC): '5xx', 'UNAVAILABLE', желілік таймауттар кезінде қайталау қауіпсіз.

• Шекарада 'Idempotency-Key' (HTTP) немесе request-ID пайдаланыңыз; сервер дедуплициялауы керек.
• «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 мс оқу; 200-500 мс), '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 бар бір-екі реттік ретрай.

6) Concurrency caps және «ретрайлардың дауылы»

per-client/per-tenant/per-endpoint.
Сұрау салуға талпыныстардың жиынтық лимиті (мысалы, 2-3).
Кезектерді үрлемеу үшін admission control арқылы «ыстық» эндпойнттарды тежеңіз.

7) Circuit Breaker және лимиттермен өзара іс-қимыл

Егер CB ашық болса, ретрацияны тікелей орындамаңыз - fallbackке кіріңіз немесе 'half-open' сынамасын күтіңіз.
'429' кезінде - 'Retry-After'; ол болмаған жағдайда - «жұмсақ» backoff қолданыңыз.
Ретраялар жүктемені арттыра алады; бейімделу шегін қолданыңыз (оқиға кезінде 'max _ attempts' дегенді төмендетіңіз).

8) Хаттамалар мен келісімшарттар

HTTP

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

gRPC

Шекті мәнмәтінді пайдаланыңыз; 'UNAVAILABLE', 'DEADLINE _ EXCEEDED' әдісін құрметтеңіз.
Демпотенттік RPC үшін - ретраларды қосыңыз; мутациялар үшін - тек қана демпотенттіктің қолдауымен.

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

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

10) Hedging vs Retries

Hedging (айналы сұрау) артқы жасырындылықта жоғары сыни оқылымдар үшін пайдалы.
Шектеңіз: X% артық емес сұраулар, «старт-грейс» кідірісі (мысалы, p95-жасырындылығы), жеңілгендерді болдырмау.
Жазу әрекеттеріне күшті ұқсамаушылықсыз hedging қолданбаңыз.

11) Телеметрия және бақылау

Теги: `tenant_id`, `endpoint`, `attempt`, `decision` (retry/skip), `reason`, `backoff_ms`, `deadline_ms`, `idempotency_key`.
Метрика: ретрайлардың үлесі, ретрайлардан кейінгі табыстылық, p95/p99 «end-to-end», асып кеткен мерзімдер саны, CB іске қосылуы.
Аудит логтары: «шулы» кілттердің/эндпойнттардың жоғарғы N, 429/503 корреляциясы.

12) Тестілеу және хаос

Профильдер: «аралар» (burst-тыныштық), «дауыл» (жаппай таймауттар), «жабысқақ» қателер (әрбір 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 алгоритмі; параметрлері жүктеме тестімен валидацияланған.
• Сәйкестік: жазбалар үшін кілттер/журналдар/өтемақылар.
• Ретрай-саясаткерлер оқу және жазу үшін ерекшеленеді; respect `Retry-After`.
• Ретрайлардың бәсекелестігі және әрекеттердің жалпы саны шектеулі.
• circuit breaker және rate limits жүйесімен біріктіру теңшелді.
• Телеметрия: тегтер, метрика, себептер логы; p95/p99 дашбордтар, ретраялардан кейінгі табыстардың үлесі.
• Тапсырмалар үшін «дауыл» және латенттілік, DLQ сынақтары.
• Клиенттерге арналған құжаттама: кодтар/тақырыптар, backoff мысалдары және болдырмау.

16) Типтік қателер

Таймаусыз/мерзімсіз қайталау - «мәңгілік күту».
Джиттерсіз бекітілген үзілістер - синхронды толқындар және DDoS-өздігінен жұмыс істеу.
Іспеттілігі жоқ қауіпсіз жазбалардың ретрайлері - дубль және рассинхронизация.
'Retry-After' және CB сигналдарын елемеу - оқыс оқиғаның өршуі.
caps және admission control болмағандықтан кезектегі тар жерлер.
Ретрайлардың себептері/шешімдері телеметриясының болмауы - «соқыр ұшу».

17) Жылдам рецепттер

API көпшілік оқулары: 3 әрекеттер, 'initial = 100ms', 'max = 1s', full jitter, 5% трафикке дейін hedging.
Сыни жазбалар (төлем): 1-2 әрекет макс, қатаң таймаут, міндетті 'Idempotency-Key', hedging жоқ.
Сыртқы интеграциялар: '429/Retry-After', 'max _ attempts = 3', 'max _ backoff = 2-5s', шығыс ағынының лимиттерін құрметтеу.
Фондық тапсырмалар: delay-backoff (5s → 30s → 2m), DLQ, демпотенттік өңдегіштер.

Қорытынды

Қайталаудың жақсы саясаты - бұл жедел қалпына келтіру мен бақыланатын бас тарту арасындағы теңгерім. Дедлайндық, демпотенттік, джиттермен экспоненциалды backoff, бәсекелестікті шектеу және инфрақұрылым сигналдарын құрметтеу ретрацияны «дауылдан» сенімділікті арттыру және SLO-ны ұстап тұру құралына айналдырады.