7장

요구사항

• 질답을 통해 얻는다

• ID는 유일해야 한다.

• ID는 숫자로만 구성되어야 한다.

• ID는 64비트로 표현될 수 있는 값이어야 한다.

• ID는 발급 날짜에 따라 정렬 가능해야 한다.

• 초당 10,000개의 ID를 만들 수 있어야 한다.

다중 마스터 복제

• 서버 개수 k만큼 auto_increment를 시킨다.

• 하지만 다음과 같은 단점이 있다.

  • 여러 데이터 센터에 걸쳐 규모를 늘리기 어렵다.

  • ID의 유일성은 보장되지만, 시간 흐름에 맞추어 커지도록 보장할 수 없다.

  • 서버 개수가 바뀌면 잘 동작하지 않는다.

UUID

• 장점

  • 단순하다, 동기화 이슈도 없다.

  • 각 서버가 자기가 쓸 ID를 알아서 만드는 구조이므로 규모 확장도 쉽다.

• 단점

  • 128비트로, 길다. (64비트보다 큼)

  • ID를 시간순으로 정렬할 수 없다.

  • 숫자가 아닌 값이 포함될 수 있따.

티켓 서버

• Auto_increment 기능을 갖춘 서버를 중앙 집중형으로 하나만 사용하는 것

• 장점

  • 유일성이 보장되는, 숫자로만 구성된 ID가 쉽게 만들어진다.

  • 구현하기 쉽다

• 단점

  • SOF가 된다. 즉, 티켓 서버에 장애가 생기면 모든 시스템이 영향을 받는다.

  • 만약 티켓 서버를 늘린다면? 결국 데이터 동기화 이슈가 발생한다.

트위터 스노우플레이크 접근법

트위터에서 쓴다.

• 여러 section으로 나눈다.

  • sign 비트 - 1비트

  • 타임스탬프 - 41비트 - 기원 시각 이후 몇 밀리초가 경과했는가

  • 데이터 센터 ID - 5비트

  • 서버 ID - 5비트

  • 일련번호 - 12비트 - 각 서버에서 ID를 생성할 때마다 일련번호를 1만큼 증가시킨다. 이 값은 1 밀리초가 경과할때마다 0으로 초기화된다.

마무리

여러 가지 더 논의해볼만한 주제들

• 시계 동기화 - 시계가 다를 수 있다. - NTP(Network Time Protocol)이 보편적이다

• section 길이 최적화 - 동시성이 낮고 수명이 길다면, 일련번호를 줄이고 타임스탬프를 늘릴 수 있다.

• 고가용성