2016-06-14 37 views
6

abbiamo installato un cluster Kafka/Zookeeper composto da 3 broker. Abbiamo un produttore, che invia messaggi a un argomento specifico di Kafka e alcuni gruppi di consumatori che leggono da detto argomento. Questi consumatori eseguono le elezioni dei leader tramite Zookeeper (indipendentemente da Kafka).Cosa succede se Zookeeper fallisce completamente?

Le versioni utilizzate sono:

  • Kafka: 0.9.0.1
  • Zookeeper: 3.4.6 (incluso nel Kafka-Package)

Tutti i processi sono gestiti da supervisore. Finora, tutto funziona bene. Quello che abbiamo provato ora (a scopo di test) era semplicemente quello di eliminare tutti i processi di Zookeeper e vedere cosa succede.

Come previsto, i nostri processi consumer non sono più in grado di connettersi a Zookeeper. Ma inaspettatamente, i Broker di Kafka continuarono a funzionare. Il nostro produttore non si lamentava affatto ed era ancora in grado di scrivere sull'argomento. Sebbene non potessi usare kafka/bin/kafka-topics.sh o simili, poiché richiedono tutti un parametro zookeeper, potrei comunque vedere crescere la dimensione effettiva del log degli argomenti. Dopo aver riavviato i processi dello zoo, di nuovo tutto ha funzionato come prima.

Quello che non riuscivamo a capire ora è ... cosa è successo realmente lì? Abbiamo pensato, Kafka avrebbe richiesto una connessione di lavoro Zookeeper e non siamo riusciti a trovare alcuna spiegazione per questo comportamento online.

+0

Zookeeper non è richiesto per tutte le operazioni eseguite da Kafka. Ad esempio, Kakfa Consumer Clients commette le proprie compensazioni su ZK. Per quanto ne so. ZK viene anche utilizzato se un broker non riesce a eleggere nuovi leader per la partizione ospitata dal broker guasto. Tuttavia, finché tutto il broker è attivo, la scrittura non è un problema: vedere https://kafka.apache.org/090/documentation.html#replication e http://www.confluent.io/blog/hands- free-kafka-replication-a-lesson-in-operational-simplicity/per semplici dettagli. –

+1

> I client consumer Kakfa commettono le loro compensazioni su ZK. Fanno? Per quanto ho capito, il "nuovo consumatore" non ha bisogno di questo., Dal momento che volevano disaccoppiare i consumatori da Zookeeper. Ecco perché usi la proprietà bootstrap.servers invece di zookeeper.connect e usa Kafka-Ports – tehK

+1

Sì. Il vecchio consumatore commuta l'offset in ZK. I nuovi consumatori commettono i loro offset in un argomento di Kafka e sono indipendenti da ZK. –

risposta

0

Quando si dispone di un nodo di zookeeper, il broker non sarà in grado di contattare zookeeper, dopo che il broker scopre che zookeeper non è raggiungibile, anche il broker diventerà irraggiungibile. Da qui il produttore e il consumatore. In caso di produttore inizia a cadere (rifiuta il record). In caso di consumatore può accadere che, il record di lettura che non è accettato possa finire di nuovo elaborare quando il broker è pronto ...

in caso di 3node zk un nodo guasto è accettabile poiché il quorum è ancora soddisfatto ... ma non posso permettermi i guasti 2node che porteranno alle conseguenze di cui sopra ...

Problemi correlati