Belajar RabbitMQ
Belajar RabbitMQ untuk Event-Driven Architecture (EDA)
Last updated
Belajar RabbitMQ untuk Event-Driven Architecture (EDA)
Last updated
Ketika kita mengembangkan sebuah aplikasi, sering kali aplikasi tersebut perlu berkomunikasi dengan aplikasi lain. Contoh paling sederhana adalah komunikasi antara aplikasi yang kita buat dengan database. Proses komunikasi ini dikenal sebagai Remote Procedure Call (RPC). Salah satu protokol RPC yang populer saat ini adalah RESTful API. Keunggulan utama dari RPC adalah kemampuannya untuk memungkinkan komunikasi secara synchronous dan real-time.
Misalnya kita membangun sistem toko online yang terdiri dari beberapa aplikasi, seperti product, promo, shopping cart, order, logistic, dan payment. Ketika pelanggan melakukan pembelian, semua barang yang dipilih akan disimpan di shopping cart. Untuk menampilkan informasi produk dan promo yang sedang berlaku, shopping cart perlu berkomunikasi dengan aplikasi product dan promo. Setelah pelanggan memutuskan untuk membeli barang di shopping cart, aplikasi tersebut akan mengirimkan data produk ke aplikasi order. Selanjutnya, data ini akan diproses oleh aplikasi logistic untuk menghitung ongkos kirim, dan oleh aplikasi payment untuk menyelesaikan pembayaran.
Dalam kasus ini, misalnya kita ingin menambahkan fitur untuk mendeteksi penipuan dengan menambahkan aplikasi fraud detection. Proses pengecekan penipuan akan dilakukan saat sebuah order dibuat, sehingga jika terdeteksi adanya kecurangan, order tersebut dapat dibatalkan secara otomatis. Untuk mendukung ini, data order perlu dikirim ke aplikasi fraud detection. Namun, semakin banyak interaksi antar aplikasi yang terjadi, kompleksitas sistem akan meningkat. Pengirim data juga harus menambahkan mekanisme untuk mengirim data ke aplikasi lain, yang dapat membuat sistem menjadi semakin rumit untuk dikelola.
RPC adalah mekanisme komunikasi di mana pengirim secara langsung menentukan penerima data. Berbeda dengan RPC, ada mekanisme komunikasi lain yang dikenal sebagai Messaging atau Publish/Subscribe. Dalam mekanisme Messaging, pengirim tidak menentukan siapa penerima data. Sebaliknya, pengirim hanya mengirim data ke perantara yang disebut Message Broker. Selanjutnya, semua penerima data akan mengambil data langsung dari Message Broker. Dengan cara ini, jika ada penerima data baru, pengirim tidak perlu mengetahuinya, karena tugas pengirim hanyalah mengirimkan data ke Message Broker, yang kemudian mengelola distribusi datanya.
Dengan menggunakan komunikasi Messaging, pengirim tidak perlu memahami atau menangani kompleksitas proses yang dilakukan oleh penerima data. Bahkan jika jumlah penerima data berubah, pengirim tidak perlu mengetahuinya, karena tugas pengirim hanya mengirimkan data ke Message Broker, yang akan mengelola distribusi data ke semua penerima secara otomatis.
Salah satu kekurangan komunikasi Messaging adalah kemampuannya yang tidak realtime seperti RPC, sehingga bisa terjadi delay (jeda waktu) antara saat pengirim mengirim data hingga data tersebut diterima oleh penerima. Hal ini dapat menyebabkan data menjadi tidak konsisten selama proses pengiriman berlangsung. Selain itu, ketika terjadi kegagalan dalam penerimaan atau pemrosesan data oleh penerima, pengirim tidak akan langsung mengetahuinya. Oleh karena itu, penerima harus memiliki mekanisme untuk menangani kegagalan, seperti fitur retry (mencoba ulang) atau kemampuan untuk memberi tahu pengirim bahwa proses data telah gagal, agar langkah koreksi dapat dilakukan.
RabbitMQ merupakan aplikasi yang sangat ringan, sehingga tidak memerlukan banyak sumber daya hardware untuk dijalankan. Selain itu, RabbitMQ didukung oleh ekosistem yang besar, dengan kompatibilitas luas terhadap berbagai teknologi dan bahasa pemrograman seperti Java, .NET, Ruby, C/C++, PHP, Golang, Scala, Python, dan lainnya. RabbitMQ juga menawarkan keandalan tinggi (High Availability) dengan kemampuan berjalan dalam cluster, sehingga meminimalkan risiko downtime. Bahkan, RabbitMQ mendukung penerapan lintas zona atau wilayah data center, memastikan ketersediaan layanan yang optimal di berbagai lokasi.
Jalankan perintah docker compose up -d dan pastikan container nya sudah running dengan cara jalankan perintah docker ps.
Saat pengirim data mengirimkan data ke RabbitMQ, data tersebut tidak langsung dikirimkan ke penerima, melainkan terlebih dahulu diterima oleh Exchange. Setelah data diterima di Exchange, Exchange akan menentukan ke mana data tersebut harus diteruskan, berdasarkan tipe Exchange yang digunakan. Setiap tipe Exchange memiliki aturan pengiriman yang berbeda, dan masing-masing tipe akan dibahas lebih lanjut dalam materi tersendiri.
Untuk membuat Exchange di RabbitMQ, kita bisa menggunakan Web Management pada bagian Exchanges. Saat membuat Exchange, ada beberapa parameter yang perlu ditentukan:
Name: Menentukan nama untuk Exchange yang akan dibuat.
Type: Menentukan tipe Exchange yang digunakan. Tipe ini akan menentukan bagaimana data dikirimkan ke Queue dan akan dibahas lebih lanjut pada materi khusus untuk setiap tipe Exchange.
Durability: Menentukan apakah Exchange akan tetap ada setelah RabbitMQ di-restart. Jika dipilih Durable, Exchange akan tetap ada setelah restart, sedangkan jika dipilih Transient, Exchange akan hilang setelah restart.
Auto Delete: Menentukan apakah Exchange akan otomatis dihapus ketika semua Queue yang terikat padanya (unbind) sudah tidak ada lagi.
Internal: Menandakan bahwa Exchange hanya digunakan untuk komunikasi internal di RabbitMQ dan tidak dapat diakses oleh Producer. Dengan kata lain, Exchange ini hanya digunakan dalam sistem RabbitMQ itu sendiri.
Alternate-Exchange: Menentukan Exchange alternatif yang akan menerima pesan jika pesan tidak berhasil dikirimkan ke Queue yang dituju. Fitur ini berguna untuk mengelola pesan yang gagal dalam proses pengiriman.
Queue (antrian) adalah tempat penyimpanan untuk data yang diterima dari Exchange. Exchange berfungsi sebagai gerbang untuk menerima data, kemudian meneruskan data tersebut ke Queue yang telah ditentukan. Jika kita membuat Exchange tanpa menghubungkannya dengan Queue, maka data yang diterima oleh Exchange akan hilang, karena Exchange tidak berfungsi untuk menyimpan data secara permanen, melainkan hanya sebagai perantara. Queue digunakan oleh Consumer (penerima data) untuk mengambil data yang telah dikirim oleh Exchange. Dengan cara ini, Queue memastikan bahwa data dapat disimpan sementara menunggu untuk diproses oleh Consumer.
Untuk membuat Queue di RabbitMQ, prosesnya sangat mudah dan bisa dilakukan melalui halaman Queue di Web Management. Saat membuat Queue, ada beberapa parameter yang perlu ditentukan:
Virtual Host: Menentukan Virtual Host tempat Queue tersebut akan ditempatkan. Virtual Host akan dibahas lebih lanjut pada materi tersendiri.
Type: Menentukan tipe Queue yang digunakan. Saat ini, disarankan untuk menggunakan Quorum karena lebih andal dan cocok untuk aplikasi yang membutuhkan konsistensi data. Classic Queue sudah tidak disarankan lagi karena memiliki keterbatasan, sementara Stream digunakan untuk kebutuhan Data Streaming yang memerlukan penanganan data dalam jumlah besar dan berkelanjutan.
Name: Menentukan nama untuk Queue yang akan dibuat.
Arguments: Memberikan informasi tambahan untuk mengkonfigurasi Queue, seperti pengaturan terkait kedaluwarsa pesan atau batasan ukuran.
Di RabbitMQ, Arguments digunakan untuk mengonfigurasi berbagai aspek dari Queue, Exchange, atau Binding. Argument-argument ini memungkinkan kita untuk menyesuaikan perilaku dan fungsionalitas dari berbagai komponen RabbitMQ sesuai kebutuhan aplikasi. Berikut adalah beberapa argument umum yang sering digunakan di RabbitMQ beserta contoh dan penjelasannya:
Deskripsi: Menentukan Exchange yang akan menerima pesan yang gagal diproses atau yang telah kedaluwarsa di Queue.
Contoh: Jika sebuah pesan tidak dapat diterima oleh konsumen (consumer), atau ada masalah dengan pengiriman, pesan tersebut bisa dipindahkan ke Dead Letter Exchange.
Gunanya: Berguna untuk menangani pesan yang tidak dapat diproses, agar tidak hilang dan bisa dianalisis atau diproses lebih lanjut.
Contoh Penggunaan:
Deskripsi: Menentukan Routing Key untuk pesan yang dikirim ke Dead Letter Exchange.
Contoh: Ketika sebuah pesan dipindahkan ke Dead Letter Exchange, kita bisa menentukan Routing Key tertentu untuk memudahkan pengelompokan pesan.
Gunanya: Membantu dalam pengelolaan pesan yang gagal diproses, sehingga bisa dibedakan dari pesan lainnya.
Contoh Penggunaan:
Deskripsi: Menentukan waktu TTL (Time-To-Live) untuk pesan dalam Queue. Setelah waktu yang ditentukan habis, pesan akan dihapus secara otomatis.
Contoh: Jika sebuah pesan tidak diproses dalam waktu yang ditentukan, maka pesan tersebut akan dihapus.
Gunanya: Menghindari pesan yang tidak pernah diproses untuk tetap berada dalam antrian, mengurangi penumpukan data yang tidak relevan.
Contoh Penggunaan:
Deskripsi: Menentukan waktu kedaluwarsa untuk Queue itu sendiri. Setelah waktu yang ditentukan, Queue akan otomatis dihapus jika tidak ada yang mengaksesnya.
Contoh: Jika tidak ada pesan atau interaksi dengan Queue dalam waktu tertentu, Queue akan dihapus secara otomatis.
Gunanya: Membantu mengelola Queue yang hanya diperlukan untuk periode tertentu.
Contoh Penggunaan:
Deskripsi: Menentukan batas maksimal jumlah pesan yang dapat disimpan dalam Queue. Jika jumlah pesan melebihi batas ini, pesan yang paling lama akan dihapus.
Contoh: Mengatur batasan jumlah pesan di dalam Queue untuk menghindari penumpukan data yang tidak diperlukan.
Gunanya: Berguna dalam aplikasi yang memerlukan pemrosesan data dengan volume besar dan ingin menghindari penumpukan pesan.
Contoh Penggunaan:
Deskripsi: Menentukan jumlah prioritas yang bisa diberikan pada pesan dalam Queue. Nilai ini menentukan seberapa banyak level prioritas yang dapat diterapkan pada pesan yang masuk ke dalam Queue.
Contoh: Jika aplikasi membutuhkan pengurutan pesan berdasarkan prioritas, kita bisa menggunakan argument ini untuk mengatur level prioritas pesan.
Gunanya: Mengelola antrian pesan berdasarkan tingkat urgensinya.
Contoh Penggunaan:
Deskripsi: Menentukan mode Queue. Bisa diset ke default, lazy, atau classic.
default: Queue berjalan dengan cara standar.
lazy: Mengurangi penggunaan memori dengan menyimpan pesan di disk, bukan di RAM.
classic: Mode standar untuk Queue, dengan pesan disimpan di memori.
Contoh: Mengatur mode Queue berdasarkan kebutuhan performa, misalnya jika memori terbatas, gunakan lazy mode.
Gunanya: Mengoptimalkan penggunaan memori dan disk berdasarkan kebutuhan aplikasi.
Contoh Penggunaan:
Deskripsi: Menentukan apakah Queue harus bersifat durable, yang berarti Queue tetap ada setelah RabbitMQ di-restart.
Contoh: Menggunakan argument ini untuk memastikan Queue tetap bertahan setelah RabbitMQ di-restart, sangat berguna untuk aplikasi yang membutuhkan ketahanan data.
Gunanya: Menjamin ketersediaan Queue meskipun terjadi restart pada RabbitMQ.
Contoh Penggunaan:
Deskripsi: Menentukan di mana master queue akan berada dalam cluster RabbitMQ. Ini berguna ketika ada lebih dari satu node yang menangani Queue dalam cluster.
Contoh: Jika kita ingin master queue berada di node tertentu dalam cluster, kita bisa menggunakan argument ini.
Gunanya: Menyediakan pengaturan di mana Queue utama akan berada dalam cluster untuk distribusi beban yang lebih baik.
Contoh Penggunaan:
Binding adalah koneksi yang menghubungkan Exchange dengan Queue di RabbitMQ. Secara default, saat kita membuat Exchange dan Queue, keduanya tidak akan terhubung satu sama lain. Untuk itu, kita perlu melakukan Binding agar pesan yang diterima oleh Exchange dapat diteruskan ke Queue yang sesuai. Binding ini juga melibatkan penggunaan Routing Key untuk menentukan bagaimana pesan dipilih dan diteruskan dari Exchange ke Queue. Tanpa adanya Binding, pesan yang diterima oleh Exchange tidak akan bisa sampai ke Queue, sehingga tidak ada data yang bisa diproses oleh Consumer. Binding memungkinkan komunikasi yang efisien antara komponen-komponen ini dalam sistem RabbitMQ.
Di RabbitMQ, kita dapat melakukan Binding dari satu Exchange ke beberapa Queue, yang memungkinkan satu Exchange untuk mengirimkan pesan ke beberapa Queue sekaligus. Hal ini memudahkan pengelolaan alur pesan dalam aplikasi yang kompleks. Begitu juga sebaliknya, kita dapat melakukan Binding dari satu Queue ke beberapa Exchange, yang memungkinkan sebuah Queue untuk menerima pesan dari berbagai Exchange. Fleksibilitas ini memberikan kontrol lebih besar atas bagaimana pesan disalurkan dan diterima, memungkinkan arsitektur yang lebih dinamis dan efisien sesuai dengan kebutuhan aplikasi.
Sekarang kita akan coba binding exchange notification ke queue email, sms, dan whatsapp.
Routing Key adalah kunci yang digunakan untuk menentukan bagaimana pesan diteruskan dari Exchange ke Queue saat dilakukan Binding di RabbitMQ. Saat kita mengirim pesan ke Exchange, kita menyertakan Routing Key untuk memberi petunjuk kepada Exchange tentang ke mana pesan tersebut harus diarahkan. Kemudian, ketika melakukan Binding antara Exchange dan Queue, kita juga mendefinisikan Routing Key pada Binding tersebut.
Routing Key bekerja berbeda-beda tergantung pada tipe Exchange yang digunakan, dan ini mempengaruhi bagaimana pesan-pesan dikirimkan ke Queue yang terhubung.
Sebelumnya, kita sudah membuat Exchange dengan tipe Direct. Direct Exchange adalah tipe Exchange yang merutekan pesan yang diterima ke Queue yang tepat berdasarkan kecocokan Routing Key yang telah ditentukan saat proses Binding. Dalam sistem ini, setiap pesan yang dikirim ke Exchange disertai dengan Routing Key yang akan dicocokkan dengan Binding Key pada Queue-Queue yang terhubung. Jika terdapat Routing Key yang tidak cocok dengan Binding Key di Queue manapun, maka pesan tersebut akan diarahkan ke Alternate-Exchange yang telah ditentukan. Jika tidak ada Alternate-Exchange yang tersedia, maka pesan tersebut akan hilang dan tidak akan sampai ke penerima. Keberadaan Alternate-Exchange ini memberikan cara untuk menangani pesan yang tidak dapat diproses, memberikan tingkat fleksibilitas dan kontrol yang lebih besar dalam pengelolaan aliran data di RabbitMQ.
Saat melakukan perutean menggunakan Direct Exchange, tidak ada batasan untuk melakukan Binding ke Queue yang sama, bahkan jika menggunakan Routing Key yang berbeda. Misalnya, kita bisa membuat Queue baru bernama all_notification, kemudian melakukan Binding untuk beberapa Routing Key seperti email, sms, dan whatsapp. Hal ini diperbolehkan, karena Direct Exchange akan merutekan pesan ke Queue berdasarkan kecocokan antara Routing Key yang dikirim dengan Binding Key yang ada pada Queue. Dengan demikian, satu Queue dapat menerima pesan dari berbagai Routing Key, memberikan fleksibilitas dalam pengelolaan dan pengiriman pesan.
Seperti yang sudah dibahas sebelumnya, untuk mengirim data atau publish message, proses ini dilakukan ke Exchange. RabbitMQ menggunakan format standar untuk pesan yang dikirim. Routing Key adalah informasi yang digunakan pada Direct Exchange untuk merutekan pesan ke Queue yang sesuai. Selain itu, ada Headers, yang memungkinkan penambahan informasi dalam bentuk pasangan key-value yang dapat disesuaikan sesuai kebutuhan. Properties juga mirip dengan Headers, namun memiliki key yang sudah baku dan ditentukan oleh sistem. Terakhir, Payload adalah data yang sebenarnya dikirim oleh Producer, yang berisi informasi utama yang ingin disampaikan ke Queue. Dengan struktur ini, RabbitMQ memastikan pengiriman pesan yang fleksibel dan terorganisir dengan baik.
Untuk melakukan publish message, kita bisa menggunakan Web Management, Silahkan buka Exchange yang ingin dikirimkan data, pada bagian bawah terdapat form untuk Publish Message.
Membaca data dari Queue disebut dengan Consume Message. Setelah pesan berhasil di-consume, pesan tersebut otomatis akan hilang dari Queue. Queue di RabbitMQ berfungsi sebagai struktur data berbentuk antrian, di mana prinsipnya mengikuti aturan FIFO (First In, First Out), yaitu pesan yang pertama kali masuk ke dalam Queue akan menjadi pesan pertama yang diproses atau di-consume terlebih dahulu. Hal ini memastikan bahwa alur pengiriman pesan tetap teratur dan efisien, dengan memastikan bahwa pesan diproses dalam urutan kedatangannya, memberi prioritas pada pesan yang lebih dulu masuk ke dalam Queue.
Untuk melakukan Consume Message, kita bisa menggunakan Web Management di RabbitMQ. Caranya, buka Queue yang ingin kita baca pesannya, kemudian pilih menu Get Messages. Cobalah untuk Consume Message dari Queue seperti email, sms, dan whatsapp. Pastikan untuk menggunakan Automatic Ack (Acknowledge), yang berarti data akan secara otomatis diakui sebagai sukses dibaca. Setelah pesan di-acknowledge, pesan tersebut akan hilang secara otomatis dari Queue, menandakan bahwa proses pembacaan dan pengolahan data telah berhasil dilakukan.
Fanout Exchange adalah tipe Exchange yang akan selalu merutekan setiap data yang diterima ke seluruh Queue yang terhubung dengannya. Artinya, setiap data yang kita kirim ke Exchange ini akan diteruskan ke semua Queue yang telah ter-bind dengan Fanout Exchange. Fanout Exchange mirip dengan Broadcast, di mana setiap Queue akan menerima data yang sama, tanpa memperhatikan Routing Key. Sebagai latihan, kita dapat membuat Exchange dengan tipe fanout yang dinamakan announcement. Selanjutnya, buat dua Queue, yaitu customers dan sellers, lalu lakukan Binding kedua Queue tersebut ke Exchange announcement. Setelah itu, Publish Message ke Exchange announcement, dan pastikan semua pesan diterima oleh kedua Queue, yaitu customers dan sellers. Dengan demikian, semua Queue yang terhubung ke Fanout Exchange akan menerima pesan yang sama secara bersamaan.
Topic Exchange merupakan jenis Exchange yang mirip dengan Direct Exchange, di mana Exchange merutekan pesan ke Queue sesuai dengan Routing Key yang diterima. Namun, pada Topic Exchange, Routing Key menggunakan kata-kata yang dipisahkan oleh tanda titik, seperti customers.event.update, customers.event.new, atau customers.event.delete. Ketika melakukan Binding dari Queue ke Topic Exchange, kita bisa menggunakan dua wildcard, yaitu:
* (star), yang mewakili satu kata.
# (hash), yang mewakili nol atau lebih kata.
Sebagai contoh, customers.event.* akan cocok dengan Routing Key seperti customers.event.new, customers.event.update, atau customers.event.delete. Sedangkan customers.# akan cocok dengan Routing Key seperti customers.a, customers.a.b, atau customers.a.b.c. *.event.* akan mencocokkan Routing Key seperti customers.event.a dan sellers.event.b, sementara # akan mencocokkan semua Routing Key yang ada.
Sebagai latihan, kita dapat membuat Topic Exchange dengan nama events, kemudian buat tiga Queue: all_events, all_messages, dan all_customer_messages. Untuk all_events, lakukan Binding dengan *.events.* ke Exchange events. Untuk all_messages, lakukan Binding dengan # ke Exchange events. Sedangkan untuk all_customer_messages, lakukan Binding dengan customers.events.* ke Exchange events. Setelah itu, Publish Message ke Exchange events, dan pastikan pesan-pesan tersebut masuk ke Queue yang sesuai dengan Routing Key-nya, seperti yang telah ditentukan pada masing-masing Binding.
Header Exchange adalah jenis Exchange yang merutekan data ke Queue berdasarkan atribut Header pada pesan yang dikirim. Proses perutean ini dilakukan dengan mencocokkan Header pesan dengan atribut Binding yang telah didefinisikan pada Queue. Berbeda dengan Routing Key pada Direct atau Topic Exchange, perutean di Header Exchange sepenuhnya bergantung pada pasangan key-value di bagian Header pesan.
Sebagai latihan, kita dapat membuat Header Exchange dengan nama download, lalu membuat beberapa Queue dengan konfigurasi berikut:
Queue download_report_pdf, dengan Binding: type=report dan format=pdf.
Queue download_report_excel, dengan Binding: type=report dan format=excel.
Queue download_summary_pdf, dengan Binding: type=summary dan format=pdf.
Selanjutnya, lakukan Publish Message dengan berbagai kombinasi Header. Misalnya, kirim pesan dengan Header type=report dan format=pdf, dan pastikan pesan tersebut diterima di Queue download_report_pdf. Begitu pula untuk kombinasi lainnya, pastikan pesan masuk ke Queue yang sesuai dengan atribut Binding yang telah ditentukan.
Round-Robin Dispatching adalah salah satu keunggulan dalam menggunakan Queue, di mana kita dapat menjalankan lebih dari satu Consumer untuk memproses data secara bersamaan. Dengan kemampuan ini, beban pemrosesan data dalam Queue dapat dibagi di antara beberapa Consumer, memungkinkan pemrosesan data dilakukan secara paralel. Hal ini tidak hanya meningkatkan efisiensi, tetapi juga mempercepat waktu pemrosesan keseluruhan, terutama ketika terdapat volume data yang besar untuk diproses. RabbitMQ secara otomatis mendistribusikan pesan ke Consumer secara bergantian (round-robin), memastikan beban kerja dibagi secara merata di antara semua Consumer yang aktif.
RabbitMQ memiliki fitur yang disebut Virtual Host (vHost), yang berfungsi seperti mesin virtual untuk mengelola Exchange dan Queue secara terpisah. Dengan Virtual Host, kita dapat memisahkan konfigurasi Exchange dan Queue berdasarkan kebutuhan, sehingga tidak saling bertabrakan. Misalnya, jika RabbitMQ digunakan oleh banyak tim dalam suatu organisasi, setiap tim dapat memiliki Virtual Host masing-masing, sehingga Exchange dan Queue milik satu tim tidak akan berbenturan dengan tim lainnya. Secara default, setelah instalasi RabbitMQ, terdapat satu Virtual Host bernama / (slash), yang dapat digunakan langsung atau ditambahkan sesuai kebutuhan.
Untuk membuat Virtual Host, kita bisa menggunakan menu Admin --> Virtual Host. Setelah membuat Virtual Host, kita bisa menggunakan Virtual Host tersebut ketika membuat Exchange atau Queue
Policy adalah fitur di RabbitMQ yang memungkinkan kita menambahkan Arguments secara otomatis ke Exchange atau Queue tanpa harus melakukannya satu per satu secara manual. Dengan menggunakan Policy, pengelolaan konfigurasi menjadi lebih efisien, terutama ketika kita perlu mengatur banyak Exchange atau Queue dengan pengaturan yang seragam. Untuk membuat Policy, kita dapat menggunakan menu Admin -> Policies pada Web Management. Saat membuat Policy, ada beberapa informasi yang perlu ditentukan:
Name: Nama Policy untuk mempermudah identifikasi.
Pattern: Regular expression yang digunakan untuk memilih Exchange atau Queue yang ingin diterapkan Policy.
Priority: Menentukan prioritas jika ada lebih dari satu Policy yang berlaku untuk Exchange atau Queue yang sama, karena hanya satu Policy dengan prioritas tertinggi yang akan digunakan.
Definition: Arguments yang akan secara otomatis ditambahkan ke Exchange atau Queue yang terpilih berdasarkan Pattern.
Setelah Policy dibuat, kita dapat melihat Policy yang diterapkan pada Exchange atau Queue di bagian Features pada masing-masing komponen. Contohnya, kita dapat membuat beberapa Policy untuk mengatur durasi pesan, batasan kapasitas, atau pengaturan lainnya secara konsisten di berbagai Exchange atau Queue.
User Management di RabbitMQ adalah fitur yang memungkinkan kita mengelola akses pengguna terhadap RabbitMQ, baik untuk keperluan Publish Message maupun Consume Message. Saat pertama kali menginstal RabbitMQ beserta Plugin Web Management, terdapat default user bernama guest, yang bisa digunakan untuk masuk ke Web Management. Pengguna ini juga dapat digunakan untuk berbagai operasi awal di RabbitMQ.
Untuk melihat informasi pengguna yang ada, kita dapat membuka menu Admin -> Users di Web Management. Membuat pengguna baru sangat mudah, kita hanya perlu memberikan Username, Password, dan Tags. Tags berfungsi untuk menentukan hak akses pengguna terhadap fitur RabbitMQ, seperti berikut:
(none): Tidak memiliki akses ke Web Management.
management: Dapat mengakses Web Management, termasuk virtual host, exchange, queue, dan bindings yang diizinkan.
policymaker: Memiliki semua hak akses dari tag management, ditambah kemampuan mengelola policy.
monitoring: Memiliki semua hak akses dari tag management, serta dapat melihat semua informasi pada virtual host.
administrator: Memiliki hak penuh untuk melakukan semua tindakan di RabbitMQ.
Setelah membuat beberapa pengguna dengan tag yang berbeda, kita dapat mencoba login menggunakan akun tersebut untuk melihat perbedaan hak aksesnya. Misalnya, pengguna dengan tag administrator memiliki akses penuh, sedangkan pengguna dengan tag management hanya dapat mengakses virtual host dan komponennya yang diizinkan. Hal ini memastikan bahwa akses pengguna dapat diatur sesuai dengan kebutuhan dan tingkat keamanan yang diinginkan.
Permission di RabbitMQ adalah fitur yang memungkinkan kita mengatur hak akses pengguna terhadap Virtual Host dan komponennya. Secara default, ketika kita membuat pengguna baru, meskipun mereka dapat login ke Web Management, mereka tidak secara otomatis memiliki izin untuk mengakses Virtual Host mana pun. Oleh karena itu, kita harus menambahkan Permission agar pengguna dapat berinteraksi dengan Virtual Host tertentu.
Dalam menambahkan Permission, kita perlu menentukan regular expression untuk mengatur operasi yang diperbolehkan. Operasi ini dikelompokkan menjadi tiga kategori utama, sesuai dengan standar operasi AMQP:
Configure: Hak untuk membuat, menghapus, atau mengubah Exchange dan Queue.
Write: Hak untuk mengirim pesan (Publish Message) ke Exchange.
Read: Hak untuk membaca pesan (Consume Message) dari Queue.
Permission ini memberikan fleksibilitas dalam mengontrol akses pengguna terhadap komponen RabbitMQ, sehingga memastikan keamanan dan pengelolaan yang efisien. Dengan menetapkan izin yang spesifik, kita dapat memastikan bahwa setiap pengguna hanya memiliki akses yang diperlukan untuk tugas mereka.
Setelah memahami cara mengelola RabbitMQ melalui Web Management, langkah selanjutnya adalah mengintegrasikan RabbitMQ ke dalam aplikasi yang kita buat. Dalam implementasi nyata, proses Publish Message dan Consume Message biasanya dilakukan langsung dari aplikasi. Untuk mempermudah interaksi dengan RabbitMQ, kita dapat menggunakan Client Library, yaitu kumpulan kode atau pustaka yang disediakan untuk berkomunikasi dengan RabbitMQ.
Sekarang kita akan praktek menggunakan bahasa pemrograman Go dan library amqp untuk koneksi ke rabbitmq. Tujuan utamanya adalah membangun layanan berlangganan notifikasi yang memungkinkan pengguna untuk mendaftarkan alamat email mereka dan memilih jenis notifikasi yang ingin diterima, seperti email, SMS, atau WhatsApp. Layanan ini bertindak sebagai "publisher" yang mengirimkan informasi langganan ke RabbitMQ, di mana setiap tipe notifikasi memiliki queue tersendiri. RabbitMQ digunakan untuk mendistribusikan pesan-pesan ini secara andal, sementara exchange tipe "direct" memastikan pesan dikirim hanya ke queue yang sesuai berdasarkan jenis notifikasi yang dipilih oleh pengguna.
Dalam aplikasi ini, endpoint REST API tersedia di POST /subscribe untuk menerima permintaan dari pengguna. Pengguna cukup mengirimkan email atau nomor telepon dan jenis notifikasi yang diinginkan sebagai data JSON,. Sistem ini akan memvalidasi input pengguna, kemudian mempublikasikan pesan ke RabbitMQ exchange bernama notification_exchange dengan menggunakan routing key yang sesuai. Misalnya, pesan yang memiliki subscription type "email" akan diteruskan ke queue khusus untuk notifikasi email. Proyek ini dirancang agar fleksibel untuk diintegrasikan dengan layanan konsumen (consumer) seperti sistem notifikasi otomatis yang membaca pesan dari RabbitMQ dan mengirimkan notifikasi sesuai jenis yang diminta.
Kira-kira struktur projek golang nya akan seperti ini
Pertama kita akan implementasikan kodingan untuk subscription_service yang bertindak sebagai publisher
Kita perlu membuat file .env untuk menyimpan kredensial dari aplikasi
Dan kita buat file playground.http untuk menjalankan endpoint /subsribe
Sekarang jalankan publisher nya dengan menjalankan perintah go run main.go, dan coba jalankan endpoint tersebut. Buka dashboard queueu di rabbit mq dan kita akan bisa melihat total message yang masuk.
Selanjutnya, kita akan mengimplementasikan aplikasi subsrciber nya.
Untuk listen incoming message dari masing-masing queue, kita jalankan handler nya di goroutine yang berbeda kemudian tampilkan pesan nya ke standard output / console. Coba kirim lagi dari aplikasi publisher nya dan kita akan melihat message yang masuk.
Sekarang kita akan buat implementasi sistem yang sama menggunakan Java Spring Boot. Silahkan bootstraping projek springboot di website start.spring.io dan berikut dependency yang kita butuhkan:
Selanjutnya kita sesuaikan konfigurasnya terlebih dahulu
Kita buat konfigurasi yang berisi beans yang dibutuhkan untuk membuat exchange, queue, dan binding.
Terakhir kita buat controller untuk menangani request response.
Jalankan aplikasi springboot nya dan coba request menggunakan playground.http yang pernah kita buat pada project Go.
Selanjutnya kita akan buat aplikasi subsrciber nya.
Terakhir kita buat consumer/listener nya, di spring cukup mudah, kita cukup menggunakan anotasi RabbitListener
Jalankan consumer nya dan kita bisa lihat message yang dikirim tadi berhasil di consumer oleh notification service.
Mengapa Membutuhkan Delayed Job?
Dalam pengembangan aplikasi, sering kali ada kebutuhan untuk menjalankan tugas tertentu pada waktu yang telah ditentukan, misalnya:
Mengirim email pengingat kepada pengguna 24 jam sebelum acara berlangsung.
Memproses pembayaran otomatis setelah waktu tertentu.
Menunda eksekusi tugas berat agar tidak membebani server pada saat puncak aktivitas.
RabbitMQ dengan plugin Delayed Message Exchange menyediakan solusi untuk kebutuhan tersebut. Dengan menggunakan header x-delay, kita dapat menunda pengiriman pesan ke queue untuk dieksekusi pada waktu yang ditentukan.
Studi Kasus: Email Reminder Acara
Deskripsi: Sebuah sistem event management ingin mengirimkan email pengingat secara otomatis kepada peserta acara. Email dikirimkan x menit sebelum acara dimulai. Sistem akan menggunakan RabbitMQ sebagai message broker untuk menjadwalkan pengiriman email dengan waktu yang telah ditentukan.
Arsitektur:
Producer: Aplikasi yang mengirimkan data acara (nama peserta, email, dan waktu acara) ke RabbitMQ dengan header x-delay yang disesuaikan dengan waktu pengiriman email.
Consumer: Layanan yang membaca pesan dari queue dan memproses pengiriman email ketika waktu delay selesai.
Langkah Implementasi
Menginstall Plugin Delayed Message Exchange
Aktifkan plugin RabbitMQ untuk mendukung delayed jobs:
Membuat Exchange dan Queue
Buat exchange dengan tipe x-delayed-message menggunakan perintah berikut:
Kemudian buat queue untuk menampung pesan:
Lakukan binding antara exchange dan queue:
Atau jika menggunakan web management
Karena saya menggunakan Docker, maka saya custom image rabbitmq:4.0.5-management dengan menambahkan dan enable plugin rabbitmq_delayed_message_exchange.
Membuat Producder
Berikut adalah kode untuk producer:
Membuat Consumer
Berikut adalah contoh kode Consumer untuk membaca dan memproses pesan dari queue:
Di producer kita set event nya jam 7 malam, dan delayed message nya selama 15 menit sebelum event berlangsung, pada kodingan tersebut kita simulasikan waktu sekarang jam 18:44:30 supaya kita bisa menunggu 30 detik tepat 15 menit sebelum message di tersebut consume oleh consumer. Pada gambar di bawah kita bisa lihat di log console, producer mengirim jam 12:16:47 (waktu real) dan diterima jam 12:17:17 (waktu real) dengan total durasi tepat 30 detik : 13 + 17 = 30
Kita dapat membuat sistem yang andal untuk menjadwalkan tugas-tugas yang tertunda (delayed jobs).
Konsep producer dan consumer membuat sistem menjadi terdistribusi dan lebih fleksibel.
Implementasi header x-delay memberikan kontrol penuh atas waktu penundaan setiap pesan, memungkinkan berbagai skenario penggunaan seperti pengiriman email terjadwal, pemberitahuan waktu habis, atau pembaruan otomatis pada aplikasi.
Pendekatan ini relevan untuk berbagai jenis aplikasi yang membutuhkan efisiensi dan keandalan dalam pengelolaan penjadwalan tugas.
Pada tahun 2021, RabbitMQ merilis dukungan untuk fitur yang disebut Streams. RabbitMQ Streams dirancang untuk menyelesaikan masalah yang biasanya hanya dapat ditangani oleh Kafka, seperti:
Persistence: Pesan di Streams disimpan permanen hingga dihapus manual atau berdasarkan kebijakan retensi.
Non-Destructive Consumption: Konsumen bisa membaca ulang (Replayability) pesan tanpa menghapusnya.
Throughput Tinggi: Streams mampu menangani jutaan pesan per detik dengan Stream Plugin.
Beberapa konsumer dapat membaca dari satu stream tanpa perlu membuat antrean (queue) baru.
Stream di RabbitMQ dapat dipahami sebagai log yang hanya dapat ditambahkan (append-only log). Setiap event yang dipublikasikan ke Stream akan ditambahkan ke log tanpa bisa dimodifikasi atau dihapus. Event ini disimpan secara persisten dengan cara menuliskannya ke sistem file.
Setiap event yang ada di Stream memiliki dua metadata penting:
Index: Menunjukkan urutan event dalam log, yang berfungsi sebagai pengenal unik.
Timestamp: Waktu ketika event ditambahkan ke Stream.
Secara sederhana, Stream dapat dianggap sebagai antrean (Queue) yang diperluas dengan kemampuan untuk menyimpan pesan secara permanen. Walaupun penjelasan ini sangat disederhanakan, konsep tersebut membantu memahami tujuan dari fitur ini.
RabbitMQ Streams menggunakan protokol AMQP 0.9.1, sehingga dapat digunakan dengan mudah bersama integrasi RabbitMQ yang sudah ada. Untuk detail fitur lebih mendalam, Kamu dapat merujuk pada dokumentasi resmi RabbitMQ.
Terkait Streams, RabbitMQ memiliki dua komponen utama yang perlu dipahami:
Stream Core Komponen inti ini menambahkan kemampuan dasar RabbitMQ untuk menangani Streams. Mendukung protokol AMQP 0.9.1 dan dapat digunakan langsung tanpa konfigurasi tambahan.
Stream Plugin Plugin ini memperluas fungsionalitas Streams dengan mendukung protokol AMQP 1.0 yang berbasis biner. Plugin ini juga menambahkan fitur-fitur seperti Super Streams untuk throughput tinggi dan lingkungan dengan latensi rendah.
Untuk memulai, kita akan memanfaatkan Stream Core dengan membuat antrean (Queue) reguler terlebih dahulu. Setelah itu, kita akan melihat bagaimana cara meningkatkan antrean tersebut menjadi Stream. Proses ini dimulai dengan menyiapkan proyek yang terdiri dari dua komponen utama: Producer untuk membuat antrean dan mengirim pesan, serta Consumer untuk membaca pesan.
Membuat Producer untuk Mengirim Pesan
Berikut adalah kode sederhana di producer/main.go untuk membuat Producer yang akan mendeklarasikan antrean bernama events dan mengirim 1000 pesan:
Meningkatkan Antrean Menjadi Stream
Seperti yang disebutkan sebelumnya, RabbitMQ Stream mudah digunakan karena Anda dapat memanfaatkan kode yang sama untuk membuat Stream dengan sedikit penyesuaian. Anda hanya perlu menambahkan parameter x-queue-type pada amqp.Table{} untuk mendeklarasikan Stream.
Jika Anda mencoba menjalankan kode ini tanpa menghapus antrean sebelumnya, Anda akan mendapatkan kesalahan berikut:
Menghapus Antrean Lama
Untuk menghapus antrean, Anda dapat menggunakan Admin Dashboard RabbitMQ atau perintah CLI seperti berikut:
Setelah antrean dihapus, jalankan kembali program Go Anda. Kali ini antrean events akan terdaftar sebagai Stream.
Retention di Stream
Penting untuk memahami berbagai parameter dan pengaturan, khususnya yang berkaitan dengan retensi data. Secara default, sebuah stream akan menyimpan data hingga ruang penyimpanan disk habis, kecuali kita menerapkan kebijakan retensi tertentu. RabbitMQ memungkinkan kita untuk mengonfigurasi kebijakan retensi berbasis waktu atau ukuran agar data yang disimpan dalam Stream dapat dikelola dengan lebih efisien.
Parameter Retensi Penting dalam RabbitMQ Streams
x-stream-max-segment-size-bytes Parameter ini menentukan ukuran maksimum untuk setiap file “Segment”. Dalam Stream, data disimpan di disk dalam bentuk log file, dan ketika file log mencapai ukuran tertentu, sistem akan membuat file segment baru. Dengan mengatur parameter ini, kita dapat mengontrol ukuran file segment yang dihasilkan.
x-max-length-bytes Parameter ini mengatur panjang maksimum data yang dapat disimpan dalam Stream. Jika batas ini tercapai, RabbitMQ akan mulai menghapus file segment yang lebih lama untuk membuat ruang bagi data baru. Kebijakan ini dikenal sebagai retensi berbasis ukuran.
x-max-age Parameter ini menentukan usia maksimum data sebelum dihapus dari log Stream. Satuan waktu yang valid meliputi tahun (Y), bulan (M), hari (D), jam (h), menit (m), dan detik (s). Sebagai contoh, dengan mengatur nilai "10s", data yang berusia lebih dari 10 detik akan dihapus. Namun, penting untuk diingat bahwa penghapusan hanya terjadi setelah file segment penuh dan diganti dengan segment baru.
Mengapa Retensi Perlu Dikombinasikan dengan Segment Size?
Retensi dalam RabbitMQ Streams hanya akan dipicu ketika file segment penuh dan diganti. Oleh karena itu, penting untuk mengatur x-stream-max-segment-size-bytes agar retensi berbasis waktu (x-max-age) dan ukuran (x-max-length-bytes) dapat berfungsi sesuai harapan. Misalnya, jika kita mengatur retensi waktu menjadi 10 detik, data lama tidak akan langsung dihapus, melainkan setelah file segment saat ini selesai digunakan.
Untuk memahami pengaturan ini, mari kita mencoba mengonfigurasi ukuran segment dan panjang maksimal Stream.
Langkah 1: Menghapus Stream Lama
Kita mulai dengan menghapus Stream lama menggunakan perintah berikut:
Langkah 2: Mengonfigurasi Pengaturan Stream
Perbarui file main.go di producer untuk mengatur parameter retensi dalam objek amqp.Table:
Pada contoh ini, kita mengatur ukuran segment menjadi 0,03 MB dan panjang maksimum Stream menjadi 0,15 MB. Pengaturan ini mempermudah pengujian dan memonitor hasilnya.
Jalankan producer untuk membuat Stream baru dan tambahkan 1001 event. Kemudian, masuk ke dalam container Docker untuk melihat file segment yang dibuat oleh RabbitMQ:
Hasilnya akan menunjukkan folder dengan nama Stream dan file segment di dalamnya. File-file ini mencerminkan data event yang disimpan sebagai log. Misalnya:
Ukuran total segment ini akan mendekati batas maksimum 0,15 MB.
Jalankan kembali producer untuk menambahkan 1001 event baru. Kali ini, jumlah data akan melampaui batas retensi 0,15 MB, dan RabbitMQ akan mulai menghapus segment lama untuk memberikan ruang bagi data baru. Hasil ini dapat diverifikasi dengan memeriksa ulang folder segment menggunakan perintah ls sebelumnya.
Setelah memiliki Producer dan Stream, langkah berikutnya adalah membuat Consumer untuk membaca data dari Stream. Proses ini cukup sederhana karena konsumsi Stream hampir mirip dengan konsumsi Queue biasa. Namun, ada beberapa pengaturan penting yang perlu diperhatikan.
Pengaturan Penting dalam Konsumsi Stream
Prefetch Count Pengaturan ini wajib diatur, karena jika tidak, kode kita akan gagal berjalan. Prefetch count menentukan jumlah pesan yang dikirim oleh server sebelum menunggu konfirmasi (acknowledgment) dari consumer.
Auto Acknowledge (Auto Ack)
Pengaturan Auto Ack harus diset ke false. Stream tidak mendukung Auto Ack, sehingga pengaturan ini wajib dinonaktifkan agar consumer dapat berfungsi dengan baik.
Berikut adalah kode sederhana untuk menghubungkan aplikasi ke Stream dan mulai membaca data.
Mengatasi Keanehan saat Konsumsi Stream
Ketika Anda menjalankan kode di atas, mungkin terlihat bahwa tidak ada pesan yang dicetak meskipun Stream telah berisi pesan. Hal ini terjadi karena Stream secara default hanya mendengarkan pesan baru yang masuk.
Untuk mengatasi ini, jalankan kembali Producer, dan Consumer akan mulai mencetak pesan. Contoh output:
Memahami x-stream-offset
x-stream-offset adalah konfigurasi penting yang memungkinkan kita menentukan dari mana Consumer harus mulai membaca pesan di Stream. Opsi yang tersedia:
next (default): Mulai membaca dari pesan baru yang masuk.
first: Membaca dari pesan pertama yang tersedia.
last: Membaca dari pesan terbaru.
offset: Mulai membaca dari indeks pesan tertentu.
timestamp: Mulai membaca dari pesan berdasarkan waktu POSIX tertentu.
interval: Mulai membaca dari waktu tertentu sebelum waktu saat ini, misalnya "1h" untuk satu jam yang lalu.
Contoh Penggunaan x-stream-offset
Membaca dari indeks tertentu Jika ingin membaca pesan mulai dari indeks 2000, gunakan pengaturan berikut:
Dengan pengaturan ini, pesan mulai dari indeks ke-2000 akan dibaca.
Membaca pesan terbaru
Gunakan pengaturan last untuk membaca pesan terbaru:
Membaca semua pesan sejak awal
Untuk membaca seluruh pesan di Stream, gunakan pengaturan first:
Membaca pesan berdasarkan waktu Jika ingin membaca pesan dari satu jam yang lalu, gunakan pengaturan interval:
Catatan Penting
Kode di atas menggunakan loop untuk membaca pesan secara terus-menerus. Semua pengaturan x-stream-offset hanya menentukan titik awal konsumsi. Setelah itu, Consumer akan terus membaca pesan baru yang masuk ke Stream.
Pastikan selalu mengelola koneksi dan channel dengan baik untuk menghindari kebocoran sumber daya.
RabbitMQ Stream Plugin
RabbitMQ Stream Plugin adalah fitur yang memungkinkan RabbitMQ untuk memanfaatkan protokol biner baru dalam mengelola stream. Ini berbeda dari Streams Core, yang menggunakan protokol AMQP 0.9.1. Penggunaan protokol biner ini meningkatkan performa RabbitMQ secara signifikan.
Performa Lebih Tinggi: Protokol biner yang digunakan oleh Stream Plugin lebih efisien dibandingkan protokol AMQP 0.9.1 yang digunakan Streams Core. Ini cocok untuk kasus penggunaan intensif data seperti streaming log, real-time analitik, atau sistem pesan berskala besar.
Fitur Tambahan: Stream Plugin menyediakan fitur unik seperti Super Streams, yang memungkinkan pembagian data secara otomatis ke beberapa shard untuk meningkatkan skalabilitas. Anda dapat menemukan daftar lengkap fitur ini di dokumentasi resmi RabbitMQ.
Manajemen yang Lebih Baik: Dengan mengaktifkan Stream Plugin, Anda juga dapat mengelola stream melalui UI RabbitMQ Management, yang memudahkan dalam memonitor dan mengatur stream.
Secara bawaan, Stream Plugin sudah termasuk dalam RabbitMQ, tetapi perlu diaktifkan terlebih dahulu. Langkah-langkahnya adalah sebagai berikut:
Hapus Instance Lama RabbitMQ Jika Anda sudah menjalankan RabbitMQ tanpa Stream Plugin, Anda perlu menghapusnya:
Jalankan RabbitMQ dengan Pengaturan Baru Pastikan port 5552 (default untuk Stream Plugin) terbuka, dan tambahkan variabel lingkungan yang diperlukan:
Aktifkan Plugin Setelah container berjalan, aktifkan Stream Plugin dan UI manajemen stream:
Setelah plugin diaktifkan, buka RabbitMQ Management UI di port 15672, dan tab baru untuk Stream akan muncul.
Untuk memanfaatkan Stream Plugin di Go, Kita perlu menggunakan Stream Client yang didesain khusus untuk protokol biner Stream Plugin.
1. Instalasi Client
Unduh pustaka RabbitMQ Stream untuk Go:
2. Contoh Kode: Membuat Producer
Berikut adalah contoh kode untuk menghubungkan ke RabbitMQ, mendeklarasikan stream, dan mengirimkan pesan:
3. Batch Send
Untuk mengirim beberapa pesan sekaligus (batch), gunakan BatchSend:
Stream Plugin menyimpan data dalam format biner, bukan teks biasa, untuk meningkatkan efisiensi. Kita dapat melihat file segmen di direktori:
Contoh output:
Pada bagian ini, kita akan mulai mengonsumsi Stream menggunakan Plugin.
Penting untuk dicatat bahwa kita menggunakan Stream Core dalam implementasi dasar. Anda bisa menjalankan consumer/main.go lagi dan melihat bahwa Anda akan menerima pesan-pesan baru.
Ya, Stream Plugin dan Stream Core bisa digunakan secara seamless bersama-sama.
Namun, kita ingin menggunakan Plugin SDK untuk memanfaatkan kemampuan tambahan yang disediakan.
Sekali lagi, konsumer kita akan melakukan hal yang sama seperti sebelumnya, namun dengan beberapa perbedaan yang bisa kita lihat.
Mari kita buat konsumer yang menerima semua pesan dari stream menggunakan Plugin terlebih dahulu.
Jika Anda menjalankan kode di atas, Anda seharusnya melihat semua pesan yang tercetak di konsol.
Untuk mengubah cara kita menerima pesan berdasarkan Offset atau Timestamp, kita cukup memodifikasi parameter yang kita pasang ke dalam fungsi SetOffset:
Jika kita ingin mengambil pesan-pesan yang dikirim dalam dua jam terakhir, kita bisa menggunakan Timestamp:
Subentries adalah teknik yang memungkinkan kita menunggu beberapa pesan untuk dikumpulkan sebelum mengirimnya melalui jaringan. Setiap Subentry akan mendapatkan slot di dalam frame jaringan yang dikirim. Teknik ini membantu meningkatkan throughput dengan mengurangi jumlah lalu lintas jaringan secara signifikan. Selain itu, kita juga dapat menggunakan kompresi untuk mengurangi ukuran data yang dikirim lebih jauh.
Berikut adalah contoh penerapan Subentry dan kompresi GZIP dalam kode produksi:
Dengan pengaturan ini, Anda mengaktifkan kompresi GZIP dan memberitahukan SDK untuk menggunakan subentries.
Catatan: Subentries dapat meningkatkan throughput tetapi juga dapat memperkenalkan latensi karena menunggu subentry untuk terisi. Selain itu, ada latensi dalam melakukan kompresi dan dekompresi pada konsumer.
Sebelum dan setelah menambahkan Subentries dan kompresi, kita bisa membandingkan lalu lintas jaringan dengan menggunakan tcpdump. Berikut adalah contoh perintah yang digunakan untuk merekam lalu lintas TCP:
Setelah menambahkan Subentry dan kompresi, jalankan perintah yang sama:
Kita dapat membandingkan ukuran paket data yang dikirim sebelum dan setelah menambahkan Subentries dengan perintah berikut:
Deduplication adalah fitur built-in di RabbitMQ yang mencegah pengiriman pesan yang sama berulang kali. Untuk menerapkan deduplication, kita perlu menambahkan ID unik untuk setiap pesan yang diterbitkan.
Contoh implementasinya adalah sebagai berikut:
Namun, penting untuk dicatat bahwa kita tidak bisa menggunakan Subentry dan deduplication secara bersamaan. Subentries menonaktifkan deduplication karena tidak ada ID publikasi yang diterapkan dalam batch.
Stream Plugin lebih efisien daripada Stream Core, tetapi memerlukan beberapa langkah tambahan.
Gunakan Protobuf untuk mendefinisikan event dan gunakan ini dalam RabbitMQ untuk meningkatkan kualitas data yang dikirim.
Gunakan library bersama untuk mengelola payload, sehingga marshalling dan unmarshalling tetap bersih.
Saat membangun aplikasi nyata, pastikan untuk memperhatikan latensi dan throughput yang dihasilkan dari penggunaan Subentries dan kompresi.
SOON
RabbitMQ adalah salah satu aplikasi Message Broker yang digunakan untuk mendukung komunikasi berbasis Messaging. Aplikasi ini bersifat open-source dan gratis, sehingga dapat digunakan secara gratis. RabbitMQ dikenal sebagai Message Broker yang ringan dan fleksibel, serta dapat diinstal di hampir semua sistem operasi, termasuk Windows, Linux, dan macOS. Untuk informasi lebih lanjut, Kamu dapat mengunjungi situs resminya di .
RabbitMQ mengikuti standar AMQP (Advanced Message Queuing Protocol), yang memungkinkan komunikasi dengan RabbitMQ dilakukan selama kita mengikuti standar protokol tersebut. Hal ini menjadi salah satu keunggulan RabbitMQ, karena memberikan fleksibilitas bagi penggunanya. Jika di kemudian hari kamu memutuskan untuk beralih ke Message Broker lain, selama Message Broker tersebut juga mendukung standar AMQP, proses migrasi dapat dilakukan tanpa perubahan besar pada implementasi. Informasi lebih lanjut tentang AMQP dapat dilihat di .
Untuk menginstal RabbitMQ, langkah pertama yang perlu dilakukan adalah mengunduh file distribusi RabbitMQ terlebih dahulu. Kamu dapat mengaksesnya melalui . Pilih file distribusi yang sesuai dengan sistem operasi yang kamu gunakan, lalu ikuti petunjuk instalasi yang disediakan untuk menginstalnya pada sistem operasi tersebut. Jika aplikasi RabbitMQ sudah berjalan dengan benar, kita bisa mengeceknya menggunakan terminal dengan perintah : rabbitmqctl status Untuk sekarang saya akan menginstall dan menjalankan RabbitMQ menggunakan Docker Compose.
Image rabbitmq-management telah menyediakan antarmuka web untuk monitoring message queues, manajemen pengguna, melihat statistik, konfigurasi exchange dan queue, dan lain sebagainya. Kamu bisa menggunakan user admin dan password password untuk masuk ke dashboard RabbitMQ karena kredensial default RabbitMQ telah kita ubah via docker compose. Jika kamu tidak custom kredensial maka default user nya adalah guest dan password guest. Ketika kita menginstall RabbitMQ tanpa docker maka default web management nya belum aktif, kita bisa aktifkan dengan menjalankan perintah rabbitmq-plugins enable rabbitmq_management dan selanjutnya kita bisa membuka halaman web management RabbitMQ melalui
Penggunaan Client Library harus disesuaikan dengan teknologi yang digunakan dalam aplikasi kita. RabbitMQ mendukung berbagai Client Library untuk banyak bahasa pemrograman, sehingga memungkinkan fleksibilitas dalam memilih teknologi. Daftar lengkap Client Library yang didukung dapat dilihat di .
