Allouer atomiquement le proxy le moins utilisé dans Redis

Utilisez un ensemble trié et un court script Lua pour choisir et incrémenter le compteur d'allocations d'un proxy entre les workers.

Quand plusieurs workers partagent un pool via Redis, un ensemble trié peut appliquer une politique simple : choisir le proxy éligible ayant le moins d'allocations enregistrées. Stockez l'identifiant du proxy comme membre et son compteur d'allocations comme score.

Pour un pool servant des requêtes publiques autorisées, la liste de proxies gratuits peut fournir des candidats de point de terminaison à évaluer selon les règles d'éligibilité de ce pool. Initialisez les membres éligibles avec un compteur de départ convenu. Faites ensuite de la sélection et de l'incrément une seule opération côté serveur :

local chosen = redis.call('ZRANGE', KEYS[1], 0, 0)[1]
if not chosen then
    return nil
end

redis.call('ZINCRBY', KEYS[1], 1, chosen)
return chosen

Passez la clé de l'ensemble trié comme unique argument de clé du script via l'interface EVAL de votre client Redis. Un pool vide produit un résultat nul que l'application doit gérer sans émettre de requête.

Pourquoi combiner les deux commandes ?

Des lectures et des incréments séparés laissent deux workers observer le même minimum avant que l'un ou l'autre ne le mette à jour. Redis exécute un script Lua de façon atomique, donc un autre worker ne peut pas insérer une sélection entre la lecture et l'incrément de ce script. Gardez le script court, car son exécution bloque les autres travaux Redis.

ZRANGE renvoie le score le plus bas en premier ; les scores égaux sont départagés par l'ordre des membres, pas au hasard. ZINCRBY augmente d'un le score du membre choisi pour l'allocation suivante.

Définir ce que signifie le score

Ceci compte les allocations, y compris une allocation dont la requête réseau échoue ensuite. Il ne mesure ni la latence, ni les requêtes réussies, ni le travail en cours. Choisir à répétition l'unique membre éligible reste possible ; le script ne le réserve pas exclusivement.

Maintenez l'éligibilité avec les règles de santé et de politique du pool. Si vous retirez un membre puis le restaurez, décidez si son compteur historique doit être conservé. Démarrer un proxy restauré à zéro peut concentrer les allocations sur lui pendant qu'il rattrape.

Une politique de moindre concurrence nécessite un autre cycle de vie, incluant l'achèvement et le traitement des tâches abandonnées. N'interprétez pas ce compteur cumulatif comme ce cycle de vie.

Articles similaires