RabbitMQ Adalah: Cara Kerja, Exchange & Jenis Antrian

Sebagian besar aplikasi web bekerja dengan pola yang sederhana. Pengguna menekan tombol, aplikasi mengerjakan semua tugas yang menyertainya, lalu halaman berikutnya muncul. Selama tugasnya ringan, pola ini memadai dan tidak ada alasan untuk mengubahnya.

Persoalan muncul saat ada pekerjaan lambat di tengah alur tersebut. Sebuah pendaftaran mungkin perlu mengirim email verifikasi, membuat thumbnail dari foto profil, dan mencatat data ke layanan analitik. Pengguna tidak peduli pada ketiganya, tetapi ia tetap menunggu sampai semuanya selesai. Kalau layanan email sedang lambat, halaman pendaftaran ikut lambat. Kalau layanan email mati, pendaftaran ikut gagal, padahal datanya sudah tersimpan.

Cara keluar dari situasi ini adalah memisahkan "mencatat bahwa pekerjaan perlu dilakukan" dari "mengerjakannya". Aplikasi cukup menitipkan catatan tugas ke sebuah perantara, lalu langsung membalas pengguna. Program lain mengambil catatan itu dan mengerjakannya di belakang layar. Perantara yang menampung titipan inilah yang disebut message broker, dan RabbitMQ adalah salah satu yang paling banyak dipakai.

RabbitMQ Adalah Perantara Pesan, Bukan Database

RabbitMQ adalah perangkat lunak message broker (perantara pesan) yang menerima pesan dari satu aplikasi lalu meneruskannya ke aplikasi lain. Di antara keduanya, pesan disimpan sementara dalam antrian. Ia berperan seperti kantor pos di tengah sistem Anda: pengirim menaruh surat, penerima mengambil ketika sempat, dan keduanya tidak perlu aktif bersamaan.

Karena namanya sering muncul berdampingan dengan perangkat infrastruktur lain, ada baiknya menegaskan apa yang bukan RabbitMQ. Ia bukan database — pesan yang sudah diambil consumer akan hilang dari antrian, dan Anda tidak bisa melakukan query terhadap isinya. Ia juga bukan framework maupun bahasa pemrograman, melainkan perangkat lunak server yang berjalan mandiri dan diajak bicara lewat jaringan oleh aplikasi Anda.

RabbitMQ ditulis dengan bahasa Erlang, bahasa yang sejak awal dirancang untuk sistem telekomunikasi yang harus tetap hidup meski ada bagian yang bermasalah. Protokol utamanya adalah AMQP (Advanced Message Queuing Protocol) versi 0-9-1, sebuah standar terbuka yang menentukan bagaimana pesan dikirim dan diakui penerimaannya. Sejak versi 4.0, AMQP 1.0 juga menjadi protokol inti yang selalu aktif. Lewat plugin tambahan, RabbitMQ dapat melayani MQTT dan STOMP.

Satu hal lagi yang perlu Anda pegang: RabbitMQ tidak menggantikan API yang sudah Anda punya. API menjawab permintaan yang butuh jawaban seketika, sedangkan RabbitMQ menangani pekerjaan yang jawabannya boleh menyusul.

Perjalanan Satu Pesan di Dalam RabbitMQ

Cara tercepat memahami RabbitMQ adalah mengikuti satu pesan dari awal sampai akhir. Ada satu kejutan kecil di tahap pertama yang sering membuat pemula tersandung.

Publisher tidak pernah mengirim pesan ke antrian. Aplikasi pengirim, yang disebut publisher, selalu mengirim pesan ke sebuah exchange — bukan langsung ke antrian tujuan. Bersama pesan itu, publisher menyertakan sebuah label teks bernama routing key, misalnya email.verifikasi.

Exchange bertugas menentukan ke mana pesan tersebut diteruskan. Ia tidak menyimpan apa pun; ia hanya membaca aturan lalu mendorong pesan ke depan. Aturan yang dipakainya bernama binding, yaitu kaitan antara sebuah exchange dan sebuah antrian, lengkap dengan pola routing key yang harus dipenuhi. Kalau tidak ada satu pun binding yang cocok, pesan tersebut dibuang tanpa pemberitahuan.

Setelah lolos, pesan masuk ke queue (antrian) dan menunggu di sana. Antrian inilah satu-satunya bagian yang benar-benar menyimpan pesan. Aplikasi penerima, yang disebut consumer, terhubung ke antrian dan menerima pesan begitu tersedia.

Tahap terakhir yang menentukan keandalan seluruh sistem adalah acknowledgement atau ack — pemberitahuan dari consumer bahwa pesan sudah selesai diproses. Selama ack belum dikirim, RabbitMQ tetap menganggap pesan itu belum beres. Kalau consumer mati di tengah jalan, pesan yang belum di-ack akan dikembalikan ke antrian dan diberikan ke consumer lain. Inilah alasan pekerjaan tidak hilang meskipun proses yang mengerjakannya berhenti mendadak.

Dua angka turunan dari mekanisme ack akan sering Anda lihat di antarmuka pengelolaan. Unacked adalah jumlah pesan yang sudah diserahkan ke consumer tetapi belum dikonfirmasi selesai; angka yang terus membesar menandakan consumer Anda kewalahan atau tersangkut. Pengendalinya adalah prefetch count, batas berapa banyak pesan yang boleh dipegang satu consumer sebelum ia mengirim ack. Nilai 0 berarti tanpa batas, sehingga satu consumer dapat memborong seluruh antrian dan menyisakan consumer lain menganggur. Perlu diperhatikan bahwa RabbitMQ menerapkan batas ini per consumer, berbeda dari spesifikasi AMQP 0-9-1 yang menghitungnya per channel.

Diagram alur pesan RabbitMQ dari publisher ke exchange, queue, lalu consumer yang mengirim ack.

Satu istilah lagi yang akan Anda temui adalah virtual host atau vhost. Vhost adalah ruang terpisah di dalam satu server RabbitMQ, masing-masing dengan exchange, antrian, dan izin aksesnya sendiri. Fungsinya mirip database terpisah dalam satu server database: memisahkan lingkungan pengembangan dan produksi tanpa perlu menyalakan dua server.

Empat Jenis Exchange dan Kapan Memakainya

Karena exchange yang memutuskan arah pesan, jenis exchange yang Anda pilih menentukan pola komunikasi seluruh sistem. AMQP 0-9-1 menyediakan empat jenis.

1. Direct exchange: pesan diteruskan ke antrian yang binding-nya persis sama dengan routing key. Routing key laporan.harian hanya masuk ke antrian yang terikat dengan kata yang sama persis. Pilih ini saat setiap jenis pekerjaan punya satu tujuan yang jelas.
2. Fanout exchange: routing key diabaikan sepenuhnya, dan salinan pesan dikirim ke semua antrian yang terikat padanya. Cocok untuk peristiwa yang perlu diketahui banyak pihak sekaligus, misalnya perubahan harga yang harus menyegarkan cache, memicu notifikasi, dan masuk ke catatan audit.
3. Topic exchange: mencocokkan routing key dengan pola bertingkat yang dipisah titik. Antrian yang terikat pola pesanan.*.jakarta akan menerima pesanan.baru.jakarta tetapi mengabaikan pesanan.baru.surabaya. Tanda # mewakili nol atau lebih kata. Jenis inilah yang paling sering dipakai karena satu exchange bisa melayani banyak pola sekaligus tanpa perlu diubah saat ada consumer baru.
4. Headers exchange: mengabaikan routing key dan mencocokkan atribut pada header pesan. Berguna saat keputusan routing bergantung pada beberapa nilai sekaligus, tetapi pencocokannya lebih lambat dan jarang diperlukan.

Ada satu exchange bawaan yang perlu Anda kenali, yaitu default exchange — sebuah direct exchange tanpa nama. Setiap antrian otomatis terikat padanya dengan routing key yang sama dengan nama antrian, sehingga pesan terlihat seolah dikirim langsung ke antrian. Bentuk ini praktis untuk percobaan pertama, tetapi jangan dijadikan kebiasaan: begitu pola routing Anda berkembang, exchange tanpa nama tidak menyediakan tempat untuk mengaturnya.

Diagram empat jenis exchange RabbitMQ: Direct ke satu antrian, Fanout ke semua, Topic sesuai pola, Headers sesuai atribut.

Classic Queue, Quorum Queue, dan Stream

Bagian ini yang paling sering ketinggalan zaman di rujukan berbahasa Indonesia, padahal konsekuensinya besar untuk keandalan sistem Anda. RabbitMQ modern menyediakan tiga jenis antrian dengan pembagian tugas yang tegas.

Antrian RabbitMQ bekerja secara FIFO (first in, first out) — pesan yang masuk lebih dulu keluar lebih dulu. Namun urutan yang benar-benar dialami consumer bisa bergeser oleh dua hal: pemakaian prioritas pesan, dan pesan yang dikembalikan ke antrian karena gagal diproses. Kalau urutan mutlak diperlukan, jalankan satu consumer saja untuk antrian tersebut.

Classic queue adalah jenis asli dan paling ringan. Sampai seri 3.x, antrian ini bisa direplikasi ke node lain lewat fitur yang disebut mirroring. Fitur tersebut dihapus total pada RabbitMQ 4.0, setelah tiga tahun berstatus akan ditinggalkan. Setelah upgrade ke versi 4, bagian policy yang mengatur mirroring tidak lagi berpengaruh dan classic queue berjalan dengan satu salinan saja. Artinya, panduan lama yang mengajarkan ketersediaan tinggi lewat mirroring sudah tidak berlaku.

Quorum queue adalah jenis antrian tereplikasi yang menggantikannya. Ia menyalin data ke beberapa node dan memakai algoritma konsensus Raft untuk memastikan mayoritas node sepakat sebelum sebuah pesan dianggap tersimpan. Perilakunya saat jaringan terputus jauh lebih mudah diperkirakan. Sejak versi 4.0, quorum queue punya batas pengiriman ulang bawaan sebesar 20 kali; pesan yang gagal diproses melebihi angka itu akan dipindahkan ke antrian khusus atau dibuang. Batas ini melindungi node dari consumer yang terjebak dalam putaran gagal lalu ulangi tanpa henti.

Stream menyimpan pesan sebagai catatan berurutan yang hanya bertambah di ujung. Berbeda dengan antrian biasa, pesan tidak hilang setelah dibaca, sehingga beberapa consumer dapat membaca rentetan yang sama dari posisi berbeda. Pakai stream saat Anda memerlukan riwayat peristiwa yang dapat diputar ulang.

Diagram tiga jenis antrian RabbitMQ: Classic satu server, Quorum tersalin ke tiga server, Stream dibaca ulang.

Pilihan sederhananya: quorum queue untuk pekerjaan yang tidak boleh hilang, classic queue untuk pekerjaan yang boleh diulang. Pakai stream saat riwayat pesan perlu dibaca lebih dari sekali.

Perubahan besar lain di balik layar adalah penyimpan metadata, yaitu tempat RabbitMQ mencatat pengguna, izin, dan susunan antriannya. Perannya dipegang Mnesia sejak awal, lalu digantikan Khepri yang berbasis Raft dan menjadi bawaan sejak versi 4.2.0. Instalasi lama yang di-upgrade tetap memakai Mnesia sampai administrator mengaktifkan Khepri secara sengaja.

Fungsi RabbitMQ dalam Sistem Nyata

Dari cara kerja di atas, muncul beberapa peran yang paling sering Anda temui di lapangan.

1. Memindahkan pekerjaan lambat ke belakang layar: pengiriman email, pembuatan berkas PDF, pemrosesan gambar, dan sinkronisasi ke layanan pihak ketiga tidak perlu ditunggu pengguna. Halaman membalas dalam sepersekian detik, sisanya dikerjakan consumer.
2. Meredam lonjakan trafik: saat kampanye promosi membuat pesanan masuk sepuluh kali lipat, antrian menahan kelebihannya dan consumer mengerjakan sesuai kemampuannya. Sistem melambat, tetapi tidak tumbang.
3. Membagi pekerjaan ke banyak worker: beberapa consumer — sering disebut worker karena tugasnya memang mengerjakan sesuatu — dapat menempel pada satu antrian, dan pesan dibagikan bergiliran di antara mereka. Menambah kapasitas berarti menyalakan worker baru, bukan mengubah kode. Polanya serupa dengan load balancing pada lalu lintas web, hanya saja yang dibagi adalah pekerjaan.
4. Menghubungkan layanan yang ditulis berbeda bahasa: layanan Python dapat menitipkan pekerjaan yang diambil layanan Java atau Go, karena keduanya hanya perlu memahami AMQP.
5. Menangani pekerjaan yang gagal dengan rapi: pesan yang ditolak berkali-kali dapat diarahkan ke dead letter queue (antrian penampung pesan gagal). Kegagalan menjadi terlihat dan bisa diperiksa, bukan menghilang begitu saja.

Kelebihan RabbitMQ

1. Routing yang jauh lebih fleksibel: kombinasi jenis exchange dan pola routing key memungkinkan aturan pengiriman yang rumit tanpa satu baris pun logika percabangan di aplikasi Anda.
2. Jaminan pengiriman yang dapat diatur: mekanisme ack, antrian yang bertahan setelah restart, dan konfirmasi ke publisher memberi Anda kendali atas seberapa ketat jaminan yang diinginkan.
3. Dukungan bahasa dan protokol yang luas: pustaka klien resmi maupun komunitas tersedia untuk hampir semua bahasa populer, dan selain AMQP, RabbitMQ melayani MQTT serta STOMP lewat plugin.
4. Antarmuka pengelolaan bawaan: plugin management menyediakan tampilan web untuk memantau antrian, laju pesan, dan koneksi. Anda dapat melihat penumpukan pesan tanpa perlu memasang perangkat pemantau terpisah lebih dulu.
5. Gratis dan berlisensi terbuka: kode server serta plugin intinya berlisensi MPL 2.0, salah satu lisensi open source yang diakui luas. Tidak ada batas jumlah pesan, node, maupun koneksi.

Kelemahan dan Hal yang Perlu Anda Pertimbangkan

1. Pesan hilang setelah dikonsumsi: pada antrian biasa, pesan yang sudah di-ack tidak dapat dibaca ulang. Kalau Anda memerlukan pemutaran ulang riwayat, pilihannya adalah stream atau perangkat lain yang memang dirancang untuk itu.
2. Bukan pilihan tercepat untuk aliran data masif: throughput RabbitMQ memadai untuk sebagian besar aplikasi bisnis. Namun untuk aliran berskala jutaan pesan per detik, perangkat berbasis catatan berurutan lebih unggul.
3. Membawa runtime Erlang sendiri: versi Erlang harus cocok dengan versi RabbitMQ. Ini menambah satu hal yang perlu diperhatikan setiap kali Anda melakukan upgrade.
4. Cluster tidak berjalan sendiri: menjalankan beberapa node berarti mengurus penemuan antar-node, jenis antrian yang tepat, dan pemulihan setelah gangguan jaringan. Kompleksitasnya nyata, dan sebagian besar aplikasi kecil tidak membutuhkannya.
5. Menambah satu komponen yang bisa mati: begitu RabbitMQ menjadi jalur utama komunikasi, ia perlu dipantau, dicadangkan, dan diperbarui seperti komponen penting lainnya. Sistem Anda mendapat kelenturan, tetapi kehilangan kesederhanaan.
6. Antrian yang menumpuk dapat menghabiskan disk: kalau consumer lebih lambat daripada publisher dalam waktu lama, pesan terus menumpuk. Tetapkan batas panjang antrian dan masa berlaku pesan sejak awal, jangan menunggu disk penuh.

RabbitMQ vs Kafka vs Redis: Memilih yang Sesuai

Ketiganya sering disebut bersamaan, padahal perbedaan dasarnya bukan soal kecepatan melainkan cara memperlakukan pesan.

Pilih RabbitMQ ketika setiap pesan mewakili satu pekerjaan yang harus dikerjakan tepat satu kali, dan aturan pengirimannya tidak sederhana. Ini kondisi yang paling umum pada aplikasi bisnis: pesanan, tagihan, notifikasi, dan pekerjaan latar.

Pilih Kafka ketika Anda mengalirkan peristiwa dalam jumlah sangat besar dan beberapa sistem berbeda perlu membaca aliran yang sama, mungkin berulang kali. Analitik, penelusuran perilaku pengguna, dan pipeline data adalah wilayahnya.

Pilih Redis ketika kebutuhan antrian Anda sederhana dan Redis sudah terpasang sebagai cache. Menambah satu antrian di sana lebih murah daripada menyalakan broker baru. Begitu Anda mulai memerlukan routing bertingkat atau jaminan pengiriman yang ketat, RabbitMQ menjadi pilihan yang lebih tepat.

Port dan Kredensial Bawaan yang Perlu Anda Tahu

Kebingungan pertama yang hampir selalu muncul adalah dua nomor port yang mirip. 5672 dipakai aplikasi Anda untuk mengirim dan menerima pesan, sedangkan 15672 dipakai manusia untuk membuka antarmuka pengelolaan di browser. Membuka 5672 lewat browser tidak akan menampilkan apa pun.

Port 4369 dan 25672 sebaiknya tidak pernah terbuka ke internet. Keduanya jalur internal antar-node, dan mengeksposnya membuka pintu ke seluruh cluster.

Soal kredensial, server yang baru dinyalakan membuat virtual host / beserta pengguna guest dengan kata sandi guest. Ada satu aturan pengaman yang sering mengejutkan: pengguna guest hanya boleh terhubung dari localhost. Percobaan masuk dari komputer lain akan ditolak dengan pesan PLAIN login refused: user 'guest' can only connect via localhost. Kalau Anda menemui pesan itu, penyebabnya bukan kata sandi yang salah. Buat pengguna baru dengan kata sandi sendiri, beri izin pada vhost yang diperlukan, lalu hapus atau ganti kata sandi guest sebelum server tersentuh jaringan.

Mencoba RabbitMQ dalam Beberapa Menit

Cara tercepat berkenalan adalah menjalankannya lewat Docker, karena Anda tidak perlu memasang Erlang secara terpisah. Perintah berikut menyalakan RabbitMQ beserta antarmuka pengelolaannya:

docker run -it --rm --name rabbitmq -p 5672:5672 -p 15672:15672 rabbitmq:4-management

Akhiran -management pada nama image menandakan plugin antarmuka web sudah aktif, sehingga Anda tidak perlu mengaktifkannya manual. Opsi --rm menghapus container beserta seluruh datanya begitu dihentikan, yang justru diinginkan saat mencoba-coba. Setelah container berjalan, buka http://localhost:15672 lalu masuk dengan guest dan guest — dari localhost, pembatasan tadi tidak berlaku.

Untuk pemakaian sungguhan, RabbitMQ perlu berjalan terus-menerus sebagai layanan dan membuka portnya sendiri. Shared hosting tidak menyediakan keduanya, sehingga Anda membutuhkan VPS Indonesia atau server yang Anda kelola sendiri. Sebagai titik awal, satu node dengan 2 vCPU dan RAM 4 GB memadai untuk beban ringan sampai menengah. Soal versi, pilih seri 4.3 untuk pemasangan baru per Agustus 2026, karena hanya seri inilah yang masih menerima perbaikan gratis dari komunitas.

Pertanyaan yang Sering Muncul

Apakah RabbitMQ gratis? Ya. Kode server dan plugin intinya berlisensi MPL 2.0, tanpa batas jumlah pesan maupun node. Yang berbayar adalah dukungan komersial dan edisi Tanzu dari Broadcom, bukan perangkat lunaknya.

Apa kegunaan utama RabbitMQ? Menjalankan pekerjaan di luar alur permintaan pengguna dan menghubungkan layanan yang tidak perlu aktif bersamaan — pengiriman email, pemrosesan berkas, penerusan pesanan antar-layanan, serta meredam lonjakan trafik.

Apa beda Kafka dan RabbitMQ? RabbitMQ membagikan pekerjaan lalu menghapus pesannya setelah selesai. Kafka menyimpan pesan sebagai catatan berurutan selama masa retensi, sehingga banyak pembaca dapat mengulangnya dari posisi mana pun.

Versi mana yang sebaiknya dipakai? Rilis stabil terbaru adalah 4.3.4 yang terbit 23 Juli 2026. Dukungan komunitas untuk seri 4.2 berakhir 31 Juli 2026, sedangkan seri 3.13 sudah berakhir sejak 30 September 2024. Kalau Anda masih menjalankan seri 3.x, jadwalkan upgrade dan perhitungkan hilangnya mirroring classic queue.

Apakah RabbitMQ berlebihan untuk aplikasi kecil? Sering kali iya. Selama pekerjaan latar Anda hanya beberapa per menit dan tidak masalah kalau tertunda, penjadwal sederhana atau tabel pekerjaan di database sudah mencukupi.

Kesimpulan

RabbitMQ adalah message broker yang menerima pesan lewat exchange, mengarahkannya ke antrian berdasarkan binding, lalu menyerahkannya ke consumer yang mengonfirmasi penyelesaian dengan ack. Empat jenis exchange menentukan pola pengirimannya, sementara pilihan antara classic queue, quorum queue, dan stream menentukan seberapa kuat jaminan keandalannya.

Anda mulai membutuhkannya ketika ada pekerjaan lambat yang tidak layak ditunggu pengguna, ketika beberapa layanan perlu berbicara tanpa harus hidup bersamaan, atau ketika lonjakan trafik perlu diredam. Sebaliknya, aplikasi dengan sedikit pekerjaan latar belum memerlukan komponen tambahan ini. Kalau Anda memutuskan memakainya, mulai dari seri 4.3, pakai quorum queue untuk pekerjaan yang tidak boleh hilang, dan ganti kredensial guest sebelum server menyentuh jaringan.

Semoga artikel ini membantu.