문제 이해 및 설계 범위 확정

  • 요구사항
    • ID는 유일해야 한다.
    • ID는 숫자로만 구성되어야 한다.
    • ID는 64비트로 표현되어야 한다.
    • ID는 발급 날짜에 따라 정렬 가능해야 한다.
    • 초당 10000개의 ID를 만들 수 있어야 한다.

개략적 설계안 제시 및 동의 구하기

다중 마스터 복제

  • 데이터베이스의 auto_increment 기능을 활용하는 것이다.
    • 다음 ID의 값을 구할 때 1만큼 증가시키는 것이 아니라, k만큼 증가시킨다.
  • 단점
    • 규모를 늘리기 어렵다.
    • ID의 유일성이 보장되지만, 시간 흐름에 맞춰 커지도록 보장할 수 없다.

UUID

  • UUID: 컴퓨터 시스템에 저장되는 정보를 유일하게 식별하기 위한 128비트짜리 수
  • 중복 UUID가 1개 생길 확률을 50%로 끌어 올리며녀 초당 10억 개의 UUID를 100년 동안 계속해서 만들어야 한다.
  • 장점
    • 서버 사이의 조율이 필요없어서 동기화 이슈가 없다.
    • 규모 확장도 쉽다.
  • 단점
    • ID가 128비트로 길다.
    • ID 시간순으로 정렬할 수 없다.
    • 숫자가 아닌 값이 포함될 수도 있다.

티켓 서버

  • 중앙 집중형으로 ID를 발급하는 서버를 사용한다.
  • 장점
    • 티켓 서버가 SPOF가 된다.

트위터 snowflake 접근법

  • 사인 비트(1비트): 쓰임새가 없지만 나중을 위해 유보해둔다.
  • 타임스탬프(41비트): 기원 시각 이후로 몇 밀리초가 경과했는지를 나타내는 값이다.
    • 41비트로 표현할 수 있는 값은 대략 69년에 해당한다.
    • 따라서 이 ID 생성기는 69년동안만 동작한다.
      • 기원 시각을 현재에 가깝게 맞춰서 오버플로가 발생하는 시점을 늦추는 방법이 있다.
      • 69년이 지나면 기원 시각을 바꾸거나 ID 체계를 다른 것으로 이전하여야 한다.
  • 데이터센터 ID(5비트)
  • 서버 ID(5비트)
  • 일련번호(12비트): 각 서버에서는 ID를 생성할 때마다 이 일련번호를 1만큼 증가시킨다. 이 값은 1밀리초가 경과할 때마다 0으로 초기화된다.