고유한 숫자 증분 식별자

Question

특정 XML RPC에 대한 각 요청에 대해 고유한 증분 숫자 트랜잭션 ID를 생성해야 합니다.이 번호는 내 도메인 전체에서 고유해야 하지만 여러 컴퓨터에서 생성됩니다.

나는 데이터베이스에서 이 숫자를 추적하고 매 트랜잭션마다 행 잠금 등을 처리하고 싶지 않습니다.마이크로초 타임스탬프를 사용하여 이를 해킹하려고 했지만 단 몇 개의 스레드에서만 충돌이 발생했습니다. 내 애플리케이션은 수백 개의 스레드를 지원해야 합니다.

어떤 아이디어라도 감사하겠습니다.

편집하다:각 거래 ID가 이전 요청보다 커야 한다면 어떻게 될까요?

Answer 1

수백 개의 스레드에서 이것을 사용하고 여러 기계에서 작업하고 증분 ID가 필요한 경우 마지막으로 생성 된 ID 번호를 저장하고 잠그기 위해 중앙 집중식 장소가 필요합니다. 이것은 반드시 데이터베이스에있을 필요는 없지만 가장 일반적인 옵션입니다. 서비스 ID를 제공하는 중앙 서버는 동일한 기능을 제공 할 수 있지만이를 배포하는 목적을 물리 칠 수 있습니다.

점진적이어야한다면 모든 형태의 타임 스탬프는 고유 한 보장되지 않습니다.

증분이 필요하지 않으면 안내가 작동합니다. 각 시스템에서 타임 스탬프 + 하드웨어 ID의 일부 유형의 병합을 수행하면 고유 한 식별자가 제공 될 수 있지만 ID 번호 부분이 반드시 고유 한 것은 아닙니다.

하드웨어 ID + 증분 타임 스탬프를 사용할 수 있습니까? 이렇게하면 각 특정 머신의 ID가 증분적이지만 전체 도메인에서 반드시 고유 한 것은 아닙니다.

---- 편집하다 -----

나는 어떤 형태의 타임 스탬프를 사용하는 것이 두 가지 이유로 당신에게 효과가 있다고 생각하지 않습니다.

첫째, 다른 기계의 2 개의 스레드가 어떤 타이머 해상도를 사용하든 정확히 동시에 예약을 시도하지 않도록 보장 할 수 없습니다. 충분히 높은 해상도에서는 가능성이 낮지 만 보장되지는 않을 것입니다.

둘째,이 작업을 수행하려면 위의 충돌 문제를 해결할 수 있더라도 모든 시스템이 마이크로 초 정확도로 정확히 동일한 시계를 갖도록해야합니다. 이는 실제로 실용적이지 않습니다.

Answer 2

이는 특히 성능 병목 현상을 일으키고 싶지 않은 경우 매우 어려운 문제입니다.ID가 '증분' 및 '숫자'여야 한다고 말씀하셨습니다. 이는 구체적인 비즈니스 제약 조건인가요, 아니면 다른 목적으로 존재하는 제약인가요?

이것이 필요하지 않은 경우 가장 일반적인 플랫폼에 라이브러리가 있는 UUID를 사용할 수 있습니다.이를 통해 매우 짧은 시간 내에 많은(수백만!) 개의 ID를 생성할 수 있으며 충돌 없이 매우 편안하게 사용할 수 있습니다.Wikipedia 주장에 대한 관련 기사는 다음과 같습니다.

다시 말해, 향후 100 년 동안 매 초마다 10 억 개의 UUID를 생성 한 후에 만 ​​하나의 복제본 만 생성 할 확률은 약 50%입니다.

Answer 3

요구 사항에서 '증분'을 제거하면 안내.

공통 데이터없이 여러 프로세스에서 점진적으로 구현할 수있는 방법을 모르겠습니다.

Answer 4

Windows 플랫폼을 타겟팅하는 경우 시도 했습니까? 연동 API ?

Answer 5

안내 생성기를위한 Google 원하는 언어에 대해서는 숫자가 필요한 경우 숫자로 변환하십시오. 그래도 점진적이지는 않습니다.

또는 각 스레드에 "예비"(또는 백만 또는 10 억) 트랜잭션 ID를 "예약"하고 한 번에 하나씩 나눠주고 다음 번에 다 떨어질 때 "예약"을 "예약"하십시오. 여전히 점진적이지 않습니다.

Answer 6

나는 Guid Crowd와 함께 있지만 가능하지 않다면 사용을 고려할 수 있습니까? DB4O 또는 SQL 라이트 무거운 가중 데이터베이스를 통해?

Answer 7

각 클라이언트가 자체 "다음 ID"를 추적 할 수 있다면 Sentral Server와 대화하고 한 번에 1000 씩 다양한 ID를 얻을 수 있습니다. 클라이언트가 ID가 부족하면 서버와 다시 대화해야합니다.

이렇게하면 시스템이 중심적인 ID 소스를 갖게되며 모든 ID에 대해 데이터베이스와 대화 할 필요가 없습니다.