분산 시스템에서 유일성이 보장되는 ID를 만드는 방법은 여러 가지다.
-
다중 마스터 복제(multi-master replication)
- DB의 auto_increment 기능을 사용
- +1 증가가 아니고 k만큼 증가 -> k는 사용중인 DB서버 갯수
- 단점
- 여러 데이터 센터에 걸쳐 규모를 늘리기 어렵다.
- ID의 유일성은 보장되지만, 그 값이 시간 흐름에 맞추어 커지도록 보장할 수는 없다.
- 서버를 추가하거나 삭제할 때도 잘 동작하도록 만들기 어렵다.
-
UUID(Universally Unique Identifier)
- 128비트 숫자이며, 32자리 16진수로 표현
- 장점
- 만들기 쉽고 동기화 이슈도 없다.
- 각 서버가 자기가 쓸 ID를 알아서 만드는 구조이므로 규모 확장도 쉽다.
- 단점
- ID가 128비트로 길다.
- ID를 시간순으로 정렬할 수 없다.
- ID에 숫자(numeric)아닌 값이 포함될 수 있다.
-
티켓 서버(ticket server)
- auto_increment 기능만 수행하는 db서버 즉 티켓서버를 중앙 집중형으로 하나만 사용하는 것.
- 장점
- 유일성이 보장되는 숫자로만 구성된 ID를 쉽게 만들 수 있다.
- 구현하기 쉽고, 중소 규모 애플리케이션에 적합하다.
- 단점
- 티켓 서버가 SPOF(Single-Point-of-failure)가 된다.
-
트위터 스노우플레이크(twitter snowflake) 접근법
- 64비트 ID를 역할별로 쪼개서 구성
- 사인(sign) 비트 : 1비트를 할당, 나중을 위해 유보
- 타임스탬프(timestamp) : 41비트 할당, epoch 이후로 몇 밀리초가 경과했는지 나타냄
- 데이터센터 ID : 5비트 할당, 2^5 = 32개 데이터 센터 지원 가능
- 서버 ID : 5비트 할당, 데이터 센터당 32개 서버를 사용할 수 있다.
- 일련번호 : 12비트 할당, 각 서버에서 ID 생성시 이 일련번호를 1만큼 증가, 이 값은 1밀리초가 경과할 때마다 0으로 초기화