CDN:Limpeza e pré-busca de recursos

Limpeza de recursos

Uma operação de limpeza envia um comando de invalidação de cache para os nós de borda, em vez de excluir arquivos diretamente. Ao receber esse comando, o nó de borda marca os recursos correspondentes em cache como "inválidos" ou "expirados". Na próxima solicitação do usuário, o nó detecta que o cache está inválido, busca a versão mais recente na origem e a entrega ao usuário, armazenando simultaneamente a nova versão em cache.

Método padrão de limpeza no console: Ao executar uma limpeza de diretório ou baseada em expressão regular no console CDN, o sistema usa uma limpeza suave por padrão. Esse tipo de limpeza apenas marca o cache como expirado. Quando o nó de borda busca dados na origem, ele inclui um cabeçalho If-Modified-Since ou If-None-Match na solicitação. Caso o servidor de origem retorne uma resposta 304 Not Modified, o nó de borda mantém a cópia antiga em cache. Embora essa abordagem economize tráfego de retorno à origem, ela pode fazer com que os usuários acessem conteúdo desatualizado em situações como atualizações de arquivos com o mesmo nome, remoção de conteúdo não conforme ou após mudanças de configuração. Para limpar completamente o cache, recomendamos chamar a operação de API purgeObjectCaches e definir o parâmetro Force como true para executar uma limpeza forçada.

Casos de uso

• Atualizações e lançamentos de recursos: Após atualizar ou fazer upgrade de recursos no servidor de origem, envie as URLs ou diretórios correspondentes para limpeza. Isso garante que os usuários acessem o conteúdo mais recente, que será então armazenado em cache nos nós de borda.

• Remoção de recursos não conformes: Se o seu site contiver conteúdo não conforme, excluí-lo apenas do servidor de origem não é suficiente, pois ele ainda pode existir no cache dos nós de borda. Realize uma limpeza de URL para remover os recursos em cache e assegurar que o conteúdo inadequado seja eliminado prontamente.

Pré-busca de recursos

A operação de pré-busca é um mecanismo baseado em pull que faz com que os nós de borda busquem proativamente recursos do servidor de origem e os armazenem em cache. Não se trata de um push vindo do servidor de origem. A pré-busca melhora a velocidade de acesso inicial para novos recursos ou páginas de eventos e reduz a pressão de retorno à origem durante lançamentos de products ou eventos, protegendo assim o servidor de origem.

Mecanismo de pré-busca: Por padrão, uma operação de pré-busca armazena recursos nos nós de retorno à origem de Nível 2 (a camada de cache L2), em vez de distribuí-los para todos os nós de borda L1. Quando um usuário acessa um recurso pela primeira vez, o nó de borda L1 puxa o conteúdo de um nó de retorno à origem de Nível 2 ou do próprio servidor de origem e o armazena em cache. Portanto, a pré-busca serve principalmente para reduzir a carga no servidor de origem. A cobertura abrangente de cache nos nós de borda L1 depende dos padrões reais de acesso dos usuários. Somente após a solicitação de um usuário acionar um nó L1 para armazenar o conteúdo localmente é que os usuários subsequentes na mesma região poderão se beneficiar de um acerto direto de cache nesse nó L1.

Casos de uso

• Configuração inicial da CDN: Após adicionar seu domínio à CDN, faça a pré-busca de recursos estáticos populares para os nós de borda. Quando os usuários solicitarem esses recursos, os nós de borda poderão responder diretamente, eliminando tempos lentos de carregamento inicial e melhorando a experiência do usuário.

• Lançamento de eventos promocionais: Antes de um grande evento, realize a pré-busca de todos os recursos estáticos das páginas do evento. Quando o evento começar, todos os recursos estáticos já estarão em cache nos nós de borda e poderão ser servidos diretamente, garantindo tempos rápidos de carregamento da página.

• Lançamento de pacotes de instalação ou arquivos grandes: Antes de lançar uma nova versão ou pacote de atualização, faça a pré-busca dos recursos para os nós de borda. Depois que o product entrar em produção, os nós de borda atenderão às solicitações de download diretamente, o que aumenta as velocidades de download e reduz a carga no servidor de origem.

Hierarquia de cache de pré-busca e resultados esperados

Uma operação de pré-busca armazena recursos principalmente nos nós de agregação L2, e não em todos os nós de borda L1 (POPs). Quando um usuário solicita um recurso pré-buscado pela primeira vez, o POP L1 o recupera do nó L2 ou do servidor de origem. Assim, o objetivo principal da pré-busca é reduzir a pressão no servidor de origem, e não garantir acertos imediatos de cache em todos os POPs L1.

• Avaliação de custos: A pré-busca ajuda a melhorar as taxas de acerto de cache. No entanto, para arquivos pequenos ou recursos pouco acessados, avalie cuidadosamente o custo da pré-busca. Essa operação gera tráfego de retorno à origem, que é aproximadamente igual ao tamanho do arquivo multiplicado pelo número de nós L2.

Limpar recursos

1. Faça login no console CDN.

2. No painel de navegação à esquerda, clique em Purge and Prefetch.

3. Na aba Purge/Prefetch, selecione Purge como o tipo de operação.

4. Selecione um tipo de limpeza e envie a tarefa.

Como limpar um site inteiro (limpeza de site completo ou limpeza de diretório raiz)

A CDN não oferece uma opção de limpeza de site completo com um clique, mas você pode conseguir isso através dos seguintes métodos:

1. Limpeza de diretório: Selecione Directory como método de limpeza e insira a URL do diretório raiz do seu nome de domínio (por exemplo, https://<accelerated domain name>/). A URL deve terminar com uma barra (/).

2. Limpeza forçada (API): Se alguns POPs ainda servirem conteúdo desatualizado após uma limpeza de diretório, chame a Cache Purge API (RefreshObjectCaches) e defina o parâmetro Force como true. Uma limpeza forçada remove incondicionalmente os recursos em cache de todos os POPs, forçando uma busca na origem na próxima solicitação.

   Nota

   O parâmetro Force não está disponível no formulário de limpeza do console. Para realizar uma limpeza forçada, use a API ou SDK.

3. Clique em Submit para iniciar a tarefa de limpeza.

   • Depois de enviada, uma tarefa de limpeza não pode ser cancelada.

   • Uma tarefa de limpeza geralmente leva de 5 a 6 minutos para se propagar por toda a rede. Se um recurso em cache tiver um tempo de expiração menor que esse, não é necessário limpá-lo manualmente.

   • Se você ativar a limpeza automatic CDN cache no console OSS, não poderá visualizar as tarefas de limpeza automática iniciadas a partir do OSS no console CDN.

Pré-buscar recursos

1. Faça login no console CDN.

2. No painel de navegação à esquerda, clique em Purge and Prefetch.

3. Na aba Purge/Prefetch, selecione Prefetch como o tipo de operação.

4. Na caixa de entrada de URL, insira as URLs completas dos arquivos para pré-busca, uma por linha. A pré-busca de diretórios não é suportada. Exemplo: https://<accelerated domain name>/install/package.zip.

5. Clique em Submit para iniciar a tarefa de pré-busca.

   • Depois de enviada, uma tarefa de pré-busca não pode ser cancelada.

   • O tempo de conclusão de uma tarefa de pré-busca depende do tamanho do arquivo, da quantidade de arquivos e do desempenho do servidor de origem. Geralmente, leva de 5 a 30 minutos.

Observações sobre a pré-busca de arquivos OSS

Quando seu servidor de origem é o OSS, observe os seguintes requisitos de URL:

• Formato de URL: Insira a URL completa do nome de domínio acelerado pela CDN (por exemplo, https://cdn.example.com/path/file.zip). Não insira a URL do endpoint interno ou público do bucket OSS (por exemplo, https://<Origin Domain Name>/...).

• Parâmetros de assinatura: As URLs de pré-busca não devem conter parâmetros de assinatura temporária do OSS, como Expires, OSSAccessKeyId ou Signature. Esses são parâmetros de autorização temporária que causam falha nas tarefas de pré-busca.

• Código de status de resposta do servidor de origem: Uma tarefa de pré-busca requer um código de status 200 do servidor de origem. Se o servidor de origem retornar um redirecionamento 308 ou qualquer código de status diferente de 200, a tarefa de pré-busca falhará. Por exemplo, se a falta de uma barra final na URL causar um redirecionamento, adicione a barra final e reenvie a tarefa.

Automatizar tarefas de limpeza ou pré-busca

Recomendamos que você use an automated script to purge and prefetch resources nas seguintes situações:

• Você não tem desenvolvedores para automatizar tarefas e enviá-las manualmente resulta em altos custos operacionais.

• Você tem muitas URLs para limpar ou pré-buscar e enviá-las em lotes é ineficiente.

• Você precisa verificar manual ou programaticamente se as tarefas de limpeza e pré-busca estão sendo executadas conforme o esperado.

~ % curl -I http://oss.xxx.cn/1.png
HTTP/1.1 200 OK
Server: Tengine
Content-Type: image/png
Content-Length: 1605553
Connection: keep-alive
Date: Sun, 23 Feb 2025 15:33:38 GMT
x-oss-request-id: 67BB3Fxxx32B63123
x-oss-cdn-auth: success
Accept-Ranges: bytes
ETag: "469118F2ACF477CACAF4C9xxx"
Last-Modified: Wed, 12 Feb 2025 03:29:36 GMT
x-oss-object-type: Normal
x-oss-hash-crc64ecma: xxx005350070
x-oss-storage-class: Standard
Content-MD5: RpEY8qz0d8rxxx
x-oss-server-time: 103
Via: cache6.12cn2655[196,195,200-0,M], cache15.12cn2655[197,0], kunlun3.cn192[0,0,200-0,H], kunlun7.cn192[3,0]
Age: 69
Ali-Swift-Global-Savetime: 1740324818
X-Cache: HIT TCP_MEM_HIT dirn:-2:-2
X-Swift-SaveTime: Sun, 23 Feb 2025 15:33:38 GMT
X-Swift-CacheTime: 3600
Timing-Allow-Origin: *
EagleId: 3adad01b1740324887846539le

Limpeza suave (política padrão da CDN)

• Caso de uso: Atualizações rotineiras de conteúdo, como publicação de novas versões de arquivos estáticos.

• Mecanismo: Este é o comportamento padrão para limpezas de diretório e baseadas em expressão regular enviadas através do console. Quando um nó de borda da CDN busca dados na origem, ele inclui um cabeçalho If-Modified-Since ou If-None-Match na solicitação. O servidor de origem usa esses cabeçalhos para determinar se o recurso foi atualizado.

• Efeito: Se o recurso no servidor de origem não mudou, o servidor retorna um código de status 304 Not Modified. O nó de borda da CDN continua então a servir a cópia antiga em cache, o que não consome tráfego de retorno à origem. Este é um método otimizado que economiza custos e reduz a carga no servidor de origem. Nota: Se você precisar limpar completamente o cache (por exemplo, para remover conteúdo não conforme, aplicar alterações de configuração ou atualizar um arquivo com o mesmo nome), uma limpeza suave pode não atender às suas necessidades. Nesses casos, use uma limpeza forçada.

Limpeza forçada

• Casos de uso: Remoção urgente de recursos não conformes ou errôneos, forçar uma atualização em toda a rede após corrigir configurações incorretas do cabeçalho de resposta Cache-Control, ou atualizar um arquivo no servidor de origem que tenha o mesmo nome.

• Mecanismo: Para acionar uma limpeza forçada, defina o parâmetro Force como true ao chamar a operação de API RefreshObjectCaches. Neste modo, o nó de borda da CDN marca incondicionalmente o recurso em cache como inválido e não realiza uma verificação de validação 304.

• Efeito: Na próxima solicitação do recurso, o nó de borda da CDN deve buscar a nova versão na origem, mesmo que o arquivo no servidor de origem não tenha mudado.

Exemplo de parâmetro de limpeza forçada via API:

{
  "ObjectType": "Directory",
  "ObjectPath": "https://<accelerated domain name>/static/",
  "Force": true
}

Descrições dos principais parâmetros:

• ObjectType: Especifique Directory ou File.

• ObjectPath: Especifique o caminho completo do diretório terminando com /, ou uma URL de arquivo específica.

• Force: Defina como true para ativar a limpeza forçada. Isso limpa o cache diretamente, ignorando a validação If-Modified-Since/If-None-Match do servidor de origem.

Casos de uso típicos para limpeza forçada

Recomendamos usar a limpeza forçada (chamando a Cache Purge API e definindo Force=true) nos seguintes cenários:

• Remoção de conteúdo não conforme ou malware: Após excluir arquivos maliciosos do servidor de origem, use uma limpeza forçada ou garanta que o servidor de origem retorne o código de status HTTP correto (como 404) para a URL excluída. Caso contrário, os POPs podem continuar a servir conteúdo não conforme do cache após uma revalidação padrão.

• Atualizações de arquivos com o mesmo nome (alterações de configuração): Se você substituir um arquivo no servidor de origem por uma nova versão usando o mesmo nome de arquivo, uma revalidação pode retornar um código de status 304 Not Modified e continuar servindo o conteúdo antigo em cache. Use uma limpeza forçada para garantir que o conteúdo mais recente seja servido em todos os POPs.

• Problemas de exibição de página ou loops na homepage: Se outras páginas do seu site continuarem mostrando a homepage ou imagens forem exibidas incorretamente, e a limpeza de URL não resolver o problema, use uma limpeza de diretório com Force=true através da API.