Terjemahan disediakan oleh mesin penerjemah. Jika konten terjemahan yang diberikan bertentangan dengan versi bahasa Inggris aslinya, utamakan versi bahasa Inggris.
Opsi penyebaran untuk Amazon MQ untuk broker RabbitMQ
Broker RabbitMQ dapat dibuat sebagai broker instans tunggal atau dalam deployment klaster. Untuk kedua mode deployment, Amazon MQ memberikan daya tahan tinggi dengan menyimpan data secara redundan.
Anda dapat mengakses broker RabbitMQ Anda dengan menggunakan bahasa pemrograman apa pun yang didukung RabbitMQ
Topik
Opsi 1: Amazon MQ untuk broker instans tunggal RabbitMQ
Broker single instance terdiri dari satu broker dalam satu Availability Zone di belakang Network Load Balancer (). NLB Broker berkomunikasi dengan aplikasi Anda dan dengan volume EBS penyimpanan Amazon. Amazon EBS menyediakan penyimpanan tingkat blok yang dioptimalkan untuk latensi rendah dan throughput tinggi.
Menggunakan Network Load Balancer memastikan bahwa titik akhir Amazon MQ untuk broker RabbitMQ Anda tetap tidak berubah jika instans broker diganti selama jendela pemeliharaan atau karena kegagalan perangkat keras Amazon yang mendasarinya. EC2 Penyeimbang Beban Jaringan memungkinkan aplikasi dan pengguna Anda untuk terus menggunakan titik akhir yang sama untuk terhubung ke broker.
Diagram berikut mengilustrasikan broker instans tunggan Amazon MQ for RabbitMQ.
Opsi 2: Amazon MQ untuk penyebaran cluster RabbitMQ
Deployment klaster adalah pengelompokan logis dari tiga node broker RabbitMQ di balik Penyeimbang Beban Jaringan, masing-masing membagikan pengguna, antrean, dan status terdistribusi di beberapa Availability Zone (AZ).
Dalam deployment klaster, Amazon MQ mengelola kebijakan broker secara otomatis untuk mengaktifkan pencerminan klasik di semua simpul, memastikan ketersediaan tinggi (HA). Setiap antrian yang dicerminkan terdiri dari satu simpul utama dan satu atau lebih cermin. Setiap antrean memiliki simpul utamanya sendiri. Semua operasi untuk antrean yang diberikan pertama-tama diterapkan pada simpul utama antrean lalu disebarkan ke cermin. Amazon MQ membuat kebijakan sistem default yang menetapkan ha-mode ke all dan ha-sync-mode ke automatic. Hal ini memastikan bahwa data direplikasi ke semua simpul dalam klaster di Availability Zone yang berbeda untuk daya tahan yang lebih baik.
catatan
Selama jendela pemeliharaan, semua pemeliharaan ke klaster dilakukan satu simpul pada satu waktu, menjaga setidaknya dua simpul berjalan setiap saat. Setiap kali simpul dinonaktifkan, koneksi klien ke simpul tersebut diputus dan perlu dibuat lagi. Anda harus memastikan bahwa kode klien dirancang untuk terhubung kembali secara otomatis ke klaster Anda. Untuk informasi selengkapnya tentang pemulihan koneksi, lihat Secara otomatis pulih dari kegagalan jaringan.
Karena Amazon MQ menetapkan ha-sync-mode: automatic, selama jendela pemeliharaan, antrean akan menyinkronkan ketika setiap simpul kembali menggabungkan klaster. Sinkronisasi antrian memblokir semua operasi antrean lainnya. Anda dapat mengurangi dampak sinkronisasi antrean selama jendela pemeliharaan dengan membuat antrian tetap pendek.
Kebijakan default tidak boleh dihapus. Jika Anda menghapus kebijakan ini, Amazon MQ akan secara otomatis membuatnya kembali. Amazon MQ juga akan memastikan bahwa properti HA diterapkan ke semua kebijakan lain yang Anda buat pada broker terklaster. Jika Anda menambahkan kebijakan tanpa properti HA, Amazon MQ akan menambahkannya untuk Anda. Jika Anda menambahkan kebijakan dengan properti ketersediaan tinggi yang berbeda, Amazon MQ akan menggantinya. Untuk informasi selengkapnya tentang pencerminan klasik, lihat Antrian cermin klasik
Diagram berikut menggambarkan penyebaran broker cluster RabbitMQ dengan tiga node di tiga Availability Zones (AZ), masing-masing dengan EBS volume Amazon sendiri dan status bersama. Amazon EBS menyediakan penyimpanan tingkat blok yang dioptimalkan untuk latensi rendah dan throughput tinggi.
