Mekanisme pengulangan pengiriman pesan dan pembatasan pesan ApsaraMQ for RocketMQ - ApsaraMQ for RocketMQ

Topik ini menjelaskan mekanisme pengulangan pengiriman pesan dan pembatasan pesan dari ApsaraMQ for RocketMQ.

Informasi Latar Belakang

Pengulangan pengiriman pesan

Mekanisme pengulangan pengiriman pesan ApsaraMQ for RocketMQ menjawab pertanyaan berikut:

Jika terjadi pengecualian pada node tertentu, apakah pesan masih dapat dikirim sesuai harapan?
Apakah pengulangan pesan memengaruhi eksekusi logika konsumsi pesan?
Apa saja kekurangan dari pengulangan pesan?

Pembatasan pesan

Mekanisme pembatasan pesan ApsaraMQ for RocketMQ menjawab pertanyaan berikut:

Kapan pembatasan pesan dipicu?
Apa perilaku klien saat pembatasan pesan dipicu?
Bagaimana cara mencegah pembatasan pesan agar tidak dipicu dan menangani pembatasan pesan yang tidak terduga?

Pengulangan pengiriman pesan

Apa itu pengulangan pengiriman pesan?

Saat klien produser ApsaraMQ for RocketMQ memulai permintaan untuk mengirim pesan ke broker, permintaan tersebut mungkin gagal karena masalah seperti kegagalan jaringan atau pengecualian layanan. Untuk memastikan keandalan pesan, ApsaraMQ for RocketMQ menyediakan logika bawaan di SDK klien untuk mencoba kembali permintaan yang gagal.

Anda dapat menggunakan mekanisme pengulangan pengiriman pesan dalam mode transmisi sinkron dan asinkron.

Kondisi pemicu

Pengulangan pengiriman pesan dipicu ketika kondisi berikut terpenuhi:

Permintaan pengiriman pesan dari klien gagal atau habis waktu.
- Koneksi gagal atau permintaan habis waktu karena pengecualian jaringan.
- Koneksi gagal karena restart atau undeploy broker.
- Permintaan habis waktu karena broker berjalan lambat.
Broker mengembalikan kode kesalahan.
- Kesalahan logika sistem: kesalahan yang disebabkan oleh logika operasi yang salah.
- Kesalahan pembatasan sistem: kesalahan yang disebabkan oleh kapasitas berlebih.

Catatan

Untuk pesan transaksional, hanya pengulangan transparan yang dilakukan. Tidak ada pengulangan yang dilakukan dalam skenario pengecualian jaringan atau timeout. Untuk informasi lebih lanjut tentang pengulangan transparan, lihat Pengulangan Transparan.

Proses pengulangan

Anda dapat menentukan jumlah maksimum pengulangan saat menginisialisasi produser. Saat salah satu kondisi pemicu sebelumnya terjadi, klien produser mencoba mengirim ulang pesan yang gagal sampai pesan berhasil dikirim atau jumlah maksimum pengulangan tercapai. Jika pesan masih gagal dikirim dalam percobaan terakhir, kesalahan akan dikembalikan.

Transmisi sinkron: Thread panggilan diblokir sampai pengulangan berhasil atau percobaan terakhir gagal. Jika percobaan terakhir gagal, sistem mengembalikan kode kesalahan dan pengecualian.
Transmisi asinkron: Thread panggilan tidak diblokir. Hasil panggilan dikembalikan sebagai peristiwa pengecualian atau peristiwa sukses.

Interval pengulangan

Klien segera mencoba mengulangi pesan yang gagal, kecuali jika klien menerima kesalahan pembatasan sistem.
Jika klien menerima kesalahan pembatasan sistem, klien mencoba mengulangi pesan yang gagal berdasarkan interval yang ditentukan dalam kebijakan pengulangan eksponensial mundur.
Algoritma mundur eksponensial menggunakan parameter berikut untuk mengontrol perilaku pengulangan:
- INITIAL_BACKOFF: menentukan interval antara kegagalan pertama dan pengulangan pertama. Nilai default: 1 detik.
- MULTIPLIER: menentukan faktor dengan mana interval dikalikan setelah setiap pengulangan gagal. Nilai default: 1,6.
- JITTER: menentukan faktor dengan mana interval diacak. Nilai default: 0,2.
- MAX_BACKOFF: menentukan batas atas interval. Nilai default: 120 detik.
- MIN_CONNECT_TIMEOUT: menentukan interval minimum. Nilai default: 20 detik.
Algoritma berikut direkomendasikan:
```
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 informasi lebih lanjut, lihat connection-backoff.md.

Batasan fitur

Evaluasi pemblokiran tautan: Dalam mekanisme pengulangan pengiriman pesan ApsaraMQ for RocketMQ, produser hanya dapat mengonfigurasi jumlah maksimum pengulangan. Jika pengecualian sistem memicu logika pengulangan bawaan di SDK, broker harus menunggu hasil pengulangan terakhir. Ini dapat memblokir tautan permintaan. Oleh karena itu, Anda harus mengevaluasi durasi timeout dan jumlah maksimum pengulangan untuk setiap permintaan untuk mencegah pengulangan memblokir tautan permintaan.
Penanganan pengecualian: Mekanisme pengulangan pengiriman pesan bawaan klien ApsaraMQ for RocketMQ tidak menjamin bahwa pesan yang gagal berhasil dikirim. Jika pesan masih gagal dikirim dalam percobaan terakhir, pemanggil harus menangkap pengecualian dan memberikan perlindungan redundansi untuk mencegah inkonsistensi dalam hasil pengiriman pesan.
Pesan duplikat: Jika klien produser ApsaraMQ for RocketMQ mengirim ulang pesan karena timeout permintaan, klien tidak mengetahui hasil pemrosesan pesan di broker. Akibatnya, pesan duplikat mungkin ada di broker. Pastikan logika konsumsi pesan Anda dapat menangani pesan duplikat dengan benar.

Pembatasan pesan

Apa itu pembatasan pesan?

Dalam ApsaraMQ for RocketMQ, pembatasan pesan dipicu untuk mencegah beban kerja yang terlalu tinggi pada sumber daya dasar saat kapasitas sistem menjadi tidak mencukupi atau penggunaan sistem melebihi ambang batas yang ditentukan. Saat pembatasan pesan dipicu, broker langsung gagal dan mengembalikan kesalahan pembatasan sistem.

Kondisi pemicu

Pembatasan pesan dapat dipicu dalam ApsaraMQ for RocketMQ dalam skenario berikut:

Tekanan penyimpanan tinggi: Grup konsumen mulai mengonsumsi pesan dari offset maksimum antrian. Untuk informasi lebih lanjut, lihat Manajemen Kemajuan Konsumen. Dalam skenario seperti peluncuran bisnis, grup konsumen harus mengonsumsi pesan pada waktu tertentu. Dalam hal ini, tekanan penyimpanan pada antrian melonjak, dan pembatasan dipicu.
Pesan yang belum dikonsumsi berlebihan di broker: Jika konsumen tidak dapat mengonsumsi pesan dengan kecepatan yang sama dengan pesan dikirim, sejumlah besar pesan mungkin menumpuk di antrian. Jika jumlah pesan yang menumpuk melebihi ambang batas, pembatasan pesan dipicu untuk mengurangi beban kerja pada sistem hilir.

Perilaku

Saat pembatasan pesan dipicu, klien menerima kesalahan pembatasan sistem. Item berikut menggambarkan kode kesalahan dan pesan kesalahan yang diterima oleh berbagai jenis klien:

gRPC
- Kode kesalahan: 530
- Kata kunci pesan kesalahan: TOO_MANY_REQUESTS
Saat klien menerima kode kesalahan pembatasan sistem, klien mencoba mengulangi pesan yang gagal berdasarkan interval yang ditentukan dalam kebijakan pengulangan mundur eksponensial. Untuk informasi lebih lanjut, lihat Pengulangan Pengiriman Pesan.
Remoting
- Kode kesalahan: 215
- Kata kunci pesan kesalahan: messages flow control
Saat klien yang menggunakan ApsaraMQ for RocketMQ TCP client SDK for Java versi sebelum 1.9.0.Final menerima kode kesalahan pembatasan sistem, klien tidak mencoba mengulangi pesan yang gagal. Saat klien yang menggunakan ApsaraMQ for RocketMQ TCP client SDK for Java 1.9.0.Final atau lebih baru menerima kode kesalahan pembatasan sistem, klien mencoba mengulangi pesan yang gagal berdasarkan kebijakan mundur eksponensial. Untuk informasi lebih lanjut, lihat Pengulangan Pengiriman Pesan.
Saat klien produser yang menggunakan open source Apache RocketMQ SDK menerima kode kesalahan pembatasan sistem, klien tidak mencoba mengulangi pesan yang gagal. Saat klien konsumen yang menggunakan open source Apache RocketMQ SDK menerima kode kesalahan pembatasan sistem, klien mencoba mengulangi pesan yang gagal berdasarkan kebijakan mundur eksponensial.

Catatan

Untuk informasi tentang versi yang didukung dari klien gRPC dan Remoting, lihat Deskripsi Kompatibilitas SDK.

Saran

Cara mencegah pembatasan agar tidak dipicu: Gunakan fitur observabilitas untuk memantau penggunaan dan kapasitas sistem. Ini membantu memastikan bahwa sumber daya dasar mencukupi.
Cara menangani pembatasan pesan yang tidak terduga: Jika pembatasan pesan yang tidak terduga dipicu dan proses pengulangan bawaan gagal di klien, kami sarankan Anda sementara beralih permintaan ke sistem lain.