ApsaraMQ for RocketMQ:Akumulasi pesan dan penundaan

Jika laju konsumsi pesan pada klien tidak dapat mengimbangi laju produksi pesan pada broker selama pemrosesan pesan, maka akan terjadi akumulasi pesan yang menyebabkan penundaan dalam konsumsi pesan. Kami menyarankan Anda memperhatikan akumulasi pesan dan penundaan dalam skenario berikut:

• Pesan terus-menerus terakumulasi karena kemampuan konsumsi sistem hilir tidak sesuai dengan kemampuan produksi sistem hulu. Selain itu, konsumsi pesan tidak dapat pulih secara otomatis.

• Sistem bisnis memiliki persyaratan tinggi terhadap konsumsi pesan real-time sehingga bahkan penundaan yang disebabkan oleh akumulasi pesan sementara tidak dapat diterima.

Gambar berikut menunjukkan cara klien ApsaraMQ for RocketMQ mengonsumsi pesan melalui TCP.

Menggunakan klien untuk mengonsumsi pesan dalam mode push mencakup dua fase berikut:

• Fase 1: Tarik pesan. Klien menarik pesan dari broker ApsaraMQ for RocketMQ dalam batch menggunakan polling panjang. Pesan yang ditarik kemudian disimpan dalam antrian buffer lokal.

  Ketika pesan ditarik dalam batch, throughput tinggi dapat dicapai di jaringan internal tipikal. Sebagai contoh, transaksi per detik (TPS) server spesifikasi rendah (4 vCPU dan 8 GB memori) dengan satu thread dan satu partisi bisa mencapai puluhan ribu. Untuk server dengan beberapa partisi, TPS bisa mencapai ratusan ribu. Oleh karena itu, hambatan dalam akumulasi pesan tidak berasal dari fase ini.

• Fase 2: Kirim pesan ke thread konsumsi. Klien mengirimkan pesan yang disimpan secara lokal ke thread konsumsi, lalu thread tersebut menggunakan logika konsumsi pesan untuk memproses pesan.

  Kemampuan konsumsi klien bergantung pada kompleksitas (durasi konsumsi) logika bisnis dan konkurensi konsumsi. Jika logika bisnis kompleks dan banyak waktu diperlukan untuk memproses satu pesan, throughput keseluruhan tidak dapat tinggi. Ketika jumlah pesan yang disimpan dalam antrian buffer lokal mencapai batas atas, klien akan berhenti menarik pesan dari broker.

Mekanisme konsumsi sisi klien yang disebutkan di atas menunjukkan bahwa hambatan dalam akumulasi pesan disebabkan oleh kemampuan konsumsi klien lokal, yaitu durasi konsumsi dan konkurensi konsumsi. Untuk mencegah dan menyelesaikan masalah yang disebabkan oleh akumulasi pesan, Anda harus mengonfigurasi durasi konsumsi dan konkurensi dengan benar. Perhatikan bahwa durasi konsumsi lebih diprioritaskan daripada konkurensi konsumsi.

Faktor-faktor yang memengaruhi durasi konsumsi mencakup CPU, komputasi dalam memori, dan operasi I/O eksternal. Dalam kebanyakan kasus, rekursi dan loop tidak didefinisikan dalam kode. Oleh karena itu, waktu komputasi internal hampir dapat diabaikan dibandingkan dengan operasi I/O eksternal. Operasi I/O eksternal biasanya mencakup logika bisnis berikut:

• Baca dan tulis data pada database eksternal, seperti database MySQL.

• Baca dan tulis data pada sistem cache eksternal, seperti Redis.

• Panggilan sistem hilir, seperti panggilan Dubbo dan panggilan antarmuka HTTP hilir.

Anda harus menyusun logika dan kapasitas sistem dari panggilan eksternal semacam itu untuk memahami waktu yang diharapkan dikonsumsi oleh setiap panggilan. Ini memungkinkan Anda menentukan apakah waktu yang dikonsumsi oleh operasi I/O dalam logika konsumsi masuk akal. Dalam kebanyakan kasus, pesan terakumulasi karena durasi konsumsi meningkat akibat pengecualian layanan atau batas kapasitas di sistem hilir.

Tabel berikut menjelaskan metode untuk menghitung konkurensi konsumsi di ApsaraMQ for RocketMQ.

Konkurensi konsumsi klien ditentukan oleh jumlah thread per node dan jumlah node. Dalam kebanyakan kasus, Anda harus terlebih dahulu menyesuaikan jumlah thread pada satu node. Jika sumber daya perangkat keras pada node telah mencapai batas atas, Anda harus menambahkan node untuk meningkatkan konkurensi konsumsi.

Saat menetapkan konkurensi konsumsi pada satu node, jumlah thread yang terlalu besar dapat menyebabkan overhead besar dalam pergantian thread. Gunakan model berikut untuk menghitung jumlah thread optimal pada satu node dalam lingkungan ideal:

• Jumlah vCPU dari satu node adalah C.

• Waktu yang dikonsumsi untuk pergantian thread diabaikan, dan operasi I/O tidak mengonsumsi sumber daya CPU.

• Thread memiliki cukup pesan yang menunggu untuk diproses, dan memori mencukupi.

• Dalam logika, waktu CPU adalah T1, dan waktu operasi I/O eksternal adalah T2.

Sebuah thread tunggal dapat mencapai TPS sebesar 1/(T1 + T2). Jika pemanfaatan CPU mencapai nilai yang diinginkan 100%, Anda harus menetapkan C × (T1 + T2)/T1 thread untuk membuat satu node mencapai kemampuan konsumsi maksimumnya.