Comment utiliser Redis pour la fonction de mise en cache d'inventaire planifiée

1. Contexte commercial

J'ai décidé de comparer cette question aux questions de la copie d'examen pour éviter d'introduire le contexte des projets de notre entreprise. Quant aux détails de l'entreprise, vous n'avez pas besoin d'y prêter attention ~ regardez simplement le titre :

Supposons que vous soyez le meilleur collectionneur d'un certain pays et que vous ayez entre vos mains divers trésors de valeur consécutive. Un jour, vous aurez peut-être l’impression que votre collection devient ennuyeuse et déciderez de vendre ces objets de valeur contre de l’argent.

Mais il est trop bas pour vendre ces précieux trésors au marché aux légumes. À l'ère « Internet + », nous devons bien sûr utiliser des méthodes de vente différentes : il y a un immeuble de 300 chambres (numérotées de 001 à 300) à votre nom, et il y a un coffre-fort verrouillé par mot de passe dans chaque chambre. (du 1er décembre au 31 décembre), vous sélectionnerez 300 des meilleurs « trésors supérieurs » (également appelés trésors de classe A) et les mettrez dans les coffres-forts de ces 300 pièces. Les trésors à placer dans la pièce ont déjà été décidés. . Toute personne souhaitant acheter des trésors doit effectuer une réservation en ligne au moins un jour à l'avance, puis utiliser le code de réservation pour ouvrir le coffre-fort et récupérer la marchandise. Les trésors non réservés seront repris par vos soins et ne seront plus vendus.

Pour réaliser un tel système de réservation en ligne, son interface frontale ressemblera probablement à ceci :

Il y a trois contrôles à remplir dans l'image ci-dessus. Après avoir cliqué, une boîte de sélection apparaîtra. Le problème maintenant est qu’il n’y a qu’un seul trésor dans une chambre et qu’il ne peut pas être réservé deux fois. Une fois que l'acheteur a sélectionné le type de trésor et le numéro de chambre, il est recommandé de fournir des informations rapides dans la zone de sélection de la date lorsqu'il sélectionne la date de réservation. Par exemple, la chambre n° 051 a été réservée le 3 décembre et maintenant un autre utilisateur a sélectionné la chambre n° 051. Lorsque la boîte de sélection de date apparaît, la date du 3 décembre doit être définie comme non sélectionnable. Comme indiqué ci-dessous (le 3 décembre est affiché comme "manquant") :

Alors, comment un système d'inventaire aussi simple peut-il être stocké dans Redis ?

2. Solution de gestion d'inventaire (Redis)

Notre idée initiale est que notre inventaire peut être considéré comme un immense tableau tridimensionnel, où la première dimension représente le type de trésor, la deuxième dimension représente le numéro de la pièce et la troisième. La dimension représente la date de réservation. Redis propose cinq types de stockage : chaîne, hachage, liste, ensemble et ensemble trié. Nous pouvons utiliser le type Hash pour stocker des données dans le scénario actuel car il peut répondre à nos besoins, et le type Set est également une option réalisable.

La clé de Redis est définie sur le type de trésor + le numéro de pièce (par exemple, A:205, A représente le meilleur trésor, 205 est le numéro de pièce), la valeur de Redis est le type de hachage et la clé de hachage est le date (par exemple, 05/12/2016), hachage La valeur est vraie ou fausse, indiquant qu'elle a été réservée ou non. Représenté dans un schéma comme suit :

Si la salle A catégorie 158 a été réservée le 8 décembre, elle sera stockée sous le nom

Redis Value —— table de hachage ['2016-12-08'=&gt ; 1]

1 2 3

Redis Key —— A:158Redis Key —— A:158   Redis Value —— hash table ['2016-12-08' => 1]

🎜🎜🎜

3. Solution avancée de gestion des scénarios et des stocks

Le lancement des meilleurs trésors de classe A a été chaleureusement accueilli et un grand nombre de commandes ont été passées peu de temps après son lancement. De nombreuses personnes de la classe moyenne sont intéressées par la collection, mais les prix élevés les rebutent souvent. Ainsi, vous choisissez des trésors de type B dans votre collection. Ils sont légèrement inférieurs aux trésors de type A, mais le prix est plus raisonnable, et on les appelle aussi « excellent trésor ».

Comme il y a plus de trésors dans le type B que dans le type A, vous envisagez de changer la façon de jouer Dans ces 300 pièces, mettez un coffre-fort dans chaque pièce. dans une pièce sur deux. Toutes les heures, un trésor de classe B sera mis dans les boîtes de chacune des 300 pièces. Les trésors non réservés seront repris après cette heure et remplacés par des trésors pour l'heure suivante. Après que l'acheteur ait effectué sa réservation, il récupérera le trésor selon les horaires prévus. Pour les trésors de catégorie B, votre système de réservation aura une option supplémentaire, qui est l'heure de prise en charge. Comme indiqué ci-dessous :

Maintenant, comme il existe une autre condition prédéterminée (l'heure de ramassage), lorsque vous stockez l'inventaire, pensez-y de manière approximative, L'inventaire est en réalité un vaste tableau à quatre dimensions. Cette phrase peut être réécrite comme suit : Les informations en quatre dimensions incluent le type de trésor, le numéro de chambre, la date de réservation et l'heure de prise en charge. Comment stocker ce genre de trésor dans Redis ?

En fait, si vous y réfléchissez bien, lorsque vous stockez des trésors de classe A de qualité supérieure, notre stockage dans Redis est un gaspillage de dimensions

En fait, nous seulement. used Une hashValue est utilisée pour stocker le statut prédéterminé, ce qui entraîne un gaspillage des informations dans cette dimension. Considérant que l'heure de prise en charge est toute l'heure, soit 0 à 1 heure, 1 à 2 heures,..., 23 à 24 heures, soit un total de 24 situations tout au long de la journée, nous pouvons donc complètement utiliser des entiers binaires pour représenter le temps des éléments réservés. Par exemple, 1 signifie 0 à 1 point, 2 signifie 1 à 2 points, 4 signifie 2 à 3 points,...,

23 à 24 points peuvent être calculés en utilisant 2 à la puissance 23 (8388608) express. Pour réserver plusieurs périodes horaires, il vous suffit d'effectuer une opération OU logique sur les valeurs.

De cette façon, notre structure Redis devient comme ceci :

Par exemple, salle au trésor de classe B 103, réservée en décembre de 8h à 00h les 5 et 6, stocké dans redis sous le nom

1 # 🎜🎜#2 3

Clé Redis ——B:103 # 🎜🎜# # 🎜🎜#Redis Key  —— B:103   Redis Value —— hash table ['2016-12-05' => 3840, '2016-12-06' => 3840]Redis Value —— table de hachage ['2016-12-05' => code>'06/12/2016' => 3840]

Pour les trésors de catégorie B, lorsque vous effectuez de nouvelles réservations, vous devez d'abord retirer la valeur de hachage d'origine, effectuer une opération OU logique avec la nouvelle heure de prise en charge prévue, puis réécrire le résultat dans Redis, contrairement à la catégorie A. Tout comme les trésors , appelez directement hSet pour définir la valeur de hachage ; lors de l'annulation de la réservation, veillez à retirer d'abord la valeur de hachage d'origine, à déduire la période de temps à annuler de la valeur de hachage (opération OR exclusive + ET logique), puis à ajouter le restant L'heure de prise en charge prévue est réécrite dans Redis et hDel ne peut pas être directement appelé pour la supprimer.

4. Plan avancé de gestion des stocks

Depuis le lancement des trésors de classe B, votre entreprise est devenue beaucoup plus populaire qu'avant. Une nouvelle demande est donc revenue. Il y a maintenant un grand nombre de touristes, d'étudiants et d'autres personnes sans grandes économies qui sont très intéressés par vos trésors. Les gens qui viennent dans cette ville veulent rapporter des souvenirs. Bien que le prix des trésors de type B soit légèrement inférieur à celui du type A, il reste quand même un peu cher pour ces personnes. Vous décidez donc de vendre vos trésors les plus abordables (trésors de catégorie C).

Parmi ces 300 pièces, les trésors de type C stockent le plus grand nombre, vous ajoutez donc 100 coffres au trésor spécifiquement pour stocker les trésors de type C dans chaque pièce. Ces 100 coffres aux trésors sont numérotés n°1, n°2,..., n°100. De même, à chaque heure de la journée, vous placerez un trésor de type C dans les 100 coffres au trésor de chacune de ces 300 pièces (ce qui signifie que l'ensemble du bâtiment mettra à jour 30 000 trésors de type C toutes les heures). Si personne ne fait de réservation, le trésor sera remplacé dans l'heure suivante. Enfin, les besoins de chacun peuvent être satisfaits.

Pour les trésors de type C, votre interface de réservation ressemblera à ceci :

Nous avons ajouté une autre condition de réservation. Nous sommes actuellement confrontés au problème du stockage des stocks. Comme d'habitude, cet inventaire est en fait un vaste tableau à cinq dimensions. Le type de trésor, le numéro de chambre, la date de réservation, l'heure de ramassage et le numéro du coffre au trésor occupent chacun une dimension. Nous avons déjà utilisé toutes les capacités de Redis. Que devons-nous faire maintenant pour stocker les données ?

Cette fois, le stockage de l'inventaire Redis doit être combiné avec les caractéristiques de l'entreprise. Tout d'abord, les deux dimensions du numéro du coffre au trésor et de l'heure de ramassage n'ont pas trop de plages de valeurs. Il n'y a que 100 numéros de coffre au trésor, il suffit de changer la valeur de hachage en un tableau d'une longueur de 100, et chaque position du tableau. contient INT. Le temps de ramassage indiqué par le type est suffisant. Cependant, la valeur de hachage ne peut être qu'une chaîne... Nous devons donc effectuer une opération de sérialisation du tableau, puis le désérialiser lors de la lecture. Heureusement, la longueur n'est que de 100, donc l'efficacité de la sérialisation ne deviendra pas le goulot d'étranglement du système.

Le mode de stockage est le suivant : Les 23 et 24 décembre, parmi les trésors de type C de la salle 258, les coffres aux trésors numérotés 97 et 99 ont été réservés entre 11h et 13h

Redis Value —— 23'=> '[97 => 6144, 99 => 6144]', ' 2016-12-24'=> '[97 => 6144, 99 => 6144]'] code>

1 2 3

Redis Key —— C:258Redis Key —— C:258   Redis Value —— hash table ['2016-12-23' => '[97 => 6144, 99 => 6144]', '2016-12-24' => '[97 => 6144, 99 => 6144]' ]

🎜🎜🎜

Parmi eux, 6144 est exprimé en binaire sous la forme "110000000000", et la valeur de hachage est la chaîne après sérialisation du tableau. Le format json peut être utilisé dans des projets réels. D'accord, Redis dispose désormais de stockage pour trois types de trésors.

Pour les trésors de classe C, lorsque l'utilisateur annule une réservation ou ajoute une nouvelle réservation, hSet et hDel ne peuvent pas être simplement appelés pour écraser les paramètres et les suppressions. Sortez la situation pré-commandée et effectuez une petite opération avec l'heure de prise en charge pré-commandée.

5. Optimisation du stockage

L'inventaire est théoriquement un tableau multidimensionnel Le travail principal que nous effectuons est de savoir comment stocker raisonnablement chaque dimension et faciliter son ajout, sa suppression. et les opérations de requête. Du point de vue de l'économie de mémoire, lorsque personne n'a fait de réservation au début, Redis peut être complètement vide pour les trésors de classe A, la valeur de hachage est égale à false et il n'y a aucune clé redis ou clé de hachage correspondante, etc. . Efficace.

De plus, combiner le type de trésor et le numéro de pièce pour créer une clé redis entraînera un plus grand nombre de clés liées à l'inventaire du trésor dans redis Afin de faciliter la gestion unifiée de ces clés, nous pouvons ajouter un autre redis Le cache est spécialement utilisé pour stocker toutes les valeurs de clé redis liées à l'inventaire du trésor, comme le montre la figure ci-dessous. Il convient de noter que dans ce cas, l'utilisation du type de données set peut répondre aux exigences, au lieu d'utiliser le type de données hash, car la complexité de l'ajout, de la suppression, de la modification et de l'interrogation du type de données set est O(1). Il stocke toutes les valeurs de clé d'inventaire qui existent déjà dans Redis.

L'un des avantages de cette procédure est que si un jour nous rencontrons des circonstances particulières et devons vider tous les caches liés à l'inventaire, nous pouvons rapidement récupérer facilement toutes les clés d'inventaire et supprimez-les. Un autre avantage est que cela nous donne des idées pour une expansion continue... Imaginez que la situation la plus compliquée actuellement soit celle des trésors de type C, avec un total de 5 dimensions. Supposons qu'à l'avenir vous n'utilisiez plus 300 pièces dans un bâtiment pour vendre des trésors, mais plusieurs bâtiments, les utilisateurs devront alors ajouter une autre dimension lors de la passation de commandes : le numéro du bâtiment. Lorsque nous sommes confrontés à cette situation, nous pouvons réduire complètement l'inventaire supplémentaire des clés pour créer des numéros à utiliser, garantissant ainsi l'évolutivité dans des situations plus complexes qui peuvent survenir.

Après cette extension, chaque fois que vous ajoutez un nouvel enregistrement de réservation, vous devez faire attention pour détecter si la valeur de clé redis correspondante existe déjà dans la collection de clés d'inventaire. Si elle n'existe pas, vous en avez besoin. pour ajouter la valeur de la clé redis à l'inventaire dans la collection de clés. L'opération de suppression est similaire.

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!