Liberação do Dispatcher do Adobe Managed Services

Este documento o orientará sobre como ocorre a liberação e explicará sobre o mecanismo que executa a liberação de cache e a invalidação.

Como funciona

Ordem de operação

O fluxo de trabalho usual está melhor descrito quando os autores de conteúdo vão ativar uma página, quando o publicador recebe o novo conteúdo, ele aciona uma solicitação de liberação para o dispatcher, conforme mostrado neste diagrama:

O autor recebe o conteúdo, que aciona o publicador para enviar uma solicitação de liberação para o dispatcher

Essa cadeia de eventos destaca que apenas liberamos os itens novos ou que foram alterados.  Isso garante que o conteúdo tem sido recebido pelo publicador antes de limpar o cache, de forma a evitar condições de corrida, em que a liberação poderia ocorrer antes que as alterações pudessem ser recebidas do publicador.

Agentes de replicação

Durante a criação, há um agente de replicação configurado para apontar para o publicador que, quando algo for ativado, ele acione para enviar o arquivo e todas as suas dependências para o publicador.

Quando o publicador recebe o arquivo, ele possui um agente de replicação configurado para apontar para o dispatcher, que aciona no evento Ao receber.  Em seguida, ele vai serializar uma solicitação de liberação e publicá-la no dispatcher.

Agente de replicação do autor

A seguir estão algumas capturas de tela de exemplo de um agente de replicação padrão configurado

Captura de tela do agente de replicação padrão da página da Web do AEM /etc/replication.html

Geralmente, há 1 ou 2 agentes de replicação configurados no autor para cada publicador com quem replicam conteúdo.

O primeiro é o agente de replicação padrão, que envia ativações de conteúdo.

O segundo é o agente reverso.  Isso é opcional e está configurado para verificar a caixa de saída de cada publicador para ver se há conteúdo novo a ser transmitido para o autor como uma atividade de replicação reversa

Agente de replicação do publicador

A seguir há uma captura de tela de exemplo de um agente de replicação de liberação padrão

Captura de tela do agente de replicação de liberação padrão da página da Web do AEM /etc/replication.html

Replicação de liberação do Dispatcher recebendo host virtual

O módulo do dispatcher procura por cabeçalhos específicos para saber quando uma solicitação POST é algo a ser transmitido para as renderizações do AEM ou se é serializado como uma solicitação de liberação e precisa ser manipulado pelo próprio manipulador do dispatcher.  A seguir está uma captura de tela da página de configuração, que mostra esses valores:

Foto da guia de configurações da tela de configuração principal com o Tipo de serialização mostrado como Liberação do Dispatcher

A página de configuração padrão mostra o Tipo de serialização como Liberação do Dispatcher e define o nível de erro

Captura de tela da guia de transporte do agente de replicação. Isso mostra o URI no qual publicar a solicitação de liberação. /dispatcher/invalidate.cache

Na guia transporte você pode ver o URI ser definido para apontar para o endereço IP do dispatcher que receberá as solicitações de liberação.  O caminho /dispatcher/invalidate.cache não é como o módulo determina se é uma liberação, é apenas um endpont óbvio que você pode ver no log de acesso para saber se era uma solicitação de liberação.  Na guia Expandido, veremos tudo contido ali para qualificar se é uma solicitação de liberação do módulo do dispatcher.

Captura de tela da guia Expandido do agente de replicação. Observe que os cabeçalhos são enviados com a solicitação POST para avisar o dispatcher sobre a liberação

O método HTTP de solicitações de liberação é apenas uma solicitação GET com alguns cabeçalhos de solicitação especial:

  • CQ-Action
    • Usa uma variável do AEM com base na solicitação, e o valor geralmente é ativar ou excluir
  • CQ-Handle
    • Usa uma variável do AEM com base na solicitação, e o valor geralmente é o caminho completo para o item liberado, por exemplo /content/dam/logo.jpg
  • CQ-Path
    • Usa uma variável do AEM com base na solicitação, e o valor geralmente é o caminho completo para o item que está sendo liberado, por exemplo /content/dam
  • Host
    • É aqui que o cabeçalho do host é falsificado para direcionar um <VirtualHost> específico que está configurado no servidor Web Apache do dispatcher (/etc/httpd/conf.d/enabled_vhosts/aem_flush.vhost).  O valor inserido no código que corresponde a uma entrada no ServerName ou ServerAlias do arquivo aem_flush.vhost
Tela de um agente de replicação padrão mostrando que o agente de replicação reage e aciona quando novos itens são recebido de um evento de replicação do conteúdo de publicação do autor

Na guia Acionadores, observaremos os acionadores alternados usado e onde eles estão

  • Ignorar padrão
    • Essa opção fica ativada para que o agente de replicação não seja acionado durante a ativação de página.  Isso é algo que acionaria uma liberação quando uma instância do autor fizesse uma alteração na página.  Como é um publicador, não queremos desativar esse tipo de evento.
  • Ao receber
    • Quando um novo arquivo é recebido, queremos acionar uma liberação.  De forma que quando o autor nos envia um arquivo atualizado, nós acionaremos e enviaremos uma solicitação de liberação para o dispatcher.
  • Nenhum controle de versão
    • Marcamos essa opção para evitar que o publicador gere novas versões, pois um novo arquivo foi recebido.  Substituiremos o arquivo que temos e confiaremos que o autor vai monitorar as versões, em vez do publicador.

Agora, observaremos a aparência usual de uma solicitação de liberação na forma de um comando curl

$ curl \ 
-H "CQ-Action: Activate" \ 
-H "CQ-Handle: /content/dam/logo.jpg" \ 
-H "CQ-Path: /content/dam/" \ 
-H "Content-Length: 0" \  
-H "Content-Type: application/octect-stream" \ 
-H "Host: flush" \ 
http://10.43.0.32:80/dispatcher/invalidate.cache

Este exemplo liberaria o caminho /content/dam ao atualizar o arquivo .stat nesse diretório.

O arquivo .stat

O mecanismo de liberação é de natureza simples e queremos explicar a importância dos arquivos .stat gerados na raiz do documento onde os arquivos em cache são criados.

Dentro dos arquivos .vhost and _farm.any, nós configuramos uma diretiva da raiz do documento para especifica onde armazenar / veicular arquivos quando entra uma solicitação de um usuário final.

Se for executar o comando a seguir no servidor do dispatcher, começará localizando os arquivos .stat

 

$ find /mnt/var/www/html/ -type f -name ".stat"

Aqui está um diagrama da aparência dessa estrutura de arquivo ao armazenar itens em cache e enviar uma solicitação de liberação processada pelo módulo do dispatcher

Arquivos stat misturados ao conteúdo e datas mostradas com os níveis de stat mostrados

Nível do arquivo stat

Observe que em cada diretório havia um arquivo .stat presente.  Isso é um indicador de que ocorreu uma liberação.  No exemplo acima, a configuração statfilelevel estava definida como 3 dentro do arquivo de configuração farm correspondente.

A configuração statfilelevel indica quantas pastas o módulo percorrerá para atualizar um arquivo .stat.  O arquivo .stat está vazio e nada mais que um nome de arquivo com um carimbo de data e hora poderia ser criado manualmente além da execução do comando de toque na linha de comando do servidor do dispatcher.

Se a configuração de nível do arquivo stat for definida como muito alta, cada solicitação de liberação percorrerá a árvore de diretório tocando os arquivos files.  Isso pode se tornar uma importante ocorrência de desempenho em árvores de cache grandes, além de impactar o desempenho geral do dispatcher.

Definir esse nível de arquivo como muito baixo pode fazer com que uma solicitação de liberação limpe mais do que o esperado.  Isso faria com que o cache fosse retido com mais frequência, com menos solicitações sendo vinculadas do cache, o que pode causar problemas de desempenho.

Observação:

Defina o statfilelevel a um nível razoável.  Olhe sua estrutura de pasta e certifique-se de que esteja configurada para permitir liberações concisas sem ter que percorrer por muitos diretórios.   Teste e certifique-se de que se ajusta a suas necessidades durante um teste de desempenho do sistema.

Um bom exemplo é um site compatível com idiomas.  A árvore de conteúdo usual teria os seguintes diretórios

/content/brand1/en/us/

Neste exemplo, use um configuração de nível 4 do arquivo stat.  Isso garantirá que, ao liberar o conteúdo contido na pasta us, ele não fará com que as pastas de idioma também sejam liberadas.

Interação do carimbo de data e hora do arquivo stat

Quando uma solicitação de conteúdo é recebida, ocorre a mesma rotina

  1. O carimbo de data e hora do arquivo .stat é comparado ao do arquivo solicitado
  2. Se o arquivo .stat for mais novo que o arquivo solicitado, ele excluirá o conteúdo em cache e obterá um novo a partir do AEM e, em seguida, o armazenará em cache.  Depois disso, vinculará o conteúdo
  3. Se o arquivo .stat for mais antigo que o arquivo solicitado, ele saberá que o arquivo é novo e pode vincular o conteúdo.

Interação de cache - Exemplo 1

No exemplo acima, uma solicitação para o conteúdo /content/index.html

A data e hora do arquivo index.html é 01/11/2019 às 18:21

A data e hora do arquivo .stat mais recente é 01/11/2019 às 12:22

Ao entender o que lemos acima, você pode perceber que o arquivo index é mais recente que o arquivo .stat, e o arquivo seria vinculado do cache para o usuário final que o solicitou

Interação de cache - Exemplo 2

No exemplo acima, uma solicitação para o conteúdo /content/dam/logo.jpg

A data e hora do arquivo logo.jpg é 31/10/2019 às 13:13

A data e hora do arquivo .stat mais recente é 01/11/2019 às 12:22

Como pode ver neste exemplo, o arquivo é mais antigo que o arquivo .stat e será removido, e uma arquivo novo trazido do AEM o substituirá no cache antes de ser vinculado ao usuário final que o solicitou.

Configurações do arquivo farm

Toda a documentação do conjunto completo de opções de configuração consta aqui: https://docs.adobe.com/content/help/pt-BR/experience-manager-dispatcher/using/configuring/dispatcher-configuration.html#configuring-dispatcher_configuring-the-dispatcher-cache-cache

Destacaremos algumas delas que pertencem à liberação de cache

Raiz do documento

Esta entrada de configuração consta na seguinte seção do arquivo farm:

/myfarm { 
    /cache { 
        /docroot

Você especifica o diretório o qual deseja que o dispatcher preencha e gerencie como um diretório de cache.

Observação:

Esse diretório deve corresponder à configuração da raiz do documento apache do domínio para o qual o servidor da Web está configurado para usar.

Ter pastas docroot aninhadas para cada farm contido nas subpastas da raiz do documento apache é uma péssima ideia por diversos motivos.

Nível dos arquivos stat

Esta entrada de configuração consta na seguinte seção do arquivo farm:

/myfarm { 
    /cache { 
        /statfileslevel

Esta configuração mede a qual profundidade os arquivos .stat precisarão ser gerados quando entrar uma solicitação de liberação.

O /statfileslevel definido como o seguinte número com a raiz do documento de /var/www/html/ terias os resultados a seguir durante a liberação /content/dam/brand1/en/us/logo.jpg

  • 0 - os arquivos stat a seguir seriam criados
    • /var/www/html/.stat
  • 1 - os arquivos stat a seguir seriam criados
    • /var/www/html/.stat
    • /var/www/html/content/.stat
  • 2 - os arquivos stat a seguir seriam criados
    • /var/www/html/.stat
    • /var/www/html/content/.stat
    • /var/www/html/content/dam/.stat
  • 3 - os arquivos stat a seguir seriam criados
    • /var/www/html/.stat
    • /var/www/html/content/.stat
    • /var/www/html/content/dam/.stat
    • /var/www/html/content/dam/brand1/.stat
  • 4 - os arquivos stat a seguir seriam criados
    • /var/www/html/.stat
    • /var/www/html/content/.stat
    • /var/www/html/content/dam/.stat
    • /var/www/html/content/dam/brand1/.stat
    • /var/www/html/content/dam/brand1/en/.stat
  • 5 - os arquivos stat a seguir seriam criados
    • /var/www/html/.stat
    • /var/www/html/content/.stat
    • /var/www/html/content/dam/.stat
    • /var/www/html/content/dam/brand1/.stat
    • /var/www/html/content/damn/brand1/en/.stat
    • /var/www/html/content/damn/brand1/en/us/.stat

 

Observação:

Lembre-se que quando ocorre a interação do carimbo de data e hora, ela procura pelo arquivo .stat mais próximo.

Ter um nível 0 de arquivo .stat e um arquivo stat somente em /var/www/html/.stat significa que o conteúdo contido em /var/www/html/content/dam/brand1/en/us/ procuraria pelo arquivo .stat mais próximo, percorreria por até 5 pastas para encontra o único arquivo .stat existente no nível 0 e compararia as datas.  Isso significa que uma liberação de nível tão alto invalidaria todos os itens em cache.

Invalidação permitida

Esta entrada de configuração consta na seguinte seção do arquivo farm:

/myfarm { 
    /cache { 
        /allowedClients {

Você coloca nesta configuração uma lista de endereços IP permitidos para enviar solicitações de liberação.  Se uma solicitação de liberação entrar no dispatcher, ela deverá vir de um IP confiável.  Caso esteja com uma configuração incorreta ou envia uma solicitação de liberação de um endereço IP não confiável, você verá o erro a seguir no arquivo de log:

[Mon Nov 11 22:43:05 2019] [W] [pid 3079 (tid 139859875088128)] Flushing rejected from 10.43.0.57

Regras de invalidação

Esta entrada de configuração consta na seguinte seção do arquivo farm:

/myfarm { 
    /cache { 
        /invalidate {

Essas regras geralmente indicam quais arquivos podem ser invalidados com uma solicitação de liberação.

Para evitar que arquivos importantes sejam invalidado com uma ativação de página, coloque regras que especifiquem quais arquivos podem ser invalidados e quais devem ser invalidados manualmente.  Aqui está um conjunto de amostras das configurações que permitem que apenas arquivos html sejam invalidados:

/invalidate { 
   /0000 { /glob "*" /type "deny" } 
   /0001 { /glob "*.html" /type "allow" } 
}

Teste/Solução de problemas

Ao ativar a página e observar a luz verde indicando que a ativação de página foi bem-sucedida, deverá esperar que o conteúdo ativado também seja liberado do cache.

Atualize a página e veja os arquivos antigos. O quê? Tinha uma luz verde?!

Vamos seguir algumas etapas manuais do processo de liberação para nos informarmos sobre o que poderia dar errado.  A partir do shell do publicador, execute a solicitação de liberação a seguir usando o curl:

 

$ curl -H "CQ-Action: Activate" \ 
-H "CQ-Handle: /content/<PATH TO ITEM TO FLUSH>" \ 
-H "CQ-Path: /content/<PATH TO ITEM TO FLUSH>" \ 
-H "Content-Length: 0" -H "Content-Type: application/octet-stream" \ 
-H "Host: flush" \ 
http://<DISPATCHER IP ADDRESS>/dispatcher/invalidate.cache

Teste de solicitação de liberação de exemplo

$ curl -H "CQ-Action: Activate" \ 
-H "CQ-Handle: /content/customer/en-us" \ 
-H "CQ-Path: /content/customer/en-us" \ 
-H "Content-Length: 0" -H "Content-Type: application/octet-stream" \ 
-H "Host: flush" \ 
http://169.254.196.222/dispatcher/invalidate.cache

Após desativar o comano de solicitação do dispatcher, desejará ver o que foi feito com os logs e com os arquivos .stat.  Siga o arquivo de log e você verá as seguintes entradas para confirmar a ocorrência de solicitação de liberação do módulo do dispatcher

[Wed Nov 13 16:54:12 2019] [I] [pid 19173:tid 140542721578752] Activation detected: action=Activate [/content/dam/logo.jpg] 
[Wed Nov 13 16:54:12 2019] [I] [pid 19173:tid 140542721578752] Touched /mnt/var/www/html/.stat 
[Wed Nov 13 16:54:12 2019] [I] [pid 19173:tid 140542721578752] Touched /mnt/var/www/html/content/.stat 
[Wed Nov 13 16:54:12 2019] [I] [pid 19173:tid 140542721578752] Touched /mnt/var/www/html/content/dam/.stat 
[Wed Nov 13 16:54:12 2019] [I] [pid 19173:tid 140542721578752] "GET /dispatcher/invalidate.cache" 200 purge [publishfarm/-] 0ms

Agora que vemos o módulo selecionado e reconhecemos a solicitação de liberação, precisamos ver como ele afetou os arquivos .stat.  Execute o comando a seguir e veja os carimbos de data e hora serem atualizados conforme emite outra liberação:

$ watch -n 3 "find /mnt/var/www/html/ -type f -name ".stat" | xargs ls -la $1"

Como pode ver da saída de comando, os carimbos de data e hora dos arquivos .stat atuais

-rw-r--r--. 1 apache apache 0 Nov 13 16:54 /mnt/var/www/html/content/dam/.stat 
-rw-r--r--. 1 apache apache 0 Nov 13 16:54 /mnt/var/www/html/content/.stat 
-rw-r--r--. 1 apache apache 0 Nov 13 16:54 /mnt/var/www/html/.stat

Agora, se executarmos a liberação novamente, você verá os carimbos de data e hora serem atualizados

-rw-r--r--. 1 apache apache 0 Nov 13 17:17 /mnt/var/www/html/content/dam/.stat 
-rw-r--r--. 1 apache apache 0 Nov 13 17:17 /mnt/var/www/html/content/.stat 
-rw-r--r--. 1 apache apache 0 Nov 13 17:17 /mnt/var/www/html/.stat

Vamos comparar nossos carimbos de data e hora de conteúdo aos dos arquivos .stat

$ stat /mnt/var/www/html/content/customer/en-us/.stat 
  File: `.stat' 
  Size: 0           Blocks: 0          IO Block: 4096   regular empty file 
Device: ca90h/51856d    Inode: 17154125    Links: 1 
Access: (0644/-rw-r--r--)  Uid: (   48/  apache)   Gid: (   48/  apache) 
Access: 2019-11-13 16:22:31.000000000 -0400 
Modify: 2019-11-13 16:22:31.000000000 -0400 
Change: 2019-11-13 16:22:31.000000000 -0400 
 
$ stat /mnt/var/www/html/content/customer/en-us/logo.jpg 
File: `logo.jpg' 
  Size: 15856           Blocks: 32          IO Block: 4096   regular file 
Device: ca90h/51856d    Inode: 9175290    Links: 1 
Access: (0644/-rw-r--r--)  Uid: (   48/  apache)   Gid: (   48/  apache) 
Access: 2019-11-11 22:41:59.642450601 +0000 
Modify: 2019-11-11 22:41:59.642450601 +0000 
Change: 2019-11-11 22:41:59.642450601 +0000

Se olhar para qualquer carimbo de data e hora observará que o conteúdo tem um horário mais recente que o arquivo .stat, o que informa o módulo a ser vinculado ao arquivo do cache, pois ele é mais recente que o arquivo .stat.

Resumindo, algo atualizou os carimbos de data e hora deste arquivo, o que não o qualifica como "liberado" ou substituído.

Próximo ➡ Vanity URLs

Logotipo da Adobe

Fazer logon em sua conta