¿Cuál es la diferencia entre el caché de primer nivel y el caché de segundo nivel de Spring?

Caché de nivel 1: \x0d\ es el caché de nivel de sesión. Cuando una sesión realiza una operación de consulta, colocará los resultados de esta operación en el caché de primer nivel. \x0d\Si esta sesión (debe ser la misma sesión) realiza la misma operación nuevamente dentro de un corto período de tiempo, la hibernación la obtendrá directamente del caché de primer nivel en lugar de conectarse a la base de datos para obtener los datos. \x0d\Es un caché integrado para toda la transacción y no se puede descargar. \x0d\Caché de segundo nivel: \x0d\ es el caché de nivel SessionFactory. Como sugiere el nombre, al realizar una consulta, los resultados de la consulta se almacenarán en el caché de segundo nivel. \x0d\Si una sesión creada por el mismo sessionFactory realiza la misma operación, la hibernación obtendrá el resultado del caché de segundo nivel en lugar de conectarse a la base de datos. \x0d\Este es un caché de complemento opcional. De forma predeterminada, SessionFactory no habilitará este complemento. \x0d\ Se puede configurar en una granularidad por clase o por colección. El adaptador de caché se utiliza para integrar software de implementación de caché específico con Hibernate. \x0d\Estrictamente hablando, el caché de SessionFactory se divide en dos categorías: caché integrado y caché externo. El caché de segundo nivel al que habitualmente nos referimos se refiere a un caché externo. \x0d\El caché integrado se implementa de manera similar al caché a nivel de sesión. El primero son los datos contenidos en algunos atributos de colección del objeto SessionFactory, y el segundo se refiere a los datos contenidos en algunos atributos de colección de los almacenes de caché integrados de Session\x0d\SessionFactory que asignan metadatos y declaraciones SQL predefinidas. \x0d\Los metadatos de mapeo son una copia de los datos en el archivo de mapeo; \x0d\La declaración SQL predefinida se deriva de los metadatos de mapeo durante la fase de inicialización de Hibernate. La caché incorporada de \x0d\SessionFactory es de solo lectura. Las aplicaciones no pueden modificar los metadatos de mapeo y las declaraciones SQL predefinidas en la caché, por lo que SessionFactory no necesita sincronizar la caché incorporada ni los archivos de mapeo. \x0d\Los dos niveles de caché de Hibernate se encuentran en la capa de persistencia y almacenan copias de los datos de la base de datos. \x0d\Dos características del caché:\x0d\Cache Scope\x0d\Cache Concurrent Access Policy\x0d\1. El alcance del caché\x0d\ determina el ciclo de vida del caché y quién puede acceder a él. El alcance del caché se divide en tres categorías. \x0d\Alcance de la transacción\x0d\Alcance del proceso\x0d\Alcance del clúster\x0d\Nota:\x0d\Para la mayoría de las aplicaciones, debe considerar cuidadosamente si desea utilizar un caché para todo el clúster, porque la velocidad de acceso no será necesariamente más rápida que ¿Cuánto más rápido es acceder directamente a los datos de la base de datos? \x0d\La caché con alcance de transacción es la caché de primer nivel de la capa de persistencia y generalmente es necesaria para todo el proceso o el clúster; la caché de segundo nivel de la capa de persistencia y generalmente es opcional. \x0d\2. Estrategia de acceso concurrente al caché\x0d\ Cuando varias transacciones simultáneas acceden a los mismos datos almacenados en caché en la capa de persistencia al mismo tiempo, se producirán problemas de concurrencia y se deben tomar las medidas necesarias de aislamiento de transacciones. \x0d\Pueden ocurrir problemas de concurrencia con cachés de todo el proceso o de todo el clúster, es decir, cachés de segundo nivel. \x0d\ Por lo tanto, se pueden establecer los siguientes cuatro tipos de estrategias de acceso concurrente, cada estrategia correspondiente a un nivel de aislamiento de transacción. \x0d\La política de acceso concurrente transaccional tiene el nivel de aislamiento de transacciones más alto y el nivel de aislamiento de solo lectura es el más bajo. Cuanto mayor sea el nivel de aislamiento de la transacción, menor será el rendimiento de la concurrencia. \x0d\A Transaccional: Aplicable únicamente en entornos administrados. Proporciona un nivel de aislamiento de transacciones de lectura repetible. \x0d\Para datos que se leen con frecuencia pero que rara vez se modifican, se puede utilizar este tipo de aislamiento porque puede evitar problemas de concurrencia, como lecturas sucias y lecturas no repetibles. \x0d\B Lectura-escritura: proporciona un nivel de aislamiento de transacción de lectura confirmada.

Solo aplicable en entornos no agrupados. \x0d\Para datos que se leen con frecuencia pero que rara vez se modifican, se puede utilizar este tipo de aislamiento porque puede evitar problemas de concurrencia, como lecturas sucias. \x0d\C Tipo de lectura y escritura no estricto: no se garantiza la coherencia del caché y los datos en la base de datos. \x0d\Si existe la posibilidad de que dos transacciones accedan a los mismos datos en el caché al mismo tiempo, se debe configurar un tiempo de vencimiento corto para los datos para evitar lecturas sucias. \x0d\Esta estrategia de acceso concurrente se puede utilizar para datos que rara vez se modifican y permiten lecturas sucias ocasionales. \x0d\D Solo lectura: esta estrategia de acceso simultáneo se puede utilizar para datos que nunca se modificarán, como los datos de referencia. \x0d\¿Qué tipo de datos son adecuados para almacenarse en la caché de segundo nivel? \x0d\1. Datos que rara vez se modifican\x0d\2. Datos que no son muy importantes, se permiten datos concurrentes ocasionales\x0d\3 Datos a los que no se accederá simultáneamente\x0d\4. ¿Eso no es adecuado para el almacenamiento en el caché de segundo nivel? \x0d\1. Datos modificados con frecuencia\x0d\2. Datos financieros, la concurrencia no está permitida\x0d\3. \x0d\El proceso general de la estrategia de caché de segundo nivel de Hibernate es el siguiente:\x0d\1) Al consultar las condiciones, siempre emita una declaración SQL como select * from table_name where ? (seleccione todos los campos) para consultar la base de datos y obtener todos los objetos de datos a la vez. \x0d\2) Coloque todos los objetos de datos obtenidos en la caché de segundo nivel según sus ID. \x0d\3) Cuando Hibernate accede al objeto de datos según el ID, primero lo verifica desde el caché de primer nivel de la sesión, si no se puede encontrar, si el caché de segundo nivel está configurado, luego lo verifica desde el segundo; -Caché de nivel; si no se puede encontrar, consulta la base de datos nuevamente y coloca el resultado en el caché de acuerdo con el ID. \x0d\4) Al eliminar, actualizar o agregar datos, el caché se actualiza al mismo tiempo. \x0d\Nota: \x0d\La estrategia de caché de segundo nivel de Hibernate es una estrategia de caché para consultas de ID y no tiene ningún efecto en las consultas condicionales. Con este fin, Hibernate proporciona almacenamiento en caché de consultas para consultas condicionales. \x0d\El proceso de la estrategia de caché de consultas es el siguiente:\x0d\1) Hibernate primero forma una clave de consulta basada en esta información. La clave de consulta incluye la información general solicitada por la consulta condicional: SQL, parámetros requeridos por SQL, registro. rango (posición inicial rowStart, el número máximo de registros (maxRows), etc. \x0d\2) Hibernate busca en la caché de consultas la lista de resultados correspondiente en función de esta clave de consulta. Si existe, devuelva la lista de resultados; si no existe, consulte la base de datos, obtenga la lista de resultados y coloque la lista de resultados completa en el caché de consultas de acuerdo con la clave de consulta. \x0d\3) El SQL en la clave de consulta implica algunos nombres de tablas. Si se modifica, elimina, agrega, etc. algún dato en estas tablas, estas claves de consulta relacionadas se borrarán del caché.