Quiz: Resume an Interrupted Batch

40건 중 10건씩 확정하도록 바꾸기 전에 가장 먼저 확인할 업무 조건은?

• 평균 응답 시간을 측정해 10건이 가장 빠른지 확인한다.
• 고객이 일부만 완료된 상태와 중단 시 처리 범위를 승인했는지 확인한다.
• 전체 취소 SQL에 LIMIT 10을 붙일 수 있는지 확인한다.
• 진행률 화면을 25% 단위로 표시할 수 있는지 확인한다.

첫 청크 완료 후 새 pending 주문이 들어왔다. 원 승인 범위를 지키는 다음 청크 선택은?

• 현재 pending 전체를 다시 조회하고 앞에서 10건을 고른다.
• 현재 pending을 정렬해 OFFSET 10부터 10건을 고른다.
• 처음 승인한 건수만 유지하고 새 주문으로 빈자리를 채운다.
• 동결한 승인 ID·버전·수량 배열을 저장된 next_index부터 자른다.

둘째 청크의 다섯 번째 주문에서 버전 충돌이 났다. 승인된 청크 원자성에 맞는 처리는?

• 둘째 청크 전체를 롤백하고 첫 청크와 다른 담당자의 후속 변경은 보존한다.
• 충돌한 한 행만 건너뛰고 둘째 청크의 완료 위치를 저장한다.
• 첫 청크까지 취소를 되돌려 전체가 처음 상태인 것처럼 만든다.
• 현재 버전을 새 기대값으로 바꾸고 승인 없이 둘째 청크를 다시 실행한다.

두 워커가 같은 작업을 실행한다. 이 수업의 작업 행 잠금이 지키는 핵심은?

• orders 전체를 잠가 다른 고객의 조회를 모두 중단한다.
• 두 워커가 같은 청크를 병렬 변경해 처리 속도를 두 배로 만든다.
• 다음 구간 선택부터 변경·감사·진행률 확정까지 같은 작업을 직렬화한다.
• 연결이 끊겨도 잠금을 영구 보관해 다른 워커의 접근을 막는다.

청크 커밋 직후 응답을 받기 전에 클라이언트가 종료됐다. 같은 작업의 다음 진행 API를 다시 호출하면?

• 같은 작업 ID이므로 항상 직전 processed 목록을 그대로 반환해야 한다.
• 저장된 다음 위치부터 진행하므로 직전 청크를 다시 실행하지 않을 수 있다.
• 응답 기록이 없으므로 job_audit를 지우고 처음부터 처리해야 한다.
• 처리 결과가 불명확하므로 새로운 작업 ID로 원 승인 전체를 다시 등록한다.

진행률은 20/40이고 확정했던 2번 주문은 삭제됐다. 같은 수량의 99번 주문이 있다면 보고서는?

• 수량이 같으므로 99번을 2번의 대체 완료 증거로 넣는다.
• 삭제된 주문은 분모에서 빼고 19/39로 과거 진행률을 수정한다.
• 현재 없는 행을 복구한 뒤에만 보고서를 생성하도록 한다.
• 과거 확정 ID에는 2번을 남기고 현재 대조에서는 missing으로 분류한다.