Este guia fornece uma compreensão e uma imagem geral das funcionalidades de fiabilidade do Pub/Sub.
Porquê o Pub/Sub?
Como paradigma de mensagens, a publicação/subscrição foi concebida para separar os produtores de mensagens dos consumidores dessas mensagens. Em vez de os produtores enviarem pedidos diretos aos consumidores com os dados, publicam esses dados num serviço Pub/Sub, como o Pub/Sub. O serviço envia essas mensagens de forma assíncrona aos consumidores interessados que subscreveram.
O resultado é que o serviço absorve todas as complexidades de encontrar consumidores interessados nos dados. O serviço também gere a taxa à qual os consumidores recebem os dados, com base na respetiva capacidade. A desvinculação permite que os produtores de dados escrevam mensagens em grande escala com baixa latência, independentemente do comportamento dos consumidores.
O Pub/Sub oferece uma entrega de mensagens altamente escalável e fiável. Embora o serviço trate grande parte disto automaticamente, tem controlo sobre diferentes aspetos dos seus publicadores e subscritores que podem afetar a disponibilidade e o desempenho. O resto deste guia fornece alguns detalhes sobre estes aspetos.
Isolamento
Por predefinição, o Pub/Sub é um serviço global: os tópicos e as subscrições
não estão inerentemente associados a regiões específicas, e as mensagens fluem no
serviço Pub/Sub entre regiões quando necessário. Quando usa o ponto final global, os publicadores e os subscritores ligam-se à região mais próxima da rede onde o Pub/Sub é executado.pubsub.googleapis.com Quando usa os endpoints regionais, como us-central1-pubsub.googleapis.com, ou os endpoints de localização, como pubsub.us-central1.rep.googleapis.com, os publicadores e os subscritores ligam-se ao Pub/Sub na região especificada. Quando executa
publicadores ou subscritores fora de Google Cloud, é melhor usar
pontos finais regionais ou de localização para garantir que as mensagens fluem entre as
regiões esperadas de forma consistente.
Isolamento regional
Para minimizar a infraestrutura da qual as operações de publicação e subscrição dependem fora de uma única região e para garantir que todos os dados permanecem isolados nessa região, siga estes passos:
Crie um tópico por região.
Embora o espaço de nomes do Pub/Sub seja global e não possa associar tópicos e subscrições a uma região específica, os metadados de todos os recursos são replicados para repositórios de dados locais na região. Por conseguinte, depois de criar um recurso, a respetiva configuração fica disponível mesmo em caso de um problema noutra região. Tenha em atenção que as atualizações às configurações do tópico ou da subscrição podem não ser propagadas imediatamente em caso de indisponibilidade.
Evite usar pontos finais globais.
Em alternativa, use endpoints regionais, quando disponíveis, e endpoints de localização, quando os endpoints regionais não estiverem disponíveis. Os pontos finais regionais oferecem um maior isolamento regional, mas ainda não estão disponíveis em todas as regiões.
Use uma política de armazenamento de mensagens e defina
enforceInTransitcomoTrue.Com a opção Aplicar em trânsito ativada, os dados nunca saem da região e todos os clientes que se ligam ao tópico numa região específica definem a política de armazenamento de mensagens para essa região.
Com os tópicos configurados desta forma, pode ter a certeza de que todas as operações de publicação e subscrição escrevem e leem dados exclusivamente na região. No caso de falhas do publicador, subscritor ou Pub/Sub numa única região, a entrega de mensagens é interrompida nessa região. A entrega de mensagens sobre tópicos e subscrições para outras regiões não é afetada.
Se também precisar que as operações administrativas e o espaço de nomes dos seus tópicos e subscrições estejam isolados regionalmente, considere usar o Managed Service for Apache Kafka.
Failover
Se não precisar de isolamento regional, pode tirar partido da capacidade do Pub/Sub de enviar mensagens de forma eficiente em várias regiões para alcançar capacidades de comutação por falha multirregional. O resto desta secção aborda a forma de criar tópicos e subscrições, bem como de posicionar publicadores e subscritores para suportar diferentes tipos de comutação por falha e redundância de dados.
Semântica de comutação por falha predefinida
Considere um caso em que existe um único tópico e subscrição. Os publicadores estão localizados em regiões dos Estados Unidos e da Austrália, e os subscritores estão localizados nas Google Cloud regiões da Europa e da Austrália. No caso em que todos os subscritores têm capacidade suficiente para receber mensagens, o fluxo de mensagens é o seguinte:
Os P representam os publicadores e os S representam os subscritores. O hexágono azul representa o serviço Pub/Sub. Os cilindros representam os locais onde as mensagens são armazenadas (as mensagens são sempre mantidas em várias zonas na região onde são publicadas). O Pub/Sub prefere enviar mensagens na mesma região onde foram publicadas quando existem subscritores disponíveis. Caso contrário, envia as mensagens para a região mais próxima da rede com subscritores que tenham capacidade. Por conseguinte, conforme mostrado na imagem anterior, as mensagens publicadas nos Estados Unidos são entregues aos subscritores na Europa, e as mensagens publicadas na Austrália permanecem na Austrália.
As secções seguintes abordam o que acontece em diferentes cenários de falha.
Os subscritores na Europa estão indisponíveis
Suponha que os subscritores na Europa foram recusados ou falham frequentemente e não conseguem manter uma ligação ao Pub/Sub. Se isto ocorresse, o serviço começaria a entregar mensagens aos subscritores na Austrália:
Os subscritores na Europa e na Austrália não estão disponíveis
Se todos os subscritores estiverem indisponíveis, o Pub/Sub armazena as mensagens até à duração de retenção de mensagens configurada.
Assim que os subscritores restabelecerem a ligação, as mensagens são entregues, a menos que a indisponibilidade dure mais do que a duração da retenção de mensagens configurada. Por predefinição, a retenção de mensagens de subscrição está definida para 7 dias. Também pode configurar a retenção de mensagens num tópico durante um máximo de 31 dias. Não escolha uma duração de retenção de mensagens inferior à indisponibilidade máxima que espera ou está disposto a tolerar.
O Pub/Sub não está disponível na Europa
Embora seja raro, também pode querer lidar com casos em que o Pub/Sub está indisponível. A indisponibilidade do Pub/Sub manifesta-se como períodos prolongados de erros inesperados em pedidos de publicação ou subscrição, ou a incapacidade de entregar mensagens publicadas aos subscritores. Por exemplo, se o Pub/Sub estivesse indisponível na região da Europa, o cenário seria muito semelhante ao de quando os subscritores estão indisponíveis:
Tenha em atenção que, neste caso, os subscritores na Europa não transitam para outra região, mesmo que usem o ponto final global. O Pub/Sub não faz intencionalmente a comutação por falha automática. Imagine que são os próprios subscritores que estão a causar um problema inesperado no Pub/Sub que resulta na indisponibilidade. Este tipo de problema é tratado como uma indisponibilidade grave. No entanto, o âmbito do impacto da indisponibilidade pode ser limitado à região à qual os subscritores se ligaram. Se o serviço lhes permitisse a comutação por falha para outra região, os subscritores também poderiam causar indisponibilidade nessa região, o que resultaria numa falha em cascata no serviço.
Os publicadores na Austrália não estão disponíveis
Se os publicadores numa região ficarem indisponíveis, as mensagens já publicadas continuam a ser entregues aos subscritores mais próximos:
Eventualmente, todas as mensagens são consumidas e reconhecidas pelos subscritores. Ao enviar mensagens, o Pub/Sub tenta minimizar a distância da rede. Por conseguinte, os subscritores na região da Austrália podem deixar de receber mensagens se os subscritores na Europa tiverem capacidade suficiente para processar todas as mensagens publicadas nos Estados Unidos.
O Pub/Sub não está disponível nos Estados Unidos
O Pub/Sub escreve mensagens de forma síncrona em várias zonas numa região. Por conseguinte, uma indisponibilidade ao nível da zona não é suficiente para impedir a entrega de mensagens. Toda a região tem de estar indisponível. Se o Pub/Sub ficar indisponível numa região onde os publicadores estão a enviar mensagens, as mensagens nessa região podem não ser entregues até o serviço ser totalmente restaurado:
A mensagem é, em última análise, entregue (assumindo que o período de retenção da mensagem não expirou), com um atraso correspondente à duração da indisponibilidade. Tenha em atenção que, tal como os subscritores, os publicadores nos Estados Unidos também não transitam para outra região quando o serviço falha. Este comportamento ajuda a evitar a probabilidade de falhas em cascata nas regiões devido a um publicador ou subscritor com defeito.
Comutação por falha e redundância controladas pelo cliente
A semântica de alternativa predefinida do Pub/Sub pode não garantir totalmente que as mensagens podem sempre fluir dos publicadores para os subscritores se houver uma interrupção em qualquer lugar entre eles. As indisponibilidades podem ocorrer em vários locais diferentes, incluindo nos seus clientes, no serviço no qual os seus publicadores ou subscritores são executados, na rede ou, raramente, no próprio Pub/Sub. Se precisar que os seus serviços sejam resilientes a estas falhas, tem de implementar as suas próprias redundâncias. Normalmente, estas redundâncias incluem a utilização de várias instâncias de clientes publicadores e subscritores em que cada uma usa um ponto final de localização diferente.
Pode querer resiliência para dois âmbitos de impacto diferentes: zonal ou regional. Seguem-se as opções de configuração para cada uma.
Resiliência zonal
O Pub/Sub tem replicação entre zonas integrada. Não tem de tomar medidas especiais para lidar com interrupções de uma única zona que afetem o próprio serviço. No entanto, para ter resiliência a interrupções para os seus clientes ou rede, é melhor executar publicadores e subscritores com capacidade suficiente em várias zonas na região. Se uma única zona estiver inativa, os clientes na outra zona podem receber o tráfego e processar as mensagens. É uma prática recomendada não publicar alterações nestes clientes em simultâneo para que, se for introduzido um erro, as outras zonas não alteradas possam continuar a processar mensagens.
Resiliência regional
Para garantir a resiliência em caso de falhas regionais, configure redundâncias adicionais nos seus publicadores e subscritores. Pode executar publicadores e subscritores em várias regiões para lidar com a possibilidade de interrupções nesses clientes ou na rede.
Se quiser ser resiliente contra potenciais falhas do Pub/Sub numa região, tem de ter um mecanismo de alternativa pronto para lidar com essa indisponibilidade. As abordagens possíveis são um compromisso entre a latência de entrega de mensagens ponto a ponto e o seu custo.
Para minimizar a latência no caso de o custo não ser uma preocupação, a melhor estratégia é publicar e subscrever sempre em simultâneo em diferentes regiões. Primeiro, escolha o número de regiões nas quais quer redundância. Em seguida, embora não seja estritamente necessário, pode configurar um tópico e uma subscrição para cada uma dessas regiões.
Cada publicador cria tantos clientes publicadores quantas regiões existirem (um para cada região) e usa um ponto final de localização diferente para garantir que as mensagens são direcionadas para regiões distintas. Se usar tópicos separados, cada cliente publicador tem de publicar no tópico correspondente por região. Para cada mensagem, o publicador chama a publicação em cada cliente. Com as publicações redundantes, não é necessário tentar novamente as publicações se alguma falhar.
Da mesma forma, cada subscritor cria esse número de clientes subscritores, um para cada região, e usa um ponto final de localização para se ligar a uma região diferente. Se usar subscrições diferentes para cada região, cada cliente subscritor tem de usar a subscrição correspondente. Tenha em atenção que as regiões usadas para publicadores e subscritores não têm necessariamente de ser as mesmas. Os subscritores recebem mensagens nas três subscrições e processam-nas.
Esta configuração tem várias funcionalidades e requisitos principais:
- Qualquer indisponibilidade de uma única região não afeta o processamento de mensagens já publicadas, nem as publicadas durante a indisponibilidade. Uma vez que as mensagens foram publicadas em várias regiões, continuam disponíveis noutras regiões, caso uma região esteja inativa. Durante a indisponibilidade, as chamadas de publicação falham na região afetada, mas têm êxito nas outras.
- A latência do processamento de mensagens não é afetada, desde que qualquer uma das regiões através das quais as mensagens estão a fluir esteja disponível.
- O processamento de mensagens tem de ser idempotente. Uma vez que cada mensagem vai ser enviada várias vezes, o processamento de mensagens tem de ser resiliente a duplicados. No caso de uma indisponibilidade regional, algumas dessas duplicações podem chegar muito mais tarde do que a primeira vez que a mensagem foi entregue. É provável que esses duplicados sejam provenientes de uma região diferente que não estava a sofrer uma indisponibilidade.
A execução com este tipo de redundância oferece a maior capacidade de recuperação a qualquer tipo de interrupções. Para serviços Google internos que dependem do Pub/Sub e requerem a disponibilidade mais elevada, esta configuração é preferível. No entanto, esta configuração tem a desvantagem de multiplicar o custo da entrega de mensagens pelo número de regiões usadas. Também existe o custo adicional da utilização da rede inter-regional para mensagens que têm de se deslocar entre regiões.
Outra abordagem à redundância é só fazer failover quando os pedidos falham ou as mensagens não fluem dos publicadores para os subscritores como esperado. Neste cenário, tem uma região principal para a qual direciona os seus publicadores e subscritores através de pontos finais de localização. Tal como antes, não têm de ser da mesma região. Também tem uma região alternativa para publicadores e subscritores que é usada quando a região principal está indisponível.
Os publicadores publicam apenas na região principal (através do ponto final de localização) quando os respetivos pedidos são enviados com êxito. Sempre que se determina que a região está inativa, os publicadores começam a publicar na região alternativa. A determinação de que a região está inativa e a comutação por falha podem ser feitas de duas formas. Pode ser feito através de um processo manual e a configuração é atualizada dinamicamente nos publicadores. Os publicadores também podem atualizar a configuração se a taxa de erro nos pedidos de publicação for suficientemente elevada.
Os subscritores têm sempre de se ligar à região principal através do ponto final de localização. Pode decidir que o subscritor pode usar a região alternativa com um ou mais dos seguintes acionadores:
- Subscrever sempre a região alternativa. Neste caso, o subscritor mantém uma ligação à região principal e à região alternativa em todos os momentos. As mesmas regiões podem ser usadas para a região principal e alternativa para publicadores e subscritores. Se for este o caso, o subscritor só deve receber mensagens através da região de cópia de segurança se o publicador tiver sofrido uma comutação por falha.
- Detetar e mudar manualmente os subscritores para a região alternativa através de uma configuração. Se detetar uma indisponibilidade, pode fazer failover para a região alternativa e, em seguida, voltar para a região principal quando a indisponibilidade tiver diminuído.
- Comutação por falha em erros de subscritores. Se os pedidos de subscritores estiverem a devolver erros, pode usar isto como uma indicação de que tem de mudar para a região alternativa. Tenha em atenção que as bibliotecas de cliente do Pub/Sub tentam novamente os pedidos de obtenção de streaming internamente em erros transitórios, pelo que pode não conseguir detetar que existem longos períodos de erros inesperados. Além disso, a taxa de erro de obtenção de streaming deve ser de 100%, mesmo durante o funcionamento normal.
- Comutação em caso de falha se o subscritor passar um período inesperadamente longo sem receber mensagens. Partindo do princípio de que existe uma publicação consistente de mensagens, os subscritores podem sempre receber mensagens. Se passar um período prolongado sem receber mensagens, pode haver um problema do lado da subscrição no Pub/Sub na região principal. Isto é corrigido através da comutação para a região alternativa.
De todas as quatro opções, a primeira é a ideal. Uma associação de subscritor não custa nada se não houver mensagens a fluir na mesma. O único custo está na pegada da instância adicional da biblioteca de cliente subscritor, que pode ser insignificante. Também tem de ter em atenção a quota de ligações de obtenção de streaming abertas por região.
A vantagem deste segundo modelo é que não existe um multiplicador no custo do Pub/Sub, uma vez que as mensagens só são publicadas uma vez. No entanto, a desvantagem é que, para determinados tipos de indisponibilidade, as mensagens publicadas antes do início da indisponibilidade podem não estar disponíveis até que a indisponibilidade seja resolvida. As mensagens armazenadas na região indisponível podem não ser entregues aos subscritores, independentemente do local onde estão ligados. As mensagens publicadas durante a interrupção na região alternativa podem estar disponíveis. Além disso, pode haver um período de indisponibilidade com taxas de erro aumentadas para os publicadores ou os subscritores. Isto depende do método usado para detetar uma indisponibilidade e do tempo de comutação para a região alternativa.
Independentemente da opção escolhida, tenha em atenção a forma como esta pode interagir com as funcionalidades do Pub/Sub. O fornecimento ordenado e o fornecimento exatamente uma vez oferecem as respetivas garantias numa região. Por exemplo, se usar a técnica de redundância de comutação por falha, a entrega de mensagens só é garantida por ordem para mensagens publicadas na mesma região. O subscritor pode receber mensagens publicadas na região alternativa antes das mensagens publicadas na região principal, mesmo que as mensagens tenham sido publicadas primeiro na região principal.
Ajustar os publicadores
Independentemente da opção de alternativa que escolher, existem alguns passos de ajuste adicionais que deve seguir nos próprios publicadores. A otimização do comportamento do publicador garante um desempenho ideal sob carga elevada. O processamento em lote de mensagens é uma forma de compensar a latência com um custo reduzido, mas não é tanto uma preocupação de fiabilidade e, por isso, não é abordado aqui. Em alternativa, concentre-se noutros parâmetros úteis para ajustar a fiabilidade, incluindo as definições de repetição e as definições de controlo de fluxo.
As publicações podem falhar por diferentes motivos, incluindo motivos temporários, como a indisponibilidade da rede, ou motivos que requerem a intervenção do utilizador, como alterações de autorizações. A biblioteca de cliente do Pub/Sub tenta novamente erros temporários através dos parâmetros especificados nas definições de repetição. Estas definições controlam o comportamento da repetição exponencial nas novas tentativas de RPCs de publicação que falham por motivos temporários. Embora as predefinições possam funcionar bem na maioria dos cenários, existem situações em que pode querer ajustar estes valores.
As duas propriedades que provavelmente vai querer ajustar são o limite de tempo da RPC inicial e o limite de tempo total. O limite de tempo da RPC inicial é o tempo que a primeira RPC de publicação tem para ser concluída. Se qualquer RPC falhar ou exceder o tempo limite, é tentado outro com um tempo limite mais longo até que o número total de pedidos ou o tempo limite total seja excedido.
O limite de tempo inicial pode ser ajustado se o seu publicador estiver limitado pela rede ou longe do centro de dados mais próximo que executa o Pub/Sub. Google Cloud As restrições de rede podem ser limitações na taxa de transferência da máquina em que o publicador está a ser executado ou podem ser o resultado de outros serviços em execução na mesma máquina que exigem muita rede. Se o limite de tempo estiver definido como demasiado curto, os RPCs iniciais podem falhar repetidamente, o que resulta em mais tentativas (com limites de tempo mais longos) necessárias para publicar com êxito. A necessidade repetida de novas tentativas aumenta a latência de publicação. Nesta situação, aumentar o limite de tempo inicial pode resultar em publicações mais rápidas.
Se a ligação de rede não for fiável, aumentar o limite de tempo total, bem como o limite de tempo inicial, pode ajudar. Um aumento do limite de tempo total dá ao RPC de publicação mais tempo para ser concluído com êxito. Quando as RPCs de publicação falham consistentemente com erros de limite de tempo excedido, considere ajustar estes valores.
Os erros de prazo excedido contínuos na publicação também podem indicar a necessidade de ajustar o controlo de fluxo do publicador. Estas definições permitem-lhe garantir que os seus publicadores são resilientes a picos de tráfego recebido que geram mais mensagens a serem enviadas para o Pub/Sub. Um grande aumento nos pedidos de saída pode sobrecarregar a CPU, a memória ou a capacidade de rede do publicador. Quando a publicação está sobrecarregada, não consegue processar pedidos ou respostas de publicação antes dos limites de tempo. Isto resulta em ainda mais pedidos de publicação e, em última análise, no alcance do limite de tempo total. O fluxo do publicador controla o número de mensagens ou bytes que podem estar pendentes sem uma resposta do pedido de publicação. Limitar o número de pedidos desta forma mantém a utilização de recursos a um nível gerível, mesmo durante picos. Consoante a forma como o publicador opera, pode permitir que os RPCs de publicação subsequentes aguardem capacidade, permitindo que a publicação bloqueie pedidos adicionais. Em alternativa, pode enviar uma resposta aos autores das chamadas do seu serviço fazendo com que o controlo de fluxo devolva um erro quando a capacidade for atingida. Configura a forma como a biblioteca de cliente do publicador responde com o comportamento de limite excedido.
Ajuste dos subscritores
A sintonia do subscritor também pode ser necessária para garantir que funcionam de forma fiável. Tal como os publicadores, pode ajustar as definições de controlo de fluxo dos subscritores para garantir que não ficam sobrecarregados. A biblioteca de cliente de subscrição usa a obtenção de streaming, em que o cliente abre um fluxo persistente para o servidor e o servidor envia mensagens à medida que ficam disponíveis. No caso de um grande aumento nas mensagens publicadas, o subscritor pode receber mais mensagens do que consegue processar. Com o controlo de fluxo, o número de mensagens pendentes não reconhecidas para o cliente num determinado momento é limitado. Isto reduz o número de mensagens processadas em simultâneo e distribui o respetivo processamento por um período mais longo. A distribuição da carga permite que os subscritores permaneçam dentro de quaisquer limitações de recursos que afetem o processamento de mensagens, o que pode resultar num efeito de cascata que se desenvolve na incapacidade de processar quaisquer mensagens.
O controlo de fluxo é suficiente se esperar apenas picos na quantidade de dados a processar que acabam por diminuir. Se o tráfego aumentar geralmente ao longo do tempo devido a uma maior utilização, o controlo de fluxo protege os subscritores. No entanto, pode resultar num atraso que continua a acumular-se e faz com que as mensagens não possam ser entregues antes de terminar o período de retenção de mensagens. Nestes casos, também pode querer definir o dimensionamento automático para aumentar o número de subscritores em resposta a um número crescente de mensagens não reconhecidas. A forma como configura esta opção depende da plataforma de computação que está a usar para os seus subscritores. Por exemplo, o escalador automático do Compute Engine permite-lhe fazer o escalonamento com base em métricas como o número de mensagens não entregues. A utilização do dimensionamento automático e do controlo de fluxo permite-lhe garantir que os seus subscritores são resilientes a outros picos de curto prazo no débito de mensagens e ao crescimento a longo prazo que requer mais capacidade de computação. Certifique-se de que segue as práticas recomendadas para usar métricas do Pub/Sub como um sinal de escalamento.
Use o instantâneo e a procura para implementações seguras
Normalmente, a perda de mensagens é um evento catastrófico. O Pub/Sub oferece a entrega, pelo menos, uma vez para todas as mensagens publicadas. No entanto, o processamento correto destas mensagens depende do comportamento dos subscritores. Se as mensagens forem reconhecidas com êxito, o Pub/Sub não as reenvia. Por conseguinte, um erro introduzido no novo código do subscritor que implementa e que confirma mensagens sem as ter processado corretamente pode resultar numa perda de mensagens induzida pelo subscritor. O Pub/Sub oferece a funcionalidade de captura instantânea e procura, que pode ajudar a garantir que processa todas as mensagens corretamente, mesmo em caso de erros do subscritor.
O padrão para cada implementação de subscritores tem de ser o seguinte:
O tempo de espera antes de determinar se o novo subscritor está a funcionar pode variar consoante o seu exemplo de utilização. A única forma de sair do fluxo de passos é quando um subscritor é considerado a trabalhar, momento em que a captura de ecrã pode ser eliminada.
A utilização da captura de ecrã e da procura não se destina a substituir as práticas recomendadas relativas à execução de software num ambiente de não produção e à implementação gradual na produção. Oferecem um nível adicional de proteção para garantir o tratamento fiável dos dados. A desvantagem é que a procura do instantâneo pode resultar na entrega duplicada de mensagens que o subscritor processou com êxito. No entanto, uma vez que o Pub/Sub tem uma semântica de entrega, pelo menos, uma vez por predefinição, os seus subscritores já são resilientes à reentrega de mensagens.