Dimensionar seu aplicativo de processamento

  • 3 minutos

Para dimensionar seu aplicativo de processamento de eventos, você pode executar várias instâncias do aplicativo e fazer com que ele equilibre a carga entre si. Nas versões mais antigas, o EventProcessorHost permitia que você balanceasse a carga entre várias instâncias do programa e eventos de ponto de verificação ao receber. Nas versões mais recentes (5.0 em diante), EventProcessorClient (.NET e Java) ou EventHubConsumerClient (Python e JavaScript) permite que você faça o mesmo.

Observação

A chave para reduzir os Hubs de Eventos horizontalmente é o modelo de consumidor particionado. Em contraste com o consumidores concorrentes padrão, o padrão de consumidor particionado permite alta escala, removendo o gargalo de contenção e promovendo o paralelismo de ponta a ponta.

Cenário de exemplo

Como um cenário de exemplo, considere uma empresa de segurança inicial que monitora 100.000 residências. A cada minuto, ele obtém dados de vários sensores, como um detector de movimento, sensor de porta/janela aberta, detector de quebra de vidro etc., instalado em cada residência. A empresa oferece um site da web para residentes monitorarem a atividade da sua casa quase em tempo real.

Cada sensor envia dados para um hub de eventos. O hub de eventos é configurado com 16 partições. Na extremidade de consumo, você precisa de um mecanismo que possa ler esses eventos, consolidá-los e fazer backup do agregado em um blob de armazenamento, que é projetado para uma página da Web amigável.

Ao projetar o consumidor em um ambiente distribuído, o cenário deve lidar com os seguintes requisitos:

  • Escala: criar vários consumidores, com cada consumidor assumindo a propriedade de leitura de algumas partições de Hubs de eventos.
  • O balanceamento de carga: aumentar ou reduzir os consumidores dinamicamente. Por exemplo, quando um novo tipo de sensor (por exemplo, um detector de monóxido de carbono) é adicionado a cada página inicial, aumenta o número de eventos. Nesse caso, o operador (um ser humano) aumenta o número de instâncias de consumidor. Em seguida, o pool de consumidores pode redistribuir o número de partições que são proprietárias, para compartilhar a carga com os consumidores recém-adicionados.
  • Retorno contínuo de falhas: se um consumidor (consumidor A) falhar (por exemplo, a máquina virtual que hospeda o consumidor falha repentinamente), outros consumidores devem poder selecionar as partições de propriedade do consumidor A e continuar. Além disso, o ponto de continuação, chamado de checkpoint ou offset, deve estar no ponto exato em que consumidor A falhou, ou um pouco antes disso.
  • Consumir eventos: enquanto os três pontos anteriores lidam com o gerenciamento do consumidor, deve haver código para consumir os eventos e fazer algo útil com ele. Por exemplo, agregá-lo e carregá-lo no armazenamento de BLOBs.

Processador de eventos ou cliente consumidor

Você não precisa criar sua própria solução para atender a esses requisitos. Os SDKs dos hubs de eventos do Azure fornecem essa funcionalidade. Em SDKs do .NET ou Java, você usa um cliente do processador de eventos (EventProcessorClient), e em SDKs de Python e JavaScript, você usa EventHubConsumerClient.

Para a maioria dos cenários de produção, recomendamos que você use o cliente do processador de eventos para ler e processar eventos. Os clientes do processador de eventos podem trabalhar de forma cooperativa no contexto de um grupo de consumidores para um determinado Hub de eventos. Os clientes gerenciarão automaticamente a distribuição e o balanceamento de trabalho, à medida que as instâncias ficam disponíveis ou indisponíveis para o grupo.

Acompanhamento de propriedade da partição

Uma instância do processador de eventos normalmente possui e processa eventos de uma ou mais partições. A propriedade de partições é distribuída uniformemente entre todas as instâncias de processador de eventos ativas associadas a uma combinação de Hub de eventos e grupo de consumidores.

Cada processador de eventos recebe um identificador exclusivo e a propriedade de declarações de partições ao adicionar ou atualizar uma entrada em um repositório de ponto de verificação. Todas as instâncias do processador de eventos se comunicam com esse repositório periodicamente para atualizar seu próprio estado de processamento e para saber mais sobre outras instâncias ativas. Esses dados são usados para balancear a carga entre os processadores ativos.

Receber mensagens

Ao criar um processador de eventos, você especifica as funções que processam eventos e erros. Cada chamada para a função que processa eventos fornece um único evento de uma partição específica. É sua responsabilidade lidar com este evento. Caso deseje garantir que o consumidor processe todas as mensagens pelo menos uma vez, você precisará escrever seu próprio código com lógica de repetição. Mas tenha cuidado com mensagens suspeitas.

É recomendável que você faça coisas de forma relativamente rápida. Ou seja, faça o menor processamento possível. Caso você precise gravar no armazenamento e fazer algum roteamento, é melhor usar dois grupos de consumidores e ter dois processadores de evento.

Definindo o ponto de verificação

Pontos de verificação é um processo pelo qual um processador de eventos marca ou confirma a posição do último evento processado com êxito em uma partição. Marcar um ponto de verificação normalmente é feito dentro da função que processa os eventos e ocorre em uma base por partição dentro de um grupo de consumidores.

Se um processador de eventos se desconectar de uma partição, outra instância poderá retomar o processamento da partição no ponto de verificação que foi confirmado anteriormente pelo último processador dessa partição nesse grupo de consumidores. Quando o processador se conecta, ele passa esse deslocamento para o hub de eventos para especificar o local para começar a ler. Assim, você pode usar o ponto de verificação para marcar eventos como "concluídos" por aplicativos de downstream e oferecer resiliência quando um processador de eventos ficar inativo. É possível retornar aos dados mais antigos, especificando um deslocamento inferior desse processo de ponto de verificação.

Instâncias de processador e de segurança do thread

Por padrão, a função que processa os eventos é chamada sequencialmente para uma determinada partição. Os eventos e chamadas subsequentes para essa função a partir da mesma participação são enfileirados em segundo plano enquanto a bomba de eventos continua a ser executada em segundo plano em outros threads. Os eventos de partições diferentes podem ser processados simultaneamente e qualquer estado compartilhado que seja acessado entre partições deve ser sincronizado.