Terjemahan disediakan oleh mesin penerjemah. Jika konten terjemahan yang diberikan bertentangan dengan versi bahasa Inggris aslinya, utamakan versi bahasa Inggris.
# 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 melindungi daya tahan data dalam situasi di mana broker crash atau restart. 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](https://www.rabbitmq.com/java-client.html) 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](best-practices-performance.md#configure-prefetching) 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 [UpdateConfiguration](https://docs.aws.amazon.com/amazon-mq/latest/api-reference/configurations-configuration-id.html)API 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-rabbitmq-editing-broker-preferences.md#rabbitmq-edit-current-configuration-console), 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](amazon-mq-accessing-metrics.md). 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](rabbitmq-queue-sync.md).
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.