Identifiant unique, numérique, incrémental

Question

Je dois générer des identifiants de transaction numériques incrémentiels uniques pour chaque demande adressée à un certain RPC XML. Ces numéros doivent uniquement être uniques sur mon domaine, mais seront générés sur plusieurs ordinateurs.

Je ne veux vraiment pas avoir à garder une trace de ce numéro dans une base de données et à gérer le verrouillage de lignes, etc. pour chaque transaction. J'ai essayé de pirater cela en utilisant un horodatage en microsecondes, mais il y a eu des collisions avec seulement quelques threads - mon application doit prendre en charge des centaines de threads.

Toutes les idées seraient appréciées.

Modifier: que se passe-t-il si chaque identifiant de transaction doit simplement être supérieur à celui de la demande précédente?

Answer 1

Si vous voulez utiliser cela à partir de centaines de threads, travailler sur plusieurs machines et nécessiter un identifiant incrémentiel, vous aurez besoin d'un emplacement centralisé pour stocker et verrouiller le dernier numéro d'identification généré. Cela ne doit pas nécessairement être dans une base de données, mais ce serait l'option la plus courante. Un serveur central qui ne fait que servir des identifiants pourrait fournir la même fonctionnalité, mais cela va probablement à l’encontre de l’objectif de la distribution.

S'ils doivent être incrémentiels, aucune forme d'horodatage ne sera garantie comme unique.

Si vous n'avez pas besoin qu'ils soient incrémentiels, un GUID fonctionnerait. Faire éventuellement un type de fusion de l'horodatage + un identifiant matériel sur chaque système pourrait donner des identifiants uniques, mais la partie correspondant au numéro d'identification ne serait pas nécessairement unique.

Pourriez-vous utiliser une paire d’ID matériel + horodatage incrémentiel? Cela rendrait les identifiants de chaque machine spécifiques incrémentiels, mais ne serait pas nécessairement unique sur tout le domaine.

---- EDIT -----

Je ne pense pas que l'utilisation d'une forme d'horodatage va fonctionner pour vous, pour 2 raisons.

Tout d’abord, vous ne serez jamais en mesure de garantir que 2 threads sur des machines différentes ne tenteront pas de planifier au même moment, quelle que soit la résolution de la minuterie que vous utilisez. Avec une résolution suffisamment élevée, ce serait peu probable, mais pas garanti.

Deuxièmement, pour que cela fonctionne, même si vous pouviez résoudre le problème de collision ci-dessus, il faudrait que tous les systèmes aient exactement la même horloge avec une précision de l'ordre de la microseconde, ce qui n'est pas vraiment pratique.

Answer 2

Il s’agit d’un problème très difficile, en particulier si vous ne voulez pas créer de goulet d’étranglement en termes de performances. Vous dites que les identifiants doivent être 'incrémentaux' et 'numériques' - s'agit-il d'une contrainte métier concrète ou d'une contrainte existante?

Si cela n’est pas nécessaire, vous pouvez utiliser des UUID, pour lesquels la plupart des plates-formes communes possèdent des bibliothèques. Ils vous permettent de générer beaucoup (des millions!) D'identifiants dans des délais très courts et d'être assez à l'aise sans collision. L'article pertinent sur wikipedia affirme:

  

En d'autres termes, seulement après avoir généré   1 milliard d'UUID par seconde pour la   100 prochaines années, la probabilité de   créer un seul doublon serait   environ 50%.

Answer 3

Si vous supprimez "incrémental" de vos besoins, vous pouvez utiliser un GUID .

Je ne vois pas comment vous pouvez implémenter de manière incrémentielle plusieurs processus sans une sorte de données communes.

Answer 4

Si vous ciblez une plate-forme Windows, avez-vous essayé API interverrouillée ?

Answer 5

Google pour les générateurs de GUID , quelle que soit la langue recherchée, et convertissez-le ensuite en un nombre si vous en avez vraiment besoin. Ce n'est cependant pas incrémental.

Ou avoir chacun des fils "réserver" Mille (ou millions, ou milliards) d’identifiants de transaction et distribuez-les un à un, puis «réserve». le prochain groupe quand il est à court. Toujours pas vraiment incrémental.

Answer 6

Je fais partie de la foule de GUID, mais si cela n’est pas possible, pourriez-vous envisager d’utiliser db4o ou SQL Lite sur une base lourde base de données?

Answer 7

Si chaque client peut garder la trace de son propre "identifiant suivant", vous pouvez parler à un serveur sentral et obtenir une plage d'identifiants, peut-être un millier à la fois. Lorsqu'un client n'a plus d'identifiant, il devra à nouveau parler au serveur.

Cela donnerait à votre système une source centrale d'identifiants tout en évitant d'avoir à parler à la base de données pour chaque identifiant.