시간·노드 ID·순번으로 분산 ID를 만듭니다. 시계가 뒤로 가거나 노드 ID가 중복되면 어떻게 되나요?
잠깐, 답변을 보기 전에
먼저 내 말로 설명해 볼까요?
답변과 점검 포인트 펼치기답변 접기
구두 답변
정의를 외우기보다, 원리와 조건을 연결해 설명해 보세요.
시간 기반 분산 ID는 비트 필드의 범위와 노드 식별·시계 정책을 지켜야 유일성을 유지할 수 있습니다. 생성 알고리즘 이름만으로 모든 재시작·시계 조정에서 안전한 것은 아닙니다.
동작 원리와 전제
같은 timestamp와 노드 ID에서 순번이 중복되면 충돌할 수 있습니다. 시계 역행은 대기·거절·논리 시간 유지 등의 정책을 요구하고, 단위 시간 순번을 소진하면 다음 시간까지 기다리거나 실패해야 합니다.
선택과 실패 처리
노드 ID 배정은 lease와 재사용 지연·영속 상태를 관리합니다. 이전 노드가 살아 있는데 새 노드에 같은 ID를 주면 위험합니다. timestamp 기반 순서는 대략적인 정렬일 수 있지만 전역 commit·인과 순서를 보장하지 않습니다.
구체적인 사례와 검증
시간 필드의 비트가 표현할 수 있는 epoch 범위와 순번 비트의 최대 생성률을 미리 계산합니다. 범위를 넘었는데 조용히 wrap하면 기존 ID와 겹칠 수 있습니다. 노드 ID 발급 서비스가 장애일 때 임의 ID를 골라 계속 생성하는 정책도 유일성을 깨뜨릴 수 있어 거절·대기 기준을 둡니다. 생성한 ID는 JavaScript나 JSON 파싱에서 정밀도를 잃지 않게 문자열로 전달할 수 있습니다. 시간 정렬은 사용자 편의나 인덱스 배치에 도움이 되지만 두 거래의 확정 순서를 나타내는 값으로 사용하지 않습니다. 생성자의 로컬 시계와 DB commit은 다른 사건입니다.
시계 역행·순번 포화·동일 노드 ID·재시작을 시험합니다. ID의 비트 폭을 JSON·DB·브라우저에서 정확히 전달하는지도 확인합니다. 유일 식별자와 요청 멱등 키, 업무 순서 번호는 별도 목적입니다.
득점 포인트
이해가 드러나는 지점을 확인해 보세요.
- 핵심 구분: 시간 기반 분산 ID는 비트 필드의 범위와 노드 식별·시계 정책을 지켜야 유일성을 유지할 수 있습니다.
- 선택 조건: 노드 ID 배정은 lease와 재사용 지연·영속 상태를 관리합니다.
- 검증 기준: 시계 역행·순번 포화·동일 노드 ID·재시작을 시험합니다.
감점 포인트
놓치기 쉬운 조건과 오해를 짚어 보세요.
- 시간 기반 ID의 숫자 순서가 전역 commit·인과 순서를 보장한다고 한다.
더 파고들 거리
하나 더 질문하며 이해의 범위를 넓혀 보세요.
- 분산 ID의 충돌·정렬·노출 특성과 논리 요청 중복을 어떻게 구분하나요?
- 표시 시각·로컬 경과 시간·권위 있는 변경 순서는 어떤 시계와 버전으로 나누나요?
- 큰 ID를 Number로 파싱하기 전에 어떤 표현으로 정밀도를 보존해야 하나요?
득점·감점 포인트는 학습용 자기 점검 기준이며, 특정 회사의 실제 채점표가 아닙니다.
원리부터 공부하고 싶다면
답변을 보충하는 개념·예제·슈도코드를 읽어 보세요.