퀴즈: 늦게 돌아온 전달자의 도장을 거절한다

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

1. A의 임대가 1000ms에 끝나고 B가 같은 시각에 재선점했습니다. A가 1001ms에 완료를 요청하면?

   1. A가 먼저 시작했으므로 B의 현재 선점을 완료 처리한다
   2. 수량이 같다면 A와 B의 결과를 모두 완료로 승인한다
   3. A의 옛 토큰은 False로 거절하고 B의 상태를 보존한다
   4. A의 요청이 늦었으므로 해당 업무 행 전체를 삭제한다

2. 작업자 이름이 worker-1로 같은 프로세스가 재시작했습니다. owner만 대조하면 부족한 이유는?

   1. 이름이 같으면 SQLite가 두 프로세스의 연결을 하나로 합친다
   2. 이름이 같으면 임대 만료 시각이 자동으로 같은 값이 된다
   3. 이름이 같으면 완료한 모든 업무를 새 프로세스가 재접수한다
   4. 같은 이름의 이전 실행과 현재 선점 세대를 구분하지 못한다

3. 두 프로세스가 대기 업무 하나를 동시에 claim합니다. 선택과 갱신을 어떻게 묶나요?

   1. BEGIN IMMEDIATE 안에서 선택·횟수 증가·임대를 함께 커밋한다
   2. 트랜잭션 밖에서 둘 다 선택한 뒤 각각 임대 상태로 덮어쓴다
   3. 각 프로세스의 메모리 잠금만 잡고 DB 선택은 독립 실행한다
   4. 전송을 먼저 한 뒤 수신 응답이 빠른 쪽이 임대를 저장한다

4. send 콜백이 응답을 기다리는 동안 다른 작업자가 새 업무를 enqueue할 수 있어야 합니다. 필요한 구조는?

   1. HTTP 응답까지 선점 트랜잭션을 열어 원자성을 보장한다
   2. 선점 커밋 후 전송하고 결과 기록은 별도 트랜잭션으로 한다
   3. 전송 동안 모든 작업자가 같은 연결을 공유하고 쓰기를 미룬다
   4. 전송 전에 큐를 삭제하고 완료한 뒤 새 DB를 생성한다

5. 큐가 오래된 token의 finish를 거절합니다. 이 사실만으로 외부 재고 서버의 중복 효과도 막았나요?

   1. 그렇다. SQLite의 토큰 비교가 외부 DB에도 자동 적용된다
   2. 그렇다. 두 HTTP 요청이 같은 큐 행에서 나왔으면 병합된다
   3. 아니다. 수신 측 업무 ID 중복 제거 등 별도 계약이 필요하다
   4. 아니다. 큐의 토큰을 매 재시도마다 0으로 바꿔야 해결된다

6. now=900, lease_ms=1000, deadline=1200인 업무를 선점합니다. lease_until은?

   1. 1900으로 두고 완료 시 최초 마감을 늘린다
   2. 1000으로 두고 모든 시각을 프로세스 시작 기준으로 바꾼다
   3. 900으로 두고 선점 직후 다른 작업자가 가져가게 한다
   4. 1200으로 제한하여 업무 마감 이후 권리를 주지 않는다