View a markdown version of this page

Broker offline dan failover klien - Amazon Managed Streaming untuk Apache Kafka

Terjemahan disediakan oleh mesin penerjemah. Jika konten terjemahan yang diberikan bertentangan dengan versi bahasa Inggris aslinya, utamakan versi bahasa Inggris.

Broker offline dan failover klien

Kafka memungkinkan broker offline; broker offline tunggal dalam cluster yang sehat dan seimbang mengikuti praktik terbaik tidak akan melihat dampak atau menyebabkan kegagalan untuk memproduksi atau mengkonsumsi. Ini karena broker lain akan mengambil alih kepemimpinan partisi dan karena lib klien Kafka akan secara otomatis fail-over dan mulai mengirim permintaan ke broker pemimpin baru.

Kontrak server klien

Ini menghasilkan kontrak bersama antara perpustakaan klien dan perilaku sisi server; server harus berhasil menetapkan satu atau lebih pemimpin baru dan klien harus mengubah broker untuk mengirim permintaan ke pemimpin baru secara tepat waktu.

Kafka menggunakan pengecualian untuk mengontrol aliran ini:

Contoh prosedur

  1. Broker A memasuki keadaan offline.

  2. Klien Kafka menerima pengecualian (biasanya pemutusan jaringan atau not_leader_for_partition).

  3. Pengecualian ini memicu klien Kafka untuk memperbarui metadatanya sehingga ia tahu tentang pemimpin terbaru.

  4. Klien Kafka melanjutkan pengiriman permintaan ke pemimpin partisi baru di broker lain.

Proses ini biasanya memakan waktu kurang dari 2 detik dengan klien Java yang dijual dan konfigurasi default. Kesalahan sisi klien bersifat verbose dan berulang tetapi tidak perlu dikhawatirkan, seperti yang dilambangkan dengan level “WARN”.

Contoh: Pengecualian 1

10:05:25.306 [kafka-producer-network-thread | producer-1] WARN o.a.k.c.producer.internals.Sender - [Producer clientId=producer-1] Got error produce response with correlation id 864845 on topic-partition msk-test-topic-1-0, retrying (2147483646 attempts left). Error: NETWORK_EXCEPTION. Error Message: Disconnected from node 2

Contoh: Pengecualian 2

10:05:25.306 [kafka-producer-network-thread | producer-1] WARN o.a.k.c.producer.internals.Sender - [Producer clientId=producer-1] Received invalid metadata error in produce request on partition msk-test-topic-1-41 due to org.apache.kafka.common.errors.NotLeaderOrFollowerException: For requests intended only for the leader, this error indicates that the broker is not the current leader. For requests intended for any replica, this error indicates that the broker is not a replica of the topic partition.. Going to request metadata update now"

Klien Kafka akan secara otomatis menyelesaikan kesalahan ini biasanya dalam 1 detik dan paling banyak 3 detik. Ini muncul sebagai produce/consume latensi pada p99 dalam metrik sisi klien (biasanya milidetik tinggi di 100-an). Lebih lama dari ini biasanya menunjukkan masalah dengan konfigurasi klien atau beban pengontrol sisi server. Silakan lihat bagian pemecahan masalah.

Fail-over yang sukses dapat diverifikasi dengan memeriksa peningkatan LeaderCount metrik pada broker lain yang membuktikan bahwa lalu lintas dan kepemimpinan bergerak seperti yang diharapkan. BytesInPerSec Anda juga akan mengamati peningkatan UnderReplicatedPartitions metrik, yang diharapkan ketika replika offline dengan broker shutdown.

Pemecahan masalah

Alur di atas dapat terganggu dengan melanggar kontrak client-server. Alasan paling umum untuk masalah meliputi:

  • Salah konfigurasi atau penggunaan lib klien Kafka yang salah.

  • Perilaku dan bug default yang tidak terduga dengan lib klien pihak ketiga.

  • Pengontrol kelebihan beban menghasilkan penugasan pemimpin partisi yang lebih lambat.

  • Pengontrol baru sedang dipilih sehingga penugasan pemimpin partisi lebih lambat.

Untuk memastikan perilaku yang benar dalam menangani kegagalan kepemimpinan, kami merekomendasikan:

  • Praktik terbaik sisi server harus diikuti untuk memastikan bahwa broker pengontrol diskalakan dengan tepat untuk menghindari penugasan kepemimpinan yang lambat.

  • Pustaka klien harus mengaktifkan percobaan ulang untuk memastikan bahwa klien menangani failover.

  • Pustaka klien harus mengkonfigurasi retry.backoff.ms (default 100) untuk menghindari badai. connection/request

  • Pustaka klien harus menyetel request.timeout.ms dan delivery.timeout.ms ke nilai yang sejalan dengan SLA aplikasi. Nilai yang lebih tinggi akan menghasilkan fail-over yang lebih lambat untuk jenis kegagalan tertentu.

  • Pustaka klien harus memastikan bahwa bootstrap.servers berisi setidaknya 3 broker acak untuk menghindari dampak ketersediaan pada penemuan awal.

  • Beberapa pustaka klien memiliki level yang lebih rendah daripada yang lain dan mengharapkan pengembang aplikasi untuk menerapkan logika coba ulang dan penanganan pengecualian sendiri. Silakan merujuk ke dokumentasi khusus lib klien untuk contoh penggunaan, dan pastikan reconnect/retry logika yang benar diikuti.

  • Kami merekomendasikan pemantauan latensi sisi klien untuk hasil, jumlah permintaan yang berhasil, dan jumlah kesalahan untuk kesalahan yang tidak dapat dicoba ulang.

  • Kami telah mengamati bahwa perpustakaan golang dan ruby pihak ketiga yang lebih lama tetap bertele-tele selama seluruh periode waktu offline broker meskipun permintaan produksi dan konsumsi tidak terpengaruh. Sebaiknya Anda selalu memantau metrik tingkat bisnis Anda selain metrik permintaan untuk keberhasilan dan kesalahan untuk menentukan apakah ada dampak nyata vs noise di log Anda.

  • Pelanggan tidak boleh khawatir tentang pengecualian sementara network/not_leader karena mereka normal, tidak berdampak, dan diharapkan sebagai bagian dari protokol kafka.

  • Pelanggan tidak boleh UnderReplicatedPartitions khawatir karena mereka normal, tidak berdampak, dan diharapkan selama satu broker offline.