Belajar RabbitMQ - RabbitMQ Clients & SDK Best Practices

#Pendahuluan

Broker tidak selalu stabil: restart, network blip, atau maintenance adalah kenyataan operasional. Ketika broker sempat turun, aplikasi client yang naif akan putus asa, membuang koneksi yang rusak, dan menunggu operator memperbaiki semuanya. Aplikasi client yang tangguh justru bangkit sendiri: mengenali koneksi yang mati, membangunnya kembali, dan melanjutkan dari posisi terakhir.

RabbitMQ memberikan alat untuk itu — connection recovery dan topology recovery — yang tersedia di sebagian besar client SDK resmi. Ini mengotomatiskan sebagian besar pekerjaan pemulihan: reconnect, redeclare queue/exchange/binding, dan restart consumer.

Episode ini membahas pola-pola ketahanan di sisi client: recovery otomatis, notifikasi pembatalan consumer, penanganan connection blocked, load balancing endpoint, hingga strategi error handling seperti retry logic dan circuit breaker untuk Python, Node.js, dan Go.

#Client Recovery

#Connection Recovery dan Topology Recovery

Connection recovery otomatis membangun ulang koneksi yang putus, sementara topology recovery otomatis mendeklarasikan ulang queue, exchange, dan binding, lalu menghidupkan kembali consumer. Di pika versi modern, recovery bawaan sudah aktif:

Pika dengan retry koneksi

import pika
 
params = pika.ConnectionParameters(
    host="localhost",
    connection_attempts=5,
    retry_delay=3,
)
connection = pika.BlockingConnection(params)

Parameter connection_attempts=5 dan retry_delay=3 membuat pika mencoba terhubung ulang hingga 5 kali dengan jeda 3 detik.

#Recovery di Node.js dan Go

amqplib di Node.js menawarkan pola manual: dengarkan event close dan panggil ulang fungsi koneksi:

Reconnect sederhana di amqplib

const amqp = require("amqplib");
 
async function connect() {
  const conn = await amqp.connect("amqp://localhost");
  conn.on("close", () => {
    console.log("koneksi putus, mencoba lagi dalam 3 detik");
    setTimeout(connect, 3000);
  });
  return conn;
}
 
connect();

#Notifikasi dan Penanganan Blocked

#Consumer Cancellation Notification

Ketika queue dihapus oleh operator atau policy sementara, broker mengirim consumer cancellation — broker berhenti mengirim pesan ke consumer tersebut. Client modern menerjemahkannya ke callback; jangan abaikan, karena consumer kalian mungkin sudah tidak menerima pesan apa pun.

Callback consumer cancellation

channel.add_on_cancel_callback(lambda method_frame: print("consumer dibatalkan"))

#Blocked Connection Handling

Ingat connection.blocked dari episode 14? Client SDK menyediakan callback yang sama. Di sisi client, gunakan untuk menjeda publish internal dan batasi buffer agar memori aplikasi tidak ikut melebar.

#Load Balancing dan Error Handling

#Client-Side Load Balancing

Saat cluster punya banyak node, client bisa mencoba beberapa endpoint sekaligus. Di pika, berikan beberapa ConnectionParameters — client akan memakai node pertama yang berhasil:

Multiple endpoints di pika

params = pika.ConnectionParameters(host=["node1", "node2", "node3"])
connection = pika.BlockingConnection(params)

Strategi ini menyebar beban koneksi dan memberikan failover otomatis bila satu node turun.

#Retry Logic dan Circuit Breaker

Membedakan jenis kegagalan adalah kunci: publish transient (network) bisa di-retry, publish permanen (exchange tidak ada, permission ditolak) tidak akan pernah berhasil. Terapkan retry dengan backoff untuk yang pertama, dan lewati yang kedua.

Untuk melindungi sistem dari kegagalan beruntun, gunakan circuit breaker: setelah N kegagalan berurutan, aplikasi berhenti mencoba untuk sementara (open state), lalu mencoba lagi setelah cooldown:

closed → open (setelah gagal beruntun) → half-open (cooldown) → closed

#Graceful Degradation

Saat broker tidak tersedia, aplikasi harus tetap melayani pengguna dengan cara lain: simpan pesan ke buffer/queue lokal, kirim respon parsial, atau jatuh ke jalur cadangan seperti HTTP. Desain degradasi ini jauh sebelum broker bermasalah — bukan saat incident berlangsung.

#Penutup

Di episode 28 ini kalian sudah menguasai connection recovery dan topology recovery, consumer cancellation notification, penanganan connection blocked, client-side load balancing, serta retry logic dan circuit breaker untuk membangun client yang tangguh.

Inti yang harus dibawa pulang:

• Connection recovery membangun ulang koneksi; topology recovery redeclare resource.
• Pika mendukung retry koneksi via connection_attempts dan retry_delay.
• Consumer cancellation memberi tahu bahwa konsumsi dihentikan broker.
• Handle connection.blocked untuk menjeda publish dengan aman.
• Beberapa endpoint di pika memberi failover otomatis antar node.
• Pisahkan retry transient dari error permanen.
• Circuit breaker dan graceful degradation melindungi aplikasi dari kegagalan beruntun.

Di episode 29 selanjutnya kita akan men-deploy RabbitMQ di Docker dan Kubernetes — memakai image resmi dengan environment variables, volume persistence, Docker Compose clustering, RabbitMQ Cluster Operator, StatefulSet dengan PersistentVolume, ConfigMaps dan Secrets, serta best practices K8s seperti headless services dan rolling updates. Inilah cara RabbitMQ hidup di dunia container!