Logo GH

재시작 및 백오프 정책

반복 (재시도) 은 일시적인 실패에서 살아남는 데 도움이되지만 잘못 구성되면 트래픽, 작업 복제 및 계단식 낙상이 발생합니다. 안정적인 리트레이 정책은 항상 마감일/타임 아웃으로 시작하고 demempotency를 고려하며 backoff + jitter를 사용합니다.

1) 기본 원칙

1. 첫 번째 타임 아웃/마감일 다음 후퇴. 시간 제한없이 반복하면 실패가 길어집니다.
2. 다시 트레이-안전/demotent 작업에만 해당됩니다. 안전하지 않은 키의 경우-demempotency 키와 트랜잭션 보증을 통해.
3. 백오프는 필수입니다. 파동을 비 동기화하기위한 지터를 갖는 지수 또는 GCRA 유사.
4. 시도 횟수와 총 예산 시간을 제한하십시오. 사용자의 SLO를 떠나지 마십시오.
5. 인프라 신호를 존중하십시오 '429/503' + 'Redure-After', 회로 차단기 상태, 대기열 제한.

2) 타임 아웃 및 마감일 (마감일 전파)

요청 시간 초과 <SLO 서비스, 마감일은 체인 아래로 전파됩니다 (HTP 헤더/gRPC 컨텍스트).
시간 초과 구성: 총 (첫 번째 시도 + 백오프 + 후속) 사용자 마감일.
읽기/기록에 대한 다른 시간 초과: 기록이 짧고 엄격합니다. 읽기는 헤징을 허용합니다.

3) 이념과 안전한 반복

읽기 (GET/idempotent RPC): '5xx', 'UNAVAILABLE', 네트워크 타임 아웃으로 안전하게 반복됩니다.

기록:
  • 국경에서 'Idempotency-Key' (HTP) 또는 요청 ID를 사용하십시오. 서버를 복제해야합니다.
  • dempotent 처리기 쓰기: "upsert", "적어도 한 번은" + 보상 (saga).
  • 외부 결제/결제-demempotent 키 및 트랜잭션 로그에만 해당됩니다.

4) 백오프 알고리즘

지수: 'max _ backoff' 로 둘러싸인 'base 2 ² 시도'.
Decorated Jitter (전체/등가 지터) -클라이언트를 비 동기화하기위한 범위의 임의성.
GCRA/Token-Bucket과 유사한 지연: 요율 제한과 일치합니다.
경계: '초기 _ 백오프' (50-200ms 읽기; 200-500 ms 레코드), 'max _ backoff' (1-5 초), 'max _ elapsed' (예: 3-10 초).

권장 패턴은 지수 백오프 + 풀 지터입니다.

5) 결정 정책을 반복/반복하지 마십시오

우리는 다음을 반복합니다

네트워크 오류/타임 아웃, '429' (정중하게 '재시도 후'), "소프트" '5xx' ('502/503/504'), gRPC 'UNAVAILABLE/DEADLINE _ EXCEEDED'.

다음과 같은 경우 반복하지 마십시오

'4xx' (일부 시나리오에서는 '409/429/408' 제외), 비즈니스 오류, '401/403', 검증 오류, 명시 적 'DoNotredch' 플래그.

현명한 예외:
  • '409 충돌' -때로는 합의/잠금 후 지연으로 반복됩니다.
  • '404' 는 영구적으로 일관된 읽기를위한 것입니다.

6) 동시성 한도 및 "폭풍 재발견"

클라이언트 당/임차인/종점당 동시 배상을 제한하십시오.
요청 당 총 시도 한도 (예: 2-3).
대기열을 팽창시키지 않도록 입학 통제를 통해 핫 엔드 포인트를 느리게하십시오.

7) 회로 차단기 및 한계와의 상호 작용

CB가 열려있는 경우 배상을 직접 수행하지 마십시오. 폴백으로 이동하거나 '하프 오픈' 샘플을 기다리십시오.
'429' 에서-' Redure-After '존중; 그렇지 않은 경우 "소프트" 백오프를 사용하십시오.
배반은 변형을 증가시킬 수 있습니다. 적응 형 임계 값을 적용하십시오 (사고의 경우 'max _ 시도').

8) 프로토콜 및 계약

모든 편지 선택 (C)

코드: '408/429/5xx'.
헤더: 'Redue-After', 가족 'RateLimit-', 'Idempotency-Key', 'Request-ID'.
클라이언트는 'X-Request-Timetime '/' Deadline-At' (그렇다면) 을 보내야합니다.

gRPC

마감일과 함께 컨텍스트 사용; 'UNAVAILABLE', 'DEADLINE _ EXCEEDED' 를 존중하십시오.
demempotent RPC의 경우 retray; 돌연변이의 경우-demempotency 지원만으로.

9) 대기열, 배경 작업 및 통합

적어도 한 번은 처리기 → demempotent 동작, 주요 중복 제거.
시도 사이의 백오프 지연 (예: 5/30/2m).
시도 및 수동 처리 제한이있는 데드 레터 큐 (DLQ).
전송/CDC-재생이 거래 무결성을 손상시키지 않도록합니다.

10) Hedging vs Retries

헤지는 꼬리 대기 시간의 매우 중요한 읽기에 유용합니다.
제한: 요청의 X% 이하, 시작 유예 지연 (예: p95 대기 시간), 패자 취소.
강력한 demempotency없이 작업을 작성하기 위해 헤징을 적용하지 마십시오.

11) 원격 측정 및 관찰 가능

지정 번호: '테넌트 _ id', '엔드 포인트', '시도', '결정' (재 시도/건너 뛰기), '이유', '백오프 _ ms', '마감일 _ ms', 'idempotency _ key'.
지표: 퇴각 비율, 퇴각 후 성공, p95/p99 "종료", 초과 마감일 수, CB 트리거링.
감사 로그: 상단 N "잡음" 키/엔드 포인트, 429/503과의 상관 관계.

12) 테스트와 혼돈

프로필: "saw" (burst-lull), "storm" (질량 타임 아웃), "sticky" 오류 (모든 Nth), 대기 시간 꼬리.
토러스 리미터/캐시/큐 오류, 클럭 왜곡.
총 지속 시간 (시도 + 백오프) 이 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 방식의 총 지속 시간.
  • 지터가있는 백오프 알고리즘; 부하 테스트에 의해 검증 된 매개 변수.
  • IDEmotence: 레코드에 대한 키/로그/보상.
  • 재판 정책은 읽기와 기록에 따라 다릅니다. '재시도 후' 를 존중하십시오.
  • 경쟁력과 총 시도 횟수는 제한되어 있습니다.
  • 회로 차단기 및 속도 제한과의 통합이 구성됩니다.
  • 원격 측정: 태그, 메트릭, 이유 로그; 대시 보드 p95/p99, 배송 후 성공의 비율.
  • "폭풍" 및 대기 시간 꼬리 테스트, DLQ 작업.
  • 고객 문서: 코드/제목, 백오프 및 취소 예.

16) 전형적인 오류

타임 아웃/마감일이없는 리플레이는 "영원한 기대" 입니다.
지터가없는 고정 일시 정지-동기파 및 DDoS 자체 방해 행위.
dempotency없이 안전하지 않은 레코드의 배상-중복 및 비 동기화.
'재시도 후' 및 CB 신호를 무시하고 확대 사건.
모자 부족과 입장 통제로 인해 대기열의 병목 현상.
배상의 이유/솔루션에 대한 원격 측정 부족 - "맹인 비행".

17) 빠른 레시피

공개 API는 '초기 = 100ms', 'max = 1', 전체 지터, 트래픽의 최대 5% 를 차단하는 3 가지 시도를 읽습니다.
중요한 기록 (지불): 1-2 최대 시도, 엄격한 타임 아웃, 필수 'Idempotency-Key', 헤징 없음.
외부 통합: '429/Redch-After', 'max _ reastions = 3', 'max _ backoff = 2-5s', 나가는 흐름 한계를 존중하십시오.
배경 작업: 지연 백오프 (5s → 30s → 2m), DLQ, demempotent 처리기.

결론

좋은 반복 정책은 빠른 복구와 통제 된 실패 사이의 균형입니다. 마감일, demempotence, 지터를 사용한 지수 백오프, 경쟁 제한 및 인프라 신호 존중은 "폭풍" 에서 SLO 신뢰성 및 보존 향상을위한 도구로 되돌아갑니다.

Contact

문의하기

질문이나 지원이 필요하시면 언제든지 연락하십시오.우리는 항상 도울 준비가 되어 있습니다!

Telegram
@Gamble_GC
통합 시작

Email — 필수. Telegram 또는 WhatsApp — 선택 사항.

이름 선택 사항
Email 선택 사항
제목 선택 사항
메시지 선택 사항
Telegram 선택 사항
@
Telegram을 입력하시면 Email과 함께 Telegram에서도 답변드립니다.
WhatsApp 선택 사항
형식: +국가 코드 + 번호 (예: +82XXXXXXXXX).

버튼을 클릭하면 데이터 처리에 동의하는 것으로 간주됩니다.