ApsaraMQ for RocketMQ：Pengiriman ulang dan pembatasan kecepatan pesan

Proses retry

SDK client menyertakan logika retry bawaan. Ketika permintaan pengiriman gagal, SDK secara otomatis mengirim ulang pesan tersebut—tidak diperlukan kode retry tingkat aplikasi.

Tentukan jumlah maksimum percobaan ulang saat menginisialisasi produsen. Jika permintaan gagal, SDK akan mencoba mengirim ulang hingga pesan berhasil dikirim atau mencapai batas retry. Setelah percobaan terakhir gagal, SDK mengembalikan error ke aplikasi Anda.

Perilaku retry berbeda berdasarkan mode pengiriman:

Pemicu retry

Retry dipicu oleh dua kategori kegagalan:

Kegagalan sisi client

• Exception jaringan menyebabkan kegagalan koneksi atau timeout permintaan.

• Broker sedang melakukan restart atau undeploy, sehingga menyebabkan kegagalan koneksi.

• Broker berjalan lambat, menyebabkan timeout permintaan.

Error sisi broker

• System logic error: Error pemrosesan internal pada broker.

• System throttling error: Broker menolak permintaan karena telah melebihi kapasitas. Lihat Throttling.

Interval retry

Interval retry bergantung pada jenis error:

Untuk error throttling, SDK menggunakan exponential backoff dengan parameter berikut:

Algoritma backoff bekerja sebagai berikut:

ConnectWithBackoff()
  current_backoff = INITIAL_BACKOFF
  current_deadline = now() + INITIAL_BACKOFF
  while (TryConnect(Max(current_deadline, now() + MIN_CONNECT_TIMEOUT)) != SUCCESS)
    SleepUntil(current_deadline)
    current_backoff = Min(current_backoff * MULTIPLIER, MAX_BACKOFF)
    current_deadline = now() + current_backoff +
      UniformRandom(-JITTER * current_backoff, JITTER * current_backoff)

Untuk spesifikasi lengkap, lihat gRPC connection backoff.

Pahami anggaran waktu total untuk retry

SDK hanya menyediakan satu kontrol retry: jumlah maksimum percobaan ulang. Dalam mode synchronous, thread pemanggil diblokir selama seluruh rangkaian retry, sehingga total waktu pemblokiran bergantung pada hubungan antara timeout per permintaan dan jumlah maksimum retry:

Total blocking time (kasus terburuk) = max_retries x per_request_timeout + sum_of_backoff_delays

Untuk error non-throttling (retry langsung), penundaan backoff bernilai nol:

Total blocking time = max_retries x per_request_timeout

Untuk error throttling, penundaan backoff bertambah secara eksponensial. Sebagai contoh, dengan parameter bawaan dan 5 kali retry:

Evaluasi timeout per permintaan dan jumlah maksimum retry secara bersamaan agar thread pemanggil tidak terlalu lama diblokir dalam mode synchronous.

Menangani pesan gagal setelah retry habis

Retry bawaan tidak menjamin pengiriman. Jika semua retry gagal, SDK mengembalikan error. Tangkap error ini di aplikasi Anda dan terapkan strategi fallback:

• Tulis pesan yang gagal ke log lokal atau dead-letter store untuk diproses ulang nanti.

• Berikan notifikasi ke sistem monitoring Anda agar Anda dapat menyelidiki akar penyebabnya.

Menangani pesan duplikat akibat retry

Ketika permintaan pengiriman mengalami timeout, SDK tidak dapat menentukan apakah broker telah menerima dan menyimpan pesan tersebut. Retry dapat menghasilkan duplikat di broker. Ini merupakan trade-off mendasar dalam sistem pengiriman at-least-once.

Untuk menangani duplikat, rancang konsumen Anda agar mendukung pemrosesan idempoten:

• Beri setiap pesan kunci bisnis unik (misalnya ID pesanan atau ID transaksi).

• Sebelum memproses, periksa apakah kunci tersebut sudah pernah diproses.

• Gunakan constraint database atau cache deduplikasi untuk menegakkan keunikan.

Pemicu throttling

Throttling dipicu dalam skenario berikut:

• Storage pressure surge: Kelompok konsumen mulai mengonsumsi dari offset maksimum suatu antrian. Dalam skenario seperti peluncuran bisnis di mana kelompok konsumen harus mulai mengonsumsi pada waktu tertentu, tekanan penyimpanan pada antrian meningkat tajam. Untuk informasi lebih lanjut, lihat Consumer progress management.

• Message accumulation: Ketika konsumen tidak mampu mengimbangi laju pesan masuk, pesan yang belum dikonsumsi menumpuk di antrian. Jika akumulasi melebihi ambang batas, broker memicu throttling untuk mengurangi tekanan pada sistem downstream.

Kode error dan perilaku retry berdasarkan jenis client

Ketika throttling dipicu, kode error dan perilaku retry bergantung pada protokol client Anda.

Client gRPC

Client Remoting

Perilaku retry untuk client Remoting bervariasi berdasarkan versi SDK:

Jika versi SDK Anda tidak melakukan retry otomatis pada error throttling, terapkan logika retry dengan exponential backoff di kode aplikasi Anda.

Mencegah dan menangani throttling

Monitor kapasitas sebelum lonjakan traffic

Gunakan fitur observabilitas ApsaraMQ for RocketMQ untuk memantau penggunaan dan kapasitas sistem. Sebelum peluncuran bisnis atau lonjakan traffic yang diprediksi:

• Verifikasi bahwa instans Anda memiliki sumber daya yang cukup untuk traffic yang diharapkan.

• Periksa lag kelompok konsumen untuk mengidentifikasi risiko akumulasi.

• Scale up instans Anda atau optimalkan throughput konsumen jika diperlukan.

Menangani throttling tak terduga saat runtime

Jika throttling terjadi secara tak terduga dan retry bawaan SDK tidak dapat memulihkan kondisi:

• Arahkan permintaan ke sistem fallback hingga kondisi throttling mereda.

• Catat event throttling (cari kode error 530 / TOO_MANY_REQUESTS untuk gRPC atau 215 / messages flow control untuk Remoting) untuk membantu mendiagnosis akar penyebabnya.