Dimensione 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, EventProcessorHost permitia equilibrar a carga entre várias instâncias do seu programa e pontos de verificação de eventos ao recebê-los. 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 escalar os Hubs de Eventos é a ideia de consumidores particionados. Em contraste com o padrão de consumidores concorrentes, o padrão de consumo particionado permite alta escala, removendo o gargalo de contenção e facilitando o paralelismo de ponta a ponta.

Cenário de exemplo

Como cenário de exemplo, considere uma empresa de segurança doméstica que monitora 100.000 casas. A cada minuto, ele obtém dados de vários sensores, como um detetor de movimento, sensor de abertura de porta / janela, detetor de quebra de vidro, e assim por diante, instalado em cada casa. A empresa fornece um site para os moradores monitorarem a atividade de 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 consumidora, você precisa de um mecanismo que possa ler esses eventos, consolidá-los e despejar a agregação em um blob de armazenamento, que é então 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: Crie vários consumidores, com cada um assumindo a responsabilidade de ler algumas partições dos Hubs de Eventos.
Balanceamento de carga: Aumentar ou reduzir os consumidores dinamicamente. Por exemplo, quando um novo tipo de sensor (por exemplo, um detetor de monóxido de carbono) é adicionado a cada casa, o número de eventos aumenta. Nesse caso, o operador (um ser humano) aumenta o número de instâncias de consumidores. Em seguida, o pool de consumidores pode reequilibrar o número de partições que possuem, para compartilhar a carga com os consumidores recém-adicionados.
Reinício automático em caso de falhas: Se um consumidor (consumidor A) falhar (por exemplo, a máquina virtual que hospeda o consumidor falha repentinamente), então outros consumidores podem assumir as partições de propriedade de consumidor A e continuar. Além disso, o ponto de continuação, chamado de ponto de verificação ou ponto de compensação , deve estar no ponto exato em que o consumidor A falhou, ou um pouco antes disso.
Consumir eventos: Enquanto os três pontos anteriores tratam da gestão do consumidor, deve haver código para consumir os eventos e fazer algo útil com eles. Por exemplo, agregue-o e carregue-o para o 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 .NET ou Java, você usa um cliente de processador de eventos (EventProcessorClient) e em SDKs 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 cooperativamente dentro do contexto de um grupo de consumidores para um determinado hub de eventos. Os clientes gerenciarão automaticamente a distribuição e o balanceamento do trabalho à medida que as instâncias ficam disponíveis ou indisponíveis para o grupo.

Rastreamento de propriedade de partições

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

Cada um dos processadores de eventos recebe um identificador exclusivo e reivindica a propriedade das partições ao adicionar ou atualizar uma entrada num repositório de pontos 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 aprender sobre outras instâncias ativas. Esses dados são usados para equilibrar 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 entrega um único evento de uma partição específica. É sua responsabilidade lidar com este evento. Se você quiser garantir que o consumidor processe cada mensagem pelo menos uma vez, você precisa escrever seu próprio código com lógica de repetição. Mas tenha cuidado com mensagens envenenadas.

Recomendamos que você faça as coisas relativamente rápido. Ou seja, fazer o mínimo de processamento possível. Se você precisar gravar no armazenamento e fazer algum roteamento, é melhor usar dois grupos de consumidores e ter dois processadores de eventos.

Ponto de verificação

de ponto de verificação é um processo pelo qual um processador de eventos marca ou confirma a posição do último evento processado com êxito dentro de uma partição. A marcação de um ponto de verificação normalmente é feita dentro da função que processa os eventos e ocorre 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 o deslocamento para o hub de eventos para especificar o local no qual iniciar a leitura. Dessa forma, você pode usar o ponto de verificação para marcar eventos como "completos" por aplicativos downstream e para fornecer resiliência quando um processador de eventos fica inativo. É possível retornar a dados mais antigos especificando um deslocamento menor desse processo de ponto de verificação.

Segurança de threads e instâncias do processador

Por padrão, a função que processa os eventos é chamada sequencialmente para uma determinada partição. Eventos subsequentes e chamadas para esta função da mesma fila de partição são enfileirados nos bastidores, à medida que o ciclo de eventos continua a ser executado em segundo plano em outros threads. Eventos de partições diferentes podem ser processados simultaneamente e qualquer estado compartilhado que é acessado entre partições tem que ser sincronizado.