Les commentaires des utilisateurs sous chaque sujet sont assemblés et écrits dans Redis. Chaque sujet aura un topicId, et chaque commentaire sera associé au topicId. Les données brutes sont. comme suit : (Apprentissage recommandé : Tutoriel vidéo Redis)
{ topicId: 'xxxxxxxx', comments: [ { username: 'niuniu', createDate: 1447747334791, content: '在Redis中分页', commentId: 'xxxxxxx', reply: [ { content: 'yyyyyy' username: 'niuniu' }, ... ] }, ... ]}
Après avoir interrogé les données de commentaire de MySQL, les avoir assemblées et enregistrées dans Redis, vous pouvez obtenir l'assembly de Redis à chaque fois Bonnes données de commentaires, comme le montre le modèle de données ci-dessus, les données sont toutes des données de valeur clé et elles doivent être stockées à l'aide de hachage. Cependant, chaque fois que les données de commentaires sont récupérées, elles doivent être paginées et triées. par le champ createDate. Le hachage doit être La pagination et le tri ne sont pas possibles.
Ensuite, examinons un par un les types de données pris en charge par Redis :
1 String : principalement utilisé pour stocker des chaînes, ne prend évidemment pas en charge la pagination. et le tri.
2. Hash : principalement utilisé pour stocker des données clé-valeur. Le modèle de commentaire est constitué de toutes les données clé-valeur, donc Hash sera sans aucun doute utilisé ici.
3. Liste : Principalement utilisé pour stocker une liste. Chaque élément de la liste est enregistré dans l'ordre dans lequel les éléments sont insérés. Si nous trions les modèles de commentaires par date de création puis les insérons dans la Liste, il semble que le tri puisse être effectué, et la pagination peut également être effectuée en utilisant la commande start stop de la touche LRANGE dans Liste.
Eh bien, ici, la liste semble répondre à nos exigences de pagination et de tri, mais les commentaires seront toujours supprimés, donc les données dans Redis doivent être mises à jour si chaque fois qu'un commentaire est supprimé, les données. dans Redis sera supprimé. Réécrire toutes les données une fois n'est évidemment pas assez élégant et l'efficacité sera considérablement réduite. Ce sera sans doute mieux si les données spécifiées peuvent être supprimées. Les deux seules instructions de la liste qui impliquent la suppression de données sont LPOP. et RPOP, mais LPOP et RPOP Seules les données en tête et en queue de la liste peuvent être supprimées, et les données à la position spécifiée ne peuvent pas être supprimées (Remarque : il existe en fait une commande LREM qui peut être supprimée, mais elle l'est. très gênant). De plus, lorsqu'il y a un accès simultané élevé à l'interface, cette liste peut être étendue indéfiniment, et il y aura beaucoup de duplication dans les données, ce qui affectera les activités normales, donc la liste n'est pas adaptée.
4. Set : stocke principalement les ensembles non commandés, non commandés ! exclure.
5. SortedSet : stocke principalement les ensembles ordonnés. L'instruction d'ajout d'élément de SortedSet, le membre de score clé ZADD [[score, member]…] liera un score de valeur pour le tri à chaque membre d'élément ajouté, SortedSet triera les éléments. en fonction de la taille de la valeur du score, vous pouvez utiliser ici createDate comme score pour le tri.
La commande ZREVRANGE key start stop dans SortedSet peut renvoyer les membres dans la plage spécifiée, qui peuvent être utilisés pour la pagination. La commande ZREM key member dans SortedSet peut supprimer le membre spécifié en fonction de la clé, qui peut satisfaire aux exigences de suppression. Comme demandé par les commentaires, SortedSet est le plus approprié ici (complexité temporelle O(log(N))).
Ainsi, les types de données qui doivent être utilisés sont SortSet et Hash. SortSet est utilisé pour le tri de pagination, et Hash est utilisé pour stocker des données de paire clé-valeur spécifiques. Dans la structure SortSet, le topicId de chaque sujet est utilisé comme clé de l'ensemble, et le createDate et le commentId des commentaires associés au sujet sont utilisés respectivement comme score et membre de l'ensemble. L'ordre du commentId est organisé. en fonction de la taille du createDate.
Lorsque vous devez interroger les commentaires sur une certaine page d'un certain sujet, vous pouvez utiliser le topic topicId du sujet via la commande zrevrange topicId (page-1)×10 (page-1)×10 +perPage, afin que vous puissiez connaître les commentaires d'un certain sujet. Le commitId de tous les commentaires par ordre chronologique sur une page sous un sujet. page est le numéro de page de la page de requête et perPage est le nombre d'éléments affichés sur chaque page.
Après avoir trouvé le commentId de tous les commentaires, vous pouvez utiliser ces commentIds comme clés pour interroger le contenu correspondant au commentaire dans la structure de hachage.
De cette façon, les deux structures SortSet et Hash sont utilisées pour atteindre l'objectif de pagination et de tri dans Redis.
Bien entendu, vous pouvez également utiliser directement le type SrotedSet au lieu du type Hash et stocker les commentaires directement dans le membre.
Mais pourquoi mettre des commentaires et trier selon différents types ? L'avantage est que vous pouvez définir différents types de tri pour les commentaires, tels que l'ordre positif et négatif par temps, l'ordre positif et négatif par likes, l'ordre positif et négatif par nombre de vues, etc. De cette façon, il vous suffit de conserver différents tris SrotedSet, et il n'est pas nécessaire de conserver le contenu de plusieurs ensembles de commentaires.
Ce qui précède est le contenu détaillé de. pour plus d'informations, suivez d'autres articles connexes sur le site Web de PHP en chinois!