Jika Anda butuh antrean pesan klasik dengan dukungan JMS penuh di ekosistem Java, mulailah dengan ActiveMQ Artemis. Jika aplikasi Anda ditulis dalam beragam bahasa dan butuh routing pesan yang fleksibel, RabbitMQ biasanya paling nyaman. Jika yang Anda kelola adalah aliran event bervolume besar yang perlu disimpan lama dan bisa dibaca ulang, pilih Kafka. Ketiganya sama-sama disebut “message broker” dalam percakapan sehari-hari, tetapi model kerjanya berbeda, dan perbedaan itulah yang menentukan pilihan.
Dua model besar: antrean dan log
ActiveMQ Artemis dan RabbitMQ termasuk broker berbasis antrean. Pesan disimpan sampai consumer mengambil dan mengakuinya, lalu dihapus. Broker aktif mengatur siapa mendapat pesan apa, melacak pengiriman ulang, dan memindahkan pesan gagal ke dead letter queue.
Kafka bekerja sebagai log terdistribusi. Pesan (Kafka menyebutnya record) ditambahkan ke ujung log dan disimpan sesuai kebijakan retensi, misalnya beberapa hari atau sampai ukuran tertentu, terlepas dari sudah dibaca atau belum. Consumer sendiri yang mencatat sampai mana ia membaca, yang disebut offset. Karena itu satu data bisa dibaca banyak kelompok consumer, dan Anda bisa memutar ulang dari titik lama.
ActiveMQ Artemis
Artemis adalah broker generasi baru dari proyek Apache ActiveMQ, ditulis di Java. Ia mendukung JMS dan Jakarta Messaging secara penuh, plus protokol lain seperti AMQP, MQTT, STOMP, dan OpenWire (protokol ActiveMQ “Classic”). Konsep dasarnya adalah address sebagai tujuan pengiriman dan queue yang terikat ke address. Routing anycast berperilaku seperti queue JMS, sedangkan multicast seperti topic.
Kelebihannya: cocok dengan aplikasi Jakarta EE dan Spring yang sudah memakai API JMS, serta punya fitur matang seperti redelivery delay, dead letter address, message grouping, dan paging ke disk saat memori penuh. Beberapa server aplikasi, misalnya WildFly, menyertakan Artemis sebagai broker bawaan.
RabbitMQ
RabbitMQ ditulis dalam Erlang dengan protokol utama AMQP 0-9-1, dan mendukung protokol lain lewat plugin. Modelnya: producer mengirim ke exchange, lalu exchange meneruskan ke satu atau beberapa queue berdasarkan aturan binding. Jenis exchange yang umum: direct (cocok persis dengan routing key), topic (pola dengan wildcard), fanout (ke semua queue yang terikat), dan headers.
Kelebihannya: library klien tersedia untuk hampir semua bahasa, management UI-nya ramah pemula, dan routing lewat exchange membuat pola “satu event ke banyak layanan” mudah disusun. RabbitMQ juga punya quorum queue untuk replikasi yang lebih aman serta fitur stream untuk kebutuhan mirip log. Developer Java biasanya memakai klien Java resmi atau Spring AMQP; klien JMS untuk RabbitMQ tersedia, tetapi bukan jalur utamanya.
Apache Kafka
Kafka menyimpan data dalam topic yang dibagi menjadi beberapa partition. Urutan dijamin di dalam satu partition, dan record dengan kunci yang sama selalu masuk ke partition yang sama. Consumer bergabung dalam consumer group; setiap partition dibaca oleh satu anggota grup, sehingga paralelisme dibatasi jumlah partition. Grup lain bisa membaca topic yang sama secara terpisah dengan offset sendiri.
Kelebihannya: throughput tinggi, retensi panjang, kemampuan replay, dan ekosistem besar seperti Kafka Connect untuk menghubungkan database dan sistem lain serta Kafka Streams untuk pemrosesan aliran data. Versi baru Kafka bisa berjalan dalam mode KRaft tanpa ZooKeeper, sehingga operasionalnya lebih sederhana dibanding dulu. Namun Kafka tidak memakai API JMS, tidak punya dead letter queue bawaan, dan secara tradisional kurang pas untuk pola antrean tugas yang butuh pengakuan per pesan.
Tabel perbandingan
| Aspek | ActiveMQ Artemis | RabbitMQ | Kafka |
|---|---|---|---|
| Model | Antrean (anycast dan multicast) | Antrean dengan exchange | Log terdistribusi |
| API atau protokol utama | JMS/Jakarta Messaging, AMQP, MQTT, STOMP, OpenWire | AMQP 0-9-1, plus plugin | Protokol Kafka sendiri |
| Routing | Address, queue, dan selector | Exchange direct, topic, fanout, headers | Topic dan partition berdasarkan kunci |
| Nasib pesan setelah dibaca | Dihapus setelah diakui | Dihapus setelah diakui (kecuali stream) | Tetap ada sampai masa retensi habis |
| Urutan | Per queue, bisa dengan message grouping | Per queue | Per partition |
| Replay data lama | Tidak secara bawaan | Lewat fitur stream | Ya, dengan mengatur offset |
| Dead letter | Bawaan (dead letter address) | Bawaan (dead letter exchange) | Dibangun di aplikasi |
| Paling cocok untuk | Aplikasi Java/Jakarta EE, integrasi enterprise | Layanan multibahasa, antrean tugas, routing fleksibel | Event streaming, analitik, sinkronisasi data volume besar |
Cara memilih: pertanyaan yang perlu dijawab
- Apakah kode Anda sudah memakai JMS? Jika ya, Artemis adalah jalur dengan perubahan paling sedikit.
- Apakah pesan perlu dibaca ulang di kemudian hari? Misalnya membangun ulang laporan dari event bulan lalu. Jika ya, Kafka unggul.
- Apakah setiap pesan adalah tugas yang harus diselesaikan satu pekerja, lengkap dengan retry dan dead letter? Artemis atau RabbitMQ lebih alami.
- Berapa bahasa pemrograman yang terlibat? Jika banyak, RabbitMQ atau Kafka dengan klien multibahasa lebih praktis. Artemis juga bisa diakses lewat AMQP atau STOMP.
- Siapa yang akan mengoperasikan? Klaster Kafka dengan banyak partition butuh pemahaman operasional lebih. Untuk tim kecil, layanan terkelola dari penyedia cloud bisa menjadi pertimbangan.
Contoh kasus
Toko online skala kecil sampai menengah yang butuh antrean untuk email, pembuatan label pengiriman, dan sinkronisasi stok akan terlayani dengan baik oleh RabbitMQ atau Artemis. Fitur retry dan dead letter bawaan sangat membantu; cara menanganinya saya jelaskan di artikel tentang dead letter queue dan redelivery. Ketika toko itu tumbuh dan tim data ingin setiap klik, perubahan stok, dan status pesanan mengalir ke gudang data untuk analisis, Kafka mulai masuk akal sebagai tulang punggung event, sementara antrean tugas tetap boleh di broker yang lama.
Memakai dua jenis broker sekaligus bukan hal aneh. Yang penting, setiap jenis pesan punya rumah yang jelas dan tim tahu alasannya.
Kesalahan pemula yang sering terlihat
- Memilih Kafka karena populer, lalu menulis sendiri retry, dead letter, dan penjadwalan ulang yang di broker antrean sudah tersedia.
- Memakai RabbitMQ sebagai penyimpanan jangka panjang dengan membiarkan jutaan pesan menumpuk di queue klasik. Queue yang sangat panjang membebani memori dan memperlambat broker.
- Mengira semua broker menjamin urutan global. Urutan hanya berlaku per queue atau per partition, dan bisa rusak oleh pengiriman ulang atau consumer paralel.
Bila Anda baru mulai dan belum yakin kebutuhan ke depan, pilih broker yang paling mudah dijalankan dan dipantau oleh tim Anda saat ini. Untuk memahami fondasi API yang dipakai Artemis, baca juga pengertian JMS dan komponennya.
