ACK 전에 꺼진 간식 자판기 · 끊긴 연결 뒤의 처리 기록 · 퀴즈
퀴즈: 재시작과 중복 처리의 경계
문항 6개. 정답과 해설은 풀어 본 뒤에 보여 드립니다.
수신기가 재고를 커밋한 뒤 ACK 전에 죽었다. 발행자가 같은 이벤트를 다시 보내면?
- 저장된 ID와 내용을 확인해 재고는 유지하고 ACK한다
- 재접속은 새 작업이므로 같은 변화량을 다시 더한다
- TCP가 중복을 제거하므로 처리 이력을 읽지 않는다
- ACK가 없었으므로 기존 커밋을 무조건 되돌린다
합계를 먼저 커밋하고 커서를 별도 트랜잭션으로 저장하면 어떤 장애 구간이 생기는가?
- 커서 저장 전에 죽어도 데이터베이스가 두 커밋을 합친다
- 합계만 남은 상태에서 재시작해 같은 변화량을 다시 더한다
- 두 테이블에 기본키가 있으면 커밋 순서가 자동으로 맞는다
- 네트워크가 정상인 동안에는 프로세스 종료가 영향을 못 준다
서버 로그는 10–20만 남았다. 마지막 처리 커서가 8인 클라이언트에게 무엇을 알려야 하나?
- 10부터 재생하고 이전 구간도 처리한 것으로 간주한다
- 커서를 20으로 바꾸고 새 이벤트가 올 때까지 기다린다
- 필요한 9가 없어 스냅샷 등 재동기화가 필요하다고 알린다
- 같은 연결 요청을 반복하면 지운 9도 결국 돌아온다고 알린다
같은 SQLite 트랜잭션에 합계와 커서를 저장했다. 이 실험으로 어디까지 말할 수 있나?
- 외부 결제 요청도 동일 트랜잭션에 자동으로 포함된다
- 세션 파일이 삭제되어도 수신기가 이전 결과를 복구한다
- ACK 유실이 없어져 발행자는 중복 재전송할 필요가 없다
- 검사한 프로세스 장애에서 로컬 효과와 커서가 함께 남는다
이미 처리한 순번 5의 변화량은 +7인데 재전송은 +9다. 무엇이 적절한가?
- 이벤트 ID의 내용 충돌로 보고 처리하지 않는다
- 더 최근 메시지이므로 차이 +2를 자동으로 더한다
- 순번만 같으면 안전하므로 성공 ACK만 돌려준다
- 새로운 이벤트로 간주해 순번 6으로 바꾸어 넣는다
마지막 실습은 ACK 직전에 수신 프로세스를 종료하고 새 프로세스로 접속한다. 검증하지 않은 것은?
- 새 프로세스가 DB에서 읽은 커서로 RESUME하는지
- 재전송을 받아도 DB의 합계가 중복 증가하지 않는지
- 디스크 전원 손실과 다수 사용자의 부하를 견디는지
- ACK가 유실돼도 이미 커밋한 이력이 남아 있는지