퀴즈: 재시도로 창고를 더 아프게 만들지 않는다

문항 6개. 정답과 해설은 풀어 본 뒤에 보여 드립니다.

1. base=100, cap=250, attempt=3, jitter=0.5일 때 재시도 지연은 몇 ms인가요?

   1. 상한을 적용한 뒤 절반인 125ms
   2. 지수 증가한 뒤 절반인 200ms
   3. 상한을 적용하지 않은 400ms
   4. 지수 증가 없이 절반인 50ms

2. 작업자가 선점 커밋 직후, 전송을 호출하기 전에 종료됐습니다. attempts는 어떻게 처리하나요?

   1. 수신 확인이 없으므로 새 작업자가 0으로 바꾼다
   2. 선점 때 소비한 값을 보존하고 재선점 때 올린다
   3. 실제 전송 여부를 추측하여 성공 횟수로 바꾼다
   4. 임대가 만료되면 이전 선점의 증가분을 되돌린다

3. 재시도를 예약할 now+delay가 deadline과 정확히 같습니다. 시도 횟수는 남아 있습니다. 결과는?

   1. pending으로 예약하고 마감 이후 한 번 더 전송한다
   2. done으로 종료하고 수신 확인 없이 성공으로 센다
   3. dead와 deadline 사유를 저장하고 자동 재시도를 멈춘다
   4. deadline을 delay만큼 늘리고 기존 횟수로 계속한다

4. 같은 ID·같은 수량을 더 긴 ttl로 다시 enqueue했습니다. 기존 업무는 이미 두 번 실패했습니다. 올바른 결과는?

   1. 새 ttl과 attempts=0을 반영하고 True를 반환한다
   2. 새 큐 행을 만들어 원래 업무와 병렬로 처리한다
   3. 원래 행을 지우고 새 접수의 순서로 교체한다
   4. 기존 예산과 상태를 보존하고 False를 반환한다

5. 전달자 20개가 매번 jitter=0.5를 사용합니다. 지수 백오프만으로 보장되지 않는 것은?

   1. 작업자 사이 재시도 시점의 무작위 분산
   2. 설정한 cap에 따른 개별 지연의 최대 범위
   3. 같은 입력에 대해 같은 결과가 나오는 계산
   4. 선점 횟수에 따라 달라지는 지연 창 계산

6. max_attempts=3이면 run_once가 반드시 짧은 시간 안에 끝나나요?

   1. 그렇다. 세 번이라는 횟수가 전송의 소요 시간도 제한한다
   2. 아니다. send 자체의 시간 제한과 종료 정책도 필요하다
   3. 그렇다. 임대 만료가 진행 중인 HTTP 연결을 강제 종료한다
   4. 아니다. 모든 실패를 즉시 재시도해야 호출 시간을 줄인다