Konfigurasi Broker
| Properti | Default | Deskripsi | | broker.id | | Setiap broker dapat diidentifikasi dengan ID bilangan bulat non-negatif yang unik; ID ini dapat digunakan sebagai "nama" broker, dan keberadaannya memungkinkan broker untuk bermigrasi ke host/port yang berbeda tanpa membingungkan konsumen. Anda dapat memilih nomor apa pun yang Anda suka sebagai ID, selama ID tersebut unik. | | log.dirs | /tmp/kafka-logs | Jalur tempat kafka menyimpan data. Jalur ini tidak unik, bisa beberapa, dan jalurnya hanya perlu dipisahkan dengan koma; Setiap kali partisi baru dibuat, partisi dipilih untuk melakukannya di bawah jalur yang berisi jumlah partisi paling sedikit. | | pelabuhan | 6667 | server menerima port yang terhubung dengan klien | | Penjaga kebun binatang.terhubung | nol | Format string koneksi ZooKeeper adalah: hostname:port, di mana nama host dan port masing-masing adalah host dan port simpul dalam kluster ZooKeeper. Untuk terhubung ke node ZooKeeper lain saat host mati, Anda dapat membuat beberapa host sebagai berikut:
hostname1:port1, hostname2:port2, hostname3:port3.
ZooKeeper memungkinkan Anda menambahkan jalur "chroot" untuk menyimpan semua data kafka di kluster di bawah jalur tertentu. Ketika beberapa kluster Kafka atau aplikasi lain menggunakan kluster ZooKeeper yang sama, Anda dapat menggunakan metode ini untuk mengatur jalur penyimpanan data. Ini dapat diimplementasikan dengan memformat string koneksi seperti ini:
nama host1:port1,nama host2:port2,nama host3:port3/chroot/path
Pengaturan ini menyimpan semua data kluster kafka di bawah jalur /chroot/path. Perhatikan bahwa sebelum memulai broker, Anda harus membuat jalur ini, dan konsumen harus menggunakan format koneksi yang sama. | | message.max.byte | 1000000 | Ukuran maksimum pesan yang dapat diterima server. Penting bahwa pengaturan konsumen dan produsen mengenai properti ini harus disinkronkan, jika tidak, pesan yang diterbitkan oleh produsen terlalu besar untuk konsumen. | | nu.jaringan.utas | 3 | Jumlah utas jaringan yang digunakan oleh server untuk memproses permintaan jaringan; Anda umumnya tidak perlu mengubah properti ini. | | nu.io.threads | 8 | Jumlah utas I/O yang digunakan oleh server untuk memproses permintaan; Jumlah utas harus setidaknya sama dengan jumlah hard disk. | | latar belakang.utas | 4 | Jumlah utas yang digunakan untuk pemrosesan latar belakang, seperti penghapusan file; Anda tidak perlu mengubah properti ini. | | queued.max.permintaan | 500 | Jumlah maksimum permintaan yang dapat diantrek untuk diproses oleh utas I/O sebelum utas jaringan berhenti membaca permintaan baru. | | host.name | nol | nama host broker; Jika nama host sudah ditetapkan, broker hanya akan terikat ke alamat ini; Jika tidak ada pengaturan, itu akan mengikat ke semua antarmuka dan menerbitkan satu salinan ke ZK | | advertised.host.name | nol | Jika ditetapkan, itu dikirim ke produsen, konsumen, dan broker lain sebagai nama host broker | | diiklankan.port | nol | Port ini diberikan kepada produsen, konsumen, dan broker lainnya, dan digunakan untuk membangun koneksi; Itu hanya perlu diatur jika port aktual dan port yang perlu diikat server berbeda. | | soket.kirim.penyangga.byte | 100 * 1024 | SO_SNDBUFF Ukuran cache, yang digunakan server untuk membuat koneksi soket | | soket.menerima.penyangga.byte | 100 * 1024 | SO_RCVBUFF ukuran cache, yang digunakan oleh server untuk terhubung ke soket | | socket.request.max.byte | 100 * 1024 * 1024 | Ukuran permintaan maksimum yang diizinkan oleh server; Ini akan menghindari luapan server, yang seharusnya lebih kecil dari ukuran tumpukan Java | | nu.partisi | 1 | Jika jumlah partisi tidak diberikan saat membuat topik, nomor ini akan menjadi jumlah partisi default di bawah topik. | | log.segmen.byte | 1014*1024*1024 | Log partisi topik disimpan dalam banyak file di direktori tertentu, yang membagi log partisi menjadi beberapa segmen; Atribut ini adalah ukuran maksimum setiap file; Ketika dimensi mencapai nilai ini, file baru akan dibuat. Pengaturan ini dapat ditimpa berdasarkan dasar setiap topik.
Lihat Login hyperlink terlihat. | | log.roll.hours | 24 * 7 | Bahkan jika file tidak mencapai log.segment.bytes, file baru dibuat setiap kali waktu pembuatan file mencapai properti ini. Pengaturan ini juga dapat ditimpa oleh pengaturan tingkat topik;
MelihatLogin hyperlink terlihat. | | log.pembersihan.kebijakan | Hapus | | | log.retention.minutes dan log.retention.hours | 7 hari | Waktu setiap file log disimpan sebelum dihapus. Waktu penghematan data default adalah sama untuk semua topik.
log.retention.minutes dan log.retention.bytes keduanya digunakan untuk mengatur penghapusan file log, terlepas dari properti mana yang telah meluap.
Pengaturan properti ini dapat ditimpa saat topik pada dasarnya ditetapkan.
MelihatLogin hyperlink terlihat. | | log.retensi.byte | -1 | Jumlah total data yang disimpan oleh setiap partisi di bawah setiap topik; Perhatikan bahwa ini adalah batas atas per partisi, jadi angka ini dikalikan dengan jumlah partisi adalah jumlah total data yang disimpan per topik. Perhatikan juga: Jika log.retention.hours dan log.retention.bytes diatur, melebihi salah satu batas akan menyebabkan file segmen dihapus.
Perhatikan bahwa pengaturan ini dapat ditimpa oleh setiap topik.
MelihatLogin hyperlink terlihat. | | log.retention.check.interval.ms | 5 menit | Periksa interval antara file tersegmentasi log untuk menentukan apakah atribut file memenuhi persyaratan penghapusan. | | log.pembersih.aktifkan | false | Ketika properti ini diatur ke false, properti ini akan dihapus setelah log disimpan untuk waktu atau ukuran maksimum. Jika diatur ke true, itu akan terjadi ketika atribut save mencapai batas atasLogin hyperlink terlihat.。 | | log.pembersih.utas | 1 | Jumlah utas yang melakukan kompresi log | | log.cleaner.io.max.bytes.per.detik | Tidak | Jumlah maksimum I/O yang dapat dimiliki pembersih log saat melakukan pemadatan log. Pengaturan ini membatasi pembersih untuk menghindari gangguan pada layanan permintaan aktif. | | log.cleaner.io.buffer.size | 500*1024*1024 | Pembersih Log mengindeks log selama proses pembersihan dan mengurangi ukuran cache yang digunakan. Yang terbaik adalah mengaturnya besar untuk memberikan memori yang cukup. | | log.pembersih.io.buffer.beban.faktor | 512*1024 | Ukuran potongan I/O yang diperlukan untuk pembersihan kayu. Anda tidak perlu mengubah pengaturan ini. | | log.pembersih.io.buffer.beban.faktor | 0.9 | faktor beban tabel hash yang digunakan dalam pembersihan log; Anda tidak perlu mengubah opsi ini. | | log.cleaner.backoff.ms | 15000 | Interval waktu di mana log dibersihkan dilakukan | | log.pembersih.min.rasio yang dapat dibersihkan | 0.5 | Konfigurasi ini mengontrol seberapa sering pemadat log mencoba membersihkan log (diasumsikanLogin hyperlink terlihat.terbuka). Secara default, hindari membersihkan lebih dari 50% batang kayu. Rasio ini terkait dengan ruang maksimum yang digunakan oleh log cadangan (50% log dikompresi pada 50%). Tingkat yang lebih tinggi berarti lebih sedikit limbah dan lebih banyak ruang dapat dibersihkan dengan lebih efisien. Pengaturan ini dapat ditimpa di setiap pengaturan topik.
MelihatLogin hyperlink terlihat.。 | | log.cleaner.delete.retention.ms | 1 hari | waktu penyimpanan; Waktu maksimum untuk menyimpan log terkompresi; Ini juga merupakan waktu maksimum bagi klien untuk menggunakan pesan, dan perbedaan antara log.retention.minutes adalah bahwa satu mengontrol data yang tidak terkompresi dan yang lainnya mengontrol data terkompresi, yang akan ditimpa oleh waktu yang ditentukan saat topik dibuat. | | log.index.size.max.byte | 10*1024*1024 | Ukuran maksimum per segmen log. Perhatikan bahwa jika ukuran log mencapai nilai ini, segmen log baru perlu dibuat meskipun ukurannya tidak melebihi batas log.segment.bytes. | | log.indeks.interval.byte | 4096 | Saat melakukan pengambilan, Anda perlu memindai offset terdekat dengan jumlah ruang tertentu, semakin besar pengaturannya, semakin baik, umumnya menggunakan nilai default | | log.flush.interval.messages.messages | Nilai Maks Panjang | log file "sinkronisasi" ke disk sebelum mengumpulkan pesan. Karena operasi IO disk adalah operasi yang lambat, tetapi juga sarana yang diperlukan untuk "keandalan data", periksa apakah interval waktu untuk menyembuhkan hard disk diperlukan. Jika nilai ini terlalu besar, itu akan menyebabkan waktu "sinkronisasi" yang terlalu lama (pemblokiran IO), jika nilai ini terlalu kecil, itu akan menyebabkan waktu "fsync" (pemblokiran IO) yang lama, jika nilai ini terlalu kecil, itu akan menyebabkan banyak kali "sinkronisasi", yang berarti bahwa permintaan klien secara keseluruhan memiliki penundaan tertentu, dan kegagalan server fisik akan menyebabkan hilangnya pesan tanpa fsync. | | log.flush.scheduler.interval.ms | Nilai Maks Panjang | Periksa apakah interval fsinkron diperlukan | | log.flush.interval.ms | Nilai Maks Panjang | Angka ini digunakan untuk mengontrol interval waktu "fsync", jika jumlah pesan tidak pernah mencapai jumlah pesan yang dipadatkan ke disk, tetapi interval waktu dari sinkronisasi disk terakhir mencapai ambang batas, sinkronisasi disk juga akan dipicu. | | log.delete.delay.ms | 60000 | Waktu retensi setelah file dihapus dalam indeks umumnya tidak perlu dimodifikasi | | otomatis.buat.topik.aktifkan | true | Apakah akan mengizinkan pembuatan topik secara otomatis. Jika true, itu akan secara otomatis membuat topik yang tidak ada ketika produce atau fetch tidak ada. Jika tidak, Anda perlu menggunakan baris perintah untuk membuat topik | | controller.socket.timeout.ms | 30000 | Waktu batas waktu soket saat pengontrol manajemen partisi melakukan pencadangan. | | pengontrol.pesan.antrian.ukuran | Nilai Maks Int. | pengontrol-ke-broker-channles | | default.replikasi.faktor | 1 | Jumlah default salinan cadangan hanya mengacu pada topik yang dibuat secara otomatis | | replica.lag.time.max.ms | 10000 | Jika pengikut tidak mengirim permintaan pengambilan dalam waktu ini, pemimpin akan menghapus kembali pengikut dari ISR dan menganggap pengikut tersebut digantung | | replica.lag.max.pesan | 4000 | Jika replika memiliki lebih dari jumlah yang tidak dicadangkan ini, pemimpin akan menghapus pengikut dan menganggap pengikut digantung | | replica.socket.timeout.ms | 30*1000 | Waktu batas waktu pemimpin untuk permintaan jaringan soket saat mencadangkan data | | replika.soket.menerima.buffer.byte | 64*1024 | Buffer penerimaan soket saat mengirim permintaan jaringan ke pemimpin selama pencadangan | | replica.fetch.max.byte | 1024*1024 | Nilai maksimum setiap pengambilan pada saat pencadangan | | replika.mengambil.min.byte | 500 | Waktu tunggu maksimum agar data mencapai pemimpin saat pemimpin membuat permintaan pencadangan | | replika.mengambil.min.byte | 1 | Ukuran respons terkecil setelah setiap pengambilan saat mencadangkan | | nu.replika.fetchers | 1 | Jumlah utas yang mencadangkan data dari pemimpin | | replica.high.watermark.checkpoint.interval.ms | 5000 | Setiap replika memeriksa seberapa sering ketinggian air tertinggi disembuhkan | | fetch.purgatory.purge.interval.requests | 1000 | Minta Pengambilan Interval Pembersihan | | producer.purgatory.purge.interval.requests | 1000 | Produser meminta interval pembersihan | | zookeeper.session.timeout.ms | 6000 | Batas waktu sesi penjaga kebun binatang. | | zookeeper.connection.timeout.ms | 6000 | Jumlah waktu maksimum klien menunggu untuk membuat koneksi dengan penjaga kebun binatang | | zookeeper.sync.time.ms | 2000 | Pengikut ZK tertinggal di belakang pemimpin ZK untuk waktu yang lama | | terkendali.mematikan.mengaktifkan | true | Apakah mungkin untuk mengontrol penutupan broker. Jika memungkinkan, broker akan dapat memindahkan semua pemimpin ke broker lain sebelum menutup. Ini mengurangi ketidaktersediaan selama proses shutdown. | | controlled.shutdown.max.percobaan ulang | 3 | Jumlah perintah yang berhasil mengeksekusi shutdown sebelum melakukan shutdown yang tidak lengkap. | | controlled.shutdown.retry.backoff.ms | 5000 | Waktu mundur di antara shutdown | | otomatis.pemimpin.menyeimbangkan ulang.mengaktifkan | true | Jika ini benar, pengontrol akan secara otomatis menyeimbangkan kepemimpinan broker atas partisi | | pemimpin.ketidakseimbangan.per.broker.persentase | 10 | Rasio ketidakseimbangan maksimum yang diizinkan oleh setiap broker | | leader.imbalance.check.interval.seconds | 300 | Periksa frekuensi ketidakseimbangan pemimpin | | offset.metadata.max.bytes | 4096 | Memungkinkan klien untuk menyimpan jumlah maksimum offset mereka | | maks.koneksi.per.ip | Nilai Maks Int. | Jumlah maksimum koneksi per broker dapat dilakukan ke setiap alamat IP | | max.connections.per.ip.overrides | | Cakupan maksimum koneksi default per IP atau nama host | | connections.max.idle.ms | 600000 | Batas batas waktu untuk koneksi kosong | | log.roll.jitter. {ms,jam} | 0 | Jumlah maksimum jitter yang diabstraksi dari logRollTimeMillis | | nu.pemulihan.utas.per.data.dir | 1 | Jumlah utas yang digunakan setiap direktori data untuk mencatat pemulihan | | tidak bersih.pemimpin.pemilihan.aktifkan | true | Menunjukkan apakah dimungkinkan untuk menggunakan pengaturan non-replika di ISR sebagai pemimpin | | hapus.topik.aktifkan | false | Dapat menghapus topik | | offsets.topic.num.partitions | 50 | Jumlah partisi untuk topik commit offset. Karena mengubah ini setelah penyebaran saat ini tidak didukung, kami sarankan untuk menggunakan pengaturan yang lebih tinggi untuk produksi (misalnya, 100-200). | | offsets.topic.retensi.menit | 1440 | Offset yang telah ada lebih lama dari batas waktu ini akan ditandai sebagai menunggu penghapusan | | offsets.retention.check.interval.ms | 600000 | Manajer offset memeriksa frekuensi offset kedaluwarsa | | offsets.topic.replication.factor | 3 | Jumlah salinan cadangan offset topik. Disarankan untuk menetapkan angka yang lebih tinggi untuk menjamin ketersediaan yang lebih tinggi | | offset.topic.segment.bytes | 104857600 | topik offset. | | offsets.load.buffer.size | 5242880 | Pengaturan ini terkait dengan ukuran batch dan digunakan saat membaca dari segmen offset. | | offsets.commit.required.acks | -1 | Jumlah konfirmasi perlu diatur sebelum penerapan offset dapat diterima, dan umumnya tidak perlu diubah |
| Properti | Default | Properti Default Server | Deskripsi | | cleanup.policy | Hapus | log.pembersihan.kebijakan | Baik "hapus" atau "kompak"; String ini menunjukkan cara memanfaatkan bagian log lama; Metode default ("hapus") akan membuang suku cadang lama ketika waktu daur ulang atau batas ukurannya tercapai. "kompak" akan memampatkan kayu gelondongan | | delete.retention.ms | 86400000 (24 jam) | log.cleaner.delete.retention.ms | Perbedaan antara log.retention.minutes adalah bahwa yang satu mengontrol data yang tidak terkompresi dan yang lainnya mengontrol data terkompresi. Konfigurasi ini dapat ditimpa oleh parameter penyematan saat topik dibuat | | flush.messages | Tidak | log.flush.interval.messages.messages | Konfigurasi ini menentukan interval waktu untuk memaksa log fsinkron. Misalnya, jika opsi ini diatur ke 1, maka fsync diperlukan setelah setiap pesan, dan jika diatur ke 5, fsync diperlukan untuk setiap 5 pesan. Secara umum, Anda disarankan untuk tidak menetapkan nilai ini. Pengaturan parameter ini memerlukan trade-off yang diperlukan antara "keandalan data" dan "kinerja". Jika nilai ini terlalu besar, itu akan menyebabkan waktu yang lama untuk "fsync" setiap kali (pemblokiran IO), dan jika nilai ini terlalu kecil, itu akan menyebabkan sejumlah besar "fsync", yang juga berarti bahwa ada penundaan tertentu dalam permintaan klien secara keseluruhan. Kegagalan server fisik akan menyebabkan pesan hilang tanpa fsync. | | flush.ms | Tidak | log.flush.interval.ms | Konfigurasi ini digunakan untuk menyematkan interval waktu antara memaksa log fsync ke disk; Misalnya, jika diatur ke 1000, maka fsync diperlukan setiap 1000 milidetik. Opsi ini umumnya tidak disarankan | | indeks.interval.byte | 4096 | log.indeks.interval.byte | Pengaturan default memastikan bahwa kita menambahkan indeks ke pesan setiap 4096 byte, dan lebih banyak indeks membuat pesan yang dibaca lebih dekat, tetapi ukuran indeks akan ditingkatkan. Opsi ini umumnya tidak diperlukan | | maks.pesan.byte | 1000000 | maks.pesan.byte | Ukuran maksimum pesan tambahan kafka. Perhatikan bahwa jika Anda meningkatkan ukuran ini, Anda juga harus meningkatkan ukuran pengambilan konsumen sehingga konsumen dapat mengambil pesan ke ukuran maksimum tersebut. | | min.dibersihkan.kotor.rasio | 0.5 | min.dibersihkan.kotor.rasio | Konfigurasi ini mengontrol seberapa sering kompresor log mencoba membersihkan log. Secara default, log dengan tingkat kompresi lebih dari 50% akan dihindari. Rasio ini menghindari pemborosan ruang terbesar | | min.insync.replicas | 1 | min.insync.replicas | Ketika produser diatur ke request.required.acks ke -1, min.insync.replicas menentukan jumlah minimum replika (setiap penulisan repica harus berhasil), dan jika angka ini tidak tercapai, produser akan menghasilkan pengecualian. | | retensi.byte | Tidak | log.retensi.byte | Jika Anda menggunakan kebijakan retensi "hapus", konfigurasi ini mengacu pada ukuran maksimum yang dapat dicapai log sebelum dihapus. Secara default, tidak ada batas ukuran tetapi hanya batas waktu | | retention.ms | 7 hari | log.retensi.menit | Jika Anda menggunakan kebijakan retensi "hapus", konfigurasi ini mengacu pada waktu ketika log disimpan sebelum log penghapusan. | | segmen.byte | 1GB | log.segmen.byte | Di Kafka, log log disimpan dalam potongan, dan konfigurasi ini mengacu pada ukuran log log yang dibagi menjadi beberapa potongan | | segmen.indeks.byte | 10MB | log.index.size.max.byte | Konfigurasi ini adalah tentang ukuran file indeks yang dipetakan antara offset dan lokasi file; Konfigurasi ini umumnya tidak perlu dimodifikasi | | segment.ms | 7 hari | log.roll.hours | Bahkan jika file potongan log tidak mencapai ukuran yang perlu dihapus atau dikompresi, setelah waktu log mencapai batas atas ini, file potongan log baru akan dipaksa | | segment.jitter.ms | 0 | log.roll.jitter. {ms,jam} | Jitter maksimum untuk dikurangi dari logRollTimeMillis. |
Konfigurasi Konsumen
| Properti | Default | Deskripsi | | group.id | | String yang secara unik mengidentifikasi grup tempat proses konsumen berada, dan jika ID grup yang sama ditetapkan, itu berarti bahwa proses ini termasuk dalam grup konsumen yang sama | | Penjaga kebun binatang.terhubung | | Tentukan string koneksi Zookeeper, formatnya adalah hostname:port, di sini host dan port adalah host dan port dari Zookeeper Server, untuk menghindari kehilangan kontak setelah mesin Zookeeper mati, Anda dapat menentukan beberapa hostname:port, menggunakan koma sebagai pemisahan:
nama host1:port1,nama host2:port2,nama host3:port3
Anda dapat menambahkan jalur chroot ZooKeeper ke string koneksi ZooKeeper, yang digunakan untuk menyimpan datanya sendiri, dengan cara:
nama host1:port1,nama host2:port2,nama host3:port3/chroot/path | | consumer.id | nol | Tidak diperlukan penyiapan, dan umumnya dibuat secara otomatis | | socket.timeout.ms | 30*100 | Batas batas waktu untuk permintaan jaringan. Batas waktu habis yang sebenarnya adalah max.fetch.wait+socket.timeout.ms | | soket.menerima.penyangga.byte | 64*1024 | socket digunakan untuk menerima ukuran cache permintaan jaringan | | fetch.message.max.byte | 1024*1024 | Jumlah maksimum byte per pesan pengambilan per permintaan pengambilan. Byte ini akan diawasi dalam memori yang digunakan untuk setiap partisi, sehingga pengaturan ini akan mengontrol jumlah memori yang digunakan oleh konsumen. Ukuran permintaan pengambilan harus setidaknya sama dengan ukuran pesan maksimum yang diizinkan oleh server, jika tidak, ukuran pesan yang dapat dikirim produsen lebih besar dari ukuran yang dapat digunakan konsumen. | | numu.konsumen.fetchers | 1 | Jumlah utas pengambilan yang digunakan untuk mengambil data | | otomatis.melakukan.aktifkan | true | Jika true, offset pesan yang diambil oleh konsumen akan secara otomatis disinkronkan ke penjaga kebun binatang. Offset komit ini akan digunakan oleh konsumen baru saat proses ditutup | | auto.commit.interval.ms | 60*1000 | Frekuensi di mana konsumen mengirimkan offset ke penjaga kebun binatang adalah dalam hitungan detik | | queued.max.pesan.potongan | 2 | Jumlah maksimum pesan yang digunakan untuk di-cache untuk konsumsi. Setiap potongan harus sama dengan fetch.message.max.bytes | | rebalance.max.percobaan ulang | 4 | Ketika konsumen baru ditambahkan ke grup konsumen, kumpulan konsumen mencoba menyeimbangkan kembali jumlah partisi yang dialokasikan untuk setiap konsumen. Jika koleksi konsumen berubah, penyeimbangan ulang ini gagal dan akan terjadi kembali saat alokasi sedang dijalankan | | fetch.min.bytes | 1 | Jumlah minimum byte yang harus dikembalikan server dengan setiap permintaan pengambilan. Jika tidak cukup data yang dikembalikan, permintaan menunggu hingga data yang cukup dikembalikan. | | fetch.wait.max.ms | 100 | Jika tidak ada cukup data untuk memenuhi fetch.min.bytes, konfigurasi ini mengacu pada jumlah waktu maksimum yang akan diblokir server sebelum merespons permintaan pengambilan. | | rebalance.backoff.ms | 2000 | waktu mundur sebelum mencoba kembali reblance | | refresh.leader.backoff.ms | 200 | Ada waktu mundur untuk menunggu sebelum mencoba menentukan apakah pemimpin partisi telah kehilangan kepemimpinannya | | otomatis.offset.reset | terbesar | Jika tidak ada offset yang diinisialisasi di zookeeper, jika offset adalah respons terhadap nilai berikut:
terkecil: Setel ulang offset otomatis ke offset terkecil
terbesar: Setel ulang otomatis offset ke offset terbesar
apa pun: memberikan pengecualian kepada konsumen | | consumer.timeout.ms | -1 | Jika tidak ada pesan yang tersedia, bahkan setelah menunggu jangka waktu tertentu, pengecualian batas waktu akan ditampilkan | | exclude.internal.topics | true | Apakah akan mengekspos pesan dari topik internal kepada konsumen | | paritition.tugas.strategi | Rentang | Pilih kebijakan untuk menetapkan partisi ke alur konsumen, rentang opsional, roundrobin | | client.id | Nilai ID grup | adalah string khusus pengguna yang membantu melacak panggilan di setiap permintaan. Ini harus secara logis mengonfirmasi aplikasi yang menghasilkan permintaan | | zookeeper.session.timeout.ms | 6000 | Batas waktu untuk sesi penjaga kebun binatang. Jika konsumen tidak mengirim pesan detak jantung ke penjaga kebun binatang selama waktu ini, itu dianggap ditutup dan reblance akan dihasilkan | | zookeeper.connection.timeout.ms | 6000 | Waktu tunggu maksimum bagi klien untuk membuat koneksi Zookeeper | | zookeeper.sync.time.ms | 2000 | Pengikut ZK dapat tertinggal di belakang pemimpin ZK untuk waktu maksimal | | offset.storage | Penjaga kebun binatang | Tempat yang digunakan untuk menyimpan offset: penjaga kebun binatang atau kafka | | offset.channel.backoff.ms | 1000 | Waktu mundur menyambungkan kembali ke saluran offset atau mencoba kembali permintaan pengambilan/penerapan dari offset yang gagal | | offsets.channel.socket.timeout.ms | 10000 | Batas batas waktu soket untuk respons terhadap respons permintaan pengambilan/penerapan saat membaca offset. Batas waktu tunggu ini digunakan oleh permintaan consumerMetadata untuk meminta manajemen offset | | offsets.commit.max.percobaan ulang | 5 | Berapa kali penerapan offset dicoba ulang. Percobaan ulang ini hanya diterapkan untuk mengimbangi penerapan antara pematian. dia | | dual.commit.enabled | true | Jika Anda menggunakan "kafka" sebagai offsets.storage, Anda dapat melakukan offset ke zookeeper dua kali (dan sekali ke kafka). Ini adalah suatu keharusan saat bermigrasi dari penyimpanan offset berbasis zookeeper ke penyimpanan offset berbasis kafka. Untuk grup konsumen tertentu, ini adalah rekomendasi yang aman untuk menonaktifkan opsi ini setelah migrasi selesai | | partisi.penetapan.strategi | Rentang | Pilih antara kebijakan "rentang" dan "roundrobin" sebagai kebijakan untuk menetapkan partisi ke aliran data konsumen; Alokasi partisi melingkar mengalokasikan semua partisi yang tersedia serta semua utas konsumen yang tersedia. Ini akan menetapkan loop partisi ke utas konsumen. Jika semua instans konsumen berlangganan determined, partisi dibagi menjadi distribusi deterministik. Strategi alokasi round-robin hanya dimungkinkan jika kondisi berikut terpenuhi: (1) Setiap topik memiliki jumlah aliran data yang sama per kekuatan konsumen. (2) Kumpulan topik langganan ditentukan untuk setiap instans konsumen dalam grup konsumen. |
Konfigurasi Produser
| Properti | Default | Deskripsi | | metadata.broker.daftar | | Sajikan bootstrapping. Produser hanya digunakan untuk mendapatkan metadata (topik, partisi, replika). Koneksi soket untuk mengirim data aktual akan dibuat berdasarkan data metadata yang dikembalikan. Formatnya adalah:
host1: port1, host2: port2
Daftar ini bisa berupa subdaftar broker atau VIP yang menunjuk ke broker | | request.required.acks | 0 | Konfigurasi ini adalah nilai pengakuan yang menunjukkan kapan permintaan produksi dianggap selesai. Secara khusus, berapa banyak broker lain yang harus mengirimkan data ke log mereka dan mengonfirmasi informasi ini kepada pemimpin mereka. Nilai tipikal meliputi:
0: Menunjukkan bahwa produsen tidak pernah menunggu konfirmasi dari broker (perilaku yang sama dengan 0,7). Opsi ini memberikan latensi paling sedikit tetapi pada saat yang sama risiko terbesar (karena data hilang saat server turun).
1: Menunjukkan bahwa replika pemimpin telah menerima konfirmasi data. Opsi ini memiliki latensi rendah dan memastikan bahwa server mengonfirmasi bahwa itu diterima.
-1: Produsen mendapatkan konfirmasi bahwa semua replika yang disinkronkan telah menerima data. Latensi adalah yang terbesar, namun, metode ini tidak sepenuhnya menghilangkan risiko pesan yang hilang, karena jumlah replika yang disinkronkan mungkin 1. Jika Anda ingin memastikan bahwa beberapa replika menerima data, maka Anda harus mengatur opsi min.insync.replicas di pengaturan tingkat topik. Baca dokumentasi desain untuk diskusi yang lebih mendalam. | | request.timeout.ms | 10000 | Broker mencoba yang terbaik untuk menerapkan persyaratan request.required.acks, jika tidak, kesalahan akan dikirim ke klien | | produsen.jenis | sinkronisasi | Opsi ini menyematkan apakah pesan dikirim secara asinkron di utas latar belakang. Nilai yang benar:
(1) asinkron: Pengiriman asinkron
(2) sinkronisasi: Pengiriman yang disinkronkan
Dengan mengatur produsen ke asinkron, kita dapat memproses permintaan dalam batch (yang bagus untuk throughput yang lebih tinggi), tetapi ini juga menciptakan kemungkinan bahwa mesin klien akan kehilangan data yang belum terkirim | | serializer.class | kafka.serializer.DefaultEncoder | Kategori serialisasi pesan. Encoder default memasuki satu byte[] dan mengembalikan byte yang sama[] | | kunci.serializer.kelas | | Kelas serialisasi untuk kata kunci. Jika ini tidak diberikan, defaultnya adalah untuk mencocokkan pesan | | partitioner.class | kafka.producer.DefaultPartitioner | partitioner untuk membagi pesan antar subtopik. Partisi default didasarkan pada tabel hash kunci | | kompresi.codec | tidak | Parameter ini dapat mengatur codec untuk mengompresi data, yang dapat dipilih sebagai "none", "gzip", "snappy". | | terkompres.topik | nol | Parameter ini dapat digunakan untuk mengatur apakah topik tertentu dikompresi. Jika codec terkompresi adalah codec selain NoCompressCodec, codec ini diterapkan ke data topik yang ditentukan. Jika daftar topik terkompresi kosong, terapkan codec terkompresi tertentu ke semua topik. Jika codec terkompresi adalah NoCompressionCodec, kompresi tidak tersedia untuk semua topik. | | message.send.max.percobaan ulang | 3 | Parameter ini akan menyebabkan produsen secara otomatis mencoba kembali permintaan pengiriman yang gagal. Parameter ini menyematkan jumlah percobaan ulang. Catatan: Menetapkan nilai non-0 akan menyebabkan kesalahan jaringan tertentu berulang: menyebabkan pengiriman dan menyebabkan hilangnya pengakuan | | retry.backoff.ms | 100 | Sebelum setiap percobaan ulang, produser memperbarui metadata topik yang relevan untuk melihat apakah pemimpin baru ditetapkan. Karena pemilihan pemimpin membutuhkan sedikit waktu, opsi ini menentukan berapa lama produsen perlu menunggu sebelum memperbarui metadata. | | topic.metadata.refresh.interval.ms | 600*1000 | Produser umumnya memperbarui metadata topik dalam beberapa skenario kegagalan (partisi hilang, pemimpin tidak tersedia, dll.). Dia akan melalui siklus reguler. Jika Anda mengaturnya ke nilai negatif, metadata hanya akan diperbarui jika gagal. Jika diatur ke 0, metadata diperbarui setelah setiap pesan dikirim (opsi ini tidak disarankan, sistem mengkonsumsi terlalu banyak). Penting: Pembaruan hanya terjadi setelah pesan dikirim, jadi jika produsen tidak pernah mengirim pesan, metadata tidak akan pernah diperbarui. | | queue.buffering.max.ms | 5000 | Interval waktu maksimum di mana pengguna menyimpan data dalam cache saat mode asinkron diterapkan. Misalnya, jika pesan diatur ke 100, pesan dalam 100 milidetik akan diproses secara berkelompok. Ini akan meningkatkan throughput, tetapi meningkatkan latensi karena caching. | | queue.buffering.max.pesan | 10000 | Saat menggunakan mode asinkron, jumlah maksimum pesan yang belum terkirim yang dapat di-cache ke antrean sebelum produsen harus diblokir atau data harus hilang | | batch.num.messages | 200 | Saat menggunakan mode asinkron, Anda dapat memproses jumlah maksimum pesan secara batch. Atau jumlah pesan telah sampai ke ini secara online atau queue.buffer.max.ms telah tiba, dan produser akan memprosesnya | | kirim.buffer.bytes | 100*1024 | Ukuran cache tulis soket | | client.id | “” | ID klien ini adalah string khusus pengguna yang disertakan dalam setiap permintaan untuk melacak panggilan, dan dia harus secara logis dapat mengonfirmasi bahwa aplikasi membuat permintaan. |
Konfigurasi Produser
| Nama | Tipe | Default | Pentingnya | Deskripsi | | boostrap.server | Daftar | | tinggi | Grup host/port untuk membuat koneksi ke kluster kafka. Data akan dimuat secara merata di semua server, terlepas dari server mana yang ditujukan untuk bootstrapping. Daftar ini hanya memengaruhi host yang diinisialisasi (yang digunakan untuk menemukan semua server). Format daftar ini:
host1:port1,host2:port2,...
Karena server ini hanya digunakan untuk menginisialisasi koneksi untuk menemukan semua keanggotaan kluster (yang dapat berubah secara dinamis), daftar ini tidak perlu berisi semua server (Anda mungkin menginginkan lebih dari satu server, meskipun dalam hal ini, satu server mungkin tidak aktif). Jika tidak ada server yang muncul dalam daftar ini, pengiriman data akan gagal hingga daftar tersedia. | | acks | String | 1 | tinggi | Produser membutuhkan sinyal dari server untuk mengakui penerimaan setelah menerima data, dan konfigurasi ini mengacu pada berapa banyak sinyal pengakuan yang dibutuhkan procuder. Konfigurasi ini sebenarnya mewakili ketersediaan cadangan data. Pengaturan berikut adalah opsi umum:
(1) acks=0: Atur ke 0 berarti produsen tidak perlu menunggu konfirmasi informasi yang diterima. Replika akan segera ditambahkan ke buffer soket dan dianggap terkirim. Tidak ada jaminan bahwa server telah berhasil menerima data dalam hal ini, dan percobaan ulang konfigurasi tidak akan berfungsi (karena klien tidak tahu apakah gagal) dan offset umpan balik akan selalu diatur ke -1.
(2) acks=1: Ini berarti setidaknya menunggu pemimpin berhasil menulis data ke log lokal, tetapi tidak semua pengikut berhasil menulis. Dalam hal ini, jika pengikut tidak berhasil mencadangkan data dan pemimpin menutup telepon lagi, pesan akan hilang.
(3) acks=all: Ini berarti bahwa pemimpin perlu menunggu semua cadangan berhasil menulis log, dan strategi ini akan memastikan bahwa data tidak akan hilang selama satu cadangan bertahan. Ini adalah jaminan terkuat.
(4) Pengaturan lain, seperti acks=2, juga dimungkinkan, yang memerlukan jumlah ack tertentu, tetapi strategi ini umumnya jarang digunakan. | | buffer.memori | panjang | 33554432 | tinggi | Produser dapat digunakan untuk menyimpan ukuran memori data. Jika data dihasilkan lebih cepat daripada dikirim ke broker, produsen akan memblokir atau melemparkan pengecualian, yang ditunjukkan oleh "block.on.buffer.full".
Pengaturan ini akan terkait dengan total memori yang dapat digunakan produsen, tetapi bukan batas keras, karena tidak semua memori yang digunakan oleh produsen digunakan untuk penembolokan. Beberapa memori tambahan digunakan untuk kompresi (jika kompresi diperkenalkan), dan beberapa digunakan untuk permintaan pemeliharaan. | | kompresi.jenis | String | tidak | tinggi | Produser adalah jenis kompresi yang digunakan untuk mengompres data. Defaultnya tidak dikompresi. Nilai opsi yang benar adalah none, gzip, snappy.
Kompresi paling baik digunakan untuk pemrosesan batch, semakin banyak pesan yang diproses dalam batch, semakin baik kinerja kompresi. | | percobaan ulang | int | 0 | tinggi | Menetapkan nilai yang lebih besar dari 0 akan menyebabkan klien mengirim ulang data apa pun setelah data gagal. Perhatikan bahwa percobaan ulang ini tidak berbeda dengan percobaan ulang saat klien menerima kesalahan pengiriman. Mengizinkan percobaan ulang untuk berpotensi mengubah urutan data, jika kedua catatan pesan dikirim ke partisi yang sama, pesan pertama gagal, pesan kedua muncul lebih awal dari pesan pertama. | | batch.ukuran | int | 16384 | Sedang | Produser akan mencoba mengelompokkan catatan pesan untuk mengurangi jumlah permintaan. Ini akan meningkatkan kinerja antara klien dan server. Konfigurasi ini mengontrol jumlah byte default pesan pemrosesan batch.
Tidak ada upaya yang dilakukan untuk memproses byte pesan yang lebih besar dari jumlah byte ini.
Permintaan yang dikirim ke broker akan berisi beberapa batch, yang akan berisi satu permintaan untuk setiap partisi.
Nilai batching yang lebih kecil kurang digunakan dan dapat mengurangi throughput (0 hanya akan menggunakan pemrosesan batch). Nilai batch yang lebih besar membuang lebih banyak ruang memori, jadi Anda perlu mengalokasikan memori untuk nilai batch tertentu. | | client.id | String | | Sedang | String ini dikirim ke server saat permintaan dibuat. Tujuannya adalah untuk dapat melacak sumber permintaan untuk memungkinkan beberapa aplikasi di luar daftar izin IP/Port untuk mengirim informasi. Aplikasi ini dapat mengatur string apa pun karena tidak memiliki tujuan fungsional selain merekam dan melacak | | linger.ms | panjang | 0 | Sedang | Grup produser akan menggabungkan pesan apa pun yang tiba antara permintaan dan pengiriman, mencatat kumpulan permintaan terpisah. Biasanya, ini hanya terjadi ketika catatan dihasilkan lebih cepat dari kecepatan pengiriman. Namun, dalam kondisi tertentu, klien akan ingin mengurangi jumlah permintaan, atau bahkan menjadi beban sedang. Pengaturan ini akan dilakukan dengan menambahkan penundaan kecil - yaitu, alih-alih mengirim rekaman segera, produser akan menunggu waktu tunda tertentu untuk memungkinkan catatan pesan lain dikirim, yang dapat dikumpulkan. Ini dapat dianggap sebagai algoritma yang mirip dengan TCP Nagle. Pengaturan ini menetapkan batas latensi yang lebih tinggi untuk batching: setelah kita mendapatkan batch.size partisi, itu akan segera mengirimkannya terlepas dari pengaturan ini, tetapi jika kita mendapatkan pesan dengan jumlah byte yang jauh lebih kecil daripada pengaturan ini, kita perlu "berlama-lama" waktu tertentu untuk mendapatkan lebih banyak pesan. Pengaturan ini default ke 0, yaitu tidak ada penundaan. Mengatur linger.ms=5, misalnya, akan mengurangi jumlah permintaan, tetapi pada saat yang sama meningkatkan penundaan sebesar 5 milidetik. | | maks.permintaan.ukuran | int | 1028576 | Sedang | Jumlah maksimum byte yang diminta. Ini juga merupakan cakupan yang efektif untuk ukuran maksimum yang tercatat. Catatan: Server memiliki penggantian ukuran rekaman pesannya sendiri, yang berbeda dari pengaturan ini. Pengaturan ini membatasi jumlah permintaan yang dapat dikirim oleh produsen secara massal pada satu waktu untuk mencegah permintaan dalam jumlah besar. | | menerima.buffer.bytes | int | 32768 | Sedang | TCP receivecache size, yang digunakan saat membaca data | | kirim.buffer.bytes | int | 131072 | Sedang | Ukuran cache pengiriman TCP, yang digunakan saat mengirim data | | timeout.ms | int | 30000 | Sedang | Opsi konfigurasi ini mengontrol jumlah waktu maksimum server menunggu konfirmasi dari pengikut. Jika jumlah permintaan yang dikonfirmasi tidak terpenuhi dalam waktu ini, kesalahan akan ditampilkan. Batas waktu habis ini diukur di sisi server dan tidak memiliki latensi jaringan termasuk permintaan | | block.on.buffer.full | Boolean | true | rendah | Ketika cache memori kita habis, kita harus berhenti menerima catatan pesan baru atau membuang kesalahan. Secara default, ini diatur ke true, namun beberapa pemblokiran mungkin tidak layak diharapkan, jadi lebih baik segera membuang kesalahan. Ini adalah kasus ketika diatur ke false: produser melemparkan kesalahan pengecualian: BufferExhaustedException jika rekaman telah dikirim dan cache penuh | | metadata.fetch.timeout.ms | panjang | 60000 | rendah | Ini mengacu pada data pertama kali dari beberapa elemen yang telah kami peroleh. Elemen meliputi: topik, host, partisi. Konfigurasi ini mengacu pada waktu yang diperlukan agar elemen berhasil diselesaikan sesuai dengan pengambilan, jika tidak, pengecualian akan dikirim ke klien. | | metadata.max.age.ms | panjang | 300000 | rendah | Waktu dalam mikrodetik adalah interval di mana kita memaksa metadata untuk diperbarui. Bahkan jika kita tidak melihat perubahan kepemimpinan partisi. | | metrik.reporters | Daftar | [] | rendah | Daftar kelas yang digunakan untuk mengukur metrik. Menerapkan antarmuka MetricReporter akan memungkinkan penambahan kelas yang berubah saat metrik baru dihasilkan. JmxReporter akan selalu menyertakan cara untuk mendaftarkan statistik JMX | | metrik.num.sampel | int | 2 | rendah | Jumlah sampel yang digunakan untuk mempertahankan metrik | | metrics.sample.window.ms | panjang | 30000 | rendah | Sistem Metrik mempertahankan jumlah sampel yang dapat dikonfigurasi dalam ukuran jendela yang dapat diperbaiki. Konfigurasi ini mengonfigurasi ukuran jendela, misalnya. Kami dapat mempertahankan dua sampel selama 30 detik. Saat jendela diluncurkan, kita menghapus dan menulis ulang jendela terlama | | recoonect.backoff.ms | panjang | 10 | rendah | Saat koneksi gagal, waktu tunggu saat kita terhubung kembali. Ini menghindari koneksi ulang klien berulang | | retry.backoff.ms | panjang | 100 | rendah | Waktu tunggu sebelum mencoba mencoba kembali permintaan produksi yang gagal. Hindari terjebak dalam lingkaran mati kirim-gagal.
|
|
Diposting pada 24/06/2021 11.47.12
|
|
|
Tuan tanah