1. Uma das caches tradicionais (404)
Este método visa direcionar o erro 404 do nginx para o back-end e, em seguida, usar proxy_store para salvar a página retornada pelo back-end.
Configuração:
localização/{
root /home/html/;#Diretório inicial
expira 1d;#Tempo de expiração da página da web
error_page 404 =200 /fetch$request_uri;#404 direcionado para o diretório /fetch
}
location /fetch/ {#404Direcione aqui
internal;#Indica que este diretório não pode ser acessado diretamente externamente
expira 1d;#Tempo de expiração da página da web
alias /home/html/;#O endereço do sistema de arquivos do diretório virtual deve ser consistente com location/, proxy_store salvará o arquivo neste diretório
proxy_pass http://www.sudone.com/;#Backend endereço upstream, /fetch também é um proxy
proxy_set_header Accept-Encoding '';# Deixe o backend não retornar conteúdo compactado ( gzip ou deflate). Salvar o conteúdo compactado causará problemas.
proxy_store on;#Especifique o nginx para salvar o arquivo retornado pelo proxy
proxy_temp_path /home/tmp;#Diretório temporário, este diretório deve estar na mesma partição do disco rígido que /home/html
}
Ao usá-lo, observe que o nginx deve ter permissão para gravar arquivos em /home/tmp e /home/html No Linux , o nginx geralmente é configurado para ser executado como usuário ninguém, portanto, esses dois diretórios devem ser definidos como chown. para ser exclusivo para o usuário ninguém, é claro que você também pode chmod 777, mas todos os administradores de sistema experientes aconselharão não usar o 777 casualmente.
2. Cache tradicional 2 (!-e)
O princípio é basicamente o mesmo do salto 404, mas mais conciso:
localização/{
raiz /home/html/;
proxy_store ativado;
proxy_set_header Aceitar codificação '';
proxy_temp_path /home/tmp;
if ( !-f $request_filename )
{
proxy_pass http://www.sudone.com/;
}
}
Você pode ver que esta configuração economiza muito código em comparação com 404. Ela usa !-f para determinar se o arquivo solicitado existe no sistema de arquivos. Se não existir, proxy_pass para o backend, e o retorno também é salvo usando. proxy_store.
Ambos os caches tradicionais têm basicamente as mesmas vantagens e desvantagens:
Desvantagem 1: Links dinâmicos com parâmetros, como read.php?id=1, não são suportados, como o nginx salva apenas o nome do arquivo, esse link só é salvo como read.php no sistema de arquivos, para que os usuários acessem o read. php?id= 2 retornará resultados incorretos. Ao mesmo tempo, não suporta a página inicial no formato http://www.sudone.com/ e o diretório secundário http://www.sudone.com/download/, porque o nginx é muito honesto e escreverá tal solicitação em um arquivo de acordo com o sistema de link, e esse link é obviamente um diretório, então o salvamento falha. Nestes casos, é necessário reescrever para salvar corretamente.
Desvantagem 2: Não há mecanismo para expiração e limpeza de cache dentro do nginx. Esses arquivos em cache serão armazenados permanentemente na máquina. Se houver muitas coisas a serem armazenadas em cache, isso ocupará todo o espaço do disco rígido. Para isso, você pode usar um script de shell para limpá-lo regularmente e pode escrever programas dinâmicos como php para fazer atualizações em tempo real.
Desvantagem 3: Apenas 200 códigos de status podem ser armazenados em cache, portanto, códigos de status como 301/302/404 retornados pelo back-end não serão armazenados em cache. Se um link pseudoestático com um grande número de visitas for excluído, ele continuará. penetrar e causar A extremidade traseira carrega muita pressão.
Desvantagem 4: o nginx não selecionará automaticamente a memória ou o disco rígido como meio de armazenamento. Tudo é determinado pela configuração. É claro que haverá um mecanismo de cache de arquivos no nível do sistema operacional no sistema operacional atual, portanto, não há necessidade. preocupe-se muito com grandes leituras simultâneas se elas estiverem armazenadas no disco rígido devido a problemas de desempenho.
As deficiências do cache tradicional do nginx também são seus recursos diferentes do software de cache como o Squid, portanto, também pode ser considerado uma vantagem. Em aplicativos de produção, é frequentemente usado como parceiro do Squid, muitas vezes não consegue bloquear links com ?, mas o nginx pode bloquear seu acesso, como: http://sudone.com/? com / será tratado como dois links no Squid, portanto causará duas penetrações, enquanto o nginx salvará apenas uma vez, independentemente de o link se tornar http://sudone.com/?1 ou http://sudone.com/; ? 123, não pode ser armazenado em cache pelo nginx, protegendo efetivamente o host de back-end.
O nginx salvará fielmente o formulário do link no sistema de arquivos, de modo que, para um link, você possa verificar facilmente o status e o conteúdo do cache na máquina de cache e também possa cooperar facilmente com outros gerenciadores de arquivos, como rsync Use-o. é completamente uma estrutura de sistema de arquivos.
Ambos os caches tradicionais podem salvar arquivos em /dev/shm no Linux. Geralmente, eu faço isso para que a memória do sistema possa ser usada para armazenamento em cache. Se a memória for usada, o conteúdo de expiração será limpo muito mais rapidamente. Ao usar /dev/shm/, além de apontar o diretório tmp para a partição /dev/shm, se houver um grande número de arquivos e diretórios pequenos, você também deve modificar o número de inodes e a capacidade máxima desta memória partição:
montar -o tamanho=2500M -o nr_inodes=480000 -o noatime,nodiratime -o remontar /dev/shm
O comando acima é usado em uma máquina com memória 3G Como a memória máxima padrão de /dev/shm é metade da memória do sistema, que é 1500M, este comando aumentará para 2500M. os inodes do sistema podem não ser suficientes por padrão, mas o interessante é que pode ser ajustado à vontade. O ajuste aqui é 480.000, o que é um pouco conservador, mas é basicamente suficiente.
3. Cache baseado em mem cache d
O nginx tem algum suporte para memcached , mas a função não é particularmente forte e o desempenho ainda é muito bom.
localização /mem/ {
se ( $uri ~ "^/mem/([0-9A-Za-z_]*)$" )
{
defina $memcached_key "$1";
memcached_pass 192.168.1.2:11211;
}
expira em 70;
}
Esta configuração apontará http://sudone.com/mem/abc para a chave abc do memcached para recuperar dados.
O nginx atualmente não possui nenhum mecanismo para gravar no memcached, portanto, a gravação de dados no memcached deve ser feita usando a linguagem dinâmica em segundo plano. Você pode usar 404 para direcionar ao back-end para gravar dados.
4. Baseado no plug-in ncache de terceiros
ncache é um bom projeto desenvolvido pela Sina Brothers. Ele usa nginx e memcached para implementar algumas funções semelhantes ao cache do Squid. Não tenho experiência no uso deste plug-in.
http://code.google.com/p/ncache/
5. A função proxy_cache recém-desenvolvida do nginx
A partir da versão nginx-0.7.44, o nginx suporta uma função de cache mais formal semelhante ao Squid. Ele ainda está em estágio de desenvolvimento e o suporte é bastante limitado. Este cache salva o link após hash com codificação md5, para que possa suportar. qualquer link Ao mesmo tempo, status diferentes de 200, como 404/301/302, também são suportados.
Configuração:
Primeiro configure um espaço de cache:
proxy_cache_path /caminho/para/níveis de cache=1:2 keys_zone=NOME:10m inativo=5m max_size=2m clean_time=1m;
Observe que esta configuração está fora da tag do servidor. Níveis especifica que o espaço de cache possui dois níveis de diretórios hash. O diretório do primeiro nível tem 1 letra e o segundo nível tem 2 letras. O nome do arquivo salvo será semelhante a /path/. to/cache /c/29/b7f54b2df7773722d382f4809d65029c; keys_zone dá um nome a este espaço, 10m significa que o tamanho do espaço é 10MB; clean_time especifica um minuto. Limpe o cache uma vez.
localização/{
proxy_pass http://www.sudone.com/;
proxy_cache NAME;#Use NAME keys_zone
proxy_cache_valid 200 302 1h;#200 e 302 códigos de status são salvos por 1 hora
proxy_cache_valid 301 1d;#301 código de status é salvo por um dia
proxy_cache_valid qualquer 1m;#Outros são salvos por um minuto
}