Terjemahan disediakan oleh mesin penerjemah. Jika konten terjemahan yang diberikan bertentangan dengan versi bahasa Inggris aslinya, utamakan versi bahasa Inggris.

Amazon MQ untuk praktik terbaik RabbitMQ

Gunakan ini sebagai referensi untuk menemukan rekomendasi dengan cepat guna memaksimalkan performa dan meminimalkan biaya throughput saat bekerja dengan broker RabbitMQ di Amazon MQ.

Aktifkan upgrade versi minor otomatis

Menggunakan keamanan versi broker terbaru dan perbaikan bug, dan peningkatan kinerja. Anda dapat mengaktifkan upgrade versi minor otomatis untuk Amazon MQ untuk mengelola upgrade ke versi patch terbaru.

Menggunakan fitur usang

Jika Anda menggunakan versi 3.13 untuk RabbitMQ di Amazon MQ, Anda akan melihat spanduk di UI Manajemen RabbitMQ yang menyatakan: Deprecated features are being used.

Ini karena RabbitMQ di Amazon MQ menggunakan fitur-fitur berikut yang tidak lagi ditawarkan pada RabbitMQ, atau secara otomatis dikonfigurasi untuk RabbitMQ di Amazon MQ:

Ini adalah spanduk informasi untuk versi 3.13 yang tidak memerlukan tindakan. Broker Amazon MQ Anda akan terus menggunakan fitur-fitur ini.

Pilih jenis instans broker yang tepat untuk throughput terbaik

Throughput pesan dari jenis instans broker tergantung pada kasus penggunaan aplikasi Anda. Jenis instans broker yang lebih kecil seperti t3.micro seharusnya hanya digunakan untuk menguji kinerja aplikasi. Menggunakan instans mikro ini sebelum menggunakan instans yang lebih besar dalam produksi dapat meningkatkan kinerja aplikasi dan membantu Anda menekan biaya pengembangan. Pada jenis instans m5.large dan di atasnya, Anda dapat menggunakan penerapan klaster untuk ketersediaan tinggi dan daya tahan pesan. Jenis instans broker yang lebih besar dapat menangani tingkat produksi klien dan antrian, throughput tinggi, pesan dalam memori, dan pesan yang berlebihan. Untuk info selengkapnya tentang memilih jenis instans yang benar, lihat Pedoman ukuran.

Gunakan beberapa saluran

Untuk menghindari churn koneksi, gunakan beberapa saluran melalui satu koneksi. Aplikasi harus menghindari rasio koneksi 1:1 ke saluran. Kami merekomendasikan menggunakan satu koneksi per proses, dan kemudian satu saluran per utas. Hindari penggunaan saluran yang berlebihan untuk mencegah kebocoran saluran.

Mengaktifkan antrean malas

Jika Anda bekerja dengan antrian yang sangat panjang yang memproses volume pesan yang besar, mengaktifkan antrian malas dapat meningkatkan kinerja broker.

Perilaku default RabbitMQ adalah meng-cache pesan dalam memori dan memindahkannya ke disk hanya ketika broker membutuhkan lebih banyak memori yang tersedia. Memindahkan pesan dari memori ke disk membutuhkan waktu dan menghentikan pemrosesan pesan. Antrian malas secara signifikan mempercepat proses memori ke disk dengan menyimpan pesan ke disk sesegera mungkin, menghasilkan lebih sedikit pesan yang di-cache dalam memori.

Anda dapat mengaktifkan antrean malas dengan menetapkan argumen queue.declare pada saat deklarasi, atau dengan mengonfigurasi kebijakan melalui konsol manajemen RabbitMQ. Contoh berikut menunjukkan cara mendeklarasikan antrean malas menggunakan pustaka klien RabbitMQ Java.

Map<String, Object> args = new HashMap<String, Object>();
args.put("x-queue-mode", "lazy");
channel.queueDeclare("myqueue", false, false, false, args);

Semua Amazon MQ untuk antrian RabbitMQ pada 3.12.13 dan di atasnya berperilaku sebagai antrian malas secara default. Untuk meningkatkan ke versi terbaru Amazon MQ untuk RabbitMQ, lihat. Meningkatkan versi mesin broker Amazon MQ

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());

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 mirror dimuat ke memori dari volume Amazon Elastic Block Store EBS (Amazon) 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 penghapusan otomatis dan TTL kebijakan untuk secara proaktif mengurangi penggunaan sumber daya, serta menjaga NACKs dari konsumen seminimal mungkin. Meminta pesan pada broker bersifat CPU intensif sehingga jumlah yang tinggi NACKs dapat memengaruhi kinerja broker.

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 AMQPKlien 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);
         }
     });

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 UpdateConfigurationAPIuntuk meningkatkan consumer_timeout nilai.

Konfigurasikan pra-pengambilan

Anda dapat menggunakan nilai pra-pengambilan RabbitMQ untuk mengoptimalkan cara konsumen mengonsumsi pesan. RabbitMQ mengimplementasikan mekanisme pra-pengambilan saluran yang disediakan oleh AMQP 0-9-1 dengan menerapkan jumlah pra-pengambilan kepada konsumen sebagai lawan dari saluran. Nilai pra-pengambilan digunakan untuk menentukan jumlah pesan yang dikirim ke konsumen pada waktu tertentu. Secara default, RabbitMQ menetapkan ukuran buffer yang tidak terbatas untuk aplikasi klien.

Ada berbagai faktor yang perlu dipertimbangkan saat menetapkan jumlah pra-pengambilan untuk konsumen RabbitMQ. Pertama, pertimbangkan lingkungan dan konfigurasi konsumen Anda. Karena konsumen perlu menyimpan semua pesan dalam memori saat pesan sedang diproses, nilai pra-pengambilan yang tinggi dapat memiliki dampak negatif pada performa konsumen, dan di beberapa kasus, membuat konsumen berpotensi merusak semuanya. Demikian pula, broker RabbitMQ sendiri menyimpan semua pesan yang dikirimkannya dalam cache dalam memori sampai menerima pengakuan konsumen. Nilai pra-pengambilan yang tinggi dapat menyebabkan server RabbitMQ Anda kehabisan memori dengan cepat jika pengakuan otomatis tidak dikonfigurasi untuk konsumen, dan jika konsumen mengambil waktu yang relatif lama untuk memproses pesan.

Dengan pertimbangan di atas, kami rekomendasikan Anda untuk selalu menetapkan nilai pra-pengambilan agar terhindar dari situasi ketika broker RabbitMQ atau konsumen kehabisan memori karena sejumlah besar pesan yang belum diproses, atau tidak diakui. Jika perlu mengoptimalkan broker untuk memproses pesan dalam volume besar, Anda dapat menguji broker dan konsumen menggunakan berbagai jumlah pra-pengambilan untuk menentukan nilai titik ketika overhead jaringan menjadi sangat tidak signifikan dibandingkan dengan waktu yang dibutuhkan konsumen untuk memproses pesan.

Contoh berikut mendemonstrasikan cara menentukan nilai pra-pengambilan 10 untuk konsumen tunggal menggunakan pustaka klien RabbitMQ Java.

ConnectionFactory factory = new ConnectionFactory();

Connection connection = factory.newConnection();
Channel channel = connection.createChannel();

channel.basicQos(10, false);

QueueingConsumer consumer = new QueueingConsumer(channel);
channel.basicConsume("my_queue", false, consumer);

Konfigurasikan Seledri

Seledri Python mengirimkan banyak pesan yang tidak perlu yang dapat membuat menemukan dan memproses informasi yang berguna menjadi lebih sulit. Untuk mengurangi kebisingan dan mempermudah pemrosesan, masukkan perintah berikut:

celery -A app_name worker --without-heartbeat --without-gossip --without-mingle

Secara otomatis pulih dari kegagalan jaringan

Kami merekomendasikan untuk selalu mengaktifkan pemulihan jaringan otomatis guna mencegah waktu henti yang signifikan ketika koneksi klien ke node RabbitMQ gagal. Pustaka klien RabbitMQ Java mendukung pemulihan jaringan otomatis secara default, dimulai dari versi 4.0.0.

Pemulihan koneksi otomatis dipicu jika pengecualian tidak tertangani dilemparkan ke loop I/O koneksi, jika terdeteksi waktu operasi baca soket habis, atau jika server kehilangan detak jantung.

Dalam kasus ketika koneksi awal antara klien dan node RabbitMQ gagal, pemulihan otomatis tidak akan dipicu. Kami merekomendasikan Anda menulis kode aplikasi untuk memperhitungkan kegagalan koneksi awal dengan mencoba ulang koneksi. Contoh berikut mendemonstrasikan percobaan ulang kegagalan jaringan awal menggunakan pustaka klien RabbitMQ Java.

ConnectionFactory factory = new ConnectionFactory();
// enable automatic recovery if using RabbitMQ Java client library prior to version 4.0.0.
factory.setAutomaticRecoveryEnabled(true);
// configure various connection settings

try {
  Connection conn = factory.newConnection();
} catch (java.net.ConnectException e) {
  Thread.sleep(5000);
  // apply retry logic
}

Aktifkan Classic Queue v2 untuk broker RabbitMQ Anda

Kami merekomendasikan untuk mengaktifkan Classic Queue v2 (CQv2) pada mesin broker versi 3.10 dan 3.11 untuk peningkatan kinerja termasuk:

Semua Amazon MQ untuk antrian RabbitMQ pada 3.12.13 dan di atasnya digunakan secara default. CQv2 Untuk meningkatkan ke versi terbaru Amazon MQ untuk RabbitMQ, lihat. Meningkatkan versi mesin broker Amazon MQ

Migrasi dari ke CQv1 CQv2

Untuk menggunakannyaCQv2, Anda harus mengaktifkan flag classic_mirrored_queue_version fitur terlebih dahulu. Untuk informasi selengkapnya tentang bendera fitur, lihat Cara mengaktifkan bendera fitur.

Untuk bermigrasi dari CQv1 keCQv2, Anda harus membuat kebijakan antrian baru atau mengedit kebijakan antrian yang ada dengan definisi kunci queue-version kebijakan yang disetel ke. 2 Untuk informasi selengkapnya tentang penerapan kebijakan, lihatMenerapkan kebijakan ke Amazon MQ untuk RabbitMQ. Untuk informasi selengkapnya tentang mengaktifkan CQv2 kebijakan antrian, lihat Antrian Klasik dalam dokumentasi RabbitMQ.

Sebaiknya ikuti praktik kinerja terbaik kami yang lain sebelum memulai migrasi.

Jika Anda menggunakan kebijakan antrian, menghapus kebijakan antrian akan menurunkan versi CQv2 antrian kembali. CQv1 Kami tidak menyarankan untuk menurunkan versi CQv2 antrian CQv1 karena RabbitMQ akan mengonversi representasi antrian di disk. Ini bisa menjadi memori intensif dan memakan waktu untuk antrian dengan kedalaman tinggi.