분산 상황에서 고유한 데이터베이스 ID를 생성하는 솔루션

비즈니스의 고유 식별자인 ID는 데이터 디자인에서 흔히 볼 수 있습니다. 예:

•Product—— product_id

•Order—— order_id

•Message—— message_id

이러한 식별자는 데이터베이스의 기본 키인 경우가 많습니다. MySQL은 기본 키에 클러스터형 인덱스를 생성하여 데이터 주소를 직접 가리킵니다. 클러스터형 인덱스를 가리키는 일반 인덱스에 비해 인덱스 쿼리가 1개 줄어들고 속도도 매우 빠릅니다. 메시지 및 주문과 같은 비즈니스는 일반적으로 시간 역순으로 데이터를 쿼리해야 합니다. 한 가지 방법은 ID 자체의 삽입 순서에 의존하는 것이 좋습니다. 따라서 분산 ID는 두 가지 핵심 조건을 충족해야 합니다.

• 전역적으로 고유함

• 시간 추세가 순서대로

어떤 사람들은 MySQL의 auto_increment를 사용할 수 없다고 말할 수도 있습니다. 직접적으로 충분합니까? 사업을 시작하는 초기에도 저는 이 솔루션을 선택하겠습니다. 이 솔루션은 간단하고 효율적이며 빠릅니다. 스타트업은 여전히 ​​빠르게 반복하고 가능한 한 빨리 제품을 생산해야 하며 제품은 너무 많은 시간을 들여 변경됩니다. 개발하는 데 시간이 쓸모가 없을 수도 있습니다. 그렇습니다. 귀중한 시간이 낭비되었습니다. 그러나 이 해결 방법에는 다음과 같은 몇 가지 문제가 있습니다.

• 병렬 삽입에 영향을 미침 - 레코드 B는 레코드 A의 기본 키에 따라 달라집니다. 레코드 A가 성공적으로 삽입될 때까지 기다렸다가 A.id를 가져와야 합니다. 레코드 B 삽입

•데이터 복구가 어려움 - 데이터가 실수로 삭제되거나 손실된 경우 로그에 ID가 없으므로 데이터 상관관계를 직접 확인할 수 없음

• 하위에 영향을 미침 -데이터베이스 및 하위 테이블 - ID를 삽입해야 알 수 있으므로 데이터베이스와 테이블은 비즈니스의 기본 키를 기준으로 나눌 수 없습니다

따라서 비즈니스가 안정된 후에는 시간을 들여 초기 기술 부채를 갚습니다.

일반적인 솔루션

데이터베이스의 auto_increment를 사용하여 고유한 ID를 생성

장점

•간단함, 기존 기능 사용, 적은 개발 노력

•ID 스텝 크기가 고정

단점

•단일 쓰기 지점, 가용성이 높지 않음

•다양한 auto_increment에 따라 여러 개의 메인 라이브러리를 확장하더라도 가용성은 향상되었지만 엄격한 ID 순서를 보장할 수는 없습니다.

• 매번 데이터베이스에 액세스해야 하므로 성능 한도에 쉽게 도달할 수 있습니다.

ID를 일괄적으로 가져와서 하나씩 할당

이런 종류의 솔루션은 ID 데이터를 데이터베이스에 저장하는 것입니다. ID 서비스는 매번 데이터베이스에서 N개의 ID를 가져와 현재 최대 ID 값을 원래 데이터 + N으로 업데이트합니다. . ID 생성 요청을 받을 때마다 여기에서 ID 서비스가 시작됩니다.

장점

•일괄 획득, 매번 데이터베이스에 액세스할 필요가 없음, 작은 데이터베이스 부담

단점

•전체 서비스가 여전히 단일임 point

•서비스 다운타임 및 재시작 시 ID 중단

•수평 확장 불가

개선

메인 서비스가 중단되는 경우 백업 서비스 추가. 위로 올라가면 백업 서비스로 이동합니다. vip + keepalived를 사용하거나 프록시를 추가할 수 있습니다.

uuid

장점

•로컬 ID 생성, 단일 문제 지점 없음, 성능 병목 현상 없음

단점

•증분 보장되지 않음 Ordered

•기본 키로 길이가 너무 길고 성능이 낮음

눈송이형 알고리즘

눈송이는 트위터의 오픈소스 분산ID 생성 알고리즘 핵심 아이디어는 긴 유형 ID가 밀리초 수로 41비트, 기계 번호로 10비트, 밀리초 내의 일련 번호로 12비트를 사용한다는 것입니다. 이 알고리즘은 이론적으로 단일 시스템에서 초당 최대 1000*(2^12) 또는 400W ID를 생성할 수 있어 비즈니스 요구 사항을 완전히 충족할 수 있습니다.

Snowflake의 아이디어를 배우고 각 기업의 비즈니스 로직과 동시성을 결합하여 나만의 분산 ID 생성 알고리즘을 구현할 수 있습니다.

장점

•시간은 높은 수준이고 추세는 증가하고 있습니다

•간단한 구현, 다른 서비스에 의존하지 않음, 확장 용이

단점

•글로벌 시계가 없고 단일 기계가 절대적으로 순서가 있지만 전체 클러스터 관점에서 보면 추세가 순서대로입니다

참고

•ID는 서브 데이터베이스 및 테이블의 식별자로 사용되는 경우가 많으므로 분할 후 데이터가 균일하지 않도록 일정 정도의 임의성을 갖는 것이 필요합니다. 일련 번호는 처음에 1부터 시작할 수 없습니다. 밀리초마다 0~9 중 하나로 시작할 수 있습니다.