Memahami broker pesan. Mempelajari mekanisme pengiriman pesan melalui ActiveMQ dan Kafka. Bab 2. ActiveMQ

Kelanjutan dari terjemahan sebuah buku kecil:
"Memahami Pialang Pesan",
penulis: Jakub Korab, penerbit: O'Reilly Media, Inc., tanggal publikasi: Juni 2017, ISBN: 9781492049296.

Terjemahan selesai

Bagian sebelumnya: Memahami Pialang Pesan. Mempelajari mekanisme pengiriman pesan melalui ActiveMQ dan Kafka. Bab 1. Pendahuluan

BAB 2

Activemq

ActiveMQ digambarkan sebagai sistem pesan klasik. Itu ditulis pada tahun 2004 untuk mengisi kebutuhan pialang pesan sumber terbuka. Pada saat itu, jika Anda ingin menggunakan pesan dalam aplikasi Anda, satu-satunya pilihan adalah produk komersial yang mahal.

ActiveMQ dikembangkan sebagai implementasi dari spesifikasi Java Message Service (JMS). Keputusan ini dibuat untuk memenuhi persyaratan untuk mengimplementasikan pesan yang sesuai dengan JMS di proyek Apache Geronimo, server aplikasi J2EE open source.
Sistem pesan (atau middleware yang berorientasi pada pesan, seperti yang kadang-kadang disebut) yang mengimplementasikan spesifikasi JMS terdiri dari komponen-komponen berikut:

Pialang

Sepotong utama dari middleware mendistribusikan pesan.

Pelanggan

Sepotong perangkat lunak yang mengirim pesan melalui broker. Ini, pada gilirannya, terdiri dari artefak berikut:

• Kode menggunakan JMS API.
• API JMS adalah seperangkat antarmuka untuk berinteraksi dengan broker sesuai dengan jaminan yang ditetapkan dalam spesifikasi JMS.
• Pustaka klien dari sistem yang menyediakan implementasi API dan berinteraksi dengan broker.

Klien dan broker berkomunikasi satu sama lain melalui protokol lapisan aplikasi, juga dikenal sebagai protokol interaksi (Gambar 2-1) . Spesifikasi JMS meninggalkan detail protokol ini ke implementasi spesifik.


Gambar 2-1. Ulasan JMS

JMS menggunakan penyedia istilah untuk menggambarkan implementasi vendor dari sistem pengiriman pesan yang mendasari JMS API, yang meliputi broker, serta perpustakaan kliennya.

Pilihan yang mendukung implementasi JMS memiliki konsekuensi yang luas untuk keputusan implementasi yang dibuat oleh penulis ActiveMQ. Spesifikasi itu sendiri memberikan panduan yang jelas tentang tanggung jawab klien dari sistem pengiriman pesan dan broker yang berkomunikasi dengannya, memberikan preferensi pada kewajiban broker untuk mendistribusikan dan mengirimkan pesan. Tanggung jawab utama klien adalah berinteraksi dengan penerima (antrian atau topik) dari pesan yang dikirim olehnya. Spesifikasi itu sendiri bertujuan untuk membuat interaksi API dengan broker relatif sederhana.

Area ini, seperti yang akan kita lihat nanti, memiliki dampak signifikan pada kinerja ActiveMQ. Selain kompleksitas broker, paket kompatibilitas untuk spesifikasi yang disediakan oleh Sun Microsystems memiliki banyak nuansa, dengan dampaknya sendiri pada kinerja. Semua nuansa ini harus diperhitungkan agar ActiveMQ dianggap kompatibel dengan JMS.

Komunikasi

Meskipun API dan perilaku yang diharapkan didefinisikan dengan baik dalam spesifikasi JMS, protokol komunikasi klien-broker yang sebenarnya sengaja dikecualikan dari spesifikasi sehingga broker yang ada dapat dibuat memenuhi persyaratan JMS. Dengan demikian, ActiveMQ bebas menentukan protokol interaksinya sendiri, OpenWire. OpenWire digunakan oleh implementasi perpustakaan klien ActiveMQ JMS, serta rekan-rekannya di .Net dan C ++: NMS dan CMS, yang merupakan sub proyek ActiveMQ yang diselenggarakan oleh Apache Software Foundation.

Seiring waktu, dukungan untuk protokol interaksi lainnya ditambahkan ke ActiveMQ, yang meningkatkan kemampuan untuk berinteraksi dengan bahasa dan lingkungan lain:

AMQP 1.0

Protokol Antrian Pesan Lanjutan (ISO / IEC 19464: 2014) tidak boleh dikacaukan dengan pendahulunya 0.X, yang diimplementasikan dalam sistem pesan lain, khususnya RabbitMQ, menggunakan 0.9.1. AMQP 1.0 adalah protokol biner tujuan umum untuk bertukar pesan antara dua node. Ia tidak memiliki konsep klien atau broker dan mencakup fungsi-fungsi seperti flow control, transaksi, dan berbagai QoS (tidak lebih dari sekali, setidaknya sekali, dan tepat sekali).

STOMP

Simple / Streaming Text Oriented Messaging Protocol, protokol yang mudah diterapkan yang memiliki lusinan implementasi klien dalam berbagai bahasa.

Xmpp

Perpesanan yang lebih luas dan protokol kehadiran. (Perpanjangan Perpesanan dan Protokol Kehadiran). Sebelumnya bernama Jabber, protokol berbasis XML ini pada awalnya dikembangkan untuk sistem obrolan, tetapi telah diperluas melampaui kasus penggunaan aslinya untuk menyertakan mempublikasikan pesan berlangganan.

MQTT

Protokol publikasi-berlangganan ringan (ISO / IEC 20922: 2016) digunakan untuk aplikasi Machine-to-Machine (M2M) dan Internet of Things (IoT).

ActiveMQ juga mendukung pengenaan protokol di atas pada WebSockets, yang menyediakan pertukaran data dupleks penuh antara aplikasi di browser web dan tujuan di broker.

Mengingat ini, sekarang ketika kita berbicara tentang ActiveMQ, kita tidak lagi merujuk secara eksklusif ke tumpukan interaksi berdasarkan perpustakaan JMS / NMS / CMS dan protokol OpenWire. Kombinasi dan pemilihan bahasa, platform, dan perpustakaan eksternal yang paling cocok untuk aplikasi ini menjadi semakin populer. Misalnya, aplikasi JavaScript dapat dijalankan di browser menggunakan pustaka Eclipse Paho MQTT untuk mengirim pesan ke ActiveMQ melalui soket web, dan pesan ini dibaca oleh proses server C ++ yang menggunakan AMQP melalui perpustakaan Apache Qpid Proton . Dari perspektif ini, lansekap perpesanan menjadi lebih beragam.

Melihat ke masa depan, AMQP, khususnya, akan memiliki lebih banyak peluang daripada sekarang, karena komponen yang bukan klien maupun pialang menjadi bagian yang lebih akrab dari lanskap perpesanan. Sebagai contoh, Apache Qpid Dispatch Router bertindak sebagai router pesan, di mana klien terhubung secara langsung, memungkinkan tujuan berbeda untuk memproses alamat yang berbeda, serta memberikan kemungkinan sharding (pemisahan).

Saat bekerja dengan perpustakaan pihak ketiga dan komponen eksternal, harap dicatat bahwa mereka memiliki kualitas variabel dan mungkin tidak kompatibel dengan fungsi yang disediakan di ActiveMQ. Sebagai contoh yang sangat sederhana - tidak mungkin mengirim pesan ke antrian melalui MQTT (tanpa mengatur perutean di broker). Dengan demikian, Anda perlu meluangkan waktu bekerja dengan opsi untuk menentukan tumpukan sistem pengiriman pesan yang paling cocok untuk persyaratan aplikasi Anda.

Pertukaran antara kinerja dan keandalan

Sebelum kita mempelajari detail tentang cara pengiriman pesan titik-ke-titik di ActiveMQ, kita perlu berbicara sedikit tentang apa yang dihadapi semua sistem dengan pemrosesan data yang berat: pertukaran antara kinerja dan keandalan.

Sistem apa pun yang menerima data, apakah itu perantara pesan atau database, harus diinstruksikan tentang cara memproses data ini jika terjadi kegagalan. Kegagalan dapat mengambil banyak bentuk, tetapi untuk kesederhanaan kami akan mempersempitnya ke situasi di mana sistem kehilangan daya dan dimatikan segera. Dalam situasi ini, kita perlu berspekulasi tentang apa yang akan terjadi pada data yang ada di sistem. Jika data (dalam hal ini, pesan) ada di memori atau di bagian volatil dari besi, misalnya, di cache, maka data ini akan hilang. Namun, jika data dikirim ke penyimpanan non-volatil, misalnya ke disk, itu akan tersedia lagi ketika sistem kembali berfungsi.

Dari sudut pandang ini, masuk akal bahwa jika kita tidak ingin kehilangan pesan jika terjadi kegagalan broker, kita perlu menulisnya ke penyimpanan permanen. Sayangnya, biaya solusi khusus ini cukup tinggi.

Perhatikan bahwa perbedaan antara menulis satu megabyte data ke disk adalah 100-1000 kali lebih lambat daripada menulis ke memori. Oleh karena itu, pengembang aplikasi harus memutuskan apakah keandalan pesan sepadan dengan hilangnya kinerja. Keputusan seperti ini harus dibuat berdasarkan skenario penggunaan.

Pertukaran antara kinerja dan keandalan didasarkan pada berbagai opsi. Semakin tinggi keandalan, semakin rendah kinerjanya. Jika Anda memutuskan untuk membuat sistem ini kurang dapat diandalkan, misalnya, menyimpan pesan hanya dalam memori, produktivitas Anda akan meningkat secara signifikan. Secara default, JMS dikonfigurasi untuk memiliki ActiveMQ di luar kotak untuk keandalan. Ada banyak mekanisme yang memungkinkan Anda untuk mengonfigurasi broker dan berinteraksi dengannya ke posisi dalam spektrum ini yang paling cocok untuk skenario spesifik menggunakan sistem pengiriman pesan.

Kompromi ini diterapkan pada tingkat broker individu. Namun, setelah menyelesaikan pengaturan broker individu, dimungkinkan untuk skala sistem pesan di luar titik ini dengan hati-hati memeriksa aliran pesan dan berbagi lalu lintas antara beberapa broker. Ini dapat dicapai dengan memberikan penerima tertentu dengan broker mereka sendiri atau dengan membagi aliran pesan keseluruhan baik pada tingkat aplikasi atau menggunakan komponen perantara. Nantinya, kami akan mempertimbangkan secara lebih rinci cara memperhitungkan topologi broker.

Menyimpan Pesan

ActiveMQ hadir dengan sejumlah strategi penyimpanan pesan pluggable. Mereka datang dalam bentuk adapter kegigihan (persistence), yang dapat dianggap sebagai mesin penyimpan pesan. Ini termasuk solusi berbasis disk seperti KahaDB dan LevelDB, serta kemampuan untuk menggunakan database melalui JDBC. Karena yang pertama paling umum digunakan, kami akan memfokuskan diskusi kami pada mereka.

Ketika broker menerima pesan persisten, mereka pertama kali ditulis ke disk dalam jurnal. Jurnal adalah struktur data pada disk di mana Anda hanya dapat menambahkan data dan terdiri dari beberapa file. Pesan yang masuk diserialkan oleh broker ke dalam representasi protokol-independen dari objek, dan kemudian disusun dalam bentuk biner, yang kemudian ditulis hingga akhir log. Log berisi log semua pesan yang masuk, serta informasi tentang pesan-pesan yang telah dikonfirmasi telah dibaca oleh klien.

Adaptor disk yang gigih mendukung file indeks yang melacak di mana pesan yang diteruskan berikut ini berada di log. Ketika semua pesan dari file log dibaca, mereka akan dihapus atau diarsipkan oleh alur kerja latar belakang ActiveMQ. Jika log ini rusak selama kegagalan broker, ActiveMQ akan membangunnya kembali berdasarkan informasi dalam file log.

Pesan dari semua antrian ditulis ke file log yang sama, yang berarti bahwa jika satu pesan tidak dibaca, seluruh file (biasanya defaultnya adalah 32 MB atau 100 MB, tergantung pada adaptor persistensi) tidak dapat dihapus. Ini dapat menyebabkan masalah dengan ruang disk rendah seiring waktu.

Pialang pesan klasik tidak dirancang untuk penyimpanan jangka panjang - baca pesan Anda!

Log adalah mekanisme yang sangat efisien untuk menyimpan dan kemudian mengambil pesan, karena akses disk berurutan untuk kedua operasi. Pada hard disk konvensional, ini meminimalkan jumlah pencarian disk dengan silinder, karena kepala pada disk hanya terus membaca atau menulis sektor ke substrat berputar disk. Demikian pula, pada SSD, akses berurutan jauh lebih cepat daripada akses acak, karena yang sebelumnya memanfaatkan halaman memori drive dengan lebih baik.

Faktor Kinerja Disk

Ada sejumlah faktor yang menentukan kecepatan di mana disk dapat bekerja. Untuk memahami hal ini, pertimbangkan metode penulisan ke disk melalui model mental pipa yang disederhanakan ( Gambar 2-2 ).


Gambar 2-2. Model Tabung Performa Disk

Sebuah pipa memiliki tiga dimensi:

Panjangnya

Sesuai dengan latensi yang diharapkan untuk menyelesaikan satu operasi. Untuk sebagian besar drive lokal, ini cukup bagus, tetapi dapat menjadi faktor pembatas utama dalam lingkungan cloud di mana drive lokal sebenarnya online. Misalnya, pada saat penulisan (April 2017), Amazon menjamin bahwa menulis ke penyimpanan EBS mereka akan "dalam waktu kurang dari 2 ms." Jika kami merekam secara berurutan, ini memberikan throughput maksimum 500 catatan per detik.

Lebar

Menentukan daya dukung atau bandwidth dari satu operasi. Cache sistem file menggunakan properti ini dengan menggabungkan banyak catatan kecil ke dalam set yang lebih kecil dari operasi penulisan yang lebih besar yang dilakukan pada disk.

Bandwidth seiring waktu

Idenya disajikan dalam bentuk serangkaian peristiwa yang dapat di pipa pada saat yang sama, diungkapkan oleh metrik yang disebut IOPS (jumlah operasi I / O per detik) . IOPS umumnya digunakan oleh produsen penyimpanan dan penyedia cloud untuk mengukur kinerja. Hard drive akan memiliki nilai IOPS yang berbeda dalam konteks yang berbeda: apakah beban kerjanya sebagian besar terdiri dari baca, tulis, atau kombinasi keduanya, dan apakah operasi ini berurutan, arbitrer, atau campuran. Pengukuran IOPS yang paling menarik dari sudut pandang broker adalah operasi membaca dan menulis berurutan, karena mereka berhubungan dengan membaca dan menulis log dari sebuah log.

Throughput maksimum broker pesan ditentukan oleh pencapaian pembatasan pertama ini, dan konfigurasi broker sebagian besar tergantung pada cara Anda berinteraksi dengan disk. Ini bukan hanya faktor bagaimana, misalnya, broker dikonfigurasi, tetapi juga tergantung pada bagaimana produsen berinteraksi dengan broker. Seperti halnya segala sesuatu yang berkaitan dengan kinerja, perlu untuk menguji broker pada beban kerja yang representatif (mis., Sedekat mungkin dengan pesan nyata) dan pada konfigurasi penyimpanan aktual yang akan digunakan dalam PROM. Ini dilakukan untuk memahami bagaimana sistem akan berperilaku dalam kenyataan.

API JMS

Sebelum kita masuk ke perincian tentang bagaimana ActiveMQ berkomunikasi dengan klien, pertama-tama kita perlu mempelajari API JMS. API mendefinisikan satu set antarmuka pemrograman yang digunakan oleh kode klien:

ConnectionFactory

Ini adalah antarmuka tingkat atas yang digunakan untuk membangun koneksi dengan broker. Dalam aplikasi perpesanan biasa, hanya ada satu instance dari antarmuka ini. Di ActiveMQ, ini adalah ActiveMQConnectionFactory. Di tingkat atas, desain ini memberi tahu lokasi pialang pesan, bersama dengan detail tingkat rendah tentang cara berinteraksi dengannya. Seperti namanya, ConnectionFactory adalah mekanisme dimana objek Connection dibuat.

Koneksi

Ini adalah objek berumur panjang yang kira-kira menyerupai koneksi TCP - setelah dibuat, biasanya ada sepanjang siklus hidup aplikasi hingga ditutup. Koneksi aman, dan dapat bekerja dengan banyak utas secara bersamaan. Objek koneksi memungkinkan Anda membuat objek Sesi.

Sesi

Ini adalah pegangan aliran saat berinteraksi dengan broker. Objek sesi bukan thread aman, yang berarti mereka tidak dapat diakses oleh banyak utas pada saat yang sama. Session adalah deskriptor transaksional utama yang dengannya programmer dapat melakukan dan mengembalikan pesan rollback jika dia dalam mode transaksional. Menggunakan objek ini, Anda membuat objek Message, MessageConsumer, dan MessageProducer, dan juga mendapatkan pointer (deskriptor) ke objek Topik dan antrian.

MessageProducer

Antarmuka ini memungkinkan Anda untuk mengirim pesan ke penerima.

Konsumen pesan

Antarmuka ini memungkinkan pengembang untuk menerima pesan. Ada dua mekanisme pengambilan pesan:

• Daftarkan MessageListener. Ini adalah antarmuka penangan pesan yang telah Anda terapkan, yang akan memproses secara berurutan setiap pesan yang dikeluarkan oleh broker menggunakan satu aliran.
• Polling untuk pesan menggunakan metode accept ().

Pesan

Ini mungkin struktur yang paling penting karena mentransfer data Anda. Pesan di JMS terdiri dari dua aspek:

• Metadata pesan. Pesan itu berisi tajuk dan properti. Baik itu, dan itu bisa dianggap sebagai elemen peta. Header adalah elemen terkenal yang ditentukan oleh spesifikasi JMS dan tersedia langsung melalui API, seperti JMSDestination dan JMSTimestamp. Properti adalah bagian informasi pesan yang berubah-ubah yang disederhanakan untuk menyederhanakan pemrosesan atau perutean pesan tanpa harus membaca muatan pesan itu sendiri. Anda dapat, misalnya, mengatur header ke AccountID atau OrderType.
• Badan pesan. Beberapa jenis pesan dapat dibuat dari Sesi tergantung pada jenis konten yang akan dikirim dalam tubuh, yang paling umum adalah TextMessage untuk string dan BytesMessage untuk data biner.

Bagaimana Antrian Bekerja: Kisah Dua Otak

Model kerja ActiveMQ yang bermanfaat, meskipun tidak akurat, adalah model dua bagian otak. Satu bagian bertanggung jawab untuk menerima pesan dari produsen, dan yang lain mengirimkan pesan ini kepada konsumen. Hubungan sebenarnya lebih kompleks untuk keperluan optimasi kinerja, tetapi model ini cukup untuk pemahaman dasar.

Mengirim pesan ke antrian

Mari kita lihat interaksi yang terjadi saat mengirim pesan. Gambar 2-3 menunjukkan kepada kita model proses yang disederhanakan dimana pesan diterima oleh broker. Ini tidak sepenuhnya sesuai dengan perilaku dalam setiap kasus, tetapi sangat cocok untuk mendapatkan pemahaman dasar.


Gambar 2-3. Mengirim Pesan ke JMS

Dalam aplikasi klien, utas menerima pointer ke MessageProducer. Itu menciptakan Pesan dengan perkiraan muatan pesan dan panggilan MessageProducer.send ("pesanan", pesan), dengan antrian sebagai tujuan akhir pesan. Karena programmer tidak ingin kehilangan pesan jika brokernya rusak, header pesan JMSDeliveryMode diatur ke PERSISTENT (perilaku default).

Pada titik ini (1), aliran pengiriman memanggil perpustakaan klien dan mengatur pesan dalam format OpenWire. Kemudian pesan dikirim ke broker.

Di broker, aliran yang diterima menghapus pesan dari baris dan mengosongkannya ke objek internal. Kemudian, objek pesan ditransmisikan ke adapter persistence, yang mengatur pesan menggunakan format Google Protocol Buffers dan menulisnya ke penyimpanan (2).
Setelah merekam pesan di penyimpanan, adaptor persistensi harus menerima konfirmasi bahwa pesan itu benar-benar direkam (3). Ini biasanya merupakan bagian paling lambat dari keseluruhan interaksi; lebih lanjut tentang ini nanti.

Segera setelah broker memastikan bahwa pesan telah disimpan, ia akan mengirim respons konfirmasi (4) kepada klien. Setelah itu, utas klien yang awalnya disebut operasi kirim () dapat melanjutkan pekerjaannya.

Konfirmasi pesan persisten yang tertunda ini adalah dasar dari jaminan yang diberikan oleh JMS API - jika Anda ingin pesan disimpan, mungkin juga penting bagi Anda apakah pesan itu diterima oleh broker di tempat pertama. Ada sejumlah alasan mengapa hal ini tidak mungkin dilakukan, misalnya, batas memori atau disk telah tercapai. Alih-alih gagal, broker baik menunda operasi pengiriman, memaksa produsen untuk menunggu sampai sumber daya sistem yang cukup muncul untuk memproses pesan (proses yang disebut Producer Flow Control), atau dia akan mengirimkan konfirmasi negatif kepada produsen, mengeluarkan pengecualian. Perilaku yang tepat dapat disesuaikan untuk setiap broker.

Dalam operasi sederhana ini, sejumlah besar interaksi I / O terjadi: dua operasi jaringan antara produsen dan broker, satu operasi simpan dan langkah konfirmasi. Operasi simpan dapat berupa penulisan sederhana ke disk atau transisi jaringan lain ke server penyimpanan.

Ini menimbulkan pertanyaan penting tentang pialang pesan: pekerjaan mereka dikaitkan dengan aliran operasi I / O yang sangat intensif dan mereka sangat sensitif terhadap infrastruktur yang digunakan, terutama pada disk.

Mari kita melihat lebih dekat pada langkah konfirmasi (3) dalam interaksi di atas. Jika adaptor persistensi berbasis file, maka menyimpan pesan melibatkan penulisan ke sistem file. Jika demikian, lalu mengapa saya perlu mengonfirmasi bahwa operasi penulisan telah selesai? Apakah tindakan menyelesaikan rekaman benar-benar berarti bahwa rekaman telah terjadi?
Tidak juga.Seperti yang biasanya terjadi, semakin dalam Anda mempelajari sesuatu, semakin kompleks ternyata. Dalam kasus khusus ini, caching adalah biang keladinya .

Tembolok, tembolok di mana-mana

Ketika proses sistem operasi, seperti broker, menulis data ke disk, itu berinteraksi dengan sistem file. Sistem file adalah proses yang mengabstraksi rincian interaksi dengan media penyimpanan yang digunakan, menyediakan API untuk operasi file seperti OPEN, CLOSE, READ, dan WRITE. Salah satu fungsi ini adalah untuk meminimalkan jumlah operasi tulis dengan buffering data yang ditulis oleh sistem operasi ke dalam blok yang dapat disimpan ke disk dalam satu pendekatan. Operasi penulisan sistem file yang terlihat seperti berinteraksi dengan disk sebenarnya ditulis ke cache buffer ini .

Ngomong-ngomong, itu sebabnya komputer Anda mengeluh ketika Anda mengeluarkan drive USB dengan tidak aman - file yang Anda salin mungkin sebenarnya belum ditulis!
Segera setelah data melampaui cache buffer, ia pergi ke level caching berikutnya, kali ini di tingkat perangkat keras - cache controller disk . Mereka sangat penting untuk sistem berbasis RAID dan melakukan fungsi yang sama seperti caching di tingkat sistem operasi: meminimalkan jumlah interaksi yang diperlukan untuk drive itu sendiri. Tembolok ini terbagi dalam dua kategori:

Write-through Writes

ditransfer ke disk segera setelah diterima.

Tulis kembali

Perekaman dilakukan pada disk hanya ketika buffer penuh mencapai nilai ambang tertentu.

Data yang disimpan dalam cache ini dapat dengan mudah hilang selama kegagalan daya, karena memori yang mereka gunakan biasanya tidak stabil (volatile) . Kartu yang lebih mahal memiliki paket baterai yang berlebihan (BBU) yang mendukung daya cache hingga seluruh sistem dapat memulihkan daya, setelah itu data akan ditulis ke disk.
Level cache terakhir ada di disk itu sendiri. Tembolok diskterletak pada hard drive (baik pada hard drive standar dan pada solid state drive) dan dapat berupa write-through atau write-back. Sebagian besar drive komersial menggunakan cache write-back dan volatile, yang lagi-lagi berarti bahwa data dapat hilang jika terjadi kegagalan daya.

Kembali ke broker pesan, Anda harus menyelesaikan langkah konfirmasi untuk memastikan bahwa data telah benar-benar mencapai disk. Sayangnya, interaksi dengan buffer perangkat keras ini bergantung pada sistem file, sehingga yang dapat dilakukan oleh proses seperti ActiveMQ adalah mengirim sinyal ke sistem file yang ingin disinkronkan semua buffer sistem dengan perangkat yang digunakan. Untuk melakukan ini, broker memanggil metode java.io.FileDescriptor.sync (), yang, pada gilirannya, memulai operasi POSIX fsync ().

Perilaku sinkronisasi ini adalah persyaratan JMS untuk memastikan bahwa semua pesan yang ditandai sebagai persisten benar-benar disimpan ke disk dan oleh karena itu dieksekusi setelah setiap pesan atau set pesan terkait dalam suatu transaksi diterima. Oleh karena itu, kecepatan di mana disk dapat melakukan sinkronisasi () sangat penting untuk kinerja broker.

Konflik internal

Menggunakan satu log untuk semua antrian menambah kompleksitas tambahan. Pada waktu tertentu, mungkin ada beberapa produsen mengirim pesan secara bersamaan. Pialang memiliki beberapa aliran yang menerima pesan-pesan ini dari soket masuk. Setiap utas harus menyimpan pesannya ke log. Karena beberapa utas tidak dapat menulis ke file yang sama pada saat yang sama, karena catatan akan bertentangan satu sama lain, maka catatan harus antri menggunakan mekanisme pengecualian bersama. Kami menyebutnya konflik utas ini .

Setiap pesan harus direkam sepenuhnya dan disinkronkan sebelum memproses pesan berikutnya. Pembatasan ini memengaruhi semua antrian di broker secara bersamaan. Dengan demikian, kecepatan seberapa cepat suatu pesan dapat diterima adalah waktu yang diperlukan untuk menulis ke disk, ditambah waktu menunggu aliran lain untuk menyelesaikan rekaman.

ActiveMQ termasuk buffer tulis, di mana aliran penerima menulis pesan mereka, menunggu selesainya rekaman sebelumnya. Kemudian buffer ditulis dalam satu tindakan ketika pesan tersedia. Setelah selesai, utas akan diberitahukan. Dengan demikian, broker memaksimalkan penggunaan bandwidth penyimpanan.

Untuk meminimalkan dampak konflik utas, set antrian dapat ditetapkan log mereka sendiri menggunakan adaptor mKahaDB. Pendekatan ini mengurangi latensi penulisan, karena pada waktu tertentu, utas kemungkinan besar akan menulis ke jurnal yang berbeda dan mereka tidak perlu saling bersaing untuk mendapatkan akses eksklusif ke satu file log.

Transaksi

Keuntungan menggunakan jurnal tunggal untuk semua antrian adalah bahwa, dari sudut pandang penulis broker, jauh lebih mudah untuk mengimplementasikan transaksi.

Mari kita lihat contoh di mana beberapa pesan dikirim oleh produser ke beberapa antrian. Menggunakan transaksi berarti bahwa seluruh rangkaian pesan yang akan dikirim harus dianggap sebagai satu operasi atom. Dalam interaksi ini, pustaka klien ActiveMQ mampu membuat beberapa optimasi yang secara signifikan akan meningkatkan kecepatan pengiriman.

Dalam operasi yang ditunjukkan pada Gambar 2-4, produser mengirim tiga pesan, semuanya dalam antrian berbeda. Alih-alih interaksi yang biasa dengan broker, ketika setiap pesan dikonfirmasi, klien mengirim ketiga pesan secara serempak, yaitu, tanpa menunggu jawaban. Pesan-pesan ini disimpan dalam memori broker. Segera setelah operasi selesai, produsen memberi tahu sesi tentang perlunya komitmen, yang pada gilirannya memaksa broker untuk melakukan satu catatan besar dengan satu operasi sinkronisasi.


Gambar 2-4. Mengirim Pesan dalam Transaksi

Dalam jenis operasi ini, ActiveMQ menggunakan dua optimisasi untuk meningkatkan kecepatan:

• Menghapus waktu tunggu sebelum pengiriman berikutnya oleh produsen menjadi mungkin
• Menggabungkan banyak operasi disk kecil menjadi satu operasi besar - ini memungkinkan Anda untuk menggunakan seluruh bandwidth disk bus

Jika kita membandingkan ini dengan situasi ketika setiap antrian disimpan dalam lognya sendiri, maka broker harus menyediakan sesuatu seperti koordinasi transaksi antara semua catatan.

Mengurangkan pesan dari antrian

Proses membaca pesan dimulai ketika konsumen menyatakan keinginan mereka untuk menerimanya baik dengan mengatur MessageListener untuk memproses pesan ketika mereka tiba, atau dengan memanggil metode MessageConsumer.receive () ( Gambar 2-5 ).


Gambar 2-5. Membaca pesan melalui JMS

Ketika ActiveMQ mengetahui konsumen, ia (ActiveMQ) membaca (halaman) pesan halaman demi halaman dari penyimpanan ke memori distribusi (1). Kemudian pesan-pesan ini dialihkan (dikirim) ke akuntan (2), sering di beberapa bagian untuk mengurangi jumlah interaksi jaringan. Pialang melacak pesan mana yang telah dialihkan dan ke konsumen mana.

Pesan yang diterima oleh konsumen tidak segera diproses oleh aplikasi, tetapi ditempatkan di area memori yang dikenal sebagaiprefetch penyangga (prefetch buffer) . Tujuan dari buffer ini adalah untuk merampingkan aliran pesan sehingga broker dapat mengeluarkan pesan kepada penyelia saat tersedia untuk dikirim, sementara konsumen dapat menerimanya secara tertib, satu per satu.

Pada titik tertentu setelah masuk ke buffer prefetch, pesan dibaca oleh logika aplikasi (X) dan konfirmasi proofread dikirim ke broker (3). Waktu waktu antara pemrosesan pesan dan konfirmasi dikonfigurasikan menggunakan parameter sesi JMS yang disebut mode pengakuan , yang akan kita bahas sedikit kemudian.
Segera setelah broker menerima konfirmasi pengiriman pesan, itu dihapus dari memori dan dari penyimpanan pesan (4). Istilah "penghapusan" agak menyesatkan, karena dalam kenyataannya catatan konfirmasi ditulis untuk jurnal dan indeks dalam indeks meningkat. Penghapusan aktual file log yang berisi pesan akan dilakukan oleh pengumpul Sampah di utas latar belakang berdasarkan informasi ini.

Perilaku yang dijelaskan di atas adalah penyederhanaan untuk memfasilitasi pemahaman. Sebenarnya, ActiveMQ tidak hanya halaman-demi-halaman membaca data dari disk, tetapi menggunakan mekanisme kursor antara bagian penerima dan pengalihan broker untuk meminimalkan interaksi dengan repositori broker sedapat mungkin. Pagination, seperti dijelaskan di atas, adalah salah satu mode yang digunakan dalam mekanisme ini. Kursor dapat dilihat sebagai cache tingkat aplikasi yang perlu disinkronkan dengan repositori broker. Protokol koherensi yang digunakan adalah bagian penting dari apa yang membuat mekanisme pengiriman ActiveMQ jauh lebih kompleks daripada mekanisme Kafka yang dijelaskan dalam bab berikutnya.

Mode Konfirmasi dan Transaksi

Berbagai mode konfirmasi, yang menentukan urutan antara pengoreksian ulang dan konfirmasi, memiliki dampak signifikan pada logika apa yang perlu diterapkan di klien. Mereka adalah sebagai berikut:

AUTO_ACKNOWLEDGE

Ini adalah mode yang paling umum digunakan, mungkin karena memiliki kata AUTO. Mode ini memaksa perpustakaan klien untuk mengakui pesan pada saat yang sama ketika pesan dibaca oleh panggilan accept (). Ini berarti bahwa jika logika bisnis yang diprakarsai oleh pesan melempar pengecualian, maka pesan tersebut hilang karena sudah dihapus pada broker. Jika pesan dibaca melalui pendengar, pesan akan dikonfirmasikan hanya setelah pendengar berhasil menyelesaikan pekerjaan.

CLIENT_ACKNOWLEDGE

Konfirmasi akan dikirim hanya ketika kode konsumen secara eksplisit memanggil metode Message.acknowledge ().

DUPS_OK_ACKNOWLEDGE

Di sini konfirmasi akan disangga oleh konsumen sebelum mengirimkannya secara bersamaan untuk mengurangi jumlah lalu lintas jaringan. Namun, jika sistem klien dimatikan, konfirmasi akan hilang, dan pesan akan dikirim ulang dan diproses untuk kedua kalinya. Oleh karena itu, kode harus mempertimbangkan kemungkinan duplikat pesan.

Mode konfirmasi dilengkapi dengan alat bacaan transaksional. Saat membuat Sesi, itu dapat ditandai sebagai transaksional. Ini berarti bahwa pemrogram harus secara eksplisit memanggil Session.commit () atau Session.rollback (). Di sisi konsumen, transaksi memperluas jangkauan interaksi yang dapat dilakukan kode sebagai satu operasi atom. Misalnya, Anda dapat membaca dan memproses beberapa pesan secara keseluruhan, atau mengurangi pesan dari satu antrian, dan kemudian mengirimkannya ke yang lain menggunakan objek Sesi yang sama.

Pengiriman dan beberapa konsumen

Sejauh ini, kami telah membahas perilaku membaca pesan dengan satu konsumen. Sekarang mari kita lihat bagaimana model ini berlaku untuk beberapa konsumen.

Ketika beberapa konsumen berlangganan antrean, perilaku default broker adalah mengirim pesan setengah jadi kepada konsumen yang memiliki tempat di buffer prefetch. Pesan akan dikirim sesuai urutan kedatangannya dalam antrian - ini adalah satu-satunya jaminan FIFO yang disediakan (masuk pertama, keluar pertama; pertama masuk, pertama keluar).

Ketika konsumen tiba-tiba dimatikan, semua pesan yang dikirim kepadanya, tetapi belum dikonfirmasi, akan dikirim kembali ke pelanggan lain yang tersedia.

Ini menimbulkan pertanyaan penting: bahkan di mana transaksi konsumen digunakan, tidak ada jaminan bahwa pesan tidak akan diproses beberapa kali.

Pertimbangkan logika pemrosesan berikut di dalam konsumen:

1. Pesan dikurangi dari antrian. Transaksi dimulai.
2. Layanan web disebut dengan isi pesan.
3. Transaksi dilakukan. Konfirmasi dikirim ke broker.

Jika klien menyelesaikan antara langkah 2 dan 3, maka proofreading pesan telah mempengaruhi beberapa sistem lain dengan memanggil layanan web. Panggilan layanan web adalah permintaan HTTP dan, karenanya, tidak bersifat transaksional.

Perilaku ini berlaku untuk semua sistem antrian - bahkan jika mereka bersifat transaksional, mereka tidak dapat menjamin bahwa tidak akan ada efek samping saat memproses pesan di dalamnya. Setelah memeriksa pemrosesan pesan secara terperinci, kami dapat dengan yakin mengatakan bahwa:

Tidak ada yang namanya pengiriman pesan hanya sekali .

Antrian memberikan jaminan pengiriman setidaknya satu kalidan bagian sensitif dari kode harus selalu mempertimbangkan kemungkinan menerima pesan berulang. Kami akan membahas nanti bagaimana klien perpesanan dapat menggunakan pembacaan idempoten untuk melacak pesan yang telah dilihat dan untuk menghindari duplikat.

Sortir pesan

Untuk satu set pesan yang tiba dalam urutan [A, B, C, D], dan untuk dua konsumen C1 dan C2, distribusi pesan yang normal adalah sebagai berikut:

C1: [A, C]
C2: [B, D]
Karena broker tidak mengontrol operasi proses membaca dan urutan pemrosesan paralel, itu tidak deterministik. Jika C1 lebih lambat dari C2, maka set pesan awal dapat diproses sebagai [B, D, A, C].

Perilaku ini dapat mengejutkan pemula yang mengharapkan pesan diproses secara berurutan dan, atas dasar ini, sedang mengembangkan aplikasi perpesanan mereka sendiri. Persyaratan bahwa pesan yang dikirim oleh pengirim yang sama diproses dalam urutan relatif satu sama lain, juga dikenal sebagai pemesanan kausal , cukup umum.

Ambil contoh penggunaan berikut yang diambil dari taruhan online sebagai contoh:

1. Akun pengguna sudah dikonfigurasikan.
2. Uang dikreditkan ke akun.
3. Taruhan dibuat yang menarik uang dari akun.

Masuk akal di sini bahwa pesan-pesan tersebut diproses sesuai urutan pengirimannya, sehingga keadaan umum akun diperhitungkan. Hal-hal aneh dapat terjadi jika sistem mencoba mengeluarkan uang dari akun yang tidak memiliki dana. Tentu saja ada beberapa cara untuk mengatasi hal ini.

Model pelanggan eksklusif termasuk mengirim semua pesan dari antrian ke satu pelanggan. Menggunakan pendekatan ini, ketika menghubungkan beberapa instance aplikasi atau utas ke antrian, mereka ditandatangani menggunakan parameter penerima khusus: my.queue?consumer.exclusive=true . Ketika Anda menghubungkan konsumen monopoli, ia menerima semua pesan. Ketika konsumen kedua terhubung, ia tidak akan menerima pesan apa pun sampai yang pertama terputus. Konsumen kedua ini sebenarnya cadangan panas, sementara konsumen pertama sekarang akan menerima pesan persis dalam urutan di mana mereka direkam dalam jurnal - dalam urutan sebab-akibat.
Kelemahan dari pendekatan ini adalah bahwa meskipun pemrosesan pesan konsisten, ini adalah hambatan kinerja karena semua pesan harus diproses oleh satu kompurator.

Untuk memahami use case ini dengan lebih cerdas, Anda perlu mempertimbangkan kembali masalahnya. Apakah semua pesan harus diproses secara berurutan? Dalam hal memproses tawaran yang dijelaskan di atas, hanya perlu memproses pesan yang terkait dengan satu akun secara berurutan. ActiveMQ menyediakan mekanisme untuk menangani situasi ini yang disebut grup pesan JMS .

Grup pesan adalah semacam mekanisme partisi yang memungkinkan produsen untuk mendistribusikan pesan ke dalam grup yang akan diproses secara berurutan sesuai dengan kunci bisnis. Kunci bisnis ini diatur dalam properti pesan yang disebut JMSXGroupID .

Kunci alami dalam hal memproses tawaran akan menjadi pengidentifikasi akun.
Untuk mengilustrasikan cara kerja pengiriman, pertimbangkan satu set pesan yang tiba dengan urutan sebagai berikut:

 [(A, Group1), (B, Group1), (C, Group2), (D, Group3), (E, Group2)] 

Ketika pesan diproses oleh mekanisme pengiriman di ActiveMQ dan ia melihat JMSXGroupID yang tidak ada sebelumnya, kunci ini diberikan kepada konsumen berdasarkan siklus. Mulai sekarang, semua pesan dengan kunci ini akan dikirim ke akuntan ini.

Di sini grup akan ditugaskan di antara dua konsumen: C1 dan C2, sebagai berikut:

 C1: [Group1, Group3] C2: [Group2] 

Pesan akan dialihkan dan diproses sebagai berikut:

 C2: [B, D] C2: [(C, Group2), (E, Group2)] 

Jika konsumen mogok, maka semua grup yang ditugaskan kepadanya akan didistribusikan kembali di antara sisa konsumen dan pesan yang tidak dikonfirmasi akan diarahkan kembali. Oleh karena itu, meskipun kami dapat menjamin bahwa semua pesan terkait akan diproses secara berurutan, kami tidak dapat mengklaim bahwa pesan tersebut akan diproses oleh konsumen yang sama.

Ketersediaan Tinggi

ActiveMQ menyediakan ketersediaan tinggi dengan master-slave berdasarkan penyimpanan bersama. Dalam skema ini, dua atau lebih broker (walaupun biasanya dua) dikonfigurasikan pada server yang terpisah, dan pesan mereka disimpan di toko pesan yang terletak di lokasi eksternal. Toko pesan tidak dapat digunakan secara bersamaan oleh beberapa contoh broker, oleh karena itu fungsi sekundernya (gudang) adalah bertindak sebagai mekanisme pemblokiran untuk menentukan broker mana yang akan mendapatkan akses eksklusif ( Gambar 2-6 ).


Gambar 2-6. Broker A adalah pemimpinnya, broker B bersiaga sebagai budak

Untuk terhubung ke repositori, broker pertama (Broker A) mengambil peran sebagai pemimpin dan membuka port-nya untuk lalu lintas pesan. Ketika broker kedua (Broker B) terhubung ke repositori, ia mencoba untuk mendapatkan kunci dan, karena ia tidak berhasil, berhenti untuk waktu yang singkat sebelum mencoba untuk mendapatkan kunci lagi. Ini disebut kendali yang dikendalikan.

Pada saat yang sama, klien berganti alamat dua broker dalam upaya untuk terhubung ke port inbound, yang dikenal sebagai konektor transportasi. Segera setelah broker utama tersedia, klien terhubung ke port-nya dan dapat mengirim dan membaca pesan.
Ketika Broker A, bertindak sebagai pemimpin, gagal karena kegagalan proses ( Gambar 2-7 ), peristiwa berikut terjadi:

1. Klien terputus dan segera mencoba untuk menyambung kembali, bergantian alamat dua broker.
2. Kunci dalam pesan dilepaskan. Pengaturan waktu ini tergantung pada implementasi penyimpanan.
3. Broker B, yang berada dalam mode slave, secara berkala mencoba mendapatkan kunci, akhirnya berhasil dan mengasumsikan peran master, membuka portalnya.
4. Klien terhubung ke Broker B dan melanjutkan pekerjaannya.

Gambar 2-7. Broker A berakhir dengan kehilangan koneksi ke repositori. Broker B yang memimpin

Logika pergantian antara beberapa alamat pialang tidak dijamin untuk dibangun ke pustaka klien, seperti halnya dalam implementasi JMS / NMS / CMS. Jika perpustakaan hanya menyediakan koneksi ulang ke satu alamat, maka Anda mungkin perlu menempatkan beberapa broker di belakang penyeimbang beban, yang juga harus sangat tersedia.

Kerugian utama dari pendekatan ini adalah bahwa untuk menyederhanakan pekerjaan satu broker logis, diperlukan beberapa server fisik. Dalam hal ini, salah satu dari dua server broker menganggur, menunggu pemutusan mitra sebelum dapat mulai bekerja.

Pendekatan ini juga memiliki kompleksitas tambahan yang digunakan penyimpanan broker, apakah itu sistem file jaringan bersama atau database, juga harus sangat mudah diakses. Ini mengarah pada biaya tambahan untuk peralatan dan administrasi pengaturan broker. Dalam skenario ini, tergoda untuk menggunakan kembali repositori ketersediaan tinggi yang ada yang digunakan oleh bagian lain dari infrastruktur, seperti database, tetapi ini adalah kesalahan.

Penting untuk diingat bahwa disk adalah pembatas utama pada keseluruhan kinerja broker. Jika disk itu sendiri secara bersamaan digunakan oleh proses selain dari pialang pesan, maka interaksi proses ini dengan disk mungkin memperlambat perekaman dari pialang dan, oleh karena itu, kecepatan di mana pesan dapat melalui sistem. Perlambatan seperti itu sulit untuk didiagnosis dan satu-satunya cara mengatasinya adalah dengan memisahkan kedua proses menjadi volume penyimpanan yang berbeda.

Untuk memastikan operasi broker yang stabil, penyimpanan khusus dan berdedikasi diperlukan.

Penskalaan vertikal dan horizontal

Pada titik tertentu dalam kehidupan proyek, Anda mungkin menemukan batasan kinerja pada pialang pesan. Batasan ini biasanya terkait dengan sumber daya, khususnya interaksi ActiveMQ dengan penyimpanan yang digunakan. Masalah-masalah ini biasanya muncul karena konflik volume atau bandwidth pesan antara penerima, misalnya, ketika satu antrian meluap broker selama periode puncak.

Ada beberapa cara untuk mendapatkan lebih banyak kinerja dari infrastruktur broker:

• Jangan gunakan ketekunan jika tidak diperlukan. Beberapa skenario penggunaan memungkinkan hilangnya pesan selama crash, terutama ketika satu sistem mengirim keadaan snapshot penuh lain ke yang lain melalui antrian, baik secara berkala atau sesuai permintaan.
• Jalankan broker pada drive yang lebih cepat. Dalam kondisi nyata, perbedaan signifikan dalam perekaman bandwidth dicatat antara HDD standar dan alternatif berbasis memori.
• Manfaatkan ukuran disk sebaik mungkin. Seperti yang ditunjukkan dalam model interaksi jalur pipa disk yang dijelaskan di atas, throughput yang lebih tinggi dapat dicapai dengan menggunakan transaksi untuk mengirim grup pesan, sehingga menggabungkan beberapa operasi penulisan menjadi satu yang lebih besar.
• Gunakan partisi lalu lintas. Anda dapat mencapai throughput yang lebih tinggi dengan memisahkan tujuan dengan salah satu cara berikut:

1. Beberapa disk dalam satu broker, misalnya, menggunakan adaptor persistensi mKahaDB untuk beberapa direktori, yang masing-masing dipasang pada disk terpisah.
2. Beberapa broker, dan pembagian lalu lintas dilakukan secara manual oleh aplikasi klien. ActiveMQ tidak menyediakan fungsi asli untuk tujuan ini.

Salah satu penyebab paling umum dari masalah kinerja broker hanyalah upaya untuk melakukan terlalu banyak dengan satu contoh. Sebagai aturan, ini terjadi dalam situasi di mana broker secara naif dibagi antara beberapa aplikasi tanpa memperhitungkan beban yang ada pada broker atau memahami volume. Seiring waktu, satu broker dimuat lebih dan lebih sampai dia berhenti berperilaku tepat.

Masalahnya sering muncul selama fase desain sistem, ketika arsitek sistem dapat mengusulkan skema seperti pada Gambar 2-8 .


Gambar 2-8. Pandangan Konseptual tentang Infrastruktur Pesan

Tujuannya adalah agar beberapa aplikasi saling berkomunikasi secara asinkron melalui ActiveMQ. Tujuannya tidak lagi ditentukan dan kemudian skema menentukan dasar dari konfigurasi broker nyata. Pendekatan ini disebut Pipa Data Universal.

Ini tidak memperhitungkan langkah fundamental analisis antara desain konseptual yang disebutkan di atas dan implementasi fisik. Sebelum melanjutkan dengan konstruksi konfigurasi tertentu, perlu untuk melakukan analisis, yang kemudian akan digunakan untuk membenarkan proyek fisik. Langkah pertama dalam proses ini adalah menentukan sistem yang berinteraksi satu sama lain - diagram yang cukup sederhana dengan persegi panjang dan panah ( Gambar 2-9 ).


Gambar 2-9. Pesan sketsa mengalir antar sistem

Setelah disetujui, Anda dapat pergi ke detail untuk menjawab pertanyaan-pertanyaan berikut:

• Berapa banyak antrian dan topik yang akan digunakan?
• Volume pesan apa yang diharapkan untuk masing-masingnya?
• Seberapa besar pesan di masing-masing penerima? Pesan besar dapat menyebabkan masalah dalam proses paging, menyebabkan melebihi batas memori dan memblokir broker.
• Apakah pesan mengalir seragam sepanjang hari atau akan ada lonjakan karena pekerjaan batch? Batch besar dalam satu antrian yang kurang digunakan dapat mengganggu penulisan disk yang tepat waktu untuk tujuan berkinerja tinggi.
• Apakah sistem di pusat data yang sama atau berbeda? Komunikasi jarak jauh melibatkan beberapa jenis pialang jaringan.

Idenya adalah untuk menentukan skenario perpesanan terpisah yang dapat digabungkan atau dibagi oleh masing-masing broker ( Gambar 2-10 ).
Setelah pemecahan seperti itu, skenario penggunaan dapat disimulasikan dengan menggabungkan satu sama lain menggunakan Modul Kinerja ActiveMQ untuk mengidentifikasi masalah.


Gambar 2-10. Identifikasi masing-masing broker

Setelah menentukan jumlah pialang logis yang tepat, Anda dapat menentukan bagaimana menerapkannya pada tingkat fisik menggunakan konfigurasi yang sangat mudah diakses dan jaringan pialang.

Ringkasan

Dalam bab ini, kami memeriksa mekanisme yang digunakan ActiveMQ untuk menerima dan mendistribusikan pesan. Kami membahas fitur-fitur yang didukung oleh arsitektur ini, termasuk stick-load balancing pesan dan transaksi terkait. Pada saat yang sama, kami memperkenalkan serangkaian konsep yang umum untuk semua sistem pengiriman pesan, termasuk protokol komunikasi dan majalah. Kami juga memeriksa secara rinci kesulitan yang terlibat dalam penulisan ke disk dan bagaimana broker dapat menggunakan teknik seperti penulisan paket untuk meningkatkan kinerja. Akhirnya, kami memeriksa bagaimana ActiveMQ dapat dibuat sangat tersedia dan bagaimana mengukurnya di luar kemampuan masing-masing broker.

Pada bab selanjutnya, kita akan melihat Apache Kafka dan bagaimana arsitekturnya mendefinisikan kembali hubungan antara klien dan broker untuk memberikan pipa pesan yang sangat kuat dengan bandwidth yang berkali-kali lebih besar daripada broker pesan biasa. Kami akan membahas fungsionalitas yang digunakannya untuk mencapai tujuan ini, dan secara singkat mempertimbangkan arsitektur aplikasi yang menyediakan fungsionalitas ini.

Bagian selanjutnya: Memahami Pialang Pesan. Mempelajari mekanisme pengiriman pesan melalui ActiveMQ dan Kafka. Bab 3. Kafka

Terjemahan selesai: tele.gg/middle_java