Profil

Pengenalan

Broker pesan adalah jenis middleware yang memungkinkan komunikasi antara sistem terdistribusi dengan memfasilitasi pertukaran pesan antara aplikasi. Pesan-pesan ini dapat mengirimkan data, perintah, atau peristiwa antara sistem. Broker pesan dirancang untuk menangani volume pesan yang tinggi dan sering digunakan dalam arsitektur layanan mikro, sistem berbasis peristiwa, dan aplikasi lain yang memerlukan komunikasi asinkron.

Karakteristik Utama

• Middleware untuk pertukaran pesan
• Dukungan untuk komunikasi asinkron
• Skalabilitas dan kinerja yang tinggi
• Pengiriman pesan yang dijamin
• Pembebanan dan failover otomatis

Teorema CAP

Penanganan teorema CAP secara umum

Broker pesan dirancang untuk memprioritaskan ketersediaan dan toleransi partisi daripada konsistensi, sehingga cocok untuk aplikasi yang membutuhkan ketersediaan dan skalabilitas yang tinggi.

Jaminan Konsistensi

Broker pesan biasanya menyediakan konsistensi akhir, yang berarti bahwa pembaruan pada database mungkin memerlukan waktu untuk menyebar ke semua node dalam sistem. Beberapa broker juga menawarkan konsistensi kuat, yang menjamin bahwa semua node melihat data yang sama secara bersamaan.

Jaminan Ketersediaan

Broker pesan dirancang untuk memprioritaskan ketersediaan, yang berarti mereka dapat terus beroperasi bahkan jika beberapa node dalam sistem gagal.

Jaminan Toleransi Partisi

Broker pesan dirancang untuk sangat skala dan menangani jumlah data yang besar di beberapa node. Mereka menggunakan pembebanan dan failover otomatis untuk memastikan bahwa data didistribusikan secara merata di seluruh sistem dan dapat terus beroperasi bahkan jika beberapa node gagal.

Penggunaan

Penggunaan Terbaik

Broker pesan sangat cocok untuk aplikasi yang memerlukan komunikasi asinkron antara sistem terdistribusi, seperti arsitektur layanan mikro, sistem berbasis peristiwa, dan analisis real-time.

Penggunaan Netral

Broker pesan juga dapat digunakan untuk aplikasi yang memerlukan komunikasi sinkron tetapi mungkin bukan pilihan terbaik untuk aplikasi yang memerlukan konsistensi yang ketat atau transaksi yang kompleks.

Penggunaan Terburuk

Broker pesan mungkin bukan pilihan terbaik untuk aplikasi yang memerlukan join atau transaksi yang kompleks atau untuk aplikasi yang memerlukan konsistensi yang ketat.

Peran di Desain Sistem

Broker pesan sangat cocok untuk sistem yang memerlukan skalabilitas dan ketersediaan yang tinggi, seperti sistem terdistribusi dan aplikasi berbasis cloud.

Data

Model Data

• Middleware untuk pertukaran pesan
• Basis data non-relasional
• Keuntungan: model data yang fleksibel, kemampuan untuk menangani volume pesan yang tinggi, kinerja yang baik dengan sistem terdistribusi
• Kekurangan: mungkin tidak cocok untuk aplikasi yang memerlukan konsistensi yang ketat atau transaksi yang kompleks.

Bahasa Kueri

• Bahasa kueri NoSQL (misalnya, API Apache Kafka)
• Keuntungan: sederhana, mudah digunakan, kinerja yang baik dengan sistem terdistribusi
• Kekurangan: mungkin tidak sekuat SQL untuk kueri yang kompleks.

Skalabilitas

Cara Meningkatkan Performa

Broker pesan dapat dibuat performa melalui pengindeksan dan teknik optimasi kinerja lainnya.

Penanganan Lalu Lintas Tinggi

Broker pesan sangat cocok untuk beban kerja baca dan tulis yang tinggi tetapi mungkin memerlukan pertimbangan partisi data dan replikasi tambahan.

Meningkatkan Skalabilitas Basis Data

Broker pesan dapat diperbesar secara horizontal melalui pembebanan dan failover otomatis.

Penggunaan dalam Sistem Terdistribusi

Broker pesan dirancang untuk sistem terdistribusi dan sangat cocok untuk aplikasi berbasis cloud.

Replikasi

Broker pesan biasanya menggunakan replikasi otomatis untuk memastikan pengiriman dan ketahanan pesan. Praktik terbaik untuk replikasi termasuk menggunakan faktor replikasi setidaknya tiga dan memastikan bahwa replika didistribusikan di beberapa pusat data.

Dalam Praktik

Praktik Terbaik

• Gunakan pengindeksan dan teknik optimasi kinerja lainnya untuk meningkatkan throughput pesan.
• Gunakan faktor replikasi setidaknya tiga untuk memastikan pengiriman dan ketahanan pesan.
• Monitor sistem untuk masalah kinerja dan sesuaikan jika perlu.

Kesalahan Umum

• Tidak memahami model data dan bagaimana itu mempengaruhi throughput pesan
• Tidak mengkonfigurasi replikasi dan partisi dengan benar
• Tidak memonitor sistem untuk masalah kinerja

Penyimpanan Data Serupa

• Apache Kafka
• RabbitMQ
• Amazon Simple Queue Service (SQS)

Bacaan Lanjutan

• “Enterprise Integration Patterns: Designing, Building, and Deploying Messaging Solutions” oleh Gregor Hohpe dan Bobby Woolf
• “Building Microservices: Designing Fine-Grained Systems” oleh Sam Newman