Belajar RabbitMQ - High Availability - Quorum Queues

#Pendahuluan

Di episode 19 kita menemukan kelemahan cluster: queue non-replicated hanya hidup di satu node, dan pesannya hilang jika node itu mati. Solusi jangka panjang untuk masalah ini adalah quorum queue — tipe queue berbasis algoritma konsensus Raft yang mereplikasi pesan ke beberapa node dan menjamin keamanan data selama mayoritas node hidup.

Quorum queue adalah pengganti resmi dari mekanisme lama classic mirrored queues, yang sudah deprecated sejak RabbitMQ 3.8 dan akan dihapus di versi 4.0. Sejak diperkenalkan pada 3.8, quorum queue menjadi tipe queue yang direkomendasikan untuk produksi: durable secara desain, akurasi pesan tinggi, dan immune terhadap kegagalan sebagian node.

Episode ini membahas cara kerja Raft di balik quorum queue, konfigurasi replikasi, penanganan poison message dengan delivery limit, fitur deduplication, karakteristik performa, serta panduan migrasi dari classic queues.

#Pengenalan Quorum Queues

#Raft Consensus dan Replica Leader-Follower

Quorum queue memakai Raft, algoritma konsensus yang sama dipakai banyak sistem terdistribusi modern. Setiap queue punya satu leader dan beberapa follower yang tersebar di node berbeda. Semua publish dan consume melewati leader; follower terus menyinkronkan data. Pesan dianggap aman setelah direplikasi ke mayoritas node.

Jika leader mati, follower yang masih hidup mengadakan pemilihan dan mengangkat leader baru. Queue tetap tersedia selama mayoritas replica hidup. Rumusnya: dengan N replica, queue bertahan dari kegagalan hingga (N-1)/2 node.

Model keamanan ini berakar pada cara Raft bekerja: sebuah publish baru dianggap berhasil setelah mayoritas replica mengonfirmasi penulisan ke disk, bukan sekadar masuk memori. Karena itu quorum queue jauh lebih aman daripada classic queue yang menulis ke disk sesuai interval tertentu.

#Quorum vs Classic Mirrored Queues

Kesimpulannya: untuk high availability, quorum queue adalah pilihan yang jelas.

#Mengonfigurasi Quorum Queues

#Deklarasi dengan x-queue-type

Quorum queue dideklarasikan dengan argumen x-queue-type=quorum:

rabbitmqadmin declare queue name=orders.q durable=true \
  arguments='{"x-queue-type":"quorum"}'

Faktor replikasi ditentukan otomatis dari jumlah node yang tersedia, atau diatur eksplisit dengan x-quorum-initial-group-size:

rabbitmqadmin declare queue name=orders.q durable=true \
  arguments='{"x-queue-type":"quorum","x-quorum-initial-group-size":3}'

x-quorum-initial-group-size=3 membagi replica queue ke tiga node. Jumlah replica yang ganjil disarankan agar pemilihan leader selalu menghasilkan mayoritas yang jelas.

#Dead Lettering dan Poison Message Handling

Quorum queue mendukung dead lettering dengan semantik khusus: alih-alih memindahkan pesan ke DLX segera, pesan poison diberi delivery limit. Jika melebihi batas, pesan di-move ke DLX. Ini mencegah pesan buruk berputar tanpa henti di queue:

rabbitmqadmin declare queue name=orders.q durable=true \
  arguments='{"x-queue-type":"quorum","x-delivery-limit":5}'

Dengan x-delivery-limit=5, pesan yang gagal diproses lebih dari 5 kali akan dibuang ke DLX (jika dikonfigurasi). Delivery limit tersedia sejak RabbitMQ 3.10.

#Fitur dan Pertimbangan

#Message Deduplication

Quorum queue (3.11+) mendukung deduplication: jika pesan di-publish ulang dengan x-deduplication-header yang sama dalam jendela tertentu, duplikatnya dibuang. Fitur ini berguna untuk idempotensi publisher:

Publish dengan header deduplication

properties = pika.BasicProperties(
    headers={"x-deduplication-header": "order-A-001"},
)
channel.basic_publish(exchange="", routing_key="orders.q",
                      body=b'{}', properties=properties)

Header x-deduplication-header membuat ulang publish dengan nilai yang sama tidak menggandakan pesan dalam queue.

Satu catatan penting tentang deduplication: fitur ini hanya menghilangkan duplikat pada tahap publish ke queue, bukan menjamin pemrosesan sekali di sisi consumer. Untuk jaminan end-to-end, tetaplah merancang consumer yang idempotent berdasarkan message_id atau header bisnis milik kalian sendiri.

#Karakteristik Performa dan Migrasi

Quorum queue sedikit lebih lambat daripada classic queue pada single node karena biaya konsensus dan penulisan disk yang agresif. Namun keandalannya jauh lebih tinggi. Untuk migrasi dari classic queue, gunakan Shovel (episode 26) untuk menyalin pesan dengan downtime minimal, atau blue-green dengan queue paralel. Hindari mengganti tipe queue di tempat — deklarasi dengan tipe berbeda akan ditolak broker.

#Memantau Quorum Queue

Untuk memantau kesehatan replica dan kehadiran leader:

rabbitmqctl list_quorum_queues name type leader online members

list_quorum_queues menampilkan leader, node yang online, dan seluruh anggota replica. Jika sebuah queue menampilkan leader kosong atau anggota online kurang dari mayoritas, berarti pemilihan leader belum tuntas — biasanya akibat masalah jaringan antar node.

#Batasan Quorum Queue

Tidak semua fitur classic queue tersedia di quorum queue. Beberapa hal yang tidak didukung: queue transient dan exclusive, TTL per pesan (x-message-ttl), expiration queue (x-expires), priority queue, dan lazy mode. Jika pola kalian bergantung pada fitur tersebut, pertimbangkan classic queue dengan konsekuensi HA-nya, atau rancang ulang polanya agar sesuai dengan model quorum.

Quorum queue tetap mendukung dead lettering, tetapi dengan semantik delivery limit yang sudah dibahas — bukan pemindahan langsung setiap pesan gagal. Pahami batasan ini sebelum memilih tipe queue, karena deklarasi dengan argumen yang tidak didukung akan ditolak broker.

#Penutup

Di episode 20 ini kalian sudah memahami konsensus Raft di balik quorum queue, membandingkannya dengan classic mirrored queues, mengonfigurasi replikasi dan delivery limit, memakai fitur deduplication, serta mempertimbangkan migrasi dari classic queues.

Inti yang harus dibawa pulang:

• Quorum queue berbasis Raft: pesan aman selama mayoritas replica hidup.
• Satu leader melayani publish dan consume; follower terus sinkron.
• Mirrored queues sudah deprecated — beralihlah ke quorum.
• x-queue-type=quorum menandai queue; faktor replikasi bisa diatur eksplisit.
• Delivery limit mencegah poison message berputar tanpa batas.
• Deduplication menjaga idempotensi publish.
• Migrasi terbaik lewat shovel atau blue-green, bukan ganti tipe di tempat.

Di episode 21 selanjutnya kita akan memasuki RabbitMQ Streams — log append-only bergaya Kafka, konsumsi non-destruktif dengan offset, replikasi dan replay dari posisi mana pun, retention policy, serta kapan sebaiknya memakai stream dibandingkan queue. Ini membuka dimensi baru RabbitMQ untuk throughput tinggi!