Existem produtos populares na página inicial do shopping online, portanto a taxa de cliques desses produtos é muito alta. Quando um usuário clica em um produto popular, ele precisa inserir a página de informações detalhadas do produto, assim como no Taobao. Toda vez que você clicar, você deve ir ao plano de fundo para consultar as informações detalhadas do produto e enviará a instrução SQL correspondente. Toda vez que você atualiza a página detalhada, você também enviará a instrução SQL. Dessa forma, o desempenho será definitivamente muito afetado. Em seguida, o uso do cache secundário do Hibernate pode resolver esse problema.
Algumas pessoas podem pensar que podemos usar o redirecionamento. Dessa forma, quando o usuário visita primeiro, eles podem descobrir as informações e colocá -las na sessão. No futuro, toda vez que o usuário atualiza, eles podem ir para a sessão, para que não haja necessidade de consultar no banco de dados. Isso faz sentido, mas não pode resolver o problema acima, porque o que queremos resolver é que vários usuários acessem o mesmo produto e clique no mesmo produto. O redirecionamento só pode garantir que o mesmo usuário clique ou atualize. Mas o cache secundário pode resolver esses problemas.
Vamos primeiro explicar a tecnologia secundária de cache com base no Hibernate4.3 em detalhes e depois fazer uma configuração específica para este projeto.
1. Hibernate4.3 Nível 2 Configuração básica
Ao contrário do Hibernate3, o pacote principal do Hibernate4.3 não possui classes relacionadas ao cache. Se quisermos usar o cache secundário, precisamos adicionar o pacote JAR em cache. A partir do download oficial do Hibernate-Release-4.3.11.Final, existem pacotes JAR necessários para o cache secundário, que devem ser adicionados primeiro ao projeto. do seguinte modo:
Em seguida, configuramos a configuração secundária relacionada ao cache em hibernate.cfg.xml:
<Factory> <Hibernate-Configuration> <Session-Factory> <propriedades name = "dialect"> org.hibernate.dialect.mysqldialect </propriedade> <propriedades name = "show_sql"> true </sistion> <!-Configure o provedor de cache secundário, que não é um pacote de jarra cache-> <! name = "hibernate.cache.region.factory_class"> org.hibernate.cache.ehcache.ehcacheregionFactory < /Property> <mapping /> <mapping /> <maping /> <!- que classes para configurar o suporte de suporte? Isso exibe principalmente produtos populares na página inicial, portanto, a classe de produto suporta em cache-> <classe-cache uSage = "somente leitura"/> </session-factory> </Hibernate-Configuration>
Em seguida, abrimos o servidor Tomcat e visitamos a página inicial, clicamos em produtos populares e nenhuma declaração SQL é enviada em segundo plano. Você pode se perguntar: o cache de segundo nível é simples? Basta configurar esses dois itens? De fato, a razão pela qual o cache de nível 2 entrou em vigor até agora é que ele possui uma configuração padrão. Existe um arquivo ehcache-failsafe.xml no ehcache-core-2.4.3.jar, que já possui uma configuração padrão. Nós o analisamos em detalhes mais tarde. Vamos primeiro analisar a estratégia de consulta do Hibernate:
2. Estratégia de consulta Hibernate4.3
O Hibernate suporta dois métodos de consulta: consulta de sessão e consulta HQL.
Existem session.Save () update () delete () get () load () e outros métodos na sessão. Esse método opera apenas em um registro, e o padrão é suportar o cache do nível 2 sem nenhuma configuração. Portanto: a configuração somente leitura é eficaz para a sessão. Se somente leitura estiver configurada no cache secundário na sessão, as operações session.update () e delete () falharão. Se você deseja ter sucesso, precisa configurar a leitura. Mas salvar () e get () carregar () são bem -sucedidos.
HQL: Este método é usado para operar vários registros por padrão, como os métodos List () e ExecuteUpdate (). Esse método é o padrão da configuração do cache secundário, incluindo somente leitura, é inválido. A lista () do HQL consulta vários registros, consulta diretamente o banco de dados e entrega os resultados da consulta ao cache secundário, que facilita a chamada de get () e carregamento (). O ExecuteUpdate não suporta cache secundário e também é atualizado diretamente para o banco de dados. O Hibernate garantirá que o banco de dados e o cache sejam sincronizados. NOTA: O HQL não possui um método save (). Se você precisar inserir dados, só poderá ligar para o método session.save ().
[Nota]: O cache de primeiro nível (existente por padrão) no hibernato também é chamado de cache no nível da sessão, não usado para melhorar o desempenho, mas para lidar com transações; O cache de segundo nível é um cache de sessão, que é válido para todas as sessões, e seu ciclo de vida é o mesmo que o SessionFactory (o SessionFactory é um singleton e será criado quando o projeto iniciar).
Para estratégias de consulta específicas, vejamos a figura a seguir:
【Nota】: Se o texto da imagem for muito pequeno, você poderá arrastar a imagem para uma nova janela para visualizar ~
O exposto acima é a estratégia de consulta de hibernato. Vamos continuar analisando a configuração do cache secundário.
3. Configuração avançada de cache de Hibernate 4.3 Nível 2
Como mencionado acima, o motivo pelo qual podemos usar o cache do Nível 2 após a configuração de dois itens no hibernate.cfg.xml é porque há uma configuração padrão. Vamos dar uma olhada nesta configuração padrão primeiro:
<ehcache xmlns: xsi = "http://www.w3.org/2001/xmlschema-stance" xsi: nonamespaceschemalocation = "../ config/ehcache.xsd"> <! Path = "java.io.tmpdir"/> <defaultCache maxElementsInmemory = "10000": <!-o número máximo de objetos suportados pela memória-> eternal = "false": <!-se o objeto é permanentemente válido, é recomendado que seja false, que os seguintes dois parâmetros serão válidos-> timerid- unidade é segundos. Ou seja, se ninguém usa esse objeto após 60 segundos, ele será destruído antecipadamente-> timeToliveSeconds = "120": <!-O ciclo de vida do objeto é segundos-> overflowtodisk = "true": <!-se o flow para o disco rígido é suportado, é recomendado para ser verdadeiro-> maxElessondisk = 100000 " MemoryStoreEvictionPolicy = "lru": <!-Política de substituição de objetos-> /> </hcache>
A explicação relevante sobre a configuração padrão já está nos comentários acima. Agora sabemos que é precisamente por causa dessa configuração padrão que o cache de segundo nível do Hibernate 4.3 pode ser executado corretamente. Agora, se quisermos configurar o cache, precisamos criar um novo arquivo Ehcache.xml no diretório SRC e reconfigurar os itens de configuração acima. Em seguida, precisamos testar cada configuração. Antes de testar, publicarei a situação exibida na página inicial e farei um número. Vamos explicar mais tarde ao testar:
O exposto acima faz parte do conteúdo exibido na página inicial. O Hibernate encontrou as informações de exibição do banco de dados e foi exibido. Nós os numeraremos e será mais fácil analisar quando testarmos o cache posteriormente. Vamos começar a testar os itens de configuração do cache acima:
Teste 1: teste o número de objetos na memória. Altere a configuração para a seguinte situação:
<DefaultCache maxElementsInmemory = "6" <!-A configuração suporta apenas 6 caches-> eternal = "true" overflowTodisk = "false" MemoryStoreEvictionPolicy = "FIFO": <!-Primeiro-in, primeiro out-> /> />
Após a conclusão da configuração, reiniciamos o servidor e abrimos a página inicial. Como há 6 configurados, apenas os últimos 6 registros encontrados no cache são armazenados, ou seja, número 3-8. Clicamos em qualquer um dos produtos em 3-8 para inserir a página de detalhes do produto. Observe que o console em segundo plano não produz nenhuma informação de consulta, o que significa que nenhuma instrução SQL é enviada. No entanto, quando clicamos no número 2 do produto, uma instrução SQL é enviada em segundo plano, ou seja, o banco de dados é consultado. Apontamos e clicamos no produto 2 novamente, e nenhuma instrução SQL foi enviada, o que significa que ela foi colocada no cache, mas o cache suporta apenas 6 dados. Como a estratégia de substituição de objetos configurada é o primeiro a entrar, primeiro o número 3 no cache acabou de ser removido. Clicamos 3 para tentar enviar uma instrução SQL. Portanto, o teste é concluído e a execução do cache do segundo nível é normal.
Teste 2: O ciclo de vida do objeto de teste. Altere a configuração para a seguinte situação:
<DefaultCache maxElementsInmemory = "100" eternal = "false" <!-Somente correspondendo a false, o seguinte ciclo de vida pode ser definido-> timeToidleSeconds = "20" timeToliveSeconds = "40" OverflowTodisk = "false" MemoryStoreEvictionPolicy = "FIFO" />
O tempo de cache é configurado como 40 segundos e, se não houver operação em 20 segundos, ele será removido. Como atribuímos 100 registros, os números 1-8 acima estão todos no cache. Depois de ativar o servidor, clicamos em qualquer um, por exemplo, clique no número 8 e nenhuma instrução SQL é emitida. Normalmente, após 20 segundos, clique no número 8 e envie uma instrução SQL, indicando que o ciclo de vida que configuramos entrou em vigor. Observe aqui que a configuração não pode ser muito curta, como 10 segundos, porque o Tomcat levará vários segundos para começar. Se houver menos configuração, o tempo poderá ter acontecido antes de testar ... então não funcionará.
Teste 3: teste se o cache secundário suporta armazenamento em disco rígido.
<DefaultCache maxElementsInmemory = "4" eternal = "false" <!-Somente definindo false pode ser definido o seguinte ciclo de vida-> timeToidleSeconds = "100" timeToliveSeconds = "200" OverflowTorSticishP = "True" <!-Somente definindo o armazenamento de disco rígido /200 "> MemoryEvicty =" True "<!-Somente, com o tuiling, o armazenamento em disco rígido pode ser apoiado->"
Definimos o armazenamento de disco rígido de suporte como verdadeiro e configuramos a capacidade máxima de armazenamento do cache secundário como 4. Reinicie o servidor. Como o cache secundário armazena até 4 registros, ele deve ser numerado 5-8. Ao clicar em 5-8, definitivamente não enviará instruções SQL, mas quando clicarmos em 1-4, não enviaremos instruções SQL, porque configuramos suporte para armazenamento em disco rígido, o Hibernate armazenará os resultados da consulta no disco rígido, para que também possamos obter os dados diretamente sem enviar as instruções SQL.
Teste 4: Teste a estratégia de substituição do cache de nível 2
<defaultCache <!-- FIFO has been eliminated and will not be used again... LRU: The algorithm that has been accessed at least recently (time policy), will ignore the access frequency, and the one that has been accessed at the farthest time will be replaced by LFU: The algorithm that has been used most recently (frequency measurement), will ignore the order of access, and the one that has the least access frequency will be replaced by -> maxElementsInMemory = "3" eternal = "false" <!-somente quando estiver configurado como falso, o seguinte ciclo de vida pode ser definido-> timeToidleSeconds = "100" timeToliveSeconds = "200" transbroffish-> Memória de flowtodisk = "false" <!
Como o nome sugere, a LRU e a LFU se concentram no último tempo e frequência de acesso, respectivamente. Vamos tomar a LFU como exemplo. Agora definimos o armazenamento máximo para 3 registros, ou seja, número 6-8. Agora, acessamos o número 6 três vezes, número 7 duas vezes, número 8 uma vez e não emitiremos instruções SQL. Acessamos o número 7 novamente e emitimos instruções SQL. Agora, o número 7 está no cache, o número 8 foi removido porque possui o menor número de acessos. Podemos clicar em número 8 novamente para testá -lo, emitir a instrução SQL e o teste é bem -sucedido. Se for um LRU, o número 6 removido é o número 6 porque o número 6 é o mais antigo acessado.
Nesse ponto, acredito que todo mundo dominou o uso do cache secundário e o teste do cache secundário termina aqui. Vamos fazer configurações para o nosso projeto de shopping online.
4. Configuração real de projetos de shopping online
Configuramos o número máximo de registros no cache secundário como 1000, definimos o ciclo de vida como 120 segundos e o ciclo de intervalo para 60 segundos. Suportamos armazenamento em disco rígido e usamos a estratégia de substituição da prioridade de frequência (LFU), porque se a taxa de cliques do usuário for alta, ela deverá ser colocada no cache secundário.
<ehcache xmlns: xsi = "http://www.w3.org/2001/xmlschema-stance" xsi: nonamespaceschemalocation = "../ config/ehcache.xsd"> <!-se o cache de cache, armazenar, para resfriar o space-> space-> disco-l) <! <DefaultCache maxElementsInMemory = "1000" eternal = "false" timeToidleSeconds = "60" timeToliveSeconds = "120" OverflowTodisk = "True" MemorystoreEvictionPolicy = "Lfu" /> < /ehcache>
Bem, em combinação com o projeto Online Mall, a configuração e o uso do cache de segundo nível do Hibernate 4.3 é introduzido.
Endereço original: http://blog.csdn.net/eson_15/article/details/51405911
O exposto acima é todo o conteúdo deste artigo. Espero que seja útil para o aprendizado de todos e espero que todos apoiem mais o wulin.com.