A exclusão do cache NGINX coloca erros críticos de desvinculação no log de erros

As informações neste post são baseadas no cache FastCGI no NGINX 1.4.6 rodando no Ubuntu Server 14.04 x64. Pode ou não ser válido para outras versões.

(Atualização 2025: No período entre a redação do post original e agora, muita coisa mudou. Os servidores estão mais rápidos e baratos, então eu não recomendaria a abordagem descrita neste post, onde tento microgerenciar a expiração do cache apenas para salvar algumas gerações extras de conteúdo dinâmico. Deixarei o conteúdo aqui para referência futura e caso alguém realmente precise dele por qualquer motivo. Não confirmei se isso ainda funciona para as versões atuais do NGINX, mas acho que funciona).

Depois de migrar vários sites do Apache para o NGINX, passei a gostar muito de seus recursos de cache integrados, que funcionam extremamente bem na maioria das circunstâncias sem muita interferência minha.

No entanto, para um dos sites, eu realmente precisava da capacidade de limpar o cache (tanto completamente quanto remover entradas individuais) eu mesmo. A edição gratuita da comunidade do NGINX suporta apenas expiração de cache baseada em tempo (ou seja, você pode configurá-lo para verificar se algo mudou após uma hora, um dia, etc.). Mas e se não houver uma maneira confiável de determinar com antecedência quando um determinado recurso mudará? Por exemplo, não tenho ideia se levará uma hora, um dia ou um ano antes de voltar e editar algo neste post - e por que armazenar em cache apenas por uma hora se armazenar em cache por um dia teria sido bom?

É aqui que a capacidade de limpar o cache manualmente (ou fazendo com que seu aplicativo da web notifique o NGINX de que algo deve ser expurgado) é necessária. As pessoas por trás do NGINX estão claramente cientes da necessidade disso, pois o recurso é suportado na versão paga do produto deles – mas, embora eles certamente tenham o direito de configurar seu licenciamento da maneira que quiserem, o preço é um pouco alto para mim quando essa função é o único recurso pago de que realmente preciso.

Felizmente, acontece que você pode simplesmente excluir arquivos do diretório de cache e o NGINX vai perceber isso e buscar uma nova cópia do seu back-end sem problemas. No entanto, se você fizer isso sem ajustar sua configuração, provavelmente verá um monte de mensagens semelhantes a esta no seu log de erros depois de um tempo:

Parece que esses erros ocorrem quando o próprio NGINX tenta excluir entradas de cache após o tempo especificado pelo parâmetro inactive da diretiva fastcgi_cache_path . O padrão para isso é apenas 10 minutos, mas você pode defini-lo para qualquer valor que desejar. Se você defini-lo para, digamos, 10 anos, é provavelmente improvável que você não tenha reiniciado o servidor nesse meio tempo, então o índice de chave na memória teria sido limpo nesse meio tempo. Se você fizer isso, precisa ter certeza de limpar o cache você mesmo, o NGINX não fará mais isso por você.

Acho muito estranho que seja considerado um erro crítico que uma entrada de cache não possa ser excluída porque não existe. O fato de sua classificação de gravidade ser tão alta significa que é impossível se livrar dela apenas ignorando entradas de log abaixo de um certo limite. Assim que uma nova cópia for obtida do back-end, a entrada existirá novamente, então isso deve ser um aviso no máximo, na minha opinião.

Agora, se a entrada de cache não pudesse ser excluída devido a problemas com permissões ou algo assim, isso seria um erro crítico, porque poderia fazer com que o NGINX continuasse servindo conteúdo em cache muito depois do tempo de expiração, mas o processo de limpeza não parece fazer essa distinção.