ApsaraMQ for Kafka：Batasan

Batas

Batas

Deskripsi

Membatasi jumlah total topik dan partisi

Didukung

Mekanisme penyimpanan dan koordinasi ApsaraMQ for Kafka didasarkan pada granularitas partisi, dan jumlah topik (dan karenanya partisi) yang berlebihan menyebabkan fragmentasi penyimpanan serta penurunan kinerja dan stabilitas kluster.

Jumlah minimum partisi per topik

• Langganan dan bayar sesuai penggunaan:

  • Untuk topik yang menggunakan penyimpanan cloud, nilai minimum adalah 2.

  • Untuk topik yang menggunakan penyimpanan lokal, nilai minimum adalah 1.

• Edisi Serverless:

  • Untuk topik yang menggunakan penyimpanan cloud-native, nilai minimum adalah 1.

Jika lalu lintas tinggi, satu partisi saja dapat menyebabkan kesenjangan data dan masalah hot spot. Atur jumlah partisi secara tepat.

Mengurangi jumlah partisi untuk suatu topik

Tidak didukung

Ini merupakan keterbatasan desain Apache Kafka.

Mengekspos ZooKeeper

Tidak didukung

Anda tidak perlu mengakses ZooKeeper untuk menggunakan klien di Apache Kafka V0.9.0 dan versi selanjutnya. ZooKeeper dalam ApsaraMQ for Kafka sebagian dibagikan dan tidak diekspos karena alasan keamanan. Anda tidak perlu memahami cara kerja ZooKeeper.

Masuk ke mesin tempat ApsaraMQ for Kafka diterapkan

Tidak didukung

Tidak ada.

Versi

Mendukung versi 2.2.x hingga 3.3.x

• Instans non-Serverless mendukung versi 2.2.x hingga 2.6.x.

• Instans Serverless mendukung versi 3.3.x.

Untuk meningkatkan versi instans, lihat Peningkatan versi instans.

Rasio partisi terhadap topik

1:1

Jumlah topik yang tersedia berkaitan langsung dengan jumlah total partisi. Misalnya, Anda membeli instans dengan 50 partisi, spesifikasi throughput alikafka.hw.2xlarge, dan 1.000 partisi bonus yang termasuk dalam spesifikasi tersebut. Jumlah total partisi untuk instans ini adalah 50 (dibeli) + 1.000 (bonus) = 1.050. Jumlah topik yang tersedia adalah 1.050.

Mengubah wilayah instans

Tidak didukung

Setelah instans dibeli dan diterapkan, wilayahnya terikat pada sumber daya fisik dan tidak dapat diubah. Untuk mengubah wilayah instans, lepas instans tersebut dan beli instans baru.

Mengubah properti jaringan instans

Didukung

Anda dapat mengubah properti jaringan sesuai kebutuhan. Untuk informasi lebih lanjut, lihat Peningkatan konfigurasi instans.

Ukuran pesan

10 MB

Ukuran pesan tidak boleh melebihi 10 MB. Jika dilanggar, pesan gagal dikirim.

Pemantauan dan peringatan

Didukung

Latensi data adalah 1 menit.

Titik akhir

Spesifikasi

• Instans non-Serverless:

  • Edisi Standar: Mendukung titik akhir default dan SSL.

  • Edisi Profesional: Mendukung titik akhir default, SSL, dan SASL.

• Instans Serverless: Mendukung titik akhir default, SSL, dan SASL.

Partisi tunggal dengan penyimpanan cloud

Dapat menjadi tidak tersedia selama downtime atau peningkatan

Buat lebih dari satu partisi. Jika Anda harus menggunakan partisi tunggal, gunakan penyimpanan lokal.

Jumlah maksimum pesan per batch

32767

Jika satu pesan berukuran kecil, atur batch.size ke nilai yang tidak melebihi 16384.

Batas

Kondisi

Deskripsi

Instans Langganan/Bayar sesuai penggunaan

Serverless (Edisi Dasar)

Serverless (Edisi Standar/Profesional)

Koneksi (node tunggal)

• Dimulai dari 1.000 koneksi.

• Untuk setiap peningkatan 100 MB/dtk dalam lalu lintas pengiriman pesan aktual, jumlah koneksi bertambah 1.000.

• Batas atas adalah 10.000.

Rumus:

C = min(10000, 1000 + (F // 100) × 1000)

• Dimulai dari 1.000 koneksi.

• Untuk setiap peningkatan 300 MB/dtk dalam kapasitas pengiriman yang dicadangkan, jumlah koneksi bertambah 1.000.

• Batas atas adalah 10.000.

Rumus:

C = min(10000, 1000 + (F // 300) × 1000)

Jumlah koneksi TCP ke satu broker.

Jika Anda memerlukan batas koneksi yang lebih tinggi, ajukan tiket.

Koneksi Internet (SSL) (node tunggal)

• Dimulai dari 200 koneksi.

• Untuk setiap peningkatan 100 MB/dtk dalam lalu lintas pengiriman pesan aktual, jumlah koneksi bertambah 100.

• Batas atas adalah 1.000.

Rumus:

C = min(1000, 200 + (F // 100) × 100)

• Dimulai dari 200 koneksi.

• Untuk setiap peningkatan 300 MB/dtk dalam kapasitas pengiriman yang dicadangkan, jumlah koneksi bertambah 100.

• Batas atas adalah 1.000.

Rumus:

C = min(1000, 200 + (F // 300) × 100)

Jumlah koneksi TCP Internet (SSL) ke satu broker.

Frekuensi koneksi (node tunggal)

50 per detik

150 per detik

150 per detik

Jumlah upaya koneksi dari klien ke server per detik. Ini termasuk koneksi yang gagal karena alasan seperti kegagalan autentikasi.

Frekuensi koneksi Internet (SSL) (node tunggal)

10 per detik

Jumlah upaya koneksi Internet (SSL) dari klien ke server per detik. Ini termasuk koneksi yang gagal karena alasan seperti kegagalan autentikasi.

Ukuran batch

Ukuran batch dengan persentil ke-50 (TP50) kurang dari 4 KB dianggap sebagai pengiriman terfragmentasi.

Ukuran batch pesan dalam permintaan PRODUCE setelah pesan dipaketkan oleh klien pengirim. Untuk meningkatkan kemampuan batching, gunakan klien versi 2.4 atau lebih baru. Untuk informasi lebih lanjut, lihat Tingkatkan kinerja pengiriman (kurangi permintaan pengiriman terfragmentasi).

Frekuensi permintaan pengiriman (kluster)

• Dimulai dari 10.000 permintaan per detik.

• Untuk setiap peningkatan 20 MB/dtk dalam lalu lintas pengiriman pesan aktual, jumlah permintaan bertambah 2.000 per detik.

Rumus:

R = 10000 + (F // 20) × 2000

• Dimulai dari 10.000 permintaan per detik.

• Untuk setiap peningkatan 300 MB/dtk dalam kapasitas pengiriman yang dicadangkan, jumlah permintaan bertambah 5.000 per detik.

Rumus:

R = 10000 + (F // 300) × 5000

• Dimulai dari 10.000 permintaan per detik.

• Untuk setiap peningkatan 60 MB/dtk dalam kapasitas pengiriman yang dicadangkan, jumlah permintaan bertambah 2.000 per detik.

Rumus:

R = 10000 + (F // 60) × 2000

Jumlah permintaan PRODUCE yang dikirim oleh klien per detik.

Jika Anda memerlukan batas permintaan yang lebih tinggi, ajukan tiket.

Frekuensi permintaan konsumsi (kluster)

• Dimulai dari 5.000 permintaan per detik.

• Untuk setiap peningkatan 20 MB/dtk dalam lalu lintas konsumsi pesan aktual, jumlah permintaan bertambah 1.000 per detik.

Rumus:

R = 5000 + (F // 20) × 1000

• Dimulai dari 5.000 permintaan per detik.

• Untuk setiap peningkatan 100 MB/dtk dalam kapasitas langganan yang dicadangkan, jumlah permintaan bertambah 2.500 per detik.

Rumus:

R = 5000 + (F // 100) × 2500

• Dimulai dari 5.000 permintaan per detik.

• Untuk setiap peningkatan 20 MB/dtk dalam kapasitas langganan yang dicadangkan, jumlah permintaan bertambah 1.000 per detik.

Rumus:

R = 5000 + (F // 20) × 1000

Jumlah permintaan FETCH yang dikirim oleh klien per detik.

Jika Anda memerlukan batas permintaan yang lebih tinggi, ajukan tiket.

Frekuensi commit offset konsumen (node tunggal)

• Dimulai dari 100 permintaan per detik.

• Untuk setiap peningkatan 100 MB/dtk dalam lalu lintas pengiriman pesan aktual, jumlah permintaan bertambah 100 per detik.

• Batas atas adalah 1.000 permintaan per detik.

Rumus:

R = min(1000, 100 + (F // 100) * 100)

• Dimulai dari 100 permintaan per detik.

• Untuk setiap peningkatan 100 MB/dtk dalam kapasitas pengiriman yang dicadangkan, jumlah permintaan bertambah 100 per detik.

• Batas atas adalah 1.000 permintaan per detik.

Rumus:

R = min(1000, 100 + (F // 100) × 100)

Jumlah permintaan `OFFSET_COMMIT` yang dikirim oleh klien per detik.

Jika Anda memerlukan batas permintaan yang lebih tinggi, ajukan tiket.

Frekuensi permintaan metadata (kluster)

• Dimulai dari 100 permintaan per detik.

• Untuk setiap peningkatan 100 MB/dtk dalam lalu lintas pengiriman pesan aktual, jumlah permintaan bertambah 100 per detik.

• Batas atas adalah 1.000 permintaan per detik.

Rumus:

R = min(1000, 100 + (F // 100) * 100)

• Dimulai dari 100 permintaan per detik.

• Untuk setiap peningkatan 100 MB/dtk dalam kapasitas pengiriman yang dicadangkan, jumlah permintaan bertambah 100 per detik.

• Batas atas adalah 1.000 permintaan per detik.

Rumus:

R = min(1000, 100 + (F // 100) × 100)

Jumlah permintaan metadata yang diterima server dari klien, seperti METADATA, INIT_PRODUCER_ID, CREATE_ACL, dan JOIN_GROUP.

Jumlah maksimum partisi

Untuk informasi tentang jumlah maksimum partisi untuk setiap spesifikasi instans, lihat Partisi instans.

Jumlah partisi mencakup partisi untuk berbagai jenis topik yang Anda buat.

Jika Anda memerlukan batas partisi yang lebih tinggi, ajukan tiket.

Frekuensi pembuatan/penghapusan partisi (kluster)

900 partisi per 10 detik

Batas ini mencakup semua operasi partisi yang dimulai dari konsol, OpenAPI, atau Kafka Admin.

Jumlah kelompok konsumen (kluster)

2.000 per kluster

Rasio langganan topik-ke-kelompok yang direkomendasikan adalah 1:1 dan tidak boleh melebihi 3:1.

Jumlah kelompok konsumen yang Anda gunakan.

Jika Anda memerlukan batas jumlah kelompok yang lebih tinggi, ajukan tiket.

Versi format pesan

Anda harus menggunakan versi format pesan yang lebih baru dari V1 untuk mengirim dan mengonsumsi pesan.

Gunakan klien versi 2.4 atau lebih baru.

Batas lainnya

• Mengaktifkan algoritma kompresi, seperti GZIP, mengonsumsi lebih banyak sumber daya server. Hal ini memengaruhi latensi layanan dan throughput.

• Menginisialisasi banyak transaksi dengan Producer Id pada frekuensi tinggi dapat menyebabkan overflow memori dan beban berlebih pada server, yang memengaruhi stabilitas. Oleh karena itu, parameter kernel transactional.id.expiration.ms diatur menjadi 15 menit. Jika Anda memiliki kebutuhan khusus, ajukan tiket.

• Pemblokiran timestamp pesan tidak valid: Jika message.timestamp.type diatur ke `CreateTime`, broker akan menolak pesan jika selisih antara timestamp broker dan timestamp pesan melebihi nilai parameter message.timestamp.difference.max.ms. Pengaturan ini mencegah konfigurasi timestamp yang salah. Jika timestamp terlalu awal, segmen log akan langsung dihapus. Jika timestamp terlalu jauh di masa depan, segmen log tidak dapat dihapus.

• Untuk mencegah penulisan abnormal ke topik compacted mengisi penyimpanan kluster dan menyebabkan downtime, batas penyimpanan default untuk partisi topik compacted adalah 5 GB. Jika Anda memiliki kebutuhan khusus, ajukan tiket.

• Jika pemanfaatan CPU instans melebihi 85%, stabilitas kluster instans dapat terpengaruh. Hal ini dapat menyebabkan masalah seperti downtime dan jitter latensi ekor panjang saat Anda mengirim dan mengonsumsi pesan.

• Kinerja Kafka didukung oleh kluster. Jika perilaku pengiriman pesan atau alokasi partisi Anda tidak merata, kluster tidak dapat beroperasi pada kapasitas penuhnya.

• Pesan transaksional open-source memiliki banyak masalah yang diketahui namun belum diperbaiki. Gunakan dengan hati-hati. Sebagai contoh, lihat KAFKA-12671. Untuk informasi lebih lanjut tentang masalah lainnya, lihat MASALAH KAFKA.

• Kafka dapat mengonsumsi ulang pesan dalam banyak skenario, seperti selama penyeimbangan ulang. Untuk mencegah pesan yang dikonsumsi ulang memengaruhi layanan Anda, Anda harus menerapkan pemeriksaan idempotensi dalam logika konsumsi Anda.

Tidak ada