Identificador único, numérico e incremental

Question

Preciso gerar IDs de transação numérica exclusiva, incremental para cada solicitação que eu faço para um determinado XML RPC. Esses números precisam ser únicos em todo o meu domínio, mas serão gerados em várias máquinas.

Eu realmente não quero ter que acompanhar esse número em um banco de dados e lidar com o bloqueio de linha etc. em todas as transações. Tentei invadir isso usando um registro de data e hora de microssegundos, mas houve colisões com apenas alguns threads - meu aplicativo precisa suportar centenas de threads.

Quaisquer idéias seriam apreciadas.

EDIT: E se cada ID da transação precisar ser maior que as solicitações anteriores?

Answer 1

Se você estiver usando isso de centenas de threads, trabalhando em várias máquinas e exigir um ID incremental, precisará de algum local centralizado para armazenar e bloquear o último número de identificação gerada. Isso não precisa necessariamente estar em um banco de dados, mas essa seria a opção mais comum. Um servidor central que não fez nada além de IDs de servir poderia fornecer a mesma funcionalidade, mas provavelmente derrota o objetivo de distribuir isso.

Se eles precisam ser incrementais, qualquer forma de registro de data e hora não será garantida.

Se você não precisar que eles sejam incrementais, um GUID funcionaria. Potencialmente fazer algum tipo de mesclagem do registro de data e hora + um ID de hardware em cada sistema pode fornecer identificadores exclusivos, mas a parte do número de identificação não seria necessariamente única.

Você poderia usar um par de IDs de hardware + timestamps incrementais? Isso tornaria o IDS de cada máquina específico incremental, mas não necessariamente seria único em todo o domínio.

---- Edit -----

Eu não acho que usar nenhuma forma de registro de data e hora vai funcionar para você, por dois motivos.

Primeiro, você nunca poderá garantir que 2 threads em diferentes máquinas não tentarão agendar exatamente ao mesmo tempo, independentemente da resolução do timer que você usa. Em uma resolução alta o suficiente, seria improvável, mas não garantido.

Segundo, para fazer isso funcionar, mesmo que você pudesse resolver o problema de colisão acima, precisará que todos os sistemas tenham exatamente o mesmo relógio com a precisão de microssegundos, o que não é realmente prático.

Answer 2

Este é um problema muito difícil, principalmente se você não deseja criar um gargalo de desempenho. Você diz que os IDs precisam ser "incrementais" e "numéricos" - isso é uma restrição comercial concreta, ou que existe para algum outro propósito?

Se não forem necessários, você pode usar UUIDs, para os quais as plataformas mais comuns possuem bibliotecas. Eles permitem que você gere muitos (milhões!) De IDs em tempo muito curto e se sinta confortável sem colisões. O artigo relevante sobre as reivindicações da Wikipedia:

Em outras palavras, somente depois de gerar 1 bilhão de UUIDs a cada segundo nos próximos 100 anos, a probabilidade de criar apenas uma duplicata seria de cerca de 50%.

Answer 3

Se você remover 'incremental' de seus requisitos, poderá usar um Guid.

Não vejo como você pode implementar incremental em vários processos sem algum tipo de dados comuns.

Answer 4

Se você segmentar uma plataforma Windows, você tentou API interligada ?

Answer 5

Google para geradores Guid Para qualquer idioma que você esteja procurando e depois convertê -lo em um número, se você realmente precisar que ele seja numérico. Não é incremental.

Ou tenha cada thread "reserva" mil (ou milhões, ou bilhões) IDs de transações e entregam um de cada vez, e "reserve" o próximo grupo quando acabar. Ainda não é realmente incremental.

Answer 6

Estou com a multidão do GUID, mas se isso não for possível, você poderia considerar usar db4o ou SQL Lite sobre um banco de dados pesado?

Answer 7

Se cada cliente puder acompanhar seu próprio "Próximo ID", você poderá conversar com um servidor Sentral e obter uma variedade de IDs, talvez um 1000 por vez. Depois que um cliente ficar sem IDs, ele terá que conversar com o servidor novamente.

Isso faria com que seu sistema tivesse uma fonte central de IDs e ainda evitaria conversar com o banco de dados para cada ID.