퀴즈: 재처리와 주문 중복

주문 전송 프로세스가 체크포인트를 주문을 보낸 뒤에 저장하도록 만들었다. 이 선택이 장애 뒤에 만들어 내는 상태는?

• 보낸 주문과 커밋한 오프셋이 항상 같아 재처리 구간이 생기지 않는다
• 체크포인트가 항상 앞서 있어 일부 신호가 영영 처리되지 않는다
• 커밋하지 못한 구간이 다시 읽혀 같은 신호의 주문이 다시 나간다
• 재시작할 때 스트림을 처음부터 다시 읽어야 순서가 맞는다

재처리에서 중복을 걸러 내려고 클라이언트 주문 id 를 만들 때, 다음 중 규칙에 넣으면 안 되는 것은?

• 주문을 만든 시각과 프로세스 id
• 신호 스트림의 이름과 오프셋
• 주문 종목과 매매 방향
• 주문 수량과 지정가

난수로 만든 UUID 를 클라이언트 주문 id 로 쓰는 구현을 재처리 관점에서 평가하면?

• 충돌 확률이 낮아 중복 제거에 가장 알맞다
• 길이가 길어 전송 대역을 많이 쓰는 것이 유일한 단점이다
• 정렬이 되지 않아 로그를 읽기 어려운 것이 주된 문제다
• 같은 신호를 다시 읽을 때마다 다른 값이 나와 중복 제거의 근거가 되지 못한다

장애 뒤 전송 로그에서 같은 오프셋이 두 번 나온 건을 모두 이중 주문으로 보고했다. 이 집계가 과대평가되는 까닭은?

• 두 번째 전송은 첫 전송보다 늦어 시장가가 달라졌기 때문이다
• 거래소가 거절한 메시지는 주문으로 남지 않으므로 접수 확인까지 봐야 하기 때문이다
• 취소 메시지는 오프셋이 없어 전송 로그에 두 번 나타나기 때문이다
• 체크포인트가 저장된 오프셋은 다시 읽히지 않기 때문이다

재처리 뒤 취소 메시지가 존재하지 않는 원주문 id 를 가리키게 되는 가장 흔한 원인은?

• 거래소가 취소 메시지의 원주문 id 형식을 바꿔 받기 때문이다
• 취소는 원주문보다 먼저 전송되도록 우선순위가 매겨지기 때문이다
• 오프셋과 주문 id 를 잇는 표가 메모리에만 있어 재시작할 때 사라지기 때문이다
• 원주문이 이미 체결되어 거래소에서 지워지기 때문이다

중복 제거 창의 길이를 정할 때 자료에서 구해야 하는 값은?

• 같은 신호가 처음 나간 시각과 재처리로 다시 나간 시각의 최대 차이
• 장애가 난 시각과 담당자가 상황을 알아차린 시각의 차이
• 체크포인트를 저장하는 주기를 초로 환산한 값
• 거래소가 접수 확인을 돌려주기까지 걸린 평균 시간