Dimensionare l'applicazione di elaborazione

  • 3 minuti

Per ridimensionare l'applicazione per l'elaborazione di eventi, è possibile eseguire più istanze dell'applicazione e far sì che l'applicazione bilanci il carico tra di esse. Nelle versioni precedenti EventProcessorHost consentiva di bilanciare il carico tra più istanze del programma ed eseguire il checkpoint degli eventi alla ricezione. Nelle versioni più recenti (5.0 e successive), EventProcessorClient (.NET e Java) o EventHubConsumerClient (Python e JavaScript) consente di eseguire la stessa operazione.

Nota

Il ridimensionamento di Hub eventi si basa sul concetto di consumer partizionati. A differenza dei criteri relativi ai consumer concorrenti, il modello consumer partizionato consente un'elevata scalabilità rimuovendo il collo di bottiglia dovuto alla contesa e agevolare il parallelismo end to end.

Scenario di esempio

Come scenario di esempio, si consideri una società per la sicurezza delle abitazioni che monitora 100.000 abitazioni. Ogni minuto, riceve dati da diversi sensori, ad esempio un rilevatore di movimento, un sensore di apertura di porte/finestre, un rilevatore di vetri rotti, e così via, installato in ogni abitazione. L'azienda fornisce un sito Web ai residenti per monitorare l'attività della propria abitazione quasi in tempo reale.

Ogni sensore esegue il push dei dati a un hub eventi. L'hub eventi è configurato con 16 partizioni. Dal lato consumer, è necessario un meccanismo che riesca a leggere questi eventi e consolidarli ed esegua il dump dell'aggregazione in un BLOB di archiviazione, successivamente proiettato in una pagina Web intuitiva.

Quando si progetta il consumer in un ambiente distribuito, lo scenario deve gestire i requisiti seguenti:

  • Scalabilità: creare diversi consumer, ciascuno tra questi che dispone di proprietà di lettura derivanti da alcune partizioni di Hub eventi.
  • Bilanciamento del carico: aumentare o ridurre in modo dinamico i consumer. Ad esempio, quando un nuovo tipo di sensore (ad esempio, un rilevatore di monossido di carbonio) viene aggiunto a ciascuna abitazione, il numero di eventi aumenta. In tal caso, l'operatore (un essere umano) aumenta il numero di istanze del consumer. Quindi, il pool di consumer può ribilanciare il numero di partizioni di cui è proprietario, condividendo il carico con i consumer appena aggiunti.
  • Recupero intuitivo dagli errori: in caso di esito negativo da parte di un consumer (consumer A), ad esempio, la macchina virtuale che ospita il consumer si arresta improvvisamente, gli altri consumer possono acquisire le partizioni delle quali è proprietario il consumer A e procedere. Inoltre, il punto di continuazione, chiamato checkpoint oppure offset, deve trovarsi nel punto esatto in cui il consumer A ha avuto esito negativo, o leggermente prima rispetto al punto.
  • Uso di eventi: mentre i tre punti precedenti affrontano la gestione del consumer, è necessario che esista un codice per l'uso degli eventi e che questo venga usato in modo utile, ad esempio, aggregandolo e caricandolo nell'archivio BLOB.

Processore di eventi o client consumer

Non è necessario creare una soluzione personalizzata per soddisfare questi requisiti. Gli SDK di Hub eventi di Azure offrono questa funzionalità. Negli SDK .NET o Java si usa un client del processore di eventi (EventProcessorClient) e negli SDK Python e JavaScript si usa EventHubConsumerClient.

Per la maggior parte degli scenari di produzione, è consigliabile usare il client processore di eventi per la lettura e l'elaborazione degli eventi. I client del processore di eventi possono lavorare in modo cooperativo all'interno del contesto di un gruppo di consumer per un determinato hub eventi. I client gestiranno automaticamente la distribuzione e il bilanciamento del lavoro man mano che le istanze diventano disponibili o non disponibili per il gruppo.

Rilevamento della proprietà di partizione

Un'istanza del processore di eventi è in genere proprietaria ed elabora eventi di una o più partizioni. La proprietà delle partizioni viene distribuita uniformemente tra tutte le istanze del processore di eventi attive associate a una combinazione di hub eventi e gruppo di consumer.

Ogni processore di eventi dispone di un identificatore univoco e attesta la proprietà delle partizioni aggiungendo o aggiornando una voce in un archivio checkpoint. Tutte le istanze del processore di eventi comunicano periodicamente con questo archivio per aggiornare il proprio stato di elaborazione e per ottenere informazioni su altre istanze attive. Questi dati vengono quindi usati per bilanciare il carico tra i processori attivi.

Ricevere messaggi

Quando si crea un processore di eventi, si specificano le funzioni che elaborano gli eventi e gli errori. Ogni chiamata alla funzione che elabora gli eventi recapita un singolo evento da una partizione specifica. È responsabilità dell'utente gestire questo evento. Se si vuole avere la certezza che il consumer elabori ogni messaggio almeno una volta, è necessario scrivere il proprio codice con la logica di ripetizione dei tentativi. Fare attenzione, tuttavia, a inserire messaggi non elaborabili.

È consigliabile eseguire operazioni relativamente veloci. Ovvero, eseguire la minor quantità di elaborazione possibile. Se è necessario scrivere nell'archiviazione ed eseguire alcune route, è consigliabile usare due gruppi di consumer e avere due processori di eventi.

Checkpoint

Il checkpoint è un processo tramite il quale un processore di eventi contrassegna o esegue il commit della posizione dell'ultimo evento elaborato correttamente all'interno di una partizione. Il contrassegno di un checkpoint viene in genere eseguito all'interno della funzione che elabora gli eventi e si verifica in base alla partizione all'interno di un gruppo di consumer.

Se un processore di eventi si disconnette da una partizione, un'altra istanza può riprendere l'elaborazione della partizione nel checkpoint di cui è stato eseguito il commit in precedenza dall'ultimo processore di tale partizione nel gruppo di consumer. Quando il processore si connette, passa l'offset all'hub eventi per specificare la posizione da cui iniziare la lettura. In questo modo è possibile usare l'impostazione del checkpoint sia per contrassegnare gli eventi come "completi" da parte delle applicazioni downstream che per offrire resilienza in caso di inattività di un processore eventi. È possibile tornare a dati precedenti specificando un offset inferiore da questo processo di checkpoint.

Istanze di elaborazione e sicurezza del thread

Per impostazione predefinita, la funzione che elabora gli eventi viene chiamata in sequenza per una determinata partizione. Le chiamate e gli eventi successivi per questa funzione provenienti dalla stessa partizione si accodano in background mentre l'event pump continua a essere eseguito in background in altri thread. Gli eventi di partizioni diverse possono essere elaborati simultaneamente e qualsiasi stato condiviso a cui si accede tra partizioni deve essere sincronizzato.