2016-03-03 38 views
5

Implementeremo un sistema Kafka Publish Subscribe.Come gestire il fallimento di Kafka Cluster

Ora, nel peggiore dei casi peggiori, se tutti i broker di kafka per un determinato argomento scendono, cosa succede?

Ho provato questo ... l'editore lo rileva dopo il timeout predefinito per il recupero dei metadati & genera un'eccezione se non ha esito positivo.

In questo caso, possiamo monitorare l'eccezione e riavviare Publisher dopo aver corretto Kafka.

Ma, per quanto riguarda i consumatori - non sembrano avere eccezioni una volta che Kafka va giù. Semplicemente non possiamo chiedere a "tutti" i consumatori di riavviare i loro sistemi. Qual è il modo migliore per risolvere questo problema?

risposta

2

Se il consumatore (versione 0.9.x) è polling e il cluster va giù che dovrebbe ottenere la seguente eccezione

java.net.ConnectException: Connection refused 

È possibile mantenere il polling finché il cluster è di nuovo non v'è alcuna necessità di riavviare il consumatore, ristabilirà la connessione.

+0

Suona come quello che mi serve ... Può questo essere fatto in V8.2.1? Se sì, come abilitare questo? – nikel

+0

Immaginavo che dal momento che si trattava di un nuovo sistema che stavi usando l'ultimo consumatore, mi dispiace ma non ho familiarità con il vecchio consumatore. – Nautilus

4

Ma, per quanto riguarda i consumatori - non sembrano avere eccezioni una volta che Kafka va giù. Semplicemente non possiamo chiedere a "tutti" i consumatori di riavviare i loro sistemi con il . Qual è il modo migliore per risolvere questo problema?

Sì, il consumatore non otterrà eccezioni e il comportamento è lavoro come progettato. Tuttavia, non è necessario riavviare tutti gli utenti, ma assicurati nella logica che l'utente chiami regolarmente la chiamata al metodo poll(). Il consumatore è progettato in modo tale da non essere eseguito, anche se non è attivo alcun cluster. Considerare i seguenti passaggi per capire cosa accadrà effettivamente:

1: Tutti i cluster sono inattivo, non è presente alcun cluster attivo.

2: consumer.poll(timeout) // This will be called form you portion of code

3: All'interno poll() metodo chiamata KafkaConsumer.java, seguente sequenza di chiamate avrà luogo.

poll() --> pollOnce() --> ensureCoordinatorKnown() --> awaitMetaDataUpdate() 

Ho evidenziato le principali chiamate di metodo che verranno chiamate dopo l'esecuzione di controlli logici internamente. Ora, a questo punto il tuo cliente aspetterà che il cluster sia di nuovo attivo.

4: Cluster di nuovo o riavviato

5: Consumatore sarà informato e si inizierà a lavorare di nuovo come normalmente era prima che il cluster va giù.

Nota: - Il consumer inizierà a ricevere messaggi dall'ultimo commit di offset, il messaggio ricevuto correttamente non verrà duplicato.

Il comportamento descritto è valido per (versione 0.9.x)

Problemi correlati