Routing & Binding #

Dalam arsitektur perutean pesan menggunakan RabbitMQ, setelah pesan berhasil melewati gerbang penerbitan (Publishing) dan diterima oleh exchange, broker memasuki fase krusial berikutnya dalam message lifecycle: Routing & Binding Evaluation (Evaluasi Rute dan Ikatan).

Di sinilah broker memproses data biner yang masuk dan menjawab pertanyaan mendasar: ke antrean mana pesan ini harus disalurkan, bagaimana mencocokkan kriteria rutenya, dan apa yang harus dilakukan jika pesan tidak memiliki tujuan. Proses evaluasi ini sepenuhnya berjalan di dalam broker di bawah kendali runtime Erlang BEAM VM. Kecepatan dan efisiensi tahap ini menentukan throughput keseluruhan sistem kita. Artikel ini akan mengupas tuntas struktur tabel rute Mnesia di tingkat kode, mekanisme penghematan memori RAM Erlang melalui pointer biner ProcBin, penyelamatan pesan via Alternate Exchange, serta bahaya penguncian skema kluster (Mnesia schema locks) akibat modifikasi binding secara dinamis saat runtime.

Posisi Evaluasi Rute dalam Lifecycle #

Evaluasi rute bertindak sebagai jembatan logis antara Exchange dengan antrean tujuan. Exchange dalam RabbitMQ hanyalah entitas logis (virtual) yang didefinisikan sebagai entri metadata di database Mnesia. Exchange tidak memiliki antrean penyimpanan pesan (mailbox) sendiri.

flowchart TD
    Msg["Pesan Masuk (Routing Key: 'sales.order')"] --> Ex["Exchange (events.topic)"]
    Ex --> RouteEval{"rabbit_router:route/2"}
    
    subgraph MnesiaETS["ETS Memory Lookup (rabbit_route)"]
        RouteEval --> QueryETS["Query ets:lookup/2"]
    end
    
    QueryETS -->|Match 1| Pointer1["ProcBin Pointer (24 bytes)"] --> QueueA["Queue A (Mailbox)"]
    QueryETS -->|Match 2| Pointer2["ProcBin Pointer (24 bytes)"] --> QueueB["Queue B (Mailbox)"]
    
    subgraph SharedHeap["Global Off-Heap Memory (Refc Binary)"]
        Payload["Payload Pesan Aktual (10 MB)"]
    end
    
    Pointer1 -.-> Payload
    Pointer2 -.-> Payload

Alur Evaluasi Rute #

Ketika Method Frame basic.publish diproses oleh channel broker:

  1. Ekstraksi Header: Broker mengekstrak nama exchange dan routing key dari frame.
  2. Lookup Binding: Broker memanggil fungsi internal rabbit_router:route/2. Fungsi ini menanyakan tabel memori ETS (Erlang Term Storage) bernama rabbit_route untuk mendapatkan seluruh aturan binding yang terdaftar pada exchange tersebut.
  3. Pencocokan Rute: Berdasarkan tipe exchange (Direct, Fanout, Topic, atau Headers), broker melakukan komparasi string atau traversal Trie tree untuk menyaring antrean mana saja yang berhak menerima pesan.
  4. Enqueueing: Pesan kemudian dimasukkan ke dalam mailbox proses Erlang yang mewakili antrean-antrean tujuan tersebut.

Query Tabel Rute Mnesia dan ETS Bag #

Tabel metadata binding kluster RabbitMQ disimpan secara permanen di database terdistribusi Mnesia. Namun, melakukan query ke disk Mnesia untuk setiap pesan yang mengalir akan melumpuhkan performa broker. Oleh karena itu, RabbitMQ memproyeksikan data binding tersebut ke dalam tabel memori ETS RAM saat broker dijalankan.

Struktur Tabel rabbit_route #

Tabel ETS rabbit_route dikonfigurasi menggunakan tipe data bag. Karakteristik tabel tipe bag di Erlang mengizinkan kita menyimpan beberapa entri data (records) dengan kunci (key) yang sama secara paralel.

  • Format Kunci: Kunci pencarian dalam tabel rabbit_route adalah nama exchange asal.
  • Struktur Record: Setiap record dalam tabel berisi informasi: {ExchangeName, BindingKey, QueueName, Arguments}.
  • Lookup Direct Exchange: Untuk Direct Exchange, broker cukup memanggil ets:lookup(rabbit_route, ExchangeName) yang berjalan dengan kompleksitas waktu $O(1)$. Broker membandingkan nilai BindingKey hasil lookup dengan Routing Key pesan untuk mendapatkan nama antrean tujuan secara instan.
  • Lookup Fanout Exchange: Broker mengambil seluruh record binding untuk exchange tersebut tanpa mempedulikan field BindingKey. Pesan langsung diduplikasi ke seluruh antrean yang terdaftar.

Replikasi Payload dan Pointer ProcBin Erlang #

Salah satu performa unggulan RabbitMQ yang jarang diketahui adalah kemampuannya menduplikasi pesan ke banyak antrean tanpa memakan banyak memori RAM broker.

Masalah Duplikasi Memori Tradisional #

Jika produsen mengirim pesan berukuran 10 MB ke sebuah Fanout Exchange yang memiliki 100 antrean terikat, sistem tradisional harus menyalin payload 10 MB tersebut sebanyak 100 kali ke memori antrean masing-masing, memboroskan RAM sebesar 1 GB secara instan untuk satu pesan saja. Ini akan memicu Garbage Collection churn yang mematikan kinerja broker.

Solusi Refc Binaries dan Pointer ProcBin di Erlang BEAM #

Runtime Erlang BEAM VM menyelesaikan masalah ini dengan memisahkan penyimpanan biner berdasarkan ukurannya:

  1. Heap Binaries (< 64 byte): Pesan yang sangat kecil disimpan langsung di memori heap lokal proses antrean masing-masing.
  2. Refc Binaries (> 64 byte): Pesan dengan ukuran di atas 64 byte disimpan dalam memori bersama global yang berada di luar heap proses (off-heap memory), yang disebut Refc Binaries (Reference-Counted Binaries).
  3. Alokasi Tunggal: Ketika pesan 10 MB masuk ke exchange, RabbitMQ hanya mengalokasikan satu kali memori 10 MB di shared off-heap memory tersebut.
  4. ProcBin Term: Untuk setiap antrean tujuan yang cocok (misalnya 100 antrean), broker hanya mengirimkan term kecil berukuran 24 byte bernama ProcBin ke mailbox proses Erlang antrean tersebut. Term ProcBin ini hanya berisi alamat pointer memori ke payload 10 MB di shared off-heap dan menaikkan nilai penghitung referensi (reference counter).

Ketika consumer membaca pesan dari salah satu antrean, ia akan mengakses data lewat pointer tersebut. Setelah pesan berhasil di-ack dan dihapus dari antrean, reference counter biner diturunkan sebesar 1. Ketika reference counter mencapai angka nol, runtime Erlang akan membebaskan memori 10 MB tersebut secara otomatis. Mekanisme ini membuat proses perutean massal (fanout) di RabbitMQ berjalan sangat cepat dengan konsumsi memori minimal.

Penyelamatan Pesan via Alternate Exchange (AE) #

Ketika produsen mengirim pesan dengan mandatory = true dan pesan tersebut gagal dirutekan karena tidak ada binding yang cocok, pesan akan dikembalikan ke produsen. Namun, jika produsen tidak memproses pemantulan pesan secara real-time, atau jika mandatory bernilai false, pesan akan dibuang secara senyap.

Untuk menyelamatkan pesan-pesan yang tidak ter-rute (unroutable messages) ini tanpa membebani aplikasi produsen dengan logika penanganan galat, RabbitMQ menyediakan fitur Alternate Exchange (AE).

Cara Kerja Alternate Exchange #

Alternate Exchange adalah exchange cadangan yang diikat ke exchange utama melalui argumen deklarasi "alternate-exchange".

flowchart LR
    A["Publish"] --> B["Exchange Utama"] -->|"No Route"| C["Alternate Exchange"] --> D["Queue Cadangan (Orphan)"]
  1. Evaluasi Pertama: Pesan dipublikasikan ke Exchange Utama.
  2. Rute Gagal: Broker mendeteksi tidak ada binding antrean yang cocok pada Exchange Utama.
  3. Alih Rute: Broker memeriksa apakah Exchange Utama memiliki argumen "alternate-exchange". Jika ada, broker langsung memindahkan pesan tersebut ke Alternate Exchange.
  4. Penerimaan: Alternate Exchange (biasanya dikonfigurasi sebagai tipe Fanout) menyalurkan pesan tersebut ke antrean penampung cadangan (antrean yatim atau orphan queue) untuk kebutuhan investigasi bug atau audit.
  5. Prioritas: Pengalihan ke Alternate Exchange membatalkan proses pemantulan pesan ke produsen, sehingga produsen tidak akan menerima sinyal basic.return meskipun mandatory bernilai true.

Kode Go: Mengonfigurasi Alternate Exchange #

Berikut adalah contoh lengkap dalam bahasa Go untuk mendeklarasikan Alternate Exchange tipe fanout, mengikatnya ke exchange utama tipe topic, dan memverifikasi penyelamatan unroutable message.

package main

import (
	"context"
	"log"
	"time"

	amqp "github.com/rabbitmq/amqp091-go"
)

func main() {
	// 1. Menghubungkan ke RabbitMQ
	conn, err := amqp.Dial("amqp://guest:guest@localhost:5672/")
	if err != nil {
		log.Fatalf("Gagal terhubung ke RabbitMQ: %s", err)
	}
	defer conn.Close()

	ch, err := conn.Channel()
	if err != nil {
		log.Fatalf("Gagal membuka channel: %s", err)
	}
	defer ch.Close()

	// 2. Deklarasi Alternate Exchange (AE) Cadangan
	aeName := "my-alternate-exchange"
	err = ch.ExchangeDeclare(
		aeName,
		"fanout", // AE paling cocok menggunakan Fanout agar menampung semua pesan gagal
		true,     // durable
		false,    // auto-delete
		false,
		false,
		nil,
	)
	if err != nil {
		log.Fatalf("Gagal mendeklarasikan AE: %s", err)
	}

	// 3. Deklarasi Antrean Penampung Cadangan (Orphan / Unrouted Messages)
	orphanQueue, err := ch.QueueDeclare(
		"unrouted-messages-queue",
		true,
		false,
		false,
		false,
		nil,
	)
	if err != nil {
		log.Fatalf("Gagal mendeklarasikan antrean unrouted: %s", err)
	}

	// Ikat antrean cadangan ke AE
	err = ch.QueueBind(orphanQueue.Name, "", aeName, false, nil)
	if err != nil {
		log.Fatalf("Gagal mengikat antrean unrouted ke AE: %s", err)
	}

	// 4. Deklarasi Exchange Utama dengan mengaitkannya ke AE
	mainExchangeName := "main-topic-exchange"
	mainExchangeArgs := amqp.Table{
		"alternate-exchange": aeName, // KUNCI MENGHUBUNGKAN EXCHANGE UTAMA DENGAN AE!
	}
	err = ch.ExchangeDeclare(
		mainExchangeName,
		"topic", // Exchange utama menggunakan Topic
		true,
		false,
		false,
		false,
		mainExchangeArgs,
	)
	if err != nil {
		log.Fatalf("Gagal mendeklarasikan Exchange Utama: %s", err)
	}

	// 5. Kirim pesan ke Exchange Utama dengan Routing Key yang TIDAK AKAN cocok dengan antrean manapun
	ctx, cancel := context.WithTimeout(context.Background(), 5*time.Second)
	defer cancel()

	payload := []byte(`{"error_report":"format_invalid","code":500}`)
	err = ch.PublishWithContext(ctx,
		mainExchangeName,
		"unmatched.routing.key", // Routing key acak yang tidak terikat antrean
		true,                   // mandatory = true (AE akan menggagalkan pemantulan)
		false,
		amqp.Publishing{
			DeliveryMode: amqp.Persistent,
			ContentType:  "application/json",
			Body:         payload,
		},
	)
	if err != nil {
		log.Fatalf("Gagal mempublikasikan pesan: %s", err)
	}
	log.Println("✓ Pesan dipublikasikan. Karena rute utama gagal, pesan dialihkan secara otomatis ke Alternate Exchange.")
}

Aliran Mailbox Proses Erlang & Penanganan Backlog #

Setelah rute yang cocok ditemukan di tabel ETS, pesan harus dikirimkan dari proses channel (rabbit_channel) ke proses antrean tujuan (rabbit_amqqueue_process). Proses pemindahan pesan ini memanfaatkan arsitektur pesan aktor (actor message passing) di runtime Erlang.

Pengiriman Pesan ke Mailbox Aktor #

Di tingkat internal Erlang, setiap antrean direpresentasikan oleh satu proses aktor terisolasi yang memiliki kotak surat (mailbox) memori. Kotak surat ini secara bawaan bersifat tidak berbatas (unbounded mailbox).

  • Mailbox Enqueue: Proses channel mengirimkan term pointer ProcBin ke mailbox proses antrean tujuan menggunakan instruksi kirim Erlang (!). Proses ini berjalan secara asinkron dan sangat cepat.
  • Backlog Bottleneck: Jika aplikasi konsumen kita sangat lambat, proses antrean tidak akan mampu memproses pesan dari kotak suratnya cukup cepat. Meskipun payload pesan aman di shared off-heap, tumpukan pointer di dalam mailbox proses Erlang akan terus membengkak, meningkatkan konsumsi RAM dan memperlambat kinerja penjadwalan proses BEAM VM.
  • Backpressure Ke Channel: Untuk mencegah kegagalan fatal akibat mailbox yang membengkak, RabbitMQ menerapkan mekanisme koordinasi internal. Jika panjang antrean melampaui batas tertentu, proses antrean akan mengirimkan sinyal kendali ke seluruh channel produsen yang terhubung untuk memperlambat pembacaan socket TCP, secara efektif menekan laju Publishing produsen dari hulu.

Optimasi Menghadapi Legacy Dynamic Binding #

Meskipun dynamic binding adalah anti-pattern yang harus dihindari di produksi, beberapa sistem warisan (legacy systems) terpaksa menerapkannya. Untuk meminimalkan dampak penguncian skema Mnesia saat terjadi dynamic binding, kita dapat melakukan tuning pada parameter startup RabbitMQ:

  • mnesia.dump_log_write_threshold: Menyetel ambang batas penulisan log transaksi Mnesia sebelum dilakukan dump ke disk. Menaikkan parameter ini (misalnya menjadi 50000) mengurangi frekuensi penulisan sinkron disk Mnesia selama aktivitas bind/unbind dinamis.
  • mnesia.dc_dump_limit: Mengontrol batas ukuran file dump Mnesia untuk mencegah terjadinya disk I/O freeze yang tiba-tiba saat Mnesia melakukan pembersihan log rute binding yang tidak aktif.

Anti-Pattern: Dynamic Binding Churn dan Mnesia Schema Locks #

Salah satu kesalahan operasional paling berbahaya saat merancang aplikasi berbasis RabbitMQ adalah memperlakukan Binding sebagai entitas dinamis yang dibuat dan dihapus sesuka hati selama runtime aplikasi berjalan.

Kasus Kesalahan: Dynamic Binding Churn #

Misalnya, aplikasi web membuat binding baru ke exchange setiap kali ada koneksi WebSocket pengguna baru masuk, lalu menghapus (unbind) binding tersebut saat koneksi ditutup.

Mengapa ini berbahaya? #

  1. Mnesia Schema Locks: Setiap operasi pembuatan dan penghapusan binding (QueueBind atau QueueUnbind) mengharuskan broker melakukan transaksi modifikasi skema pada database terdistribusi Mnesia. Transaksi ini memerlukan penguncian eksklusif (exclusive schema lock) di seluruh node klaster.
  2. Cluster Throttling: Jika ratusan pengguna terhubung dan terputus setiap menit secara acak, klaster RabbitMQ akan menghabiskan sebagian besar siklus CPU hanya untuk menegosiasikan kunci skema Mnesia dan mereplikasi pembaruan tabel Mnesia ke seluruh node. Selama proses ini, perutean pesan normal akan diblokir sementara (throttling), menyebabkan latensi pengiriman melonjak drastis.
  3. RAM Degradation: Modifikasi binding yang konstan merusak efisiensi cache tabel ETS rabbit_route. Broker harus berulang kali mengosongkan dan membangun kembali indeks pencarian di memori RAM.

Solusi Arsitektural: #

Pastikan seluruh Exchange, Antrean, dan Binding dideklarasikan secara statis sekali saja (idempotent declaration) saat startup aplikasi atau melalui skrip migrasi infrastruktur terpisah sebelum aplikasi dijalankan. Jika aplikasi membutuhkan pengiriman pesan ke konsumen spesifik secara dinamis, gunakan Topic Exchange dengan routing key terstruktur, di mana konsumen terhubung menggunakan antrean eksklusif statis yang mendengarkan pola routing key yang sesuai.

Ringkasan #

  • Virtual Exchange — Exchange dalam RabbitMQ hanyalah representasi entri metadata di database Mnesia dan tidak memiliki mailbox penyimpanan memori sendiri.
  • Penyimpanan ETS Bag — Metadata binding diproyeksikan dari database Mnesia ke tabel memori ETS rabbit_route tipe bag yang memungkinkan lookup paralel berkecepatan tinggi.
  • Pointer ProcBin Erlang — Erlang BEAM VM mencegah duplikasi memori saat menduplikasi pesan besar ke banyak antrean dengan cara mengalokasikan data biner sekali di off-heap memori global dan mengirimkan term pointer ProcBin 24 byte ke proses antrean.
  • Alternate Exchange (AE) — Gunakan argumen "alternate-exchange" saat mendeklarasikan exchange utama untuk mengalihkan pesan-pesan tak ter-rute (unroutable) ke exchange cadangan secara otomatis.
  • Hindari Dynamic Binding — Operasi bind/unbind secara dinamis saat runtime memicu penguncian skema database terdistribusi Mnesia (Mnesia schema locks) yang dapat melumpuhkan kinerja klaster.
  • Evaluasi Rute Sebelum Enqueue — Proses perutean pesan (rabbit_router:route/2) diselesaikan di sisi broker sebelum pesan ditempatkan ke dalam antrean.

← Sebelumnya: Publishing   Berikutnya: Persistent →

About | Author | Content Scope | Editorial Policy | Privacy Policy | Disclaimer | Contact