Comment générer des identifiants uniques aléatoires dans un environnement multi-processus et multi-thread?

Question

Chaque solution que je propose n'est pas une sauvegarde de thread.

def uuid(cls,db): 
    u = hexlify(os.urandom(8)).decode('ascii') 
    db.execute('SELECT sid FROM sessions WHERE sid=?',(u,)) 
    if db.fetch(): u=cls.uuid(db) 
    else: db.execute('INSERT INTO sessions (sid) VALUES (?)',(u,)) 
    return u 

Answer 1

Votre algorithme est OK (thread sûr dans la mesure où votre module DB API est sûr) et est probablement la meilleure voie à suivre. Il ne vous donnera jamais de doublon (en supposant que vous ayez une clé PRIMARY ou UNIQUE sur Sid), mais vous avez une chance négligeable d'obtenir l'exception IntegrityError sur INSERT. Mais votre code ne semble pas bon. Il est préférable d'utiliser une boucle avec un nombre limité de tentatives au lieu de récursion (qui, en cas d'une erreur dans le code pourrait devenir infini):

for i in range(MAX_ATTEMPTS): 
    sid = os.urandom(8).decode('hex') 
    db.execute('SELECT COUNT(*) FROM sessions WHERE sid=?', (sid,)) 
    if not db.fetchone()[0]: 
     # You can catch IntegrityError here and continue, but there are reasons 
     # to avoid this. 
     db.execute('INSERT INTO sessions (sid) VALUES (?)', (sid,)) 
     break 
else: 
    raise RuntimeError('Failed to generate unique session ID') 

Vous pouvez augmenter le nombre de caractères lecture aléatoire utilisé pour faire la chance de échouer encore plus petit. base64.urlsafe_b64encode() est votre ami si vous souhaitez raccourcir SID, mais assurez-vous que votre base de données utilise une comparaison sensible à la casse pour cette colonne (VARCHAR de MySQL ne convient pas sauf si vous définissez un classement binaire, mais VARBINARY est OK).

Answer 2

Pas besoin d'appeler la base de données que je pense:

>>> import uuid 

# make a UUID based on the host ID and current time 
>>> uuid.uuid1() 
UUID('a8098c1a-f86e-11da-bd1a-00112444be1e') 

De this page.

Answer 3

Si vous devez absolument vérifier uid contre la base de données et éviter les conditions de course, les transactions d'utilisation:

BEGIN TRANSACTION 
SELECT COUNT(*) FROM sessions WHERE sid=%s 
INSERT INTO sessions (sid,...) VALUES (%s,...) 
COMMIT 

Answer 4

Je commencerais avec un ID de fil unique et (en quelque sorte) concaténer que, avec un compteur de thread local , puis l'alimenter via un algorithme de hachage cryptographique.

Answer 5

Si vous avez besoin de thread pourquoi ne pas vous mettre le générateur de nombres aléatoires une fonction qui utilise un verrou partagé:

import threading 
lock = threading.Lock() 
def get_random_number(lock) 
    with lock: 
     print "This can only be done by one thread at a time" 

Si tous les fils appelant get_random_number utiliser la même instance de verrouillage, alors que l'un d'entre eux au moment peut créer un nombre aléatoire.

Bien sûr, vous avez également créé un goulot d'étranglement dans votre application avec cette solution. Il existe d'autres solutions en fonction de vos besoins telles que la création de blocs d'identifiants uniques puis leur consommation en parallèle.

Answer 6

import os, threading, Queue 

def idmaker(aqueue): 
    while True: 
    u = hexlify(os.urandom(8)).decode('ascii') 
    aqueue.put(u) 

idqueue = Queue.Queue(2) 

t = threading.Thread(target=idmaker, args=(idqueue,)) 
t.daemon = True 
t.start() 

def idgetter(): 
    return idqueue.get() 

file d'attente est souvent la meilleure façon de synchroniser les threads en Python - qui est assez fréquent que lors de la conception d'un système multi-thread votre première pensée devrait être « la meilleure façon que je pourrais le faire avec Queues ». L'idée sous-jacente est de dédier un thread pour entièrement "posséder" une ressource ou un sous-système partagé, et tous les autres threads "worker" accèdent à la ressource uniquement par get et/ou puts sur Files d'attente utilisées par ce thread dédié (Queue est intrinsèquement threadsafe) .

Ici, nous faisons un idqueue avec une longueur de seulement 2 (nous ne voulons pas la génération id pour se déchaîner, en faisant beaucoup de ids au préalable, ce qui gaspille la mémoire et épuise le réservoir d'entropie - pas sûr si 2 est optimal, mais le sweet spot va certainement être un petit entier ;-), donc le thread du générateur d'id va se bloquer en essayant d'ajouter le troisième, et attendre que de l'espace s'ouvre dans la file d'attente. idgetter (qui peut aussi être simplement défini par une affectation de niveau supérieur, idgetter = idqueue.get) trouvera normalement un identifiant déjà là et attendra (et fera de la place pour le prochain!) - sinon, il bloque et attend, se réveillant Dès que le générateur d'ID a placé un nouvel identifiant dans la file d'attente.

Answer 7

N'existe-t-il pas une donnée unique dans chaque fil? Il m'est difficile d'imaginer deux threads avec exactement les mêmes données. Bien que je ne néglige pas la possibilité.

Dans le passé, quand j'ai fait des choses de cette nature, il y a habituellement quelque chose d'unique dans le sujet. Nom d'utilisateur ou nom du client ou quelque chose de cette nature. La solution pour moi était de concaténer le UserName, par exemple, et l'heure actuelle en millisecondes puis hachage cette chaîne et obtenir un condensé hexadécimal du hachage. Cela donne une belle chaîne qui a toujours la même longueur.

Il existe une possibilité très lointaine que deux types différents de John Smith (ou autre) dans deux threads génèrent l'ID dans la même milliseconde. Si cette possibilité rend nerveux, alors la voie de verrouillage mentionnée peut être nécessaire.

Comme déjà mentionné, il existe déjà des routines pour obtenir un GUID. Personnellement, j'aime bien jouer avec les fonctions de hachage. J'ai donc réussi à faire rouler les miennes de la manière indiquée sur les grands systèmes multi-threads. C'est en dernier ressort à vous de décider si vous avez vraiment des threads avec des données en double. Assurez-vous de choisir un bon algorithme de hachage. J'ai utilisé md5 avec succès mais j'ai lu qu'il est possible de générer une collision de hachage avec md5 bien que je ne l'ai jamais fait. Dernièrement, j'ai utilisé sha1.

Answer 8

Je suggère juste une petite modification de la réponse acceptée par Denis:

for i in range(MAX_ATTEMPTS): 
    sid = os.urandom(8).decode('hex') 
    try: 
     db.execute('INSERT INTO sessions (sid) VALUES (?)', (sid,)) 
    except IntegrityError: 
     continue 
    break 
else: 
    raise RuntimeError('Failed to generate unique session ID') 

Nous tenter simplement l'insert sans vérifier explicitement l'ID généré. L'insertion très échouera rarement, donc nous avons le plus souvent seulement à faire l'appel de la base de données, au lieu de deux. Cela permettra d'améliorer l'efficacité en réduisant le nombre d'appels à la base de données, sans compromettre la sécurité des threads (car le moteur de la base de données traitera ce problème efficacement).

Answer 9

mkdtemp doit être thread-safe, simple et sécurisé:

def uuid(): 
    import tempfile,os 
    _tdir = tempfile.mkdtemp(prefix='uuid_') 
    _uuid = os.path.basename(_tdir) 
    os.rmdir(_tdir) 
    return _uuid