Je commence à utiliser Redis et je rencontre le problème suivant. P>
J'ai un tas d'objets, disons D'autres clients utilisent la valeur de Problème est, un client pourrait En d'autres termes, je cherche un moyen de faire l'équivalent d'ajouter des lignes en SQL et d'avoir un index auto-incrémenté pour travailler avec. P>
Je ne peux pas utiliser les index de la liste, car je dois souvent supprimer des parties de la liste, ce qui le rend invalide. P>
Ma situation en réalité est un peu plus complexe, c'est une version plus simple. P>
La meilleure solution que j'ai proposée et ce que je prévois de faire est d'utiliser Mais c'est un cas d'usage aussi courant dans Redis que je suis surpris qu'il n'y ait pas de réponse existante pour cela, alors je suis inquiet Je fais quelque chose de mal. P> messages code> dans mon système. Chaque fois qu'un nouveau
utilisateur code> se connecte, je passe les suivants: p>
augmenter code> une variable globale, disons
g_message_id code> et enregistrez la valeur de retour de l'augmentation (la valeur actuelle de
g_message_id code>). p> li>
lpush code> le nouveau message (y compris le
ID code> et le message actuel) dans une liste. p> li>
ol>
g_message_id code> pour vérifier s'il y a de nouveaux messages à obtenir. p>
croiss code> le
g_message_id code>, mais pas le temps de
lpush code> le message avant que un autre client essaie de le lire, en supposant qu'il y a un nouveau message. P>
watch code> et
transactions code> pour essayer d'effectuer un "autoIncrerement" moi-même. P >
3 Réponses :
Si je lis correctement, vous utilisez g_message_id strong> sous forme de séquence d'identification et comme un drapeau pour indiquer que de nouveaux message (s) sont disponibles. Une option est de la diviser en deux variables: une pour attribuer des identificateurs de message et l'autre comme un drapeau à signaler aux clients qu'un nouveau message est disponible. Les clients peuvent alors comparer la valeur actuelle / antérieure de alternatif possible, si vos clients peuvent le prendre en charge forts>: Vous voudrez peut-être examiner dans la
Redis Publier / S'abonner Commandes, E.G. Les cités pourraient publier des notifications de nouveaux messages et abonner à un ou plusieurs canaux de message pour recevoir des notifications. Vous pouvez conserver le g_msg_queue strud> pour maintenir un arriéré de N messages pour les nouveaux clients, si nécessaire. P>
Intéressant. Cela conduit à un problème connexe: lorsqu'un client interroge le serveur avec sa copie de "g_new_message_flag", comment le serveur récupère-t-il les messages de la liste? Il peut simplement retirer un certain nombre de messages basés sur la différence entre le drapeau "g_new_message_flag" et le drapeau des utilisateurs ", mais si de nouveaux messages sont ajoutés entre l'opération de soustraction et le PLPOP, le mauvais nombre de messages sera affiché.
Je vois ce que vous voulez dire - si un client est censé faire pop tous les messages disponibles i> et zéro sortir de la liste, c'est plus délicat. Je vais mettre à jour ma réponse avec quelques pensées.
En fait, je ne veux pas que le client supprime les messages, obtenez simplement les derniers messages. J'ai plusieurs clients différents avec (éventuellement) différentes valeurs de g_msg_queue, et chacune doit lire les derniers messages arrivés. La liste n'est supprimée que périodiquement par un processus d'arrière-plan (disons une fois par jour).
Ahh je t'ai vu mentionner PLOP et supposé qu'ils retiraient les messages du g_msg_queue (LPOP supprime l'entrée la plus à gauche de la liste et le renvoie)
Avez-vous vraiment besoin d'identifiants séquentiels uniques? Vous pouvez utiliser UUIDS pour obtenir uniques et horodatage pour vérifier les nouveaux messages. Si vous gardez les horloges sur tous vos serveurs correctement synchronisés, les horodatages avec une deuxième résolution doivent bien fonctionner. P>
Si vous avez vraiment besoin d'identifiants séquentiels uniques, vous devrez probablement configurer un Server de ticket de style Flickr pour gérer correctement la liste centrale des identifiants. Cela permettrait essentiellement de déplacer votre g_message_id code> dans une base de données avec une manipulation correcte de transaction. P>
Résolu mon problème .. uuid convient parfaitement à mon cas
Vous pouvez simuler automatiquement une clé unique pour de nouvelles lignes. Utilisez simplement DBSIZE pour obtenir le nombre actuel de lignes, puis dans votre code, incrémentez ce nombre par 1 et utilisez ce numéro comme clé de la nouvelle ligne. C'est simple et atomique. P>