퀴즈: 실패한 간식 주문을 지우지 않는다

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

1. 격리된 업무를 redrive할 때 초기화하면 안 되는 값은?

   1. 이전 선점부터 증가해 온 token
   2. 이번 예산에서 소비한 attempts
   3. 다시 접수 가능한 available_at
   4. 새 시간 예산의 deadline

2. redrive의 감사 행 삽입 뒤, pending 갱신 전에 예외가 났습니다. 올바른 디스크 상태는?

   1. 감사 행만 보존하고 업무는 dead로 두어 성공으로 보고한다
   2. 감사 행과 상태 변경을 모두 롤백해 기존 격리를 보존한다
   3. 감사 행은 지우고 업무만 pending으로 바꾸어 처리한다
   4. 기존 업무와 감사 내역을 삭제하고 새 업무 ID를 발급한다

3. 앞 순서의 업무는 영구 오류로 dead가 됐고 뒤 업무는 유효합니다. 이 실습 큐의 처리 계약은?

   1. 앞 업무가 고쳐질 때까지 뒤 업무도 무기한 멈춘다
   2. 순서 보장을 위해 뒤 업무를 앞 업무와 함께 삭제한다
   3. 독립 업무이므로 뒤 업무는 처리하되 격리 기록을 남긴다
   4. 뒤 업무를 앞 업무 ID로 바꾸어 수신 중복으로 처리한다

4. 수신 서버가 수량 7을 커밋한 직후 전달자가 종료되고, 다음 작업자가 같은 ID로 재전송했습니다. 기대 증거는?

   1. HTTP 요청 한 번, inbox 두 행, 업무 효과 14
   2. HTTP 요청 두 번, inbox 두 행, 업무 효과 14
   3. HTTP 요청 한 번, inbox 한 행, 업무 효과 0
   4. HTTP 요청 두 번, inbox 한 행, 업무 효과 7

5. send가 알 수 없는 예외를 냈습니다. run_once는 어떻게 처리해야 하나요?

   1. 예외를 전달하고 leased 기록을 남겨 만료 후 재선점하게 한다
   2. 모든 예외를 정상 ACK로 바꾸고 큐에 done을 기록한다
   3. 모든 예외를 Permanent로 바꾸고 감사 없이 업무를 삭제한다
   4. 외부 결과를 모르므로 attempts를 줄이고 즉시 반복 호출한다

6. 격리 목록이 줄었습니다. 운영자가 성공 증가라고 판단하기 전에 확인할 것은?

   1. 큐 파일 크기만 비교하여 작아졌으면 모두 성공으로 센다
   2. done·redrive 감사·재시도 상태를 나눠 실제 이동 이유를 본다
   3. pending을 모두 done으로 표시한 뒤 성공률을 다시 계산한다
   4. 격리 사유를 지워 같은 업무가 다시 집계되지 않게 만든다