Hay productos populares en la página de inicio del centro comercial en línea, por lo que la tasa de clics de estos productos es muy alta. Cuando un usuario hace clic en un producto popular, necesita ingresar la página de información detallada del producto, al igual que en Taobao. Luego, cada vez que haga clic, debe ir a los antecedentes para consultar la información detallada del producto, y enviará la instrucción SQL correspondiente. Cada vez que actualice la página detallada, también enviará la instrucción SQL. De esta manera, el rendimiento definitivamente se verá muy afectado. Luego, usar el caché secundario de Hibernate puede resolver este problema.
Algunas personas pueden pensar que podemos usar la redirección. De esta manera, cuando el usuario visita por primera vez, puede averiguar la información y ponerla en la sesión. En el futuro, cada vez que el usuario se actualiza, puede ir a la sesión, por lo que no es necesario consultar en la base de datos. Esto tiene sentido, pero no puede resolver el problema anterior, porque lo que queremos resolver es que varios usuarios accederán al mismo producto y hacer clic en el mismo producto. La redirección solo puede garantizar que el mismo usuario haga clic o actualice. Pero el caché secundario puede resolver estos problemas.
Primero expliquemos la tecnología de almacenamiento en caché secundario basada en Hibernate4.3 en detalle, y luego hagamos una configuración específica para este proyecto.
1. Hibernate4.3 Nivel 2 Configuración básica de caché
A diferencia de Hibernate3, el paquete central de Hibernate4.3 no tiene clases relacionadas con el caché. Si queremos usar caché secundario, necesitamos agregar el paquete de jares cachedes. Desde la descarga oficial de Hibernate-Lelease-4.3.11.Final, hay paquetes JAR requeridos para la caché secundaria, que primero debe agregarse al proyecto. como sigue:
Luego configuramos la configuración secundaria relacionada con la memoria caché en hibernate.cfg.xml:
<Hibernate-Configuration> <session-Factory> <Property name = "dialect"> org.hibernate.dialect.mysqldialect </property> <propiedad name = "show_sql"> true </property> <!-Configure el proveedor de caché secundario, tenga en cuenta que este no es un paquete de jares en caché-> <Property name = "hibernate.cache.region.factory_class"> org.hibernate.cache.ehcache.ehcacheregionFactory </property> <mapping /> <mapping /> <mapping /> <!- ¿Qué clases para configurar el almacenamiento en caché? Esto muestra principalmente productos populares en la página de inicio, por lo que la clase de productos es compatible con el almacenamiento en caché-> <class-cache use = "read-solo"/> </session-factory> </hibernate-configuration>
Luego abrimos el servidor Tomcat, luego visitamos la página de inicio, hacemos clic en productos populares y no se envían declaraciones SQL en segundo plano. Puede preguntarse, ¿es el caché de segundo nivel que es tan simple? ¿Simplemente configurar estos dos elementos? De hecho, la razón por la cual el caché de nivel 2 ha entrado en vigencia hasta ahora es que tiene una configuración predeterminada. Hay un archivo ehcache-failsafe.xml en el ehcache-core-2.3.3.Jar anterior, que ya tiene una configuración predeterminada. Lo analizaremos en detalle más tarde. Primero analicemos la estrategia de consulta de Hibernate:
2. Estrategia de consulta Hibernate4.3
Hibernate admite dos métodos de consulta: consulta de sesión y consulta HQL.
Hay session.save () update () delete () get () load () y otros métodos en la sesión. Este método solo funciona en un registro, y el valor predeterminado es admitir el caché de nivel 2 sin ninguna configuración. Por lo tanto: la configuración de solo lectura es efectiva para la sesión. Si solo lectura se configura en el caché secundario en la sesión, las operaciones session.update () y delete () fallarán. Si desea tener éxito, debe configurar la lectura-escritura. Pero guardar () y get () load () son exitosos.
HQL: este método se utiliza para operar múltiples registros de forma predeterminada, como los métodos List () y ExecuteUpdate (). Este método predeterminado a la configuración de caché secundaria, incluida la solo lectura, no es válido. La lista de HQL () consulta múltiples registros, consulta directamente la base de datos y entrega los resultados de la consulta al caché secundario, que facilita la llamada de get () y load (). ExecuteUpdate no admite almacenamiento en caché secundario, y también se actualiza directamente a la base de datos. Hibernate asegurará que la base de datos y el caché estén sincronizados. Nota: HQL no tiene un método Save (). Si necesita insertar datos, solo puede llamar al método session.save ().
[Nota]: El caché de primer nivel (existido por defecto) en Hibernate también se llama caché a nivel de sesión, no se usa para mejorar el rendimiento, sino para manejar las transacciones; El caché de segundo nivel es un caché de Factory, que es válido para todas las sesiones, y su ciclo de vida es el mismo que el SessionFactory (el SessionFactory es un singleton y se creará cuando comience el proyecto).
Para estrategias de consulta específicas, veamos la siguiente imagen:
【Nota】: Si el texto de la imagen es demasiado pequeño, puede arrastrar la imagen a una nueva ventana para ver ~
Lo anterior es la estrategia de consulta de Hibernate. Sigamos observando la configuración del caché secundario.
3. Hibernate 4.3 Nivel 2 Configuración avanzada de caché
Como se mencionó anteriormente, la razón por la que podemos usar el caché de nivel 2 después de configurar dos elementos en Hibernate.cfg.xml es porque hay una configuración predeterminada. Echemos un vistazo a esta configuración predeterminada primero:
<ehcache xmlns: xsi = "http://www.w3.org/2001/xmlschema-instance" xsi: nonamespaceschemalatation = "../ config/ehcache.xsd"> <!-Si la memoria de cache se sobrecarga, se almacenará en el espacio de disco duro-> <diskstore Path = "java.io.tmpdir"/> <defaultcache maxelementsInmemory = "10000": <!-El número máximo de objetos admitidos por la memoria-> eternal = "false": <!-si el objeto es permanentemente válido, se recomienda ser falso, por lo que los siguientes dos parámetros serán válidos-> TimetoidleseSeDs = "60": <60 ": <! segundos. Es decir, si nadie usa este objeto después de 60 segundos, se destruirá por adelantado-> timetoliveeConds = "120": <!-El ciclo de vida del objeto es segundos-> OverflowTodisk = "verdadero": <!-Si el desbordamiento del disco duro es compatible con el objeto Hard en el que se recomienda el HARTA HARTO-MAXELEMENTUNDISH = "10000000": <: <!-El número máximo del objeto de Hard en el Hard TaTo es compatible con el Hard TaTe en el Hard TaTe en el HARTO DEL HARTO DEL HARTO. MemoryStoreEvictionPolicy = "Lru": <!-Política de reemplazo de objetos-> /> < /ehcache>
La explicación relevante sobre la configuración predeterminada ya está en los comentarios anteriores. Ahora sabemos que se debe precisamente a esta configuración predeterminada que el caché de segundo nivel de Hibernate 4.3 se puede ejecutar correctamente. Ahora, si queremos configurar el caché nosotros mismos, necesitamos crear un nuevo archivo ehcache.xml en el directorio SRC y luego reconfigurar los elementos de configuración anteriores. A continuación, necesitamos probar cada configuración. Antes de las pruebas, publicaré la situación que se muestra en la página de inicio y haré un número. Expliquemos más tarde al probar:
Lo anterior es parte del contenido que se muestra en la página de inicio. Hibernate ha encontrado la información de visualización de la base de datos y se ha mostrado. Los numeraremos y será más fácil analizar cuando probemos el caché más adelante. Comencemos a probar los elementos de configuración de caché arriba:
Prueba 1: Pruebe el número de objetos en la memoria. Cambie la configuración a la siguiente situación:
<Defaultcache maxelementsInmemory = "6" <!-Establecer solo admite 6 cachés-> Eternal = "True" OverflowTodisk = "False" MemorySteeVictionPolicy = "Fifo": <!-First-in, First-Out-> />>
Después de completar la configuración, reiniciamos el servidor y abrimos la página de inicio. Dado que hay 6 configurados, solo los últimos 6 registros que se encuentran en el caché se almacenan, es decir, el número 3-8. Hacemos clic en cualquiera de los productos en 3-8 para ingresar la página de detalles del producto. Tenga en cuenta que la consola en segundo plano no genera ninguna información de consulta, lo que significa que no se envía una declaración SQL. Sin embargo, cuando hacemos clic en el producto número 2, se envía una instrucción SQL en segundo plano, es decir, se consulta la base de datos. Realizamos y hicimos clic en el producto 2 nuevamente, y no se envía una declaración SQL, lo que significa que se ha puesto en el caché, pero el caché solo admite 6 datos. Debido a que la estrategia de reemplazo de objetos configurado es primero en, primero en salir, por lo que el número 3 en el caché acaba de eliminarse. Hicimos clic 3 para intentar enviar una declaración SQL. Entonces, la prueba se completa y la ejecución de la memoria caché de segundo nivel es normal.
Prueba 2: El ciclo de vida del objeto de prueba. Cambie la configuración a la siguiente situación:
<DefaultCache maxelementsInmemory = "100" eternal = "false" <!-Solo coincidiendo con falso se puede establecer el siguiente ciclo de vida-> timetoidleseConds = "20" TimetoliveSeconds = "40" OverflowTodisk = "False" MemorySteeVictionPolicy = "Fifo" />>
El tiempo de caché se configura en 40 segundos, y si no hay operación en 20 segundos, se eliminará. Como hemos asignado 100 registros, los números 1-8 anteriores están todos en el caché. Después de habilitar el servidor, hacemos clic en cualquiera, por ejemplo, hacemos clic en el número 8, y no se emite una declaración SQL. Normalmente, después de 20 segundos, haga clic en el número 8 y envíe una instrucción SQL, lo que indica que el ciclo de vida que configuramos ha entrado en vigencia. Tenga en cuenta aquí que la configuración no puede ser demasiado corta, como 10 segundos, porque Tomcat tardará varios segundos en comenzar. Si hay menos configuración, el tiempo puede haber aumentado antes de la prueba ... entonces no funcionará.
Prueba 3: Pruebe si el caché secundario admite el almacenamiento de disco duro.
<DefaultCache maxelementsInmemory = "4" eternal = "false" <!-solo configurando falso se puede establecer el siguiente ciclo de vida-> timetoidleseConds = "100" TimetoliveSeconds = "200" OverflowTodisk = "True" <! solo al establecer true se puede admitir el almacenamiento de disco duro-> la correa de recuerdo de la memoria de la memoria = "fifo" />>>>>>>>>>>
Establecemos el almacenamiento de disco duro de soporte en verdadero y configuramos la capacidad máxima de almacenamiento del caché secundario en 4. Reinicie el servidor. Debido a que el caché secundario almacena hasta 4 registros, debe estar numerado 5-8. Al hacer clic en 5-8 definitivamente no enviará declaraciones SQL, pero cuando hacemos clic 1-4, no enviaremos declaraciones SQL, porque hemos configurado soporte para el almacenamiento de disco duro, Hibernate almacenará los resultados de la consulta en el disco duro, por lo que también podemos obtener los datos directamente sin enviar declaraciones SQL.
Prueba 4: Pruebe la estrategia de reemplazo del caché de nivel 2
<DefaultCache <!- FIFO se ha eliminado y no se volverá a utilizar ... LRU: El algoritmo al que se ha accedido al menos recientemente (política de tiempo), ignorará la frecuencia de acceso, y el que se ha accedido en el momento más lejano será reemplazado por LFU: el algoritmo de algoritmo que se utilizará más recientemente (la frecuencia de la frecuencia), ignorará el orden de acceso, y la frecuencia se ha reemplazado el acceso al algoritmo que se ha reemplazado más recientemente (la frecuencia de la frecuencia), y se ha reemplazado el acceso al menor que se ha reemplazado el acceso al menor que se ha reemplazado el acceso al menor. --> maxElementsInMemory="3" eternal="false" <!-- Only when it is configured as false can the following life cycle be set --> timeToIdleSeconds="100" timeToLiveSeconds="200" overflowToDisk="false" <!-- Only when it is configured as true can the hard disk storage be supported --> memoryStoreEvictionPolicy="LFU" />
Como su nombre indica, LRU y LFU se centran en el último tiempo y frecuencia de acceso, respectivamente. Tomemos LFU como ejemplo. Ahora establecemos el almacenamiento máximo en 3 registros, es decir, número 6-8. Ahora accedemos al número 6 tres veces, número 7 dos veces, número 8 una vez y no emitiremos declaraciones SQL. Accedemos al número 7 nuevamente y emitimos declaraciones SQL. Ahora el número 7 está en el caché, el número 8 se ha eliminado porque tiene el menor número de accesos. Podemos hacer clic en el número 8 nuevamente para probarlo, emitir la instrucción SQL y la prueba es exitosa. Si es un LRU, el número 6 que se acaba de eliminar es el número 6 porque el número 6 es el más temprano accedido.
En este punto, creo que todos han dominado el uso del caché secundario, y la prueba del caché secundario termina aquí. Hagamos configuraciones para nuestro proyecto de centro comercial en línea.
4. Configuración real de proyectos de centros comerciales en línea
Configuramos el número máximo de registros en el caché secundario en 1000, establecemos el ciclo de vida en 120 segundos y el ciclo de intervalo a 60 segundos. Apoyamos el almacenamiento de disco duro y utilizamos la estrategia de reemplazo de prioridad de frecuencia (LFU), porque si la tasa de clics del usuario es alta, debe colocarse en el caché secundario.
<ehcache xmlns: xsi = "http://www.w3.org/2001/xmlschema-instance" xsi: nonamespaceschemalocation = "../ config/ehcache.xsd"> <!-Si la memoria de cache se sobrefluye, almacenelo en el espacio de disco duro-> <diskstore ruta <Defaultcache maxelementsInmemory = "1000" eternal = "false" timetoidleseConds = "60" timetoliveSeconds = "120" OverflowTodisk = "true" MemorySteeVictionPolicy = "Lfu" /> < /ehcache>
Bueno, en combinación con el proyecto en el centro comercial en línea, se introduce la configuración y el uso del caché de segundo nivel de Hibernate 4.3.
Dirección original: http://blog.csdn.net/eson_15/article/details/51405911
Lo anterior es todo el contenido de este artículo. Espero que sea útil para el aprendizaje de todos y espero que todos apoyen más a Wulin.com.