Praktik terbaik untuk klien Kafka

Ketersediaan produsen

• Atur retries untuk menginstruksikan produsen untuk mencoba lagi mengirim pesan yang gagal selama broker gagal selesai. Kami merekomendasikan nilai integer max atau nilai tinggi serupa untuk sebagian besar kasus penggunaan. Kegagalan untuk melakukannya akan merusak ketersediaan tinggi Kafka.

• Atur delivery.timeout.ms untuk menentukan batas atas untuk total waktu antara mengirim pesan dan menerima pengakuan dari broker. Ini harus mencerminkan persyaratan bisnis tentang berapa lama pesan valid. Tetapkan batas waktu yang cukup tinggi untuk memungkinkan percobaan ulang yang cukup untuk menyelesaikan operasi failover. Kami merekomendasikan nilai 60 detik atau lebih tinggi untuk sebagian besar kasus penggunaan.

• Setel request.timeout.ms ke maksimum satu permintaan harus menunggu sebelum pengiriman ulang dicoba. Kami merekomendasikan nilai 10 detik atau lebih tinggi untuk sebagian besar kasus penggunaan.

• Setel retry.backoff.ms untuk mengonfigurasi penundaan antara percobaan ulang untuk menghindari badai percobaan ulang dan dampak ketersediaan. Kami merekomendasikan nilai minimum 200 ms untuk sebagian besar kasus penggunaan.

• Setel acks=all untuk mengonfigurasi daya tahan tinggi; ini harus sejalan dengan konfigurasi sisi server RF=3 dan min.isr=2 untuk memastikan semua partisi mengakui penulisan. ISR Selama satu broker offline, ini adalahmin.isr, yaitu2.

Ketersediaan konsumen

• Setel auto.offset.reset ke latest awalnya untuk grup konsumen baru atau yang dibuat ulang. Ini menghindari risiko penambahan beban cluster dengan mengkonsumsi seluruh topik.

• Atur auto.commit.interval.ms saat menggunakanenable.auto.commit. Kami merekomendasikan nilai minimum 5 detik untuk sebagian besar kasus penggunaan untuk menghindari risiko beban tambahan.

• Menerapkan penanganan pengecualian dalam kode pemrosesan pesan konsumen untuk menangani kesalahan sementara, misalnya, pemutus sirkuit atau tidur dengan back-off eksponensial. Kegagalan untuk melakukannya dapat mengakibatkan crash aplikasi, yang dapat menyebabkan penyeimbangan ulang yang berlebihan.

• Setel isolation.level untuk mengontrol cara membaca pesan transaksional:

  Kami merekomendasikan untuk selalu mengatur read_uncommitted secara implisit secara default. Ini hilang dari beberapa implementasi klien.

  Kami merekomendasikan nilai read_uncommitted saat menggunakan penyimpanan berjenjang.

• Setel client.rack untuk menggunakan pembacaan replika terdekat. Kami merekomendasikan pengaturan ke az id untuk meminimalkan biaya lalu lintas jaringan dan latensi. Lihat Mengurangi biaya lalu lintas jaringan MSK konsumen Amazon Anda dengan kesadaran rak.

Penyeimbangan kembali konsumen

• Setel session.timeout.ms ke nilai yang lebih besar dari waktu startup untuk aplikasi, termasuk jitter startup apa pun yang diterapkan. Kami merekomendasikan nilai 60 detik untuk sebagian besar kasus penggunaan.

• Atur heartbeat.interval.ms untuk menyempurnakan bagaimana koordinator grup memandang konsumen sebagai sehat. Kami merekomendasikan nilai 10 detik untuk sebagian besar kasus penggunaan.

• Tetapkan hook shutdown di aplikasi Anda untuk menutup konsumen dengan bersihSIGTERM, daripada mengandalkan batas waktu sesi untuk mengidentifikasi kapan konsumen meninggalkan grup. Aplikasi Kstream dapat diatur internal.leave.group.on.close ke nilai. true

• Tetapkan group.instance.id ke nilai yang berbeda dalam kelompok konsumen. Idealnya nama host, task-id, atau pod-id. Kami menyarankan untuk selalu menyetel ini untuk perilaku yang lebih deterministik dan korelasi log klien/server yang lebih baik selama pemecahan masalah.

• Setel group.initial.rebalance.delay.ms ke nilai sesuai dengan waktu penerapan rata-rata. Ini menghentikan penyeimbangan kembali terus-menerus selama penerapan.

• Setel partition.assignment.strategy untuk menggunakan penugasan lengket. Kami merekomendasikan salah satu StickyAssignor atauCooperativeStickyAssignor.

Kinerja produser

• Atur linger.ms untuk mengontrol jumlah waktu produsen menunggu batch untuk diisi. Batch yang lebih kecil secara komputasi mahal untuk Kafka karena mereka menerjemahkan ke lebih banyak utas dan operasi I/O sekaligus. Kami merekomendasikan nilai-nilai berikut.

  Nilai minimum 5 ms untuk semua kasus penggunaan termasuk latensi rendah.

  Kami merekomendasikan nilai 25 ms yang lebih tinggi, untuk sebagian besar kasus penggunaan.

  Kami merekomendasikan untuk tidak pernah menggunakan nilai nol dalam kasus penggunaan latensi rendah. (Nilai nol biasanya menyebabkan latensi terlepas dari overhead IO).

• Setel batch.size untuk mengontrol ukuran batch yang dikirim ke cluster. Kami merekomendasikan untuk meningkatkan ini ke nilai 64KB atau 128KB.

• Atur buffer.memory saat menggunakan ukuran batch yang lebih besar. Kami merekomendasikan nilai 64MB untuk sebagian besar kasus penggunaan.

• Setel send.buffer.bytes untuk mengontrol TCP buffer yang digunakan untuk menerima byte. Kami merekomendasikan nilai -1 untuk membiarkan OS mengelola buffer ini saat menjalankan produsen pada jaringan latensi tinggi.

• Atur compression.type untuk mengontrol kompresi batch. Kami merekomendasikan lz4 atau zstd menjalankan produser pada jaringan latensi tinggi.

Kinerja konsumen

• Atur fetch.min.bytes untuk mengontrol ukuran pengambilan minimum agar valid untuk mengurangi jumlah pengambilan dan beban cluster.

  Kami merekomendasikan nilai minimum 32 byte untuk semua kasus penggunaan.

  Kami merekomendasikan nilai 128 byte yang lebih tinggi untuk sebagian besar kasus penggunaan.

• Setel fetch.max.wait.ms untuk menentukan berapa lama konsumen Anda akan menunggu sebelum fetch.min.bytes diabaikan. Kami merekomendasikan nilai 1000ms untuk sebagian besar kasus penggunaan.

• Kami merekomendasikan jumlah konsumen setidaknya sama dengan jumlah partisi.

• Setel receive.buffer.bytes untuk mengontrol TCP buffer yang digunakan untuk menerima byte. Kami merekomendasikan nilai -1 untuk membiarkan OS mengelola buffer ini saat menjalankan konsumen pada jaringan latensi tinggi.

Koneksi klien

Siklus hidup koneksi memiliki biaya komputasi dan memori pada cluster Kafka. Terlalu banyak koneksi yang dibuat sekaligus menyebabkan beban yang dapat memengaruhi ketersediaan cluster Kafka. Dampak ketersediaan ini seringkali dapat menyebabkan aplikasi membuat lebih banyak koneksi, sehingga menyebabkan kegagalan cascading, yang mengakibatkan pemadaman penuh. Sejumlah besar koneksi dapat dicapai ketika dibuat pada tingkat yang wajar.

Kami merekomendasikan mitigasi berikut untuk mengelola tingkat pembuatan koneksi yang tinggi:

• Pastikan mekanisme penerapan aplikasi Anda tidak memulai ulang semua produsen/konsumen sekaligus, tetapi sebaiknya dalam batch yang lebih kecil.

• Pada lapisan aplikasi pengembang harus memastikan bahwa jitter acak (tidur acak) dilakukan sebelum membuat klien admin, klien produser, atau klien konsumen.

• PadaSIGTERM, ketika menutup koneksi, tidur acak harus dijalankan untuk memastikan tidak semua klien Kafka ditutup pada saat yang sama. Tidur acak harus dalam batas waktu sebelum SIGKILL terjadi.

  contoh Contoh A (Java)

  sleepInSeconds(randomNumberBetweenOneAndX);
                          this.kafkaProducer = new KafkaProducer<>(this.props);

  contoh Contoh B (Java)

  Runtime.getRuntime().addShutdownHook(new Thread(() -> {
      sleepInSeconds(randomNumberBetweenOneAndTwentyFive);
      kafkaProducer.close(Duration.ofSeconds(5));
  });

• Pada layer aplikasi, pengembang harus memastikan bahwa klien dibuat hanya sekali per aplikasi dalam pola tunggal. Misalnya, saat menggunakan lambda, klien harus dibuat dalam lingkup global, dan bukan di penangan metode.

• Kami merekomendasikan jumlah koneksi dipantau dengan tujuan menjadi stabil. Koneksi creation/close/shift normal selama penerapan dan failover broker.

Metrik produsen

• tingkat byte

• record-send-rate

• records-per-request-avg

• acks-latency-avg

• request-latency-avg

• request-latency-max

• record-error-rate

• record-retry-rate

• tingkat kesalahan

Metrik konsumen

• records-consumed-rate

• bytes-consumed-rate

• tingkat pengambilan

• records-lag-max

• record-error-rate

• fetch-error-rate

• tingkat jajak pendapat

• rebalance-latency-avg

• tingkat komitmen

Metrik umum

• connection-close-rate

• connection-creation-rate

• jumlah koneksi