유일성을 구조로 보장하는 가장 단순한 방법은 한 곳에서만 발급하는 것입니다. 이 방법부터 재 보고 왜 탈락하는지 봅니다.
한 곳에서 번호를 센다
저장소의 증가하는 번호나 전용 서버 하나가 번호를 셉니다. 중복이 원리적으로 불가능하고, 요구사항에서 뺐던 빈틈 없는 연속 번호까지 얻습니다.
문제는 둘입니다.
| 문제 | 내용 |
|---|---|
| 왕복 | 발급마다 물어봐야 한다. 예산 1ms 를 그대로 쓴다 |
| 단일 장애점 | 그 곳이 멈추면 모든 서비스의 쓰기가 멈춘다 |
발급량 초당 10만 도 그 한 곳의 처리량 상한에 걸립니다.
구간을 미리 받아 두면
한 번에 1,000개를 받아 로컬에서 나눠 쓰면 왕복이 1,000번에 한 번으로 줄어듭니다. 이 방법은 실무에서 널리 쓰입니다.
그런데 대가가 둘 생깁니다.
재시작하면 남은 구간이 버려진다. 번호에 빈틈이 생긴다
노드마다 다른 구간을 쓰므로 시간순 정렬이 깨진다
정렬이 깨지는 것이 치명적입니다. 앞 단계에서 정렬을 저장 비용 요구사항으로 정했는데, 구간 임대는 그것을 지키지 못합니다. 노드 A가 11000을, 노드 B가 10012000을 받으면 시간 순서와 번호 순서가 무관해집니다.
노드마다 증가폭을 다르게 주는 방법
노드 수만큼 증가폭을 두고 시작점을 다르게 주는 방법도 있습니다. 노드 셋이면 1, 4, 7 과 2, 5, 8 과 3, 6, 9 를 각각 씁니다.
이 방법은 왕복이 없지만 노드 수가 규칙에 들어 있습니다. 노드를 추가하려면 증가폭을 바꿔야 하고, 그러면 이미 발급한 번호와 충돌할 수 있습니다. 안정 해시에서 본 문제와 같은 모양입니다.
그래도 이 방법이 맞는 경우
중앙 발급기를 나쁜 방법으로 외우면 안 됩니다.
| 상황 | 중앙 발급기가 |
|---|---|
| 발급량이 초당 수천 이하 | 충분하다. 더 정교한 방법은 과설계다 |
| 빈틈 없는 연속 번호가 필요 | 유일한 방법이다. 청구서 번호나 영수증 번호 |
| 이미 저장소를 쓰고 있다 | 새 부품 없이 된다 |
요구사항에 연속 번호가 있으면 다른 선택지가 없습니다. 이 설계는 그것을 뺐기 때문에 다른 길이 열렸습니다.
이 요구사항에서는 탈락한다
지연 1ms 와 정렬 요구를 함께 지킬 수 없습니다. 왕복을 없애려면 구간 임대가 필요하고, 구간 임대는 정렬을 깨뜨립니다.
그래서 다음 단계에서 아무에게도 묻지 않고 만드는 방법을 봅니다.