All Products
Search
Document Center

ApsaraMQ for RocketMQ:Model topik Lite

Last Updated:Jun 21, 2026

Dokumen ini menjelaskan definisi, hubungan model, atribut internal, batasan perilaku, kompatibilitas versi, dan rekomendasi penggunaan LiteTopic di ApsaraMQ for RocketMQ.

Prasyarat

  • Topik lite saat ini hanya didukung oleh instans non-Serverless (subscription dan pay-as-you-go) serta instans Serverless dedicated.

  • Untuk membeli instans yang mendukung model topik lite:

    • Saat membeli instans baru, tambahkan tag kemampuan produk di halaman pembelian dengan kunci tag version_capability dan nilai tag lite-topic.

    • Untuk instans yang sudah ada, submit a ticket untuk melakukan upgrade ke versi yang mendukung model topik lite. Sertakan ID instans dan wilayah saat mengirimkan tiket.

  • Anda dapat submit a ticket untuk konsultasi gratis mengenai solusi LiteTopic sesuai skenario spesifik Anda.

Definisi

Lite topic adalah container sekunder untuk transmisi dan penyimpanan pesan di ApsaraMQ for RocketMQ, yang digunakan untuk mengidentifikasi pesan yang termasuk dalam subkelas berbeda (misalnya session, task, atau granularitas lainnya) dalam logika bisnis yang sama.

Tujuan utama lite topic adalah:

  • Mengaktifkan konsumsi eksklusif dan menetapkan isolasi data tingkat kedua.

Kami merekomendasikan memisahkan data dari subkategori berbeda ke dalam lite topic terpisah guna mencapai isolasi penyimpanan dan langganan yang lebih granular.

  • Menetapkan identitas dan izin data.

Berdasarkan identitas dan pengelolaan izin berbasis topik, lite topic memungkinkan penyempurnaan lebih lanjut terhadap identitas dan izin pengguna.

Hubungan model

Dalam model domain ApsaraMQ for RocketMQ, alur dan posisi lite topic adalah sebagai berikut:

image.png

  • Topik merupakan container tingkat atas untuk transmisi dan penyimpanan pesan di ApsaraMQ for RocketMQ. Saat tipe topik adalah Lite, Anda dapat membuat lite topic di bawahnya, dan kombinasi topik serta lite topic secara unik mengidentifikasi container penyimpanan pesan.

  • Saat tipe topik adalah Lite, setiap container penyimpanan secara default memiliki satu queue.

Atribut internal

Nama topik Lite

  • Definisi: Nama yang mengidentifikasi lite topic. Nama lite topic bersifat unik secara global dalam cakupan topik induknya.

  • Nilai: Saat tipe topik adalah Lite dan Anda memanggil setLiteTopic pada sebuah pesan, sistem akan secara otomatis membuat lite topic tersebut jika belum ada.

  • Batasan: Lihat Batasan parameter.

Time-to-live (TTL)

  • Definisi: Waktu kedaluwarsa untuk lite topic. Jika tidak ada pesan baru yang ditulis ke lite topic selama periode yang melebihi TTL-nya, sistem akan menghapusnya secara otomatis. Penghapusan berarti melepaskan kuota yang dialokasikan untuk lite topic tersebut (jumlah total dikurangi satu).

  • Nilai: Saat membuat topik bertipe Lite, Anda dapat mengatur parameter kedaluwarsa.

  • Batasan: Lihat Batasan parameter.

Kompatibilitas versi

  • Versi sisi server: 5.0-rmq-20251024-1 atau lebih baru

  • Versi sisi client: RocketMQ gRPC 5.1.0 atau lebih baru

Perbedaan antara topik tipe lite dan tipe standar

Skenario

Item perbandingan

Topik Ringan

Topik tipe standar

Penyimpanan pesan

Topik tingkat atas

Sama. Keduanya memerlukan pembuatan resource topik terlebih dahulu.

Topik tingkat kedua

Anda dapat membuat jutaan resource LiteTopic tingkat kedua di bawah satu topik, masing-masing dengan kemampuan baru.

Tidak ada resource topik tingkat kedua.

Pengelolaan siklus hidup otomatis

Pengelolaan siklus hidup LiteTopic bersifat otomatis:

  • Pembuatan otomatis: Jika LiteTopic belum ada saat mengirim atau berlangganan, sistem akan membuatnya secara otomatis.

  • Penghapusan otomatis: Tetapkan waktu kedaluwarsa. LiteTopic akan dihapus secara otomatis setelah tidak ada pesan baru yang dikirim selama durasi yang ditentukan.

Tidak ada

Pemesanan

Setiap LiteTopic memiliki tepat satu queue. Pesan dalam queue yang sama disimpan secara berurutan.

  • Per LiteTopic

Beberapa queue dibuat. Hanya topik terurut berpartisi yang menjamin pengurutan.

TPS maksimum konkuren untuk kirim/terima

Karena setiap LiteTopic hanya memiliki satu queue, TPS-nya terbatas.

Namun, Anda dapat membuat jutaan LiteTopic di bawah satu topik, sehingga total TPS meningkat seiring jumlah LiteTopic.

TPS topik meningkat secara horizontal berdasarkan jumlah queue dan jumlah node kluster.

Konsumsi pesan

Konsistensi langganan

Tidak perlu sama.

Dalam kelompok yang sama, setiap konsumen dapat berlangganan ke himpunan LiteTopic yang berbeda. Batasan tingkat kelompok lebih longgar.

Wajib.

Semua konsumen dalam kelompok yang sama harus memiliki langganan identik untuk berbagi pesan dari topik target.

Pemesanan

Konsumsi terurut: Pesan dalam satu LiteTopic diproses hanya oleh satu thread konsumen.

Mendukung konsumsi konkuren atau terurut.

Langganan dinamis

Setiap konsumen dapat secara dinamis menambah atau menghapus langganan ke LiteTopic tertentu.

Tidak ada

Jumlah maksimum LiteTopic yang dapat dilanggan oleh satu konsumen

Setiap konsumen dapat berlangganan ribuan LiteTopic.

Tidak ada

Observabilitas

Metrik

Termasuk metrik akumulasi pesan.

Tidak tersedia metrik untuk waktu keterlambatan pemrosesan pesan.

Termasuk metrik akumulasi pesan.

Metrik Waktu Pemrosesan Pesan

Jejak pesan

Sama

Kasus penggunaan umum lite topic

Kasus penggunaan 1: Komunikasi asinkron untuk sistem Multi-Agent guna mengatasi pemblokiran panggilan berdurasi panjang

Saat skenario AI semakin kompleks, sistem single-agent menghadapi keterbatasan: kurang spesialisasi, kesulitan mengintegrasikan berbagai domain, dan ketidakmampuan mendukung pengambilan keputusan kolaboratif dinamis. Aplikasi dan alur kerja single-agent beralih ke arsitektur Multi-Agent. Namun, karena tugas AI sering kali memakan waktu lama, panggilan sinkron memblokir thread pemanggil, sehingga membatasi skalabilitas untuk kolaborasi skala besar.

image.png

Seperti yang ditunjukkan di atas, alur kerja Multi-Agent bekerja sebagai berikut: Supervisor Agent membagi permintaan menjadi dua subtugas untuk dua child agent. Setiap child agent menyelesaikan bagiannya dan mengembalikan hasil ke Supervisor Agent, yang kemudian menggabungkannya dan mengirim respons akhir ke klien web. Dengan menggunakan RocketMQ untuk komunikasi asinkron:

  1. Alur penanganan permintaan:

    1. Buat topik (Request) untuk setiap child agent sebagai antrian buffer tugas. Gunakan topik prioritas untuk memproses tugas prioritas tinggi terlebih dahulu.

    2. Supervisor Agent mengirim detail subtugas ke topik request yang sesuai.

  2. Alur penanganan respons:

    1. Supervisor Agent membuat topik bertipe Lite (Response) dan berlangganan kepadanya.

    2. Setiap child agent mengirim hasil tugasnya ke LiteTopic di bawah topik Response. Beri nama setiap LiteTopic menggunakan ID tugas agar setiap tugas memiliki LiteTopic khusus sendiri.

    3. Supervisor Agent menerima hasil secara real time melalui langganan dan mendorongnya ke klien web menggunakan HTTP SSE.

Kasus penggunaan 2: Pengelolaan status sesi terdistribusi untuk mengatasi masalah kontinuitas sesi dalam aplikasi AI

Interaksi aplikasi AI bersifat unik: berdurasi panjang, multi-turn, dan sangat bergantung pada sumber daya komputasi mahal per sesi. Saat aplikasi mengandalkan koneksi persisten seperti SSE, gangguan apa pun (akibat restart gerbang, timeout, atau ketidakstabilan jaringan) menyebabkan hilangnya konteks sesi saat ini dan membuang sumber daya komputasi AI yang telah diinvestasikan.

image.png

Seperti pada alur respons kasus penggunaan 1, gunakan topik bertipe Lite untuk notifikasi hasil real time. Beri nama setiap LiteTopic menggunakan SessionID (misalnya, chatbot/{sessionID}). Semua hasil sesi dikirim sebagai pesan terurut dalam topik ini. Untuk menjaga kontinuitas sesi setelah koneksi ulang:

  1. Klien web membentuk koneksi persisten dengan node server aplikasi 1 dan memulai sesi Session2.

  2. Node server aplikasi 1 berlangganan ke LiteTopic [chat/SessionID2].

  3. Penjadwal tugas Large Language Model (LLM) mengirim hasil ke LiteTopic [chat/SessionID2] berdasarkan SessionID dalam permintaan.

  4. Karena masalah jaringan, WebSocket terhubung ulang ke node server aplikasi 2.

  5. Node server aplikasi 1 berhenti berlangganan dari LiteTopic [chat/SessionID2]. Node server aplikasi 2 berlangganan kepadanya.

  6. LiteTopic [chat/SessionID2] melanjutkan pengiriman dari offset terakhir yang dikonsumsi, memastikan kontinuitas status dan data sesi.

Kode contoh

Untuk contoh lengkap, lihat kode contoh di RocketMQ 5.x gRPC SDK.

Kirim pesan

Producer producer = provider.newProducerBuilder()
    .setTopics(topic)
    .setClientConfiguration(clientConfiguration)
    .build();
final Message message = provider.newMessageBuilder()
    .setTopic(topic)
    // Setel kunci pesan untuk pencarian tepat berdasarkan kata kunci.
    .setKeys("messageKey")
    // Setel LiteTopic
    .setLiteTopic("lite-topic-1")
    // Isi pesan
    .setBody("messageBody".getBytes())
    .build();
try {
    final SendReceipt sendReceipt = producer.send(message);
    log.info("Pesan berhasil dikirim, messageId={}", sendReceipt.getMessageId());
} catch (LiteTopicQuotaExceededException e) {
    // Kuota LiteTopic terlampaui. Evaluasi dan tingkatkan kuota.
    log.error("Kuota lite topic terlampaui", e);
} catch (Throwable t) {
    log.error("Gagal mengirim pesan", t);
}

Konsumsi pesan

Gunakan kelas LitePushConsumer:

// Inisialisasi LitePushConsumer dengan kelompok konsumen, topik target, dan parameter komunikasi.
LitePushConsumer litePushConsumer = provider.newLitePushConsumerBuilder()
    .setClientConfiguration(clientConfiguration)
    // Topik yang diikat ke ConsumerGroup saat dibuat di Konsol
    .bindTopic(topicName)
    // Setel kelompok konsumen
    .setConsumerGroup(consumerGroup)
    .setMessageListener(messageView -> {
        // Proses pesan dan kembalikan hasil konsumsi.
        LOGGER.info("Konsumsi pesan={}", messageView);
        return ConsumeResult.SUCCESS;
    })
    .build();
try {
    // Berlangganan ke LiteTopic yang diinginkan
    litePushConsumer.subscribeLite("lite-topic-1");
    litePushConsumer.subscribeLite("lite-topic-2");
    litePushConsumer.subscribeLite("lite-topic-3");
} catch (LiteSubscriptionQuotaExceededException e) {
    // Kuota langganan LiteTopic terlampaui. Evaluasi dan tingkatkan kuota.
    log.error("Kuota langganan lite terlampaui", e);
} catch (Throwable t) {
    log.error("Gagal berlangganan lite topic", t);
}
// Setelah pemrosesan bisnis selesai, segera berhenti berlangganan dari LiteTopic yang tidak digunakan
litePushConsumer.unsubscribeLite("lite-topic-3");
// Dapatkan himpunan LiteTopic yang sedang dilanggan
Set<String> liteTopicSet = litePushConsumer.getLiteTopicSet();

Perbarui langganan secara dinamis

/**
 * Tambahkan langganan secara dinamis.
 * Metode subscribeLite() melakukan panggilan jaringan dan memvalidasi kuota,
 * sehingga bisa gagal.
 * Selalu periksa hasilnya untuk memastikan langganan berhasil.
 * Kemungkinan skenario kegagalan:
 * 1. Kesalahan jaringan – ulangi panggilan.
 * 2. Validasi kuota gagal – melempar LiteSubscriptionQuotaExceededException.
 * Evaluasi apakah kuota Anda memenuhi persyaratan, dan segera panggil
 * unsubscribeLite() untuk melepaskan sumber daya dari topik yang tidak digunakan.
 */
litePushConsumer.subscribeLite("lite-topic-1");
// Hapus langganan secara dinamis
litePushConsumer.unsubscribeLite("lite-topic-1");

Batasan

  1. Satu konsumen dapat berlangganan hingga 2.000 LiteTopic (dapat disesuaikan melalui tiket).

  2. Setiap LiteTopic mendukung TPS konsumsi maksimum 200.

  3. Untuk memastikan stabilitas layanan, setiap instans memberlakukan batasan jumlah total LiteTopic yang dapat dibuat atau dilanggan. Lihat tabel berikut untuk kuota spesifik (dapat disesuaikan melalui tiket).

    1. Jumlah LiteTopics

      • Definisi: Jumlah total LiteTopic yang saat ini dibuat dan aktif di bawah satu instans selama siklus hidupnya.

      • Pemicu dan dampak: Saat batas ini tercapai, upaya mengirim pesan ke LiteTopic yang belum ada (yang akan memicu pembuatan otomatis) gagal dengan error pengiriman.

    2. Jumlah Langganan LiteTopic

      • Definisi: Jumlah total hubungan langganan aktif antara semua klien konsumen online dan LiteTopic di bawah suatu instans. Angka ini berubah secara dinamis.

      • Dampak: Saat batas ini tercapai, upaya konsumen untuk berlangganan LiteTopic baru akan gagal.

      • Aturan khusus: Bahkan jika LiteTopic dihapus, langganan konsumen yang tersisa padanya tetap dihitung dalam total hingga konsumen tersebut berhenti berlangganan.

Instans Serverless

Arsitektur penyebaran

Mode kapasitas

Spesifikasi

Jumlah maksimum LiteTopic yang dapat dibuat atau dilanggan

Dedicated

Reserved + elastic

5000

300.000

10000

600.000

15000

720.000

[20.000, 50.000]

1.000.000

(50.000, 100.000]

1.500.000

(100.000, 200.000]

2.400.000

(200.000, 300.000]

4.700.000

(300.000, 500.000]

6.300.000

(500.000, 1.000.000]

11.600.000

Instans non-Serverless (subscription dan pay-as-you-go)

Edisi Standar

Tipe instans

Batas TPS dasar untuk kirim/terima (ops/detik)

Jumlah maksimum LiteTopic yang dapat dibuat atau dilanggan

rmq.s2.2xlarge

2000

150.000

rmq.s2.4xlarge

4000

250.000

rmq.s2.6xlarge

6000

300.000

Edisi Profesional

Tipe instans

Batas TPS dasar untuk kirim/terima (ops/detik)

Jumlah maksimum LiteTopic yang dapat dibuat atau dilanggan

rmq.p2.2xlarge

2000

150.000

rmq.p2.4xlarge

4000

250.000

rmq.p2.6xlarge

6000

300.000

rmq.p2.10xlarge

10000

600.000

rmq.p2.20xlarge

20000

800.000

rmq.p2.30xlarge

30000

1.000.000

rmq.p2.40xlarge

40000

1,2 juta

rmq.p2.50xlarge

50000

1,4 juta

rmq.p2.100xlarge

100000

2.200.000

rmq.p2.120xlarge

120000

2,7 juta

rmq.p2.150xlarge

150000

3,3 juta

rmq.p2.200xlarge

200000

4,5 juta

Edisi Platinum

Tipe instans

Batas TPS dasar untuk kirim/terima (ops/detik)

Jumlah maksimum LiteTopic yang dapat dibuat atau dilanggan

rmq.u2.10xlarge

10000

600.000

rmq.u2.20xlarge

20000

800.000

rmq.u2.30xlarge

30000

1.000.000

rmq.u2.40xlarge

40000

1.200.000

rmq.u2.50xlarge

50000

1.400.000

rmq.u2.60xlarge

60000

1.600.000

rmq.u2.70xlarge

70000

1.700.000

rmq.u2.80xlarge

80000

1.800.000

rmq.u2.90xlarge

90000

2.000.000

rmq.u2.100xlarge

100000

2.200.000

rmq.u2.120xlarge

120000

2.700.000

rmq.u2.150xlarge

150000

3.300.000

rmq.u2.200xlarge

200000

4.500.000

rmq.u2.250xlarge

250000

5.600.000

rmq.u2.300xlarge

300000

6.300.000

rmq.u2.350xlarge

350000

7.500.000

rmq.u2.400xlarge

400000

9.300.000

rmq.u2.450xlarge

450000

10.400.000

rmq.u2.500xlarge

500000

11.600.000

rmq.u2.550xlarge

550000

12.800.000

rmq.u2.600xlarge

600000

14.000.000

rmq.u2.1000xlarge

1000000

23.200.000