Identificatore univoco, numerico, incrementale

Question

Devo generare ID transazione univoci, incrementali e numerici per ogni richiesta che faccio a un determinato RPC XML. Questi numeri devono solo essere univoci nel mio dominio, ma verranno generati su più macchine.

Non voglio davvero tenere traccia di questo numero in un database e occuparmi del blocco delle righe ecc. su ogni singola transazione. Ho provato a hackerarlo usando un timestamp di microsecondi, ma ci sono state collisioni con pochi thread: la mia applicazione deve supportare centinaia di thread.

Qualsiasi idea sarebbe apprezzata.

Modifica: cosa succede se ogni ID transazione deve essere maggiore di quello della richiesta precedente?

Answer 1

Se lo utilizzerai da centinaia di thread, lavorerai su più macchine e richiederai un ID incrementale, avrai bisogno di un posto centralizzato per archiviare e bloccare l'ultimo numero ID generato. Questo non deve necessariamente essere in un database, ma sarebbe l'opzione più comune. Un server centrale che non ha fatto altro che servire ID potrebbe fornire la stessa funzionalità, ma probabilmente vanifica lo scopo di distribuirlo.

Se devono essere incrementali, qualsiasi forma di data e ora non sarà garantita unica.

Se non è necessario che siano incrementali, un GUID funzionerebbe. Potenzialmente fare un qualche tipo di unione del timestamp + un ID hardware su ciascun sistema potrebbe fornire identificatori univoci, ma la parte del numero ID non sarebbe necessariamente unica.

Potresti usare una coppia di ID hardware + timestamp incrementali? Ciò renderebbe gli ID di ogni macchina specifica incrementali, ma non necessariamente univoci nell'intero dominio.

---- EDIT -----

Non credo che usare qualsiasi forma di data e ora funzionerà per te, per 2 motivi.

Innanzitutto, non sarai mai in grado di garantire che 2 thread su macchine diverse non proveranno a pianificare esattamente nello stesso momento, indipendentemente dalla risoluzione del timer che usi. Con una risoluzione sufficientemente elevata, sarebbe improbabile, ma non garantito.

In secondo luogo, per far funzionare tutto questo, anche se si potesse risolvere il problema di collisione sopra riportato, si dovrebbe fare in modo che ogni sistema abbia esattamente lo stesso clock con precisione dei microsecondi, il che non è molto pratico.

Answer 2

Questo è un problema molto difficile, in particolare se non si desidera creare un collo di bottiglia nelle prestazioni. Dici che gli ID devono essere "incrementali" e "numerici": è un vincolo commerciale concreto o esiste per qualche altro scopo?

Se questi non sono necessari, è possibile utilizzare gli UUID, per cui le piattaforme più comuni dispongono di librerie. Ti consentono di generare molti (milioni!) Di ID in tempi brevi e di sentirti a tuo agio senza collisioni. L'articolo pertinente su Wikipedia afferma:

  

In altre parole, solo dopo la generazione   1 miliardo di UUID al secondo per il   prossimi 100 anni, la probabilità di   la creazione di un solo duplicato sarebbe   circa il 50%.

Answer 3

Se rimuovi "incrementale" dai tuoi requisiti, puoi utilizzare un GUID .

Non vedo come sia possibile implementare in modo incrementale su più processi senza una sorta di dati comuni.

Answer 4

Se hai scelto come target una piattaforma Windows, hai provato API interbloccata ?

Answer 5

Google per generatori di GUID per qualsiasi lingua tu stia cercando e quindi convertilo in un numero se ne hai davvero bisogno per essere numerico. Non è però incrementale.

O ogni thread "riserva" un migliaio (o milioni o miliardi) di ID transazione e distribuirli uno alla volta e "prenotare" il prossimo mazzo quando si esaurisce. Ancora non molto incrementale.

Answer 6

Sono con il pubblico GUID, ma se ciò non fosse possibile, potresti prendere in considerazione l'utilizzo di db4o o SQL Lite su un peso elevato database?

Answer 7

Se ogni client è in grado di tenere traccia del proprio "ID successivo", è possibile parlare con un server Sentral e ottenere un intervallo di ID, forse un 1000 alla volta. Una volta che un client ha esaurito l'id, dovrà nuovamente parlare con il server.

Ciò renderebbe il tuo sistema avere una fonte centrale di ID, evitando comunque di parlare al database per ogni ID.