MyBatis: cache de consulta

Cache de consulta

O escopo do cache de primeiro nível Mybatis é o mesmo SqlSession. A mesma instrução SQL é executada duas vezes na mesma sqlSession. Após a primeira execução, os dados consultados no banco de dados serão gravados no cache (memória) e a segunda vez será obtida a partir do cache. Os dados não serão mais consultados no banco de dados, melhorando assim a eficiência da consulta. Quando um sqlSession termina, o cache de primeiro nível no sqlSession não existe. Mybatis habilita o cache de primeiro nível por padrão. 

O cache secundário do Mybatis é compartilhado por várias SqlSessions e seu escopo é o mesmo espaço para nome do mapeador.SqlSessions diferentes executam a instrução sql sob o mesmo espaço para nome duas vezes e passam os mesmos parâmetros para o sql, que finalmente executa a mesma instrução sql. Após a conclusão da execução, os dados consultados no banco de dados serão gravados no cache (memória) e, na segunda vez em que os dados obtidos do cache, não serão consultados no banco de dados, melhorando assim a eficiência da consulta. Mybatis não habilita o cache secundário por padrão.Você precisa habilitar o cache secundário na configuração de parâmetros globais.

Cache de nível 1

A área de cache de primeiro nível é dividida de acordo com o SqlSession.

Cada consulta será encontrada primeiro na área de cache.Se nenhuma consulta do banco de dados for encontrada, os dados serão gravados no cache quando a consulta for encontrada.

O cache de armazenamento interno Mybatis usa um HashMap, chave é a instrução hashCode + sqlId + Sql e value é um objeto java gerado a partir do mapeamento da consulta.

Depois que o sqlSession executar inserção, atualização, exclusão e outras operações, a área de confirmação será limpa após o envio da confirmação.

Cache secundário

A área de cache secundário é dividida de acordo com o espaço para nome do mapeador.Os dados de consulta do mapeador do mesmo espaço para nome são colocados na mesma área.Se o método de proxy do mapeador for usado, o espaço para nome de cada mapeador será diferente.Neste momento, é possível entender que a área de cache secundário é dividida de acordo com o mapeador. .

Cada consulta será encontrada primeiro na área de cache.Se nenhuma consulta do banco de dados for encontrada, os dados serão gravados no cache quando a consulta for encontrada.

O cache de armazenamento interno Mybatis usa um HashMap, chave é a instrução hashCode + sqlId + Sql. value é o objeto java gerado pelo mapeamento da consulta

Depois que o sqlSession executar inserção, atualização, exclusão e outras operações, a área de confirmação será limpa após o envio da confirmação.

Ativar cache secundário

Adicione no arquivo de configuração principal SqlMapConfig.xml

<setting name="cacheEnabled" value="true"/>

	Descrição do produto	Valor permitido	Valor padrão
cacheEnabled	Defina as configurações globais de ativação / desativação para todos os caches nesse arquivo de configuração.	verdadeiro falso	verdadeiro

Para adicionar uma linha no seu arquivo de mapeamento do Mapper: <cache />, o que significa que esse mapeador ativa o cache secundário.

O cache secundário precisa do objeto pojo mapeado pelo resultado da consulta para implementar a interface java.io.Serializable para implementar operações de serialização e desserialização.Note que, se houver uma classe pai, o membro pojo precisará implementar a interface de serialização.

public class Orders implements Serializable
public class User implements Serializable

Desativar cache secundário

A configuração useCache = false na instrução pode desativar o cache secundário da instrução de seleção atual, ou seja, toda consulta emitirá SQL para consulta, o padrão é verdadeiro, ou seja, o SQL usa o cache secundário.

<select id="findOrderListResultMap" resultMap="ordersUserMap" useCache="false">

Atualize o cache

No mesmo espaço de nomes do mapeador, se houver outros dados de operação de inserção, atualização e exclusão, o cache precisará ser atualizado.Se o cache não for atualizado, ocorrerá uma leitura suja.

Defina a propriedade flushCache = "true" na configuração da instrução.Por padrão, é verdade atualizar o cache.Se for alterado para false, não será atualizado. Ao usar o cache, se você modificar manualmente os dados da consulta na tabela do banco de dados, haverá leituras sujas.

<insert id="insertUser" parameterType="cn.itcast.mybatis.po.User" flushCache="true">

Parâmetros do MyBatis Cache

flushInterval (intervalo de atualização) pode ser definido como qualquer número inteiro positivo e eles representam um período de tempo razoável na forma de milissegundos. Por padrão, ele não está definido, ou seja, não há intervalo de atualização, e o cache é atualizado somente quando a instrução é chamada.

tamanho (número de referências) pode ser definido como qualquer número inteiro positivo; lembre-se do número de objetos que você armazena em cache e do número de recursos de memória disponíveis em seu ambiente de execução. O valor padrão é 1024.

O atributo readOnly pode ser definido como verdadeiro ou falso. Um cache somente leitura retornará a mesma instância do objeto de cache para todos os chamadores. Portanto, esses objetos não podem ser modificados. Isso fornece uma vantagem de desempenho muito importante. O cache de leitura e gravação retornará uma cópia do objeto em cache (por serialização). Isso será mais lento, mas seguro, portanto o padrão é falso.

 <cache  eviction="FIFO"  flushInterval="60000"  size="512"  readOnly="true"/>

Essa configuração mais avançada cria um buffer FIFO e o atualiza a cada 60 segundos, armazenando 512 referências ao objeto ou lista de resultados, e o objeto retornado é considerado somente leitura, portanto, entre os chamadores em threads diferentes Modificá-los causará conflitos. As estratégias de recuperação disponíveis são, o padrão é LRU:

• LRU usado menos recentemente: remova objetos que não foram usados ​​por mais tempo.
• FIFO - primeiro a entrar, primeiro a sair: remova os objetos na ordem em que entram no cache.
• Referência SOFT-Soft: remova objetos com base no status do coletor de lixo e nas regras de referência flexível.
• WEAK-Weak Reference: remova objetos de forma mais agressiva, com base no status do coletor de lixo e nas regras de referência fracas.

Integração MyBatis Ehcache

O EhCache é uma estrutura de cache em processo Java pura, é um cache distribuído Java de código aberto amplamente utilizado, possui as características de rápido e enxuto, é o CacheProvider padrão no Hibernate.

Integração: A parte pessoal de P&D do software é entregue à parte geral do software, a fim de descobrir os problemas da parte de desenvolvimento pessoal o mais cedo possível.

Implantação: o código é entregue na seção executável de desenvolvimento / teste o mais rápido possível, para que possa ser testado o mais cedo possível.

Entrega: A P&D é entregue aos clientes o mais rápido possível, a fim de descobrir problemas no ambiente de produção o mais rápido possível.

Distribuído: um serviço é dividido em vários sub-serviços e implantado em diferentes servidores.

Implantação de cluster: o mesmo serviço é implantado em vários servidores.

Princípio ehcache de integração Mybatis

Mybatis fornece uma interface de cache secundária, da seguinte maneira:

 

Sua classe de implementação padrão:

Ao implementar a interface de cache, os dados do cache mybatis podem ser integrados por outros bancos de dados de cache.A especialidade de mybatis é a operação sql. O gerenciamento de dados em cache não é a especialidade de mybatis. Para melhorar o desempenho do cache, bancos de dados de cache de mybatis e de terceiros são integrados, como ehcache, memcache , Redis etc.

Etapa 1: introduzir dependências em cache

maven坐标：
<dependency>
    <groupId>org.mybatis.caches</groupId>
    <artifactId>mybatis-ehcache</artifactId>
    <version>1.0.2</version>
</dependency>

Etapa 2: Introduzir arquivo de configuração de cache

Adicione no caminho de classe: ehcache.xml, o conteúdo é o seguinte:

<ehcache xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:noNamespaceSchemaLocation="../config/ehcache.xsd">
    <diskStore path="F:\\develop\\ehcache" />
    <defaultCache 
        maxElementsInMemory="1000" 
        maxElementsOnDisk="10000000"
        eternal="false" 
        overflowToDisk="true" 
        timeToIdleSeconds="120"
        timeToLiveSeconds="120" 
        diskExpiryThreadIntervalSeconds="120"
        memoryStoreEvictionPolicy="LRU">
    </defaultCache>
</ehcache>

Descrição do imóvel:

• diskStorel: especifica o local de armazenamento dos dados no disco
• defaultCachel: Ao criar o cache com a ajuda do CacheManager.add ("demoCache"), o EhCache adotará a estratégia de gerenciamento especificada por <defalutCache />

Os seguintes atributos são necessários:

• maxElementsInMemory - o número máximo de elementos armazenados em cache na memória 
• maxElementsOnDisk - o número máximo de elementos armazenados em cache no disco, se 0 significa infinito
• eternal-Defina se os elementos em cache nunca expirarão. Se for verdade, os dados em cache são sempre válidos; se forem falsos, devem ser julgados de acordo com timeToIdleSeconds, timeToLiveSeconds
• overflowToDisk-Defina se os elementos expirados serão armazenados em cache no disco quando o cache da memória exceder

Os seguintes atributos são opcionais:

• timeToIdleSeconds - Quando o tempo de duas visitas antes e depois dos dados armazenados em cache no EhCache exceder o valor da propriedade timeToIdleSeconds, os dados serão excluídos.O valor padrão é 0, que é o tempo inativo infinito
• timeToLiveSeconds - a vida útil efetiva do elemento de cache, o padrão é 0, ou seja, o tempo de sobrevivência do elemento é infinito
• diskSpoolBufferSizeMB-Este parâmetro define o tamanho da área de buffer do DiskStore (cache de disco), o padrão é 30 MB, cada cache deve ter seu próprio buffer
• diskPersistent - Para habilitar o disco para salvar dados no EhCache quando a VM reiniciar, o padrão é false
• intervalo de execução do encadeamento de limpeza de cache diskExpiryThreadIntervalSeconds-Disk, o padrão é 120 segundos. A cada 120s, o encadeamento correspondente limpa os dados no EhCache
• memoryStoreEvictionPolicy-Quando o cache de memória atingir o máximo, quando um novo elemento for adicionado, remova a estratégia do elemento do cache. O padrão é LRU (menos usado recentemente), LFU opcional (menos usado com frequência) e FIFO (primeiro a entrar, primeiro a sair)

Etapa 3: ativar o ehcache

EhcacheCache é a implementação do ehcache da interface de cache:

Modifique o arquivo mapper.xml, especifique EhcacheCache no cache e ajuste os parâmetros do cache conforme necessário:

<cache type="org.mybatis.caches.ehcache.EhcacheCache" > 
    <property name="timeToIdleSeconds" value="3600"/>
    <property name="timeToLiveSeconds" value="3600"/>
    <!-- 同ehcache参数maxElementsInMemory -->
    <property name="maxEntriesLocalHeap" value="1000"/>
    <!-- 同ehcache参数maxElementsOnDisk -->
    <property name="maxEntriesLocalDisk" value="10000000"/>
    <property name="memoryStoreEvictionPolicy" value="LRU"/>
</cache>

Cenário de aplicação

Para solicitações de consulta com muitas visitas e os usuários não têm altos requisitos para resultados de consultas em tempo real, a tecnologia de cache secundário mybatis pode ser usada para reduzir o acesso ao banco de dados e melhorar a velocidade de acesso. Cenários de negócios como análise estatística demorada SQL, contas telefônicas Consulta sql etc.

O método de implementação é o seguinte: ao definir o intervalo de atualização, o mybatis limpa automaticamente o cache em intervalos e define o intervalo de atualização do cache flushInterval de acordo com a frequência das alterações de dados, como 30 minutos, 60 minutos, 24 horas etc., de acordo com as necessidades.

Limitações

O cache de segundo nível Mybatis não é bom para o cache de nível de dados refinado, como os seguintes requisitos: armazenar informações do produto em cache, devido ao grande número de visitas de consulta de informações do produto, mas exigir que os usuários consultem as informações mais recentes do produto todas as vezes, se O uso do cache de segundo nível do mybatis não pode perceber que, quando um produto muda, apenas as informações do cache do produto são atualizadas sem atualizar as informações de outros produtos, porque a área do cache do segundo nível do mybaits é dividida pela unidade do mapeador, quando as informações do produto são alteradas, todas Todos os dados de cache das informações do produto são limpos. A solução desses problemas exige o armazenamento em cache direcionado de dados na camada de negócios, de acordo com a demanda.