Praktik terbaik untuk klien Apache Kafka

Ketersediaan produsen

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

• Set delivery.timeout.ms el 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.

• Set request.timeout.ms el ke maksimum permintaan tunggal 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 200ms untuk sebagian besar kasus penggunaan.

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

Ketersediaan konsumen

• Set auto.offset.reset el 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.

• Terapkan 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 aplikasi crash, yang dapat menyebabkan penyeimbangan ulang yang berlebihan.

• Set isolation.level el untuk mengontrol cara membaca pesan transaksional:

  Kami merekomendasikan 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 replika terdekat yang dibaca. Sebaiknya setel ke untuk az id meminimalkan biaya lalu lintas jaringan dan latensi. Lihat Mengurangi biaya lalu lintas jaringan konsumen Amazon MSK Anda dengan kesadaran rak.

Penyeimbangan kembali konsumen

• Set session.timeout.ms el 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.

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

• Atur pengait shutdown di aplikasi Anda untuk menutup konsumen dengan rapi di SIGTERM, daripada mengandalkan batas waktu sesi untuk mengidentifikasi kapan konsumen meninggalkan grup. Aplikasi Kstream dapat diatur internal.leave.group.on.close ke nilaitrue.

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

• Set group.initial.rebalance.delay.ms el ke nilai yang sejalan dengan waktu penerapan rata-rata. Ini menghentikan penyeimbangan ulang terus-menerus selama penerapan.

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

Kinerja produser

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

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

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

  Sebaiknya jangan pernah menggunakan nilai nol dalam kasus penggunaan latensi rendah. (Nilai nol biasanya menyebabkan latensi terlepas karena overhead IO).

• Set batch.size el untuk mengontrol ukuran batch yang dikirim ke cluster. Sebaiknya tingkatkan 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.

• Set send.buffer.bytes el untuk mengontrol buffer TCP 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 produsen pada jaringan latensi tinggi.

Kinerja konsumen

• Set fetch.min.bytes el 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 untuk paralelisme dan ketahanan yang lebih baik. Dalam beberapa situasi, Anda dapat memilih untuk memiliki lebih sedikit konsumen daripada jumlah partisi untuk topik throughput rendah.

• Set receive.buffer.bytes el untuk mengontrol buffer TCP 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 klaster 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 bertingkat, 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 producers/consumers sekaligus, tetapi sebaiknya dalam batch yang lebih kecil.

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

• Di SIGTERM, saat 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 lapisan 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 dalam pengendali metode.

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

Metrik produsen

• tingkat byte

• tingkat pengirim-rekaman

• catatan-per-permintaan-rata-rata

• acks-latensi-avg

• permintaan-latensi-rata-rata

• permintaan-latensi-maks

• tingkat kesalahan rekaman

• tingkat rekor ulang

• tingkat kesalahan

Metrik konsumen

• tingkat konsumsi rekaman

• tingkat konsumsi byte

• tingkat pengambilan

• rekord-lag-max

• tingkat kesalahan rekaman

• tingkat kesalahan pengambilan

• tingkat jajak pendapat

• rebalance-latency-avg

• tingkat komitmen

Metrik umum

• tingkat penutupan koneksi

• tingkat penciptaan koneksi

• penghitungan koneksi