Equilibre a carga de partição em várias instâncias do seu aplicativo
Para dimensionar seu aplicativo de processamento de eventos, você pode executar várias instâncias do aplicativo e ter a carga balanceada entre si. Nas versões mais antigas e obsoletas, EventProcessorHost você permitia equilibrar a carga entre várias instâncias do seu programa e eventos de ponto de verificação ao receber os eventos. 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. O modelo de desenvolvimento é simplificado usando eventos. Você pode se inscrever nos eventos em que está interessado registrando um manipulador de eventos. Se você estiver usando a versão antiga da biblioteca do cliente, consulte os seguintes guias de migração: .NET, Java, Python e JavaScript.
Este artigo descreve um cenário de exemplo para usar várias instâncias de aplicativos cliente para ler eventos de um hub de eventos. Ele também fornece detalhes sobre os recursos do cliente do processador de eventos, que permite receber eventos de várias partições ao mesmo tempo e balancear a carga com outros consumidores que usam o mesmo hub de eventos e grupo de consumidores.
Nota
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 (filtrar, agregar e assim por diante) e despejar a agregação em um blob de armazenamento, que é então projetado para uma página da Web amigável.
Aplicação ao consumidor
Quando você projeta um consumidor em um ambiente distribuído, o cenário deve lidar com os seguintes requisitos:
- Escala: crie vários consumidores, com cada consumidor se apropriando da leitura de algumas partições de Hubs de Eventos.
- Balanceamento de carga: Aumente ou reduza 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 consumo. 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.
- Retomada contínua em falhas: Se um consumidor (consumidor A) falhar (por exemplo, a máquina virtual que hospeda o consumidor falha repentinamente), outros consumidores podem pegar as partições de propriedade do consumidor A e continuar. Além disso, o ponto de continuação, chamado de ponto de verificação ou 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 eventos e fazer algo útil com ele. 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. Na versão antiga do SDK, era o host do processador de eventos (EventProcessorHost) que suportava esses recursos.
Para a maioria dos cenários de produção, recomendamos que você use o cliente do processador de eventos para ler e processar eventos. O cliente do processador destina-se a fornecer uma experiência robusta para processar eventos em todas as partições de um hub de eventos de forma eficiente e tolerante a falhas, ao mesmo tempo em que fornece um meio de verificar seu progresso. 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.
Propriedade da partição
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 processador de eventos recebe um identificador exclusivo e reivindica a propriedade das partições adicionando ou atualizando uma entrada em um armazenamento 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 aprender sobre outras instâncias ativas. Esses dados são usados para equilibrar a carga entre os processadores ativos. Novas instâncias podem se juntar ao pool de processamento para aumentar a escala. Quando as instâncias caem, seja por causa de falhas ou para reduzir a escala, a propriedade da partição é normalmente transferida para outros processadores ativos.
Os registros de propriedade de partição no armazenamento de pontos de verificação controlam o namespace dos Hubs de Eventos, o nome do hub de eventos, o grupo de consumidores, o identificador do processador de eventos (também conhecido como proprietário), a ID da partição e a hora da última modificação.
| Espaço de nomes dos Event Hubs | Nome do hub de eventos | Grupo de consumidores | Proprietário | ID da Partição | Hora da última modificação |
|---|---|---|---|---|---|
| mynamespace.servicebus.windows.net | MyEventHub | MyConsumerGroup | 3be3f9d3-9d9e-4c50-9491-85ece8334ff6 | 0 | 2020-01-15T01:22:15 |
| mynamespace.servicebus.windows.net | MyEventHub | MyConsumerGroup | f5cc5176-ce96-4bb4-bbaa-a0e3a9054ecf | 1 | 2020-01-15T01:22:17 |
| mynamespace.servicebus.windows.net | MyEventHub | MyConsumerGroup | 72B980E9-2EFC-4CA7-AB1B-FFD7BECE8472 | 2 | 2020-01-15T01:22:10 |
| : | |||||
| : | |||||
| mynamespace.servicebus.windows.net | MyEventHub | MyConsumerGroup | 844bd8fb-1f3a-4580-984d-6324f9e208af | 15 | 2020-01-15T01:22:00 |
Cada instância do processador de eventos adquire a propriedade de uma partição e começa a processar a partição a partir do último ponto de verificação conhecido. Se um processador falhar (a VM é desligada), outras instâncias o detetam observando a hora da última modificação. Outras instâncias tentam obter a propriedade das partições anteriormente pertencentes à instância inativa. O armazenamento de pontos de verificação garante que apenas uma das instâncias consiga reivindicar a propriedade de uma partição. Assim, em qualquer ponto do tempo, há no máximo um processador que recebe eventos de uma partição.
Receber mensagens
Ao criar um processador de eventos, você especifica 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.
Check Point
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.
Quando o ponto de verificação é executado para marcar um evento como processado, uma entrada no armazenamento de ponto de verificação é adicionada ou atualizada com o deslocamento e o número de sequência do evento. Os usuários devem decidir a frequência de atualização do ponto de verificação. A atualização após cada evento processado com êxito pode ter implicações de desempenho e custo, pois dispara uma operação de gravação no armazenamento de ponto de verificação subjacente. Além disso, a verificação de cada evento é indicativa de um padrão de mensagens em fila para o qual uma fila do Service Bus pode ser uma opção melhor do que um hub de eventos. A ideia por trás dos Hubs de Eventos é que você obtenha "pelo menos uma vez" entrega em grande escala. Ao tornar seus sistemas downstream idempotentes, é fácil se recuperar de falhas ou reinicializações que resultam no recebimento dos mesmos eventos várias vezes.
Siga estas recomendações ao usar o Armazenamento de Blobs do Azure como um armazenamento de ponto de verificação:
- Use um contêiner separado para cada grupo de consumidores. Você pode usar a mesma conta de armazenamento, mas usar um contêiner por cada grupo.
- Não use o contêiner para mais nada e não use a conta de armazenamento para mais nada.
- A conta de armazenamento deve estar na mesma região em que o aplicativo implantado está localizado. Se o aplicativo for local, tente escolher a região mais próxima possível.
Na página Conta de armazenamento no portal do Azure, na seção Serviço de Blob, verifique se as configurações a seguir estão desabilitadas.
- Espaço de nomes hierárquico
- Eliminação de forma recuperável de blobs
- Controlo de Versão
Segurança de threads e instâncias do processador
Por padrão, a função que processa eventos é chamada sequencialmente para uma determinada partição. Eventos subsequentes e chamadas para essa função da mesma fila de partição nos bastidores à medida que a bomba de eventos continua a ser executada 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.
Conteúdos relacionados
Veja os seguintes inícios rápidos: