Praktik terbaik untuk daya tahan dan keandalan pesan di Amazon MQ untuk RabbitMQ

Sebelum memindahkan aplikasi Anda ke produksi, selesaikan praktik terbaik berikut untuk mencegah kehilangan pesan dan pemanfaatan sumber daya yang berlebihan.

Langkah 1: Gunakan pesan persisten dan antrian yang tahan lama

Pesan persisten dapat membantu mencegah kehilangan data ketika broker lumpuh atau memulai ulang. Pesan persisten ditulis ke disk segera setelah pesan tiba. Tidak seperti antrean malas, pesan persisten di-cache dalam memori dan disk, kecuali lebih banyak memori diperlukan oleh broker. Dalam kasus ketika lebih banyak memori diperlukan, pesan dihapus dari memori oleh mekanisme broker RabbitMQ yang mengelola penyimpanan pesan ke disk, sering disebut sebagai lapisan persisten.

Untuk mengaktifkan persistensi pesan, Anda dapat menyatakan antrean sebagai durable dan mengatur mode pengiriman pesan ke persistent. Contoh berikut mendemonstrasikan penggunaan pustaka klien RabbitMQ Java untuk mendeklarasikan antrean yang tahan lama. Saat bekerja dengan AMQP 0-9-1, Anda dapat menandai pesan sebagai persisten dengan mengatur mode pengiriman “2".

boolean durable = true;
channel.queueDeclare("my_queue", durable, false, false, null);

Setelah mengonfigurasi antrean sebagai tahan lama, Anda dapat mengirim pesan persisten ke antrean dengan mengatur MessageProperties ke PERSISTENT_TEXT_PLAIN seperti yang ditampilkan dalam contoh berikut.

import com.rabbitmq.client.MessageProperties;

channel.basicPublish("", "my_queue",
            MessageProperties.PERSISTENT_TEXT_PLAIN,
            message.getBytes());

Langkah 2: Konfigurasikan konfirmasi penerbit dan pengakuan pengiriman konsumen

Proses konfirmasi pesan telah dikirim ke broker dikenal sebagai konfirmasi penerbit. Publisher mengonfirmasi membiarkan aplikasi Anda tahu kapan pesan telah disimpan dengan andal. Konfirmasi penerbit juga dapat membantu mengontrol tingkat pesan yang disimpan ke broker. Tanpa konfirmasi penerbit, tidak ada konfirmasi bahwa pesan diproses dengan sukses, dan broker Anda dapat menjatuhkan pesan yang tidak dapat diproses.

Demikian pula, ketika aplikasi klien mengirimkan konfirmasi pengiriman dan konsumsi pesan kembali ke broker, itu dikenal sebagai pengakuan pengiriman konsumen. Konfirmasi dan pengakuan sangat penting untuk memastikan keamanan data saat bekerja dengan broker RabbitMQ.

Pengakuan pengiriman konsumen biasanya dikonfigurasi pada aplikasi klien. Saat bekerja dengan AMQP 0-9-1, pengakuan dapat diaktifkan dengan mengonfigurasi metode. basic.consume Klien AMQP 0-9-1 juga dapat mengonfigurasi konfirmasi penerbit dengan mengirimkan metode. confirm.select

Biasanya, pengakuan pengiriman diaktifkan di saluran. Misalnya, ketika bekerja dengan pustaka klien RabbitMQ Java, Anda dapat menggunakan Channel#basicAck untuk menyiapkan yang pengakuan positif basic.ack sederhana seperti yang ditampilkan dalam contoh berikut.

// this example assumes an existing channel instance

boolean autoAck = false;
channel.basicConsume(queueName, autoAck, "a-consumer-tag",
     new DefaultConsumer(channel) {
         @Override
         public void handleDelivery(String consumerTag,
                                    Envelope envelope,
                                    AMQP.BasicProperties properties,
                                    byte[] body)
             throws IOException
         {
             long deliveryTag = envelope.getDeliveryTag();
             // positively acknowledge a single delivery, the message will
             // be discarded
             channel.basicAck(deliveryTag, false);
         }
     });

catatan

Pesan yang tidak diakui harus di-cache dalam memori. Anda dapat membatasi jumlah pesan yang diambil sebelumnya oleh konsumen dengan mengonfigurasi pengaturan pra-pengambilan untuk aplikasi klien.

Anda dapat mengonfigurasi consumer_timeout untuk mendeteksi ketika konsumen tidak mengakui pengiriman. Jika konsumen tidak mengirimkan pengakuan dalam nilai batas waktu, saluran akan ditutup, dan Anda akan menerima a. PRECONDITION_FAILED Untuk mendiagnosis kesalahan, gunakan UpdateConfigurationAPI untuk meningkatkan consumer_timeout nilai.

Langkah 3: Jaga antrian pendek

Dalam penerapan cluster, antrian dengan sejumlah besar pesan dapat menyebabkan pemanfaatan sumber daya yang berlebihan. Ketika broker dimanfaatkan secara berlebihan, me-reboot Amazon MQ untuk broker RabbitMQ dapat menyebabkan penurunan kinerja lebih lanjut. Jika reboot, broker yang terlalu banyak digunakan mungkin menjadi tidak responsif di negara bagian. REBOOT_IN_PROGRESS

Selama jendela pemeliharaan, Amazon MQ melakukan semua pekerjaan pemeliharaan, satu simpul pada satu waktu, untuk memastikan bahwa broker tetap operasional. Akibatnya, antrian mungkin perlu disinkronkan karena setiap simpul melanjutkan operasi. Selama sinkronisasi, pesan yang perlu direplikasi ke cermin dimuat ke dalam memori dari volume Amazon Elastic Block Store (Amazon EBS) yang sesuai untuk diproses dalam batch. Memproses pesan dalam batch memungkinkan antrean menyinkronkan lebih cepat.

Jika antrean dibuat tetap pendek dan pesan berukuran kecil, antrean berhasil disinkronkan dan melanjutkan operasi seperti yang diharapkan. Namun, jika jumlah data dalam batch mendekati batas memori simpul, simpul memicu alarm memori tinggi, menjeda sinkronisasi antrean. Anda dapat mengonfirmasi penggunaan memori dengan membandingkan metrik node RabbitMemUsed dan RabbitMqMemLimit broker di CloudWatch. Sinkronisasi tidak dapat diselesaikan hingga pesan dikonsumsi atau dihapus, atau jumlah pesan dalam batch berkurang.

Jika sinkronisasi antrian dijeda untuk penerapan klaster, sebaiknya gunakan atau hapus pesan untuk menurunkan jumlah pesan dalam antrian. Setelah kedalaman antrian berkurang dan sinkronisasi antrian selesai, status broker akan berubah menjadi. RUNNING Untuk menyelesaikan sinkronisasi antrian yang dijeda, Anda juga dapat menerapkan kebijakan untuk mengurangi ukuran batch sinkronisasi antrian.

Anda juga dapat menentukan kebijakan penghapusan otomatis dan TTL untuk secara proaktif mengurangi penggunaan sumber daya, serta menjaga NACKs dari konsumen seminimal mungkin. Requeueing pesan pada broker adalah CPU intensif sehingga jumlah yang tinggi NACKs dapat mempengaruhi kinerja broker.