测验：重启与重复处理的边界

수신기가 재고를 커밋한 뒤 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가 유실돼도 이미 커밋한 이력이 남아 있는지