P: Que tipo de cache é um bom cache?
Um cache que resolve um problema é um bom cache. Essa frase é simplesmente um disparate, equivale a gato branco, gato preto, e quem pega rato é gato bom.
Então, com a premissa de resolver o problema, qual cache é o melhor cache? Minha resposta a esta pergunta é: um cache com uma alta taxa de acertos é um bom cache.
Sob a premissa de resolver o problema, um cache com alta taxa de acerto pode exigir menos investimento em hardware do que um cache com baixa taxa de acerto. Ao mesmo tempo, o número de caches pode ser menor que o número de caches com baixa taxa de acerto. Desta forma, a velocidade de endereçamento será definitivamente mais rápida. Portanto, um cache com alta taxa de acerto é um bom cache.
Taxa de acerto do cache
Depois que uma entidade armazenada em cache é lançada no cache, se ela não tiver sido usada uma vez pelo mundo externo enquanto a entidade está armazenada em cache (durante o ciclo de vida da entidade que está sendo armazenada em cache), a taxa de acertos da entidade armazenada em cache será 0. Quanto mais vezes essa entidade for solicitada, maior será a taxa de acertos do cache.
O que é mencionado acima é a taxa de acerto de uma entidade no cache. Para o cache como um todo, sua taxa de acerto é o diagrama de distribuição da taxa de acerto de cada indivíduo armazenado em cache acima.
Para armazenamento em cache: geralmente os indivíduos mais usados são uma parte muito pequena do total. Os menos utilizados constituem uma grande proporção do todo.
Muitas vezes vemos dados como estes:
Dos 10.000 elementos armazenados em cache, 100 são usados com frequência, quase a cada minuto. 2.000 dados, solicitados uma vez por hora. 3.000 dados são solicitados uma vez por dia, e os dados restantes não foram usados nem uma vez após serem lançados no cache.
Hoje em dia, o hardware está se desenvolvendo rapidamente. Se precisarmos armazenar em cache apenas 10.000 dados, podemos jogar completamente todos os 10.000 dados no cache, independentemente de serem usados. dados no cache. Não há necessidade de realizar operações adicionais ou fazer solicitações ao banco de dados.
No entanto: o hardware se desenvolve rapidamente, assim como a quantidade de dados. Para um site pequeno, se 10.000 dados forem armazenados em cache, todos eles serão armazenados em cache. No entanto, grandes sites têm pelo menos milhões de dados ou dados de nível T. Obviamente, todos esses dados não podem ser lançados no cache. Neste momento, é muito importante projetar uma solução de cache razoável e melhorar a taxa de acertos do cache. E é necessário.
Alguns métodos comuns para melhorar a taxa de acertos do cache
De uma perspectiva puramente técnica, registramos apenas o número de solicitações do usuário por unidade de tempo e armazenamos em cache os dados mais comumente usados com base nessas informações.
Porém, na maioria das vezes, melhoramos a taxa de acertos do cache com base na lógica de negócios. Por exemplo: No ano passado e no blog publicado no ano retrasado, as solicitações de navegação para esse tipo de artigo costumavam ser pelo menos algumas vezes ao dia. Geralmente não deve ser armazenado em cache na memória.
Por outro exemplo, uma postagem com muitas respostas geralmente será vista por mais pessoas do que uma postagem com menos respostas.
Devemos usar a lógica acima e fornecer um algoritmo de cache baseado em nossa lógica de negócios real para melhorar a taxa de acertos do cache. Vamos armazenar em cache os dados apropriados, em vez de todos os dados, conforme nosso hardware permite.
Um exemplo negativo é: não importa o que aconteça, um grande blog, quando um artigo é solicitado por um usuário, descobre-se que ele não está no cache da memória, então é lido do banco de dados e depois jogado no cache.
Você sabe, existem muitos rastreadores agora. Além disso, para sites amigáveis aos mecanismos de busca, como blogs, a maior parte da pressão de acesso vem dos mecanismos de busca. Essas visitas costumam durar uma hora ou um dia, com apenas algumas ou até uma solicitação de determinado artigo, e nunca mais. A taxa de acerto do método de cache acima será muito baixa.
Alguém pode perguntar aqui, Guo Hongjun, já que você não me sugere armazenar em cache o conteúdo desses blogs, mas como posso melhorar o desempenho do meu site, devo pelo menos garantir que meu blog não será muito lento para responder? às solicitações do usuário.
Existem muitas soluções para este problema. Um dos métodos mais simples é transformar esses blogs em páginas HTML estáticas, que é o cache do sistema de arquivos. Devido ao disco rígido, o sistema de arquivos pode ser simplesmente entendido como infinitamente expansível. para que muitos conteúdos com baixa taxa de acerto sejam armazenados em cache.
Se sua página exigir algum julgamento lógico dinâmico, você poderá armazenar em cache os dados em arquivos XML e, em seguida, o segmento do servidor integrará esses arquivos XML ou incluirá arquivos. Esta também é uma boa abordagem.
Tendo dito tantas questões sobre a taxa de acerto do cache, vamos resumir brevemente as opiniões sobre a taxa de acerto do cache:
Sites pequenos podem armazenar em cache todos os dados e, geralmente, a pressão não será grande, portanto, os problemas de taxa de acertos do cache podem ser ignorados.
Grandes serviços não podem armazenar em cache todos os dados, mas apenas parte dos dados. Neste momento, o arquiteto precisa projetar um método de armazenamento em cache adequado à lógica de negócios para melhorar ao máximo a taxa de acertos do cache.
A maioria dos métodos para melhorar a taxa de acertos está vinculada à lógica de negócios e requer análise detalhada de problemas específicos. Para dados que não podem ser armazenados em cache na memória, a maneira mais simples de melhorar o desempenho é usar o cache de arquivos.
O cache de arquivo pode armazenar em cache todo o conteúdo em um arquivo estático; também pode armazenar em cache uma área da página inteira em um arquivo e, em seguida, incluí-la; também pode serializar uma entidade em um arquivo XML para armazenamento em cache;
Vejamos alguns outros aspectos menos importantes do cache:
Atividades do ciclo de vida do cache
Conteúdo que nunca expira ou muda para sempre não deve ser colocado no cache. O cache é um armazenamento temporário, não permanente, portanto o ciclo de vida do cache é limitado.
Por sua vez, poderá passar pelas seguintes atividades:
Entre no cache. (Ao entrar no cache, pode ser necessário especificar sua política de expiração futura. Se não for especificado, você precisará usar a política de expiração padrão do sistema)
Obtenha-o do cache. Observe que os problemas de segurança do thread precisam ser resolvidos neste momento.
Ao atualizar o cache, observe que você também precisa considerar problemas de segurança de thread ao sair do cache. Isso pode ser uma solicitação externa ou o cache pode limpá-lo com base na política de expiração.
Política de expiração de cache
Geralmente eu perguntaria: quais estratégias de expiração de cache você encontrou nos caches com os quais entrou em contato?
As estratégias de expiração mais comuns são as seguintes:
Se não for solicitado há muito tempo, irá expirar. A mais típica é a função Section fornecida pelo ASP e ASP.net. Na verdade, é um cache.
O cache que depende das alterações do arquivo expirará assim que o arquivo for modificado, normalmente o Web.config do site WEB. Depois que o arquivo for alterado, não apenas o cache será reiniciado, mas o processo do IIS também executará uma liberação.
Com base nisso, você poderá ver políticas de expiração de cache para muitas dependências. Por exemplo, política de expiração de cache que depende do banco de dados.
Claro, pode haver estratégias de expiração mais complexas na lógica de negócios. Na nova versão do fórum do sistema de pontos CSDN, o cache da lista de postagens irá limpá-lo para 550 dados quando o cache de dados da lista atingir 600.
Outro exemplo é que o cache de novas postagens do fórum baseadas em pontos expira quando nenhuma lista se refere à postagem, e a postagem expira.
Problema de sincronização de cache
Usar cache significa que múltiplas cópias dos mesmos dados podem coexistir. Se o seu código não considerar determinada situação, os dois dados ficarão inconsistentes. É quando os problemas ocorrerão.
A solução é simples. Pense cuidadosamente sobre sua lógica de negócios e situações de acionamento de código e não deixe nenhuma área que não tenha chegado ao fundo do poço.
Métodos simples podem tornar a lógica do seu código muito complexa.
É por isso que algumas pessoas recomendam que você não use o cache quando não for necessário. Depois de começar a usar o cache, você deverá estar preparado para adicionar muito código para lidar com a sincronização de dados.
Inicialize e preencha os dados do cache
Às vezes, depois que o cache é inicializado, alguns dados precisam ser pré-preenchidos no cache. Esta é a operação de inicialização dos dados armazenados em cache.
As seguintes questões precisam ser consideradas durante a operação de inicialização dos dados armazenados em cache:
Quanto tempo leva para inicializar? Geralmente, se for um site, podemos realizar esse trabalho de inicialização em Application_OnStart do Global.asa. A inicialização geralmente não pode demorar muito. Neste momento, nossa capacidade de otimização de código é testada.
Durante a inicialização, os dados geralmente são importados em lotes, em vez de processar um dado por vez durante o uso normal.
Resumir:
Este artigo apresenta alguns dos meus pontos de vista sobre armazenamento em cache, sem entrar em detalhes sobre tecnologias específicas de armazenamento em cache. Espero que através da descrição deste artigo, as pessoas que apenas conhecem o uso do cache, mas não entendem a ideia do cache, possam ter um entendimento preliminar.
http://blog.csdn.net/ghj1976/archive/2007/09/01/1768676.aspx