La troisième expérience du système de microservices : prendre comme exemple le système de vente flash - cache multiniveau et son mécanisme de mise à jour

22 caches multi-niveaux (côté Baidu)

22.1 Quelle mise en cache utilisez-vous ?

Réponse : mémoire locale + redis

22.2 Comment les balises mémoire sont utilisées et mises à jour

22.3 Quand modifier ce cache de premier niveau (balise mémoire) et le changer en false

Réponse : Lorsque l'inventaire de pré-réduction Redis est égal à 0, cela doit être remplacé par false.

22.4 Cette balise mémoire peut-elle être appelée cache de deuxième niveau ? (j'ai mal répondu)

22.4.1 Marquage de la mémoire et opérations de pré-inventaire Redis, laquelle appartient au cache de premier niveau et laquelle appartient au cache de deuxième niveau

Dans la conception du système de vente flash, le « marquage mémoire » et la « réduction du pré-inventaire Redis » sont des méthodes d'optimisation visant à réduire l'accès à la base de données afin d'améliorer les performances du système. Mais dans la classification hiérarchique des caches, les positions de ces deux-là peuvent s'expliquer comme suit :

1. Marquage mémoire : Cela se produit directement dans la mémoire de l'application et est très rapide. Étant donné que cette opération ne nécessite aucune communication avec un système externe, elle est généralement considérée comme un cache de premier niveau .

2. Inventaire de pré-réduction Redis : Redis est un système de stockage externe en mémoire, et bien qu'il soit très rapide, l'accès à Redis implique des délais de communication réseau par rapport à un fonctionnement directement dans la mémoire de l'application. Par conséquent, du point de vue de la classification hiérarchique du cache, Redis est généralement considéré comme un cache de deuxième niveau .

Donc, en bref, les balises mémoire sont le cache de premier niveau et l'inventaire de pré-réduction Redis est le cache de deuxième niveau.

22.4.2 Quelle est la différence entre le cache de niveau un et celui de niveau deux ?

La différence entre le cache de premier niveau et le cache de deuxième niveau est généralement définie en fonction des caractéristiques ou indicateurs suivants :

1. Lieu de stockage :

   • Cache de niveau 1 : généralement stocké dans le contexte d'une transaction ou d'une session, ce qui signifie qu'il est local et ne concerne qu'une seule session ou thread. Par exemple, dans certains frameworks ORM, le cache de premier niveau est associé à une seule session.
   • Cache de niveau 2 : Généralement global, il est stocké en dehors du processus ou de l'application et peut être partagé par plusieurs sessions ou threads. Par exemple, les systèmes de mise en cache distribués tels que Redis ou Memcached.

2. Cycle de vie :

   • Cache de niveau 1 : le cycle de vie est généralement limité à une seule session ou transaction. Les données du cache peuvent également être effacées à la fin de la session.
   • Cache de deuxième niveau : le cycle de vie s'étend au-delà d'une seule session et est généralement géré en fonction de politiques d'expiration de temps ou de capacité.

3. Partage de données :

   • Cache de niveau 1 : Parce qu'il est local, il n'est pas partagé par plusieurs sessions ou threads.
   • Cache de deuxième niveau : peut être partagé par plusieurs sessions, threads ou même plusieurs instances d'application.

4. Vitesse d'accès :

   • Cache niveau 1 : L'accès est très rapide car il se fait généralement dans la mémoire de l'application.
   • Cache de deuxième niveau : Bien qu'il soit également très rapide, il est relativement lent car il peut impliquer une communication inter-processus ou réseau.

5. Stratégie d'échec :

   • Cache de niveau 1 : expire généralement automatiquement après la fin de la session ou la fin de la transaction.
   • Cache de deuxième niveau : généralement basé sur des stratégies d'invalidation spécifiques, telles que LRU, TTL, etc.

6. Complexité :

   • Cache de niveau 1 : généralement plus simple et géré automatiquement.
   • Cache de deuxième niveau : peut nécessiter plus de configuration et de gestion, en particulier lorsqu'un système de cache distribué est impliqué.

Sur la base des caractéristiques ci-dessus, les développeurs peuvent choisir d'utiliser un cache de premier niveau, un cache de deuxième niveau ou une combinaison des deux en fonction des besoins réels pour optimiser les performances des applications.

22.4.3 Je pense que cela peut être jugé en fonction de la distance logique par rapport au CPU. Par exemple, les balises de mémoire locale ne nécessitent pas de communication réseau, elles sont donc de niveau un. Redis nécessite une communication réseau, elles sont donc de niveau deux. D'un autre point de vue , les données sont d'abord synchronisées avec redis. , puis synchronisées avec la marque mémoire

En effet, c'est un moyen très intuitif de juger du niveau de cache en fonction de la vitesse d'accès aux données et de la distance logique par rapport au CPU. Dans l'architecture informatique, cette classification est souvent utilisée pour décrire les niveaux de cache du processeur (L1, L2, L3, etc.), où les caches les plus proches du cœur du processeur et les plus rapides sont considérés comme des niveaux inférieurs.

Pour la mise en cache au niveau de l'application :

• Cache de niveau 1 : fait généralement référence au cache stocké directement dans le processus applicatif, comme le stockage des objets Java sur le tas JVM. Ce cache est extrêmement rapide d’accès et n’implique aucune communication inter-processus ou réseau.

• Cache de deuxième niveau : caches impliquant une communication inter-processus ou une communication réseau, tels que les systèmes de cache distribué tels que Redis et Memcached. Bien qu'ils soient toujours stockés en mémoire, l'accès est relativement lent en raison de la communication impliquée.

Votre argument est tout à fait valable. Si les données sont d'abord synchronisées avec Redis puis avec les balises en mémoire, alors Redis peut être considéré comme une sorte de « cache frontal » ou de « couche tampon », et les balises dans la mémoire de l'application peuvent être considérées comme plus proches du traitement des données réel et logique métier cache de niveau 1.

Cette stratégie de mise en cache hiérarchique permet aux applications de gérer les situations de forte concurrence avec plus de flexibilité tout en garantissant la cohérence des données et la vitesse de réponse du système.

22.5 Quelle est la différence entre les balises mémoire et le cache Redis ?

Réponse : L'utilisation de balises mémoire élimine le besoin de communication réseau avec l'hôte distant.

23 Mécanisme de cohérence, de mise en cache et de mise à jour MySQL (côté Baidu)

23.1 Si du trafic arrive et reste bloqué à ce point frontière, comment le jugez-vous ? Si deux demandes arrivent simultanément dans le backend lors de la vente flash du 10ème article, est-il possible que les deux demandes soient placées dans votre file d'attente de messages ?

Réponse : C'est possible, car une perte de données peut survenir lors de la redission et le cluster Redis lui-même ne peut garantir qu'une cohérence éventuelle.

23.2 S'il y a un maître et plusieurs esclaves, est-il possible que plusieurs trafics entrent ?

Réponse : Oui, mais cette probabilité est très faible, car la possibilité de plusieurs basculements maître-esclave dans un cluster Redis est très faible.

23.3 À ce moment-là, le frontal lui demandera-t-il d'attendre ?

Réponse : Oui, la file d'attente sera affichée. Le client interrogera en permanence une interface de requête de commande exposée par le backend pour voir si elle existe. Cette interface ajoutera la commande au cache Redis.

23.3.1 Pourquoi le mécanisme de synchronisation entre la base de données et Redis met-il actuellement à jour MySQL d'abord, puis met-il à jour le cache ? N'y a-t-il pas des incohérences ?

Réponse : Pour le moment, le client implique uniquement l'interrogation de l'opération de commande, pas la modification, et seul ce thread de serveur modifiera le cache Redis, vous pouvez donc d'abord mettre à jour MySQL, puis supprimer Redis.

23.4 Que dois-je faire si l'utilisateur annule la commande peu de temps après avoir passé la commande ? Que faire s'il n'y a pas de paiement (Malentendu : (1) Ces deux sont combinés en une seule chose, la restauration des stocks n'est pas mentionnée et la mise à jour du cache à deux niveaux n'est pas mentionnée)

répondre:

Lorsqu'un utilisateur annule une commande peu de temps après avoir passé une commande, ou ne paie pas après avoir passé une commande, le système doit disposer d'un mécanisme de traitement correspondant. Ces mécanismes impliquent généralement la gestion du cycle de vie des commandes, la gestion des stocks, les délais de paiement, etc. Voici quelques façons courantes d’y faire face :

1. Annulation de commande :

   • Annulation de l'inventaire : lorsque l'utilisateur annule la commande, le frontal envoie immédiatement une demande à l'interface spécifiée et le système doit immédiatement annuler la quantité d'inventaire du produit correspondante.
   • Gestion du statut des commandes : Les commandes doivent avoir plusieurs statuts, tels que "Créée", "Payée", "Annulée", etc. Lorsqu'un utilisateur annule une commande, le système doit changer le statut de la commande en « Annulée ».
   • Restauration de l'inventaire et mise à jour du cache : Cet inventaire sera restauré dans la table des produits de MySQL, puis la commande correspondante dans Redis sera supprimée. Dans le même temps, le cache des informations d'inventaire dans Redis sera supprimé, puis si le produit sur le serveur d'entreprise sera le cache épuisé mis à jour sur false

2. Commandes impayées :

   • Mécanisme de délai de paiement : définissez un délai de paiement pour la commande (par exemple, 15 ou 30 minutes). Si l'utilisateur n'effectue pas le paiement dans ce délai, le système change automatiquement le statut de la commande en « Annulé » et annule l'inventaire.
   • Rappel de délai d'attente : lorsqu'une commande est sur le point d'atteindre le délai d'expiration, les utilisateurs peuvent être rappelés de payer par SMS, e-mail ou notification dans l'application.
   • Vérifications périodiques : le backend peut utiliser des tâches planifiées ou d'autres mécanismes pour vérifier régulièrement les commandes impayées et gérer les commandes avec délai d'attente en fonction de leur heure de création.
   • Restauration des stocks et mise à jour du cache : (la logique de base est la même que la logique correspondante d'annulation de commande)

En bref, en cas d’annulation de commande ou de non-paiement des utilisateurs, le système doit disposer d’un ensemble complet de politiques et de procédures pour garantir que les intérêts du commerçant et l’expérience d’achat normale des autres utilisateurs ne sont pas affectés.

23.5 Comment mettre à jour votre cache de premier niveau ? Cela implique-t-il la mise à jour des balises mémoire de plusieurs machines à mémoire locale ?

répondre:

Le cache de premier niveau fait généralement référence au cache mémoire local du serveur d'entreprise, tel que ConcurrentHashMap en Java ou d'autres outils de mise en cache locale. Les méthodes et stratégies de mise à jour du cache de premier niveau sont les suivantes :

• Déclencheur de modification de données : lorsque des données clés (telles que l'inventaire) changent, nous devons mettre à jour en même temps les données pertinentes dans le cache de premier niveau.
• Problème de synchronisation multi-machines : Dans un environnement distribué, il peut y avoir plusieurs instances de serveur d'entreprise, donc lorsque les données du cache de premier niveau sont modifiées dans une instance, nous devons nous assurer que les données du cache des autres instances sont également mises à jour en conséquence. Ceci est généralement implémenté via un middleware de message tel que Kafka, RabbitMQ, etc. Lorsqu'une instance met à jour le cache, elle enverra un message au middleware de message, et d'autres instances mettront à jour leur propre cache de premier niveau après avoir écouté le message.
• Actualisation régulière : certaines données peuvent ne pas changer fréquemment, mais afin de garantir l'actualité et l'exactitude des données, vous pouvez définir une stratégie d'actualisation régulière, telle que le rechargement des données de la base de données ou du cache de deuxième niveau (tel que Redis) à chaque fois. dans un moment.

23.6 Vos mises à jour de cache provoqueront-elles des conflits de concurrence ? Par exemple, le thread client lit et le thread serveur écrit.

répondre:

La question de la concurrence du cache est en effet un point qui mérite attention. Selon le type de cache et la stratégie, la gestion sera différente.

• Cache Redis : Redis est un modèle monothread, qui garantit qu'une seule commande est exécutée à la fois, il n'y aura donc pas de conflits de concurrence. Cependant, dans les applications distribuées, plusieurs clients envoyant des commandes à Redis en même temps peuvent entraîner la lecture d'anciennes données. Pour éviter cette situation, vous pouvez utiliser la fonctionnalité de transaction de Redis ou le verrouillage optimiste pour garantir la cohérence des données.

• Cache mémoire local : dans un environnement multithread, le cache local peut présenter des problèmes de concurrence. Par exemple, pendant qu'un thread met à jour les données mises en cache, un autre thread peut lire ces données. Pour résoudre ce problème, vous pouvez utiliser des outils de concurrence tels que ConcurrentHashMap ou ReadWriteLock en Java. ConcurrentHashMap permet à plusieurs threads de lecture de se dérouler simultanément, mais les opérations d'écriture sont verrouillées pour garantir qu'un seul thread peut écrire à la fois. ReadWriteLock fournit également des fonctionnalités similaires, mais offre un contrôle plus précis.

En résumé, assurer la sécurité simultanée du cache est essentiel, et il est nécessaire de choisir les outils et les stratégies appropriés en fonction de la situation réelle pour y parvenir.