LabHub
배우기 러닝패스 코스

ACK 전에 꺼진 간식 자판기 · 끊긴 연결 뒤의 처리 기록 · 퀴즈

퀴즈: 재시작과 중복 처리의 경계

LabHub 에서 이어서 보기

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

  1. 수신기가 재고를 커밋한 뒤 ACK 전에 죽었다. 발행자가 같은 이벤트를 다시 보내면?

    1. 저장된 ID와 내용을 확인해 재고는 유지하고 ACK한다
    2. 재접속은 새 작업이므로 같은 변화량을 다시 더한다
    3. TCP가 중복을 제거하므로 처리 이력을 읽지 않는다
    4. ACK가 없었으므로 기존 커밋을 무조건 되돌린다
  2. 합계를 먼저 커밋하고 커서를 별도 트랜잭션으로 저장하면 어떤 장애 구간이 생기는가?

    1. 커서 저장 전에 죽어도 데이터베이스가 두 커밋을 합친다
    2. 합계만 남은 상태에서 재시작해 같은 변화량을 다시 더한다
    3. 두 테이블에 기본키가 있으면 커밋 순서가 자동으로 맞는다
    4. 네트워크가 정상인 동안에는 프로세스 종료가 영향을 못 준다
  3. 서버 로그는 10–20만 남았다. 마지막 처리 커서가 8인 클라이언트에게 무엇을 알려야 하나?

    1. 10부터 재생하고 이전 구간도 처리한 것으로 간주한다
    2. 커서를 20으로 바꾸고 새 이벤트가 올 때까지 기다린다
    3. 필요한 9가 없어 스냅샷 등 재동기화가 필요하다고 알린다
    4. 같은 연결 요청을 반복하면 지운 9도 결국 돌아온다고 알린다
  4. 같은 SQLite 트랜잭션에 합계와 커서를 저장했다. 이 실험으로 어디까지 말할 수 있나?

    1. 외부 결제 요청도 동일 트랜잭션에 자동으로 포함된다
    2. 세션 파일이 삭제되어도 수신기가 이전 결과를 복구한다
    3. ACK 유실이 없어져 발행자는 중복 재전송할 필요가 없다
    4. 검사한 프로세스 장애에서 로컬 효과와 커서가 함께 남는다
  5. 이미 처리한 순번 5의 변화량은 +7인데 재전송은 +9다. 무엇이 적절한가?

    1. 이벤트 ID의 내용 충돌로 보고 처리하지 않는다
    2. 더 최근 메시지이므로 차이 +2를 자동으로 더한다
    3. 순번만 같으면 안전하므로 성공 ACK만 돌려준다
    4. 새로운 이벤트로 간주해 순번 6으로 바꾸어 넣는다
  6. 마지막 실습은 ACK 직전에 수신 프로세스를 종료하고 새 프로세스로 접속한다. 검증하지 않은 것은?

    1. 새 프로세스가 DB에서 읽은 커서로 RESUME하는지
    2. 재전송을 받아도 DB의 합계가 중복 증가하지 않는지
    3. 디스크 전원 손실과 다수 사용자의 부하를 견디는지
    4. ACK가 유실돼도 이미 커밋한 이력이 남아 있는지