ApsaraMQ for RabbitMQ:FAQ

Querying with AliyunAMQPReadOnlyAccess

Kebijakan AliyunAMQPReadOnlyAccess hanya memberikan izin amqp:Get* dan amqp:List*. Untuk mengakses pesan dalam antrian, Anda harus menambahkan izin kustom amqp:BasicGet. Untuk informasi selengkapnya, lihat Referensi kebijakan kustom ApsaraMQ for RabbitMQ.

{
    "Version": "1",
    "Statement": [
        {
            "Action": [
                "amqp:BasicGet"
            ],
            "Resource": [
                "acs:amqp:*:*:/instances/$instanceId/vhosts/$vhostName/queues/$queueName/messages/*"
            ],
            "Effect": "Allow"
        }
    ]
}

Akumulasi pesan setelah purge antrian

Operasi purge secara default tidak menghapus pesan yang ditunda (delayed messages).

Mekanisme QoS

Jika Anda mengalami timeout atau blocking, atur QoS atau Prefetch Count menjadi 1. Hal ini mencegah client menyimpan terlalu banyak pesan yang berpotensi kedaluwarsa secara bersamaan.

Pengiriman pesan ke dead-letter queue

Pesan tanpa nilai TTL hanya dikirim ke dead-letter queue jika pesan tersebut di-NACK (negatively acknowledged) atau jumlah percobaan ulangnya mencapai batas maksimum.

Menetapkan ID pesan

Untuk informasi selengkapnya, lihat Cara menetapkan ID pesan.

Penurunan jumlah pesan di dead-letter queue

ApsaraMQ for RabbitMQ menyimpan pesan maksimal selama 3 hari. Jika sebuah pesan tidak dikonsumsi dalam waktu 3 hari, pesan tersebut akan dihapus secara otomatis dari dead-letter queue, sehingga jumlah pesan berkurang. Untuk informasi selengkapnya, lihat Batasan.

Periode retensi pesan

ApsaraMQ for RabbitMQ menyimpan semua pesan maksimal selama 3 hari, terlepas dari apakah pesan tersebut telah dikonsumsi atau belum. Untuk informasi selengkapnya, lihat Batasan.

Segmen jaringan RabbitMQ

Segmen jaringan untuk instans ApsaraMQ for RabbitMQ tidak tetap, sehingga informasi tersebut tidak dapat diperoleh sebelumnya.

Masalah penghapusan antrian otomatis

Jika konsumen belum berhasil berlangganan ke antrian, pemanggilan channel.close tidak memicu penghapusan otomatis antrian tersebut. Logika auto-delete hanya berlaku setelah konsumen berhasil berlangganan menggunakan channel.basicConsume.

Biaya penyimpanan

ApsaraMQ for RabbitMQ menyimpan pesan selama 3 hari. Biaya penyimpanan dihitung berdasarkan volume penyimpanan isi pesan. Anda tidak dapat mengosongkan ruang penyimpanan ini secara manual; ruang tersebut hanya dibebaskan ketika pesan kedaluwarsa.

Karena operasi purge tidak menghapus pesan, operasi tersebut tidak mengurangi penggunaan ruang penyimpanan Anda.

Operasi purge pada antrian

Operasi purge pada antrian mereset offset konsumen, sehingga konsumen melewatkan pesan yang belum dikonsumsi. Operasi ini tidak menghapus pesan, sehingga pesan tetap dapat diakses.

Faktor yang menentukan laju egress antrian

Laju pengiriman pesan dari suatu antrian bergantung pada volume pesan, jumlah konsumen, dan pengaturan QoS mereka.

Pertimbangan untuk antrian eksklusif

Saat menggunakan framework Spring dalam mode CONNECTION, Anda harus membuat exchange, antrian, dan binding terlebih dahulu di Konsol. Mode CONNECTION tidak secara otomatis mendeklarasikan atau membuat resource tersebut.

Tagihan untuk percobaan ulang pesan

Anda hanya dikenai biaya sekali untuk pengiriman awal. Upaya re-queuing dan konsumsi berikutnya tidak dikenai biaya tambahan.

Re-queuing terjadi ketika konsumen gagal memproses pesan dan pesan tersebut dikembalikan ke antrian server. Server menggunakan antrian retry khusus untuk mengirim ulang pesan ke konsumen pada interval tertentu.

Metrik untuk batas TPS

Batas TPS sesuai dengan metrik Peak API Request Rate per Instance di Cloud Monitor.

Melebihi batas koneksi

Meskipun batas koneksi didokumentasikan sebagai batas tingkat instans, penerapannya dilakukan di tingkat node backend. Akibatnya, jumlah total koneksi untuk suatu instans mungkin sedikit melebihi batas yang dinyatakan.

Konfigurasi instansi langganan tidak dapat disesuaikan secara dinamis. Kami menyarankan agar Anda merencanakan sumber daya dengan cermat saat membuat instans untuk menghindari melebihi batas sumber daya dan menyebabkan gangguan bisnis.

Akumulasi pesan meski laju seimbang

Meskipun laju produksi dan konsumsi seimbang, keterlambatan dalam mengakui (ACK) beberapa pesan dapat menyebabkan alat pemantauan melaporkan akumulasi pesan sementara pada waktu pengambilan sampel tertentu. Tingkat akumulasi biasanya kembali normal pada siklus pengambilan sampel berikutnya.

Penurunan tiba-tiba laju konsumsi pod

Kami menyarankan untuk memeriksa performa pod tersebut. Utilisasi CPU yang tinggi dapat mencegah client mengirim ACK secara tepat waktu. Jika server tidak menerima ACK, server tidak dapat mendorong pesan baru dan harus menunggu hingga timeout sebelum mencoba lagi. Hal ini menyebabkan penurunan laju konsumsi.

Sebagai contoh, jika QoS diatur ke 1, konsumen hanya dapat memiliki satu pesan yang belum di-ACK pada satu waktu. Server harus menunggu konsumen memproses pesan tersebut dan mengirim ACK sebelum dapat mendorong pesan berikutnya. Jika ACK tidak diterima, server harus menunggu hingga timeout sebelum mencoba lagi.

Menggunakan kunci utama default

Ya.

Error: "The channelMax limit is reached"

Server membatasi jumlah channel per koneksi, bukan jumlah total channel di seluruh koneksi.

Error ini dicatat oleh SDK setiap kali metode createChannel mengembalikan null.

Setelah melakukan peningkatan instans, Anda harus merestart client Anda. Jika tidak, koneksi yang sudah ada akan terus menggunakan batas channel sebelum peningkatan, sehingga error tetap terjadi.

Sebagai contoh, jika instans dibeli dengan Channel Max sebesar 100, client dan server menegosiasikan batas ini saat koneksi dibuat. Jika Anda kemudian meningkatkan instans untuk mendukung 2.000 atau 2.500 channel, koneksi yang dibuat sebelum peningkatan tetap terikat pada batas awal 100 channel dan akan terus memicu error tersebut.

Proses negosiasi parameter channel

Dampak peningkatan TPS

Tidak. Peningkatan batas TPS di Konsol tidak mengganggu atau memutus koneksi yang sudah ada.

Koneksi baru menyebabkan shutdown channel

Secara normal, tidak. Namun, sumber daya client yang tidak mencukupi, seperti lebar pita jaringan, memori, atau kapasitas JVM, dapat menyebabkan gangguan pada koneksi atau channel lainnya. Kami menyarankan untuk memeriksa penggunaan sumber daya client guna mengidentifikasi adanya konflik sumber daya atau kekurangan yang mungkin menyebabkan gangguan tersebut.

Konsumen antrian menghilang

Kami menyarankan untuk pertama-tama memeriksa logika aplikasi dan status sumber daya client pada saat insiden terjadi. Cari masalah seperti proses yang ditangguhkan atau kekurangan sumber daya yang dapat mengganggu aplikasi. Jika client berfungsi dengan baik, periksa apakah server mengirimkan pesan sesuai harapan.

Operasi purge antrian tidak berpengaruh

Operasi purge pada antrian tidak menghapus pesan yang belum diakui (unacked). Ini adalah pesan yang telah dikirim ke client tetapi belum diakui. Jumlah pesan unacked diperbarui secara otomatis setelah pesan tersebut kedaluwarsa.

Menghitung TPS dari log client

Gunakan kueri SQL berikut:

 * and amqp-cn-xxx and Action : SendMessage | select InstanceId as instance_id, VHost as virtual_host, Queue as queue, microtime / 1000 / 1000 as time_second, count(*) as send_qps group by instance_id, virtual_host, queue, time_second order by time_second, send_qps limit 10000000

Contoh hasil:

Log kosong setelah mengganti Logstore

Di Logstore baru, klik Enable Indexing. Tunggu sekitar satu menit, lalu refresh halaman untuk melihat log.

Prosedur:

1) Klik Enable Indexing.

2) Klik OK.

Penyebab pemutusan koneksi RabbitMQ

Jika client mengirim jumlah ACK valid yang rendah, server akan terus-menerus mengirim ulang pesan karena tidak menerima acknowledgment. Hal ini dapat menyebabkan akumulasi pesan yang terus-menerus.

Akumulasi pesan di sisi client ini dapat mencegah koneksi mengirim paket heartbeat. Hal ini akhirnya memicu error Connection ALL_IDLE dan pemutusan koneksi. Anda harus terlebih dahulu menyelidiki mengapa client gagal mengirim ACK yang valid.

Pengaturan TTL

TTL maksimum adalah 3 hari; pengaturan yang lebih besar dari 3 hari tidak berlaku. Jika TTL tidak berlaku, pesan yang kedaluwarsa tidak dipindahkan ke dead-letter queue dan dapat menyebabkan perilaku tak terduga lainnya.

1) Jika TTL tidak diatur, semua pesan dalam antrian adalah pesan normal. Metrik readyMessage dalam pemantauan mencerminkan jumlah aktual pesan yang terakumulasi.

2) Jika TTL diatur, metrik readyMessage merepresentasikan jumlah pesan aktif:

a) Jika TTL berfungsi dengan benar, jumlah pesan aktif dihitung secara dinamis berdasarkan TTL. Metrik readyMessage secara akurat mencerminkan jumlah ini.

b) Jika TTL diatur tetapi tidak berlaku, jumlah pesan aktif selalu 0. Metrik readyMessage juga menunjukkan 0 dan tidak mencerminkan akumulasi pesan aktual.

Error: "java.lang.IllegalArgumentException: Content headers exceeded max frame size: 40209 > 32768"

Error ini menunjukkan bahwa header pesan telah melebihi batas ukuran frame. Batas default untuk header pesan adalah 32 KB dan tidak dapat diubah di server.

Untuk mencegah error ini, pindahkan data besar dari header pesan ke isi pesan.

Menemukan pesan setelah purge antrian

Fungsi pencarian pesan mengkueri data log, bukan antrian langsung. Karena log disimpan lebih lama, Anda dapat menemukan catatan pesan bahkan setelah pesan tersebut di-purge dari antrian.

Error saat melepas binding langganan

Penyebab:

Antrian eksklusif hanya terlihat oleh koneksi yang pertama kali mendeklarasikannya. Oleh karena itu, antrian tersebut hanya dapat dihapus oleh koneksi spesifik tersebut dan tidak dari Konsol.

Untuk informasi selengkapnya, lihat Antrian eksklusif.

Solusi:

1) Jika Anda tidak lagi memerlukan antrian eksklusif tersebut, putuskan koneksi yang sesuai. Antrian dan binding-nya akan dihapus secara otomatis.

2) Jika Anda tidak dapat menemukan ID koneksi yang membuat antrian tersebut, hapus antrian eksklusif dengan merestart client.

Error: "VPC flow is not allowed to login in"

Penyebab:

Server mendeteksi bahwa kredensial yang digunakan bukan kredensial statis yang dihasilkan dari Konsol. Server salah mengartikan permintaan tersebut sebagai traffic autentikasi open-source dan menolak koneksi.

Solusi:

Setelah memastikan konektivitas dari VPC Anda, pastikan Anda menggunakan kredensial statis yang dihasilkan di Konsol. Jika Anda tidak yakin, kami menyarankan untuk membuat ulang kredensial tersebut.

Pembuatan instans memakan waktu lebih dari 30 menit

Langkah pemecahan masalah:

• Verifikasi bahwa VPC yang ditentukan saat pembuatan instans ada, dimiliki oleh akun Anda (UID), dan berada dalam status Available.

• Verifikasi bahwa vSwitch yang ditentukan saat pembuatan instans memenuhi persyaratan. Anda dapat merujuk ke parameter VswitchIds pada API CreateInstance.

Penyebab:

Masalah ini biasanya terjadi ketika konfigurasi VPC atau vSwitch berubah selama proses pembuatan instans. Misalnya, jika VPC dihapus setelah validasi permintaan awal berhasil, pembuatan instans asinkron akan gagal.

Solusi:

Jika parameter pembuatan berubah selama proses (misalnya, VPC atau vSwitch dihapus), rilis instans ApsaraMQ for RabbitMQ tersebut dan buat yang baru.

Akses jaringan pribadi cross-region

Solusi standar untuk akses jaringan pribadi cross-region adalah menggunakan kombinasi PrivateLink dan Cloud Enterprise Network (CEN).

Perhatikan bahwa solusi ini dikenai biaya PrivateLink. Untuk informasi selengkapnya, lihat Titik akhir PrivateLink.

Error saat membuat titik akhir PrivateLink: parameter VPC

Penyebab:

ID VPC tidak ada, atau VPC tidak dalam status Available.

Solusi:

Verifikasi bahwa Virtual Private Cloud (VPC) yang dipilih ada dan berada dalam status "Available". Anda dapat memeriksa status VPC di Konsol VPC.

Error saat membuat titik akhir PrivateLink: parameter VSwitch

Penyebab:

vSwitch yang dipilih tidak memenuhi satu atau lebih kondisi berikut:

• Anda harus memilih vSwitch dari minimal dua zona berbeda (tidak berlaku untuk beberapa wilayah single-zone).

• vSwitch harus termasuk dalam VPC yang dipilih.

• vSwitch harus dalam status Available.

• vSwitch harus memiliki minimal 20 alamat IP yang tersedia.

• Zona tempat vSwitch berada harus mendukung pembuatan NLB.

Solusi:

• Periksa jumlah vSwitch: Untuk wilayah single-zone (seperti Nanjing, Fuzhou, Wuhan-Local, Southeast Asia 6, Southeast Asia 7, NE 2, dan MEA 1), pilih minimal satu vSwitch. Untuk wilayah lainnya, pilih vSwitch dari minimal dua zona berbeda.

• Pastikan vSwitch termasuk dalam VPC yang dipilih dan berada dalam status Available.

• Pastikan vSwitch memiliki minimal 20 alamat IP yang tersedia.

• Pastikan zona tempat vSwitch berada mendukung pembuatan NLB.

Error saat membuat titik akhir PrivateLink: parameter SecurityGroup

Penyebab:

Security group yang dipilih tidak memenuhi satu atau lebih kondisi berikut:

• Security group harus memiliki aturan masuk yang mengizinkan traffic TCP pada port tujuan 5672 dan 5671.

• Security group terkelola (managed security groups) tidak didukung.

• Security group harus termasuk dalam VPC yang dipilih.

• Jumlah security group tidak boleh melebihi kuota akun Anda.

Solusi:

• Pastikan security group memiliki aturan masuk yang mengizinkan traffic TCP pada port tujuan 5672 dan 5671.

• Pastikan Anda tidak memilih security group terkelola.

• Pastikan security group termasuk dalam VPC yang dipilih.

Error: Layanan PrivateLink belum diaktifkan

Penyebab:

Layanan PrivateLink belum diaktifkan untuk akun Anda.

Solusi:

Aktifkan layanan PrivateLink, lalu coba buat kembali titik akhir PrivateLink. Untuk informasi selengkapnya, lihat Apa itu PrivateLink?.

Apa penyebab IOException atau error koneksi di client?

Berikut ini dapat menyebabkan IOException atau error koneksi: