Il y a des produits populaires sur la page d'accueil du centre commercial en ligne, donc le taux de clics de ces produits est très élevé. Lorsqu'un utilisateur clique sur un produit populaire, il doit entrer la page d'informations détaillée du produit, tout comme sur Taobao. Ensuite, chaque fois que vous cliquez, vous devez vous rendre à l'arrière-plan pour interroger les informations détaillées du produit, et vous enverrez l'instruction SQL correspondante. Chaque fois que vous actualisez la page détaillée, vous enverrez également l'instruction SQL. De cette façon, la performance sera certainement grandement affectée. Ensuite, l'utilisation du cache secondaire d'Hibernate peut résoudre ce problème.
Certaines personnes peuvent penser que nous pouvons utiliser la redirection. De cette façon, lorsque l'utilisateur visite pour la première fois, il peut trouver les informations et les mettre dans la session. À l'avenir, chaque fois que l'utilisateur actualise, il peut aller à la session, il n'est donc pas nécessaire de s'interroger dans la base de données. Cela a du sens, mais cela ne peut pas résoudre le problème ci-dessus, car ce que nous voulons résoudre, c'est que plusieurs utilisateurs accéderont au même produit et cliqueront sur le même produit. La redirection ne peut que garantir que le même utilisateur cliquera ou actualisera. Mais le cache secondaire peut résoudre ces problèmes.
Expliquons d'abord la technologie de mise en cache secondaire basée sur Hibernate4.3 en détail, puis créez une configuration spécifique pour ce projet.
1. Hibernate4.3 Configuration de base du cache de niveau 2
Contrairement à HiberNate3, le package central de HiberNate4.3 n'a pas de classes liées au cache. Si nous voulons utiliser un cache secondaire, nous devons ajouter le package JAR mis en cache. À partir du téléchargement officiel de Hibernate-Release-4.3.11.Final, il y a des packages JAR requis pour le cache secondaire, qui doit d'abord être ajouté au projet. comme suit:
Ensuite, nous configurons la configuration secondaire liée au cache dans hibernate.cfg.xml:
<Hibernate-Configuration> <session-factory> <propriété name = "dialect"> org.hibernate.dialect.mysqldialect </ propriété> <propriété name = "show_sql"> true </ propriété> <! - Configurer le fournisseur de cache secondaire, note qu'il ne s'agit pas d'un package JAR cache -> <propriété name = "hibernate.cache.region.factory_class"> org.hibernate.cache.ehcache.ehcacheRegionfactory </ propriété> <mapping /> <mapping /> <mapping /> <! - Quelles classes de configuration de la cache de support? Cela affiche principalement des produits populaires sur la page d'accueil, de sorte que la classe de produits prend en charge la mise en cache -> <class-cache usage = "read only" /> </ session-factory> </ hibernate-configuration>
Ensuite, nous ouvrons le serveur Tomcat, puis visions la page d'accueil, cliquez sur des produits populaires et aucune instruction SQL n'est envoyée en arrière-plan. Vous vous demandez peut-être, le cache de deuxième niveau est-il aussi simple? Configurez simplement ces deux éléments? En fait, la raison pour laquelle le cache de niveau 2 a pris effet jusqu'à présent est qu'il a une configuration par défaut. Il existe un fichier ehcache-failsafe.xml dans le ehcache-core-2.4.3 ci-dessus, qui a déjà une configuration par défaut. Nous l'analyserons en détail plus tard. Analysons d'abord la stratégie de requête d'Hibernate:
2. Stratégie de requête Hibernate4.3
Hibernate prend en charge deux méthodes de requête: la requête de session et la requête HQL.
Il y a session.save () update () delete () get () charte () et d'autres méthodes de la session. Cette méthode ne fonctionne que sur un seul enregistrement, et la valeur par défaut est de prendre en charge le cache de niveau 2 sans aucune configuration. Par conséquent: la configuration en lecture seule est efficace pour la session. Si la lecture seule est configurée dans le cache secondaire en session, les opérations session.update () et delete () échoueront toutes deux. Si vous voulez réussir, vous devez configurer la lecture-écriture. Mais sauver () et get () loss () réussissent.
HQL: Cette méthode est utilisée pour faire fonctionner plusieurs enregistrements par défaut, tels que list () et les méthodes EXECUTEUPDate (). Cette méthode par défaut de la configuration du cache secondaire, y compris la lecture seule, n'est pas valide. HQL's List () requêtes plusieurs enregistrements, interroge directement la base de données et remet les résultats de la requête au cache secondaire, qui facilite l'appel de get () et de charger (). EXECUTEUPDATE ne prend pas en charge la mise en cache secondaire, et il est également directement mis à jour dans la base de données. Hibernate garantira que la base de données et le cache sont synchronisés. Remarque: HQL n'a pas de méthode Save (). Si vous avez besoin d'insérer des données, vous ne pouvez appeler la méthode Session.Save ().
[Remarque]: Le cache de premier niveau (existant par défaut) dans Hibernate est également appelé cache au niveau de la session, non utilisé pour améliorer les performances, mais pour gérer les transactions; Le cache de deuxième niveau est un cache SessionFactory, qui est valide pour toutes les sessions, et son cycle de vie est le même que le SessionFactory (le SessionFactory est un singleton et sera créé au début du projet).
Pour des stratégies de requête spécifiques, examinons l'image suivante:
【Remarque】: Si le texte de l'image est trop petit, vous pouvez faire glisser l'image vers une nouvelle fenêtre pour afficher ~
Ce qui précède est la stratégie de requête de l'hibernate. Continuons à regarder la configuration du cache secondaire.
3. Hibernate 4.3 Configuration avancée de cache de niveau 2
Comme mentionné ci-dessus, la raison pour laquelle nous pouvons utiliser le cache de niveau 2 après la configuration de deux éléments dans hibernate.cfg.xml est dû au fait qu'il y a une configuration par défaut. Jetons un coup d'œil à cette configuration par défaut en premier:
<ehcache xmlns: xsi = "http://www.w3.org/2001/xmlschema-instance" xsi: nonamespaceschemalocation = "../ config / ehcache.xsd"> <! - Si la mémoire de cache déborde, elle sera storée à l'espace dur disk -> <diskstore de cache déborde, il sera storé à l'espace dur disk -> <diskstore de cache déborde, il sera storé à l'espace dur Disk -> <diskstore de cache. path = "java.io.tmpdir" /> <defaultCache maxElementsInMemory = "10000": <! - Le nombre maximum d'objets pris en charge par la mémoire -> eternal = "false": <! - Que l'objet soit définitivement valide, il est recommandé d'être faux, de sorte que les deux paramètres suivants seront valides -> timetoidleConds L'unité est des secondes. Autrement dit, si personne n'utilise cet objet après 60 secondes, il sera détruit à l'avance-> TIMETOLIVESECONDS = "120": <! - Le cycle de vie de l'objet est des secondes -> OverflowTodisk = "True": <! disque -> MemoryStoreevictionPolicy = "LRU": <! - Politique de remplacement des objets -> /> </ehcache>
L'explication pertinente sur la configuration par défaut est déjà dans les commentaires ci-dessus. Nous savons maintenant que c'est précisément à cause de cette configuration par défaut que le cache de deuxième niveau de Hibernate 4.3 peut être exécuté correctement. Maintenant, si nous voulons configurer le cache nous-mêmes, nous devons créer un nouveau fichier ehcache.xml dans le répertoire SRC, puis reconfigurer les éléments de configuration ci-dessus. Ensuite, nous devons tester chaque configuration. Avant les tests, je publierai la situation affichée sur la page d'accueil et ferai un numéro. Expliquons-le plus tard lors des tests:
Ce qui précède fait partie du contenu affiché sur la page d'accueil. Hibernate a trouvé les informations d'affichage de la base de données et elle a été affichée. Nous les numéroterons et il sera plus facile d'analyser lorsque nous testerons le cache plus tard. Commençons à tester les éléments de configuration du cache ci-dessus:
Test 1: Testez le nombre d'objets en mémoire. Modifiez la configuration dans la situation suivante:
<defaultCache maxElementsInMemory = "6" <! - Le paramètre prend en charge uniquement 6 caches -> eternal = "true" overflowtodisk = "false" memorystoreevictionpolicy = "fifo": <! - premier-in, premier-out -> />
Une fois la configuration terminée, nous redémarrons le serveur et ouvrons la page d'accueil. Puisqu'il y a 6 configurés, seuls les 6 derniers enregistrements trouvés dans le cache sont stockés, c'est-à-dire le numéro 3-8. Nous cliquons sur l'un des produits en 3-8 pour entrer la page Détails du produit. Notez que la console en arrière-plan ne publie aucune information de requête, ce qui signifie qu'aucune instruction SQL n'est envoyée. Cependant, lorsque nous cliquons sur le numéro de produit 2, une instruction SQL est envoyée en arrière-plan, c'est-à-dire que la base de données est interrogée. Nous avons reculé et cliqué sur le produit 2, et aucune instruction SQL n'est envoyée, ce qui signifie qu'il a été mis dans le cache, mais le cache ne prend en charge que 6 données. Parce que la stratégie de remplacement des objets configurée est d'abord en premier, de sorte que le numéro 3 dans le cache vient d'être supprimé. Nous avons cliqué 3 pour essayer d'envoyer une instruction SQL. Le test est donc terminé et l'exécution du cache de deuxième niveau est normale.
Test 2: Le cycle de vie de l'objet de test. Modifiez la configuration dans la situation suivante:
<defaultCache maxElementsInMemory = "100" eternal = "false" <! - Seule en correspondant false que le cycle de vie suivant peut être défini -> TIMETOIDLECONDS = "20" TIMETOLIVESECONDS = "40" overflowtodisk = "false" MemoryStoreeVictionPolicy = "fifo" />
Le temps de cache est configuré en 40 secondes, et s'il n'y a pas d'opération en 20 secondes, il sera supprimé. Étant donné que nous avons attribué 100 enregistrements, les chiffres 1 à 8 ci-dessus sont tous dans le cache. Après avoir activé le serveur, nous cliquons sur n'importe qui, par exemple, cliquez sur le numéro 8, et aucune instruction SQL n'est publiée. Normalement, après 20 secondes, cliquez sur le numéro 8 et envoyez une instruction SQL, indiquant que le cycle de vie que nous avons configuré a pris effet. Notez ici que la configuration ne peut pas être trop courte, comme 10 secondes, car Tomcat prendra plusieurs secondes pour commencer. S'il y a moins de configuration, le temps peut avoir été remonté avant les tests ... alors cela ne fonctionnera pas.
Test 3: Testez si le cache secondaire prend en charge le stockage du disque dur.
<defaultCache maxElementsInMemory = "4" eternal = "false" <! - Seulement en définissant false que le cycle de vie suivant peut être défini -> TimeToidleSonds = "100" TIMETOLIVESECONDS = "200" overflowtodisk = "true" <!
Nous définissons le stockage du disque dur de support sur true et configurons la capacité de stockage maximale du cache secondaire à 4. Redémarrez le serveur. Étant donné que le cache secondaire stocke jusqu'à 4 enregistrements, il doit être numéroté 5-8. Cliquez sur 5-8 n'enverra certainement pas d'instructions SQL, mais lorsque nous cliquerons sur 1-4, nous n'enverrons pas d'instructions SQL, car nous avons configuré la prise en charge du stockage du disque dur, Hibernate stockera les résultats de la requête sur le disque dur, afin que nous puissions également obtenir les données directement sans envoyer des instructions SQL.
Test 4: Testez la stratégie de remplacement du cache de niveau 2
<DefaultCache <! - FIFO a été éliminé et ne sera plus utilisé ... LRU: l'algorithme accessible au moins récemment (politique de temps), ignorera la fréquence d'accès, et celle accessible au moment la plus éloignée sera remplacée par LFU: l'algorithme qui a été utilisé le plus récemment (fréquence sera remplacée par l'ordre d'accès, et la fréquence de fréquence), sera remplacée par l'ordre de l'ordre, et la fréquence de fréquence), sera la fréquence, la fréquence) -> maxElementsInMemory = "3" eternal = "false" <! - Ce n'est que lorsqu'il est configuré comme faux peut-il être défini le cycle de vie suivant -> TimeToidleConds = "100" TimeTolivesEconds = "200" OverflowTodisk = "FALTSTOREEVICT
Comme son nom l'indique, LRU et LFU se concentrent respectivement sur la dernière heure d'accès et la fréquence. Prenons l'exemple de LFU. Maintenant, nous définissons le stockage maximal sur 3 enregistrements, c'est-à-dire numéro 6-8. Maintenant, nous accédons au numéro 6 trois fois, numéro 7 deux fois, numéro 8 une fois, et n'émettrons pas les instructions SQL. Nous accédons à nouveau le numéro 7 et publions des instructions SQL. Maintenant, le numéro 7 est dans le cache, le numéro 8 a été supprimé car il a le moins d'accès. Nous pouvons à nouveau cliquer sur le numéro 8 pour le tester, publier l'instruction SQL et le test est réussi. S'il s'agit d'un LRU, le numéro 6 vient d'être supprimé est le numéro 6 car le numéro 6 est le premier accessible.
À ce stade, je crois que tout le monde a maîtrisé l'utilisation du cache secondaire, et le test du cache secondaire se termine ici. Faisons des configurations pour notre projet de centre commercial en ligne.
4. Configuration réelle des projets en ligne des centres commerciaux
Nous configurons le nombre maximum d'enregistrements dans le cache secondaire à 1000, définissons le cycle de vie à 120 secondes et le cycle d'intervalle à 60 secondes. Nous prenons en charge le stockage du disque dur et utilisons la stratégie de remplacement de la priorité de fréquence (LFU), car si le taux de clics utilisateur est élevé, il doit être placé dans le cache secondaire.
<ehcache xmlns: xsi = "http://www.w3.org/2001/xmlschema-instance" xsi: nonamespaceschemalocation = "../ config / ehcache.xsd"> <! - if cache memory <defaultCache maxElementsInMemory = "1000" eternal = "false" TimeToidleSeconds = "60" TIMETOLIVESEconds = "120" overflowtodisk = "true" MemoryStoreevictionPolicy = "lfu" /> </ ehcache>
Eh bien, en combinaison avec le projet de centre commercial en ligne, la configuration et l'utilisation du cache de deuxième niveau de Hibernate 4.3 sont introduites.
Adresse originale: http://blog.csdn.net/eson_15/article/details/51405911
Ce qui précède est tout le contenu de cet article. J'espère que cela sera utile à l'apprentissage de tous et j'espère que tout le monde soutiendra davantage Wulin.com.