ApsaraMQ for RocketMQ：Retry konsumsi pesan

Pemicu retry pesan

• Konsumsi gagal. Ini mencakup kasus di mana konsumen mengembalikan status kegagalan atau melemparkan pengecualian tak terduga.

• Pemrosesan pesan timeout. Ini mencakup timeout antrian dalam PushConsumer.

Perilaku utama retry pesan

• Mesin keadaan proses retry: Mengontrol status dan logika transisi pesan selama proses retry.

• Interval retry: Waktu antara kegagalan konsumsi atau timeout terakhir hingga pesan dapat dikonsumsi kembali.

• Jumlah maksimum retry: Jumlah maksimum kali sebuah pesan dapat di-retry.

Perbedaan kebijakan retry

Untuk informasi lebih lanjut tentang kebijakan retry spesifik, lihat Kebijakan retry konsumsi PushConsumer dan Kebijakan retry konsumsi SimpleConsumer.

Mesin keadaan retry

Sebagai contoh, gambar di atas menunjukkan proses retry untuk sebuah pesan. Asumsikan pesan berada dalam status Ready selama 5 detik dan waktu pemrosesan adalah 6 detik.

Setiap kali pesan di-retry, statusnya berubah dari Ready ke Inflight lalu ke WaitingRetry. Interval retry adalah waktu antara kegagalan konsumsi atau timeout terakhir hingga pesan dapat dikonsumsi kembali. Waktu aktual antara dua upaya konsumsi juga mencakup waktu pemrosesan dan durasi dalam status Ready. Contohnya:

• Pesan memasuki status Ready pada detik ke-0 untuk upaya konsumsi pertama.

• Karena kecepatan pemrosesan konsumen, pesan tidak ditarik untuk dikonsumsi hingga 5 detik berlalu. Setelah 6 detik pemrosesan, terjadi pengecualian, dan klien mengembalikan kegagalan konsumsi.

• Pesan tidak dapat segera di-retry. Pesan harus menunggu hingga interval retry berlalu sebelum dapat dikonsumsi lagi.

• Pada detik ke-21, pesan kembali ke status Ready.

• Setelah 5 detik lagi, klien mulai mengonsumsi pesan tersebut kembali.

Oleh karena itu, interval aktual antara dua upaya konsumsi adalah: Waktu pemrosesan + Interval retry + Durasi dalam status Ready = 21 detik.

Interval retry

• Pesan tidak terurut (pesan non-terurut): Interval retry menggunakan jadwal bertingkat. Tabel berikut mencantumkan interval spesifiknya.

  Retry attempt	Retry interval	Retry attempt	Retry interval
  1	10 detik	9	7 menit
  2	30 detik	10	8 menit
  3	1 menit	11	9 menit
  4	2 menit	12	10 menit
  5	3 menit	13	20 menit
  6	4 menit	14	30 menit
  7	5 menit	15	1 jam
  8	6 menit	16	2 jam

  Catatan

  Jika jumlah retry melebihi 16, interval retry untuk setiap upaya berikutnya adalah 2 jam.

• Pesan terurut: Interval retry bersifat tetap. Untuk informasi lebih lanjut tentang nilainya, lihat Batas parameter.

Jumlah maksimum retry

• Nilai default: 16.

• Batas maksimum: 1.000.

Jumlah maksimum retry untuk PushConsumer dikontrol oleh metadata kelompok konsumen. Untuk informasi lebih lanjut tentang cara mengubah nilai ini, lihat Ubah jumlah maksimum retry.

Sebagai contoh, jika jumlah maksimum retry adalah 3, pesan dapat dikirim hingga 4 kali: 1 pengiriman pesan asli dan 3 retry.

Contoh penggunaan

Untuk memicu retry pesan untuk PushConsumer, Anda dapat mengembalikan kode status kegagalan konsumsi. SDK juga menangkap pengecualian tak terduga.

SimpleConsumer simpleConsumer = null;
        // Contoh kode: Gunakan PushConsumer untuk mengonsumsi pesan normal. Jika konsumsi gagal, kembalikan error untuk memicu retry.
        MessageListener messageListener = new MessageListener() {
            @Override
            public ConsumeResult consume(MessageView messageView) {
                System.out.println(messageView);
                // Kembalikan kegagalan konsumsi untuk secara otomatis memicu retry hingga mencapai jumlah maksimum retry.
                return ConsumeResult.FAILURE;
            }
        };
            

Lihat log retry konsumsi

Retry untuk konsumsi terurut oleh PushConsumer terjadi di klien konsumen. Server tidak dapat mengambil log detail untuk retry konsumsi. Jika hasil pengiriman pesan terurut dalam jejak pesan adalah "failed", periksa log klien konsumen untuk informasi seperti jumlah maksimum retry dan klien konsumen.

Untuk informasi lebih lanjut tentang jalur log klien konsumen, lihat Konfigurasi log.

Anda dapat mencari kata kunci berikut dalam log klien untuk dengan cepat menemukan konten terkait kegagalan konsumsi:

Message listener raised an exception while consuming messages
Failed to consume fifo message finally, run out of attempt times

Mesin keadaan retry

Berbeda dengan kebijakan retry PushConsumer, interval retry untuk SimpleConsumer dialokasikan sebelumnya. Setiap kali pesan diterima, konsumen menetapkan parameter durasi invisibility, InvisibleDuration, saat memanggil API. Durasi ini adalah waktu pemrosesan maksimum untuk pesan tersebut. Jika kegagalan konsumsi memicu retry, Anda tidak perlu menetapkan interval retry berikutnya karena nilai parameter durasi invisibility digunakan kembali.

Karena durasi invisibility dialokasikan sebelumnya, durasi tersebut mungkin sangat berbeda dari waktu pemrosesan pesan aktual dalam bisnis Anda. Anda dapat menggunakan operasi API untuk memodifikasi durasi invisibility.

Sebagai contoh, jika Anda menetapkan waktu pemrosesan maksimum menjadi 20 ms tetapi pesan tidak dapat diproses dalam waktu tersebut, Anda dapat memodifikasi durasi invisibility pesan untuk memperpanjang waktu pemrosesan. Hal ini mencegah pesan memicu mekanisme retry.

Seperti yang ditunjukkan pada gambar berikut, perubahan durasi invisibility berlaku segera. Durasi invisibility dihitung ulang sejak saat API dipanggil.

Interval retry pesan

Interval retry pesan = Durasi invisibility - Waktu pemrosesan pesan aktual

Interval retry konsumsi untuk SimpleConsumer dikontrol oleh durasi invisibility pesan. Sebagai contoh, jika durasi invisibility adalah 30 ms dan pemrosesan pesan membutuhkan 10 ms sebelum respons kegagalan dikembalikan, retry berikutnya terjadi setelah 20 ms. Dalam kasus ini, interval retry pesan adalah 20 ms. Jika pesan tidak diproses dan tidak ada respons yang dikembalikan setelah 30 ms, pesan timeout dan langsung di-retry. Dalam kasus ini, interval retry adalah 0 ms.

Jumlah maksimum retry

• Nilai default: 16.

• Batas maksimum: 1.000.

Jumlah maksimum retry untuk SimpleConsumer dikontrol oleh metadata kelompok konsumen saat pembuatan. Untuk informasi lebih lanjut tentang cara mengubah nilai ini, lihat Ubah jumlah maksimum retry.

Sebagai contoh, jika jumlah maksimum retry adalah 3, pesan dapat dikirim hingga 4 kali: 1 pengiriman pesan asli dan 3 retry.

Contoh penggunaan

Untuk memicu retry pesan untuk SimpleConsumer, Anda dapat menunggu pesan timeout.

 // Contoh kode: Gunakan SimpleConsumer untuk mengonsumsi pesan normal. Untuk memicu retry, cukup tunggu pesan timeout, dan server akan secara otomatis mencoba ulang.
        List<MessageView> messageViewList = null;
        try {
            messageViewList = simpleConsumer.receive(10, Duration.ofSeconds(30));
            messageViewList.forEach(messageView -> {
                System.out.println(messageView);
                // Jika pemrosesan gagal dan Anda ingin server mencoba ulang, cukup abaikan pesan tersebut. Anda dapat mencoba menerimanya lagi setelah durasi invisibility-nya berakhir.
            });
        } catch (ClientException e) {
            // Jika penarikan gagal karena throttling sistem atau alasan lain, Anda perlu menginisiasi permintaan baru untuk menerima pesan.
            e.printStackTrace();
        }

SDK gRPC

• Panggil operasi OpenAPI UpdateConsumerGroup.

• Modifikasi di Konsol:

  Anda dapat melakukan operasi ini sebagai berikut:

  1. Di halaman Instances, klik nama instans target.

  2. Di panel navigasi sebelah kiri, klik Groups. Di halaman Groups, klik Create Group.

  

SDK Remoting

• Modifikasi menggunakan parameter SDK Remoting: Ubah nilai properti `maxReconsumeTimes` dari konsumen.

Gunakan retry secara wajar dan hindari memicunya untuk kebutuhan seperti pembatasan laju

Seperti disebutkan dalam bagian Skenario, retry pesan cocok untuk skenario di mana pemrosesan bisnis gagal dan kegagalan konsumsi saat ini merupakan kejadian berprobabilitas rendah. Fitur ini tidak cocok untuk skenario kegagalan persisten, seperti pembatasan laju.

• Contoh salah:

  Jika kecepatan konsumsi saat ini terlalu tinggi dan memicu pembatasan laju, kembalikan kegagalan konsumsi dan tunggu retry berikutnya.

• Contoh benar:

  Jika kecepatan konsumsi saat ini terlalu tinggi dan memicu pembatasan laju, tunda penerimaan pesan dan konsumsi pesan tersebut nanti.

Bagaimana cara mengatur timeout konsumsi?

Timeout konsumsi diatur di klien konsumen. Bagian berikut menjelaskan pengaturan parameternya.

consumer.setConsumeTimeout(15); // Satuannya adalah menit. Nilai minimum adalah 1 menit, dan nilai maksimum adalah 180 menit.