Artikel ini pertama-tama mengarah pada masalah apa yang biasanya perlu dipecahkan oleh middleware pesan, kesulitan apa yang akan dihadapi dalam memecahkan masalah ini, apakah Apache RocketMQ dapat diselesaikan sebagai middleware pesan terdistribusi berkinerja tinggi dan throughput tinggi open source oleh Alibaba, dan bagaimana masalah ini didefinisikan dalam spesifikasi. Artikel ini kemudian akan memperkenalkan desain arsitektur RocketMQ, untuk memberi pembaca pemahaman cepat tentang RocketMQ.
1. Masalah apa yang perlu diselesaikan oleh middleware pesan? Publikasi/Berlangganan adalah fungsi paling dasar dari middleware pesan dan juga relatif terhadap komunikasi RPC tradisional. Saya tidak akan membahas detail di sini.
Prioritas yang dijelaskan dalam spesifikasi Prioritas Pesan mengacu pada antrean pesan, setiap pesan memiliki prioritas yang berbeda, umumnya dijelaskan oleh bilangan bulat, pesan dengan prioritas tinggi dikirimkan terlebih dahulu, jika pesan sepenuhnya dalam antrean memori, maka dapat diurutkan sesuai dengan prioritas sebelum pengiriman, sehingga prioritas tinggi dikirimkan terlebih dahulu.
Karena semua pesan di RocketMQ persisten, jika diurutkan sesuai dengan prioritas, overhead akan sangat besar, sehingga RocketMQ tidak secara khusus mendukung prioritas pesan, tetapi dapat mengimplementasikan fungsi serupa dalam solusi, yaitu mengonfigurasi antrean dengan prioritas tinggi dan antrian dengan prioritas normal, dan mengirim prioritas yang berbeda ke antrean yang berbeda.
Untuk masalah prioritas, mereka dapat diringkas menjadi 2 kategori:
- Selama prioritas tercapai, itu bukan prioritas dalam arti yang ketat, dan prioritas biasanya dibagi menjadi tinggi, sedang, rendah, atau beberapa level lebih. Setiap prioritas dapat diwakili oleh topik yang berbeda, dan saat mengirim pesan, tentukan topik yang berbeda untuk mewakili prioritas, yang dapat memecahkan sebagian besar masalah prioritas, tetapi membahayakan keakuratan prioritas bisnis.
- Prioritas ketat, prioritas dinyatakan sebagai bilangan bulat, seperti 0 ~ 65535, masalah prioritas semacam ini umumnya tidak cocok untuk diselesaikan dengan topik yang berbeda. Jika Anda ingin MQ menyelesaikan masalah ini, maka akan berdampak sangat besar pada kinerja MQ. Inilah poin untuk memastikan bahwa bisnis benar-benar membutuhkan prioritas ketat ini, dan jika prioritas dikompresi menjadi sedikit, seberapa besar dampaknya terhadap bisnis?
Urutan Pesan mengacu pada jenis pesan yang dapat digunakan dalam urutan pengirimannya. Misalnya, pesanan menghasilkan 3 pesan, yaitu pembuatan pesanan, pembayaran pesanan, dan penyelesaian pesanan. Saat mengkonsumsi, berarti untuk mengonsumsi dalam urutan ini. Tetapi pada saat yang sama, pesanan dapat dikonsumsi secara paralel.
RocketMQ dapat secara ketat memastikan bahwa pesan teratur.
Filter PesanPemfilteran pesan broker
Di Broker, penyaringan sesuai dengan kebutuhan konsumen memiliki keuntungan untuk mengurangi transmisi pesan yang tidak perlu kepada konsumen.
Kerugiannya adalah meningkatkan beban pada broker dan relatif rumit untuk diterapkan.
1. Taobao Notify mendukung berbagai metode pemfilteran, termasuk pemfilteran langsung berdasarkan jenis pesan dan pemfilteran ekspresi sintaks yang fleksibel, yang dapat memenuhi kebutuhan pemfilteran yang hampir paling menuntut.
2. Taobao RocketMQ mendukung pemfilteran berdasarkan Tag Pesan sederhana, serta Header dan isi Pesan.
3. Pemfilteran ekspresi sintaks fleksibel juga didukung dalam spesifikasi Pemberitahuan CORBA.
Pemfilteran pesan sisi konsumen
Pemfilteran ini dapat sepenuhnya disesuaikan oleh aplikasi, tetapi kelemahannya adalah banyak pesan yang tidak berguna yang dikirim ke konsumen.
Ada beberapa metode persistensi umum yang digunakan oleh persistensi pesan:
- Bertahan ke database, seperti Mysql.
- Bertahan ke penyimpanan KV, seperti levelDB, Berkeley DB, dan sistem penyimpanan KV lainnya.
- Persistensi dalam bentuk catatan file, seperti Kafka, RocketMQ
- Buat gambar data memori yang dipertahankan, seperti beanstalkd, VisiNotify
- (1), (2), dan (3) ketiga metode persistensi memiliki kemampuan untuk memperluas buffer antrean memori, dan (4) hanyalah gambar memori, yang masih dapat memulihkan data dari memori sebelumnya setelah broker menutup telepon dan memulai ulang.
Spesifikasi Pemberitahuan JMS dan CORBA tidak secara eksplisit menentukan cara bertahan, tetapi performa bagian persistensi secara langsung menentukan performa seluruh middleware pesan.
RocketMQ memanfaatkan sepenuhnya cache memori sistem file Linux untuk meningkatkan kinerja.
Ada beberapa situasi di mana Reliablity Pesan memengaruhi keandalan pesan:
- Broker ditutup secara normal
- Kerusakan broker
- OS Crash
- Mesin kehilangan daya, tetapi catu daya dapat segera dipulihkan.
- Mesin tidak mau menyala (mungkin rusak pada perangkat utama seperti CPU, motherboard, memori, dll.)
- Kerusakan perangkat disk.
(1), (2), (3), dan (4) adalah situasi di mana sumber daya perangkat keras dapat segera dipulihkan, dan RocketMQ dapat memastikan bahwa pesan tidak hilang atau sejumlah kecil data hilang (tergantung pada apakah metode flashing sinkron atau asinkron).
(5) (6) Ini adalah titik kegagalan tunggal dan tidak dapat dipulihkan, begitu terjadi, semua pesan pada titik tunggal ini hilang. Dalam kedua kasus tersebut, RocketMQ memastikan bahwa 99% pesan tidak hilang melalui replikasi asinkron, tetapi masih ada sangat sedikit pesan yang mungkin hilang. Teknologi penulisan ganda sinkron dapat sepenuhnya menghindari titik tunggal, yang pasti akan memengaruhi kinerja, sehingga cocok untuk situasi dengan persyaratan keandalan pesan yang sangat tinggi, seperti aplikasi terkait Uang.
RocketMQ mendukung penulisan ganda sinkron mulai dari versi 3.0.
Pesan Latensi Rendah dapat menjangkau konsumen segera setelah pesan sampai ke broker tanpa akumulasi pesan.
RocketMQ menggunakan metode penarikan polling yang panjang untuk memastikan bahwa pesan tersebut sangat real-time, dan pesan real-time tidak lebih rendah dari push.
Setidaknya sekali berarti bahwa setiap pesan harus dikirimkan sekali.
RocketMQ Consumer pertama-tama menarik pesan ke area lokal, dan kemudian mengembalikan ack ke server setelah konsumsi selesai.
Tepat Hanya Sekali- Tahap pengiriman pesan tidak mengizinkan pengiriman pesan duplikat.
- Pada tahap Konsumsi Pesan, pesan duplikat tidak diizinkan untuk dikonsumsi.
Hanya ketika dua kondisi di atas terpenuhi, pesan tersebut dapat dianggap "Tepat Hanya Sekali", dan untuk mencapai dua poin di atas, overhead besar pasti akan dihasilkan di lingkungan sistem terdistribusi. Oleh karena itu, untuk mengejar kinerja tinggi, RocketMQ tidak menjamin fitur ini, dan memerlukan deduplikasi dalam bisnis, yang berarti pesan konsumen harus idempoten. Meskipun RocketMQ tidak dapat secara ketat menjamin non-duplikasi, dalam keadaan normal, jarang ada pengiriman dan konsumsi berulang, hanya kelainan jaringan, mulai dan berhenti konsumen, dan situasi abnormal lainnya seperti duplikasi pesan.
Alasan utama untuk masalah ini adalah bahwa ada ketidakpastian dalam panggilan jaringan, yaitu keadaan ketiga baik tidak berhasil atau gagal, sehingga masalah pengulangan pesan muncul.
Apa yang harus saya lakukan jika Buffer Broker penuh? Buffer broker biasanya mengacu pada ukuran buffer memori antrian di broker, yang biasanya ukurannya terbatas, bagaimana jika buffer penuh?
Berikut cara penanganannya dalam spesifikasi Pemberitahuan CORBA:
- RejectNewEvents menolak pesan baru dan mengembalikan kode kesalahan RejectNewEvents ke Produser.
- Buang pesan yang ada sesuai dengan kebijakan tertentu
- AnyOrder - Acara apa pun dapat dibuang saat meluap. Ini adalah pengaturan default untuk properti ini.
- FifoOrder - Acara pertama yang diterima akan menjadi yang pertama dibuang.
- LifoOrder - Acara terakhir yang diterima akan menjadi yang pertama dibuang.
- PrioritasOrder - Peristiwa harus dibuang dalam urutan prioritas, sehingga peristiwa prioritas yang lebih rendah akan dibuang sebelum peristiwa prioritas yang lebih tinggi.
- DeadlineOrder - Acara harus dibuang dalam urutan tenggat waktu kedaluwarsa terpendek terlebih dahulu.
RocketMQ tidak memiliki konsep buffer memori, dan antrean RocketMQ adalah disk persisten, dan data dihapus secara teratur.
Untuk solusi masalah ini, RocketMQ memiliki perbedaan yang sangat signifikan dari MQ lainnya, Buffer memori RocketMQ diabstraksi menjadi antrian panjang tak terbatas, tidak peduli berapa banyak data yang masuk, dapat diinstal, infinity ini dipremiskan, broker akan secara teratur menghapus data kedaluwarsa, misalnya broker hanya menyimpan pesan selama 3 hari, maka meskipun panjang Buffer ini tidak terbatas, tetapi data dari 3 hari yang lalu akan dihapus dari akhir antrian.
Konsumsi retrospektif mengacu pada pesan bahwa konsumen telah berhasil mengkonsumsi, dan pesan tersebut perlu dikonsumsi kembali karena permintaan bisnis. Misalnya, karena kegagalan sistem konsumen, data dari 1 jam yang lalu perlu dikonsumsi kembali setelah pemulihan, maka broker harus menyediakan mekanisme untuk mengembalikan kemajuan konsumsi sesuai dengan dimensi waktu.
RocketMQ mendukung konsumsi retrospektif berdasarkan waktu, dengan dimensi waktu akurat hingga milidetik, yang dapat dilacak mundur ke depan atau ke belakang.
Fungsi utama middleware pesan penumpukan pesan adalah decoupling asinkron, dan fungsi penting lainnya adalah untuk memblokir puncak banjir data dari front-end dan memastikan stabilitas sistem back-end, yang mengharuskan middleware pesan memiliki kemampuan penumpukan pesan tertentu, dan tumpukan pesan mengintegrasikan dua situasi berikut:
- Pesan ditumpuk di buffer memori, dan setelah melebihi buffer memori, pesan dapat dijatuhkan sesuai dengan kebijakan drop tertentu, seperti yang dijelaskan dalam spesifikasi Pemberitahuan CORBA. Sangat cocok untuk layanan yang dapat mentolerir membuang pesan, dalam hal ini, kapasitas akumulasi pesan terutama terletak pada ukuran buffer memori, dan penurunan kinerja tidak akan terlalu besar setelah pesan ditumpuk, karena jumlah data dalam memori memiliki dampak terbatas pada kemampuan akses yang diberikan ke dunia luar.
- Pesan ditumpuk dalam sistem penyimpanan persisten seperti DB, penyimpanan KV, bentuk catatan file. Ketika pesan tidak dapat ditekan di cache memori, tidak dapat dihindari untuk mengakses disk, yang akan menghasilkan sejumlah besar IO baca, dan throughput IO baca secara langsung menentukan kemampuan akses pesan setelah menumpuk.
Ada empat poin utama untuk mengevaluasi kemampuan akumulasi pesan:
- Berapa banyak pesan yang bisa ditumpuk, berapa byte? Artinya, kapasitas tumpukan pesan.
- Setelah pesan menumpuk, apakah throughput pesan dipengaruhi oleh penumpukan?
- Apakah konsumsi normal konsumen akan terpengaruh setelah pesan menumpuk?
- Setelah pesan menumpuk, berapa throughput saat mengakses pesan yang menumpuk di disk?
Transaksi Terdistribusi Beberapa spesifikasi transaksi terdistribusi yang diketahui, seperti XA, JTA, dll. Diantaranya, spesifikasi XA banyak didukung oleh vendor database besar, seperti Oracle, Mysql, dll. Di antara mereka, pemimpin implementasi TM XA seperti Oracle Tuxedo banyak digunakan di bidang keuangan, telekomunikasi, dan bidang lainnya.
Transaksi terdistribusi melibatkan masalah commit dua tahap, dan dalam hal penyimpanan data, penyimpanan KV harus didukung, karena tahap kedua dari pengembalian komit perlu memodifikasi status pesan, yang harus melibatkan tindakan menemukan pesan sesuai dengan kunci. RocketMQ melewati masalah menemukan pesan sesuai dengan kunci pada tahap kedua, menggunakan tahap pertama untuk mengirim pesan yang disiapkan, mendapatkan offset pesan, dan tahap kedua untuk mengakses pesan melalui offset dan memodifikasi status, offset adalah alamat data.
Metode implementasi transaksi RocketMQ tidak dilakukan melalui penyimpanan KV, tetapi melalui metode offset yang memiliki kekurangan yang signifikan, yaitu mengubah data melalui offset akan menyebabkan terlalu banyak halaman kotor dalam sistem, yang membutuhkan perhatian khusus.
Pesan terjadwal Pesan terjadwal berarti bahwa pesan tidak dapat dikonsumsi oleh konsumen segera setelah dikirim ke broker, dan hanya dapat digunakan pada titik waktu tertentu atau setelah menunggu waktu tertentu.
Jika Anda ingin mendukung akurasi waktu sewenang-wenang, di tingkat broker, Anda harus melakukan penyortiran pesan, dan jika persistensi terlibat, maka penyortiran pesan pasti akan menimbulkan overhead kinerja yang sangat besar.
RocketMQ mendukung pesan waktu, tetapi tidak mendukung akurasi waktu sewenang-wenang, dan mendukung level tertentu, seperti waktu 5 detik, 10 detik, 1 m, dll.
Coba Lagi Pesan Setelah konsumen gagal menggunakan pesan, berikan mekanisme coba lagi untuk membuat pesan digunakan lagi. Kegagalan pesan konsumsi konsumen biasanya dapat dipertimbangkan dalam situasi berikut:
- Karena alasan pesan itu sendiri, seperti kegagalan deserialisasi, data pesan itu sendiri tidak dapat diproses (seperti isi ulang tagihan telepon, nomor ponsel pesan saat ini keluar, tidak dapat diisi ulang), dll. Kesalahan ini biasanya mengharuskan melewati pesan ini dan mengonsumsi pesan lain, dan pesan yang gagal ini 99% tidak berhasil bahkan jika konsumsi segera dicoba ulang, jadi yang terbaik adalah menyediakan mekanisme coba ulang berwaktu, yaitu coba lagi setelah 10 detik.
- Karena layanan aplikasi hilir dependen tidak tersedia, seperti koneksi DB tidak tersedia, jaringan sistem eksternal tidak dapat dijangkau, dll. Saat mengalami kesalahan ini, meskipun pesan gagal saat ini dilewati, pesan lain juga akan digunakan. Dalam hal ini, disarankan untuk menerapkan tidur 30 detik dan mengonsumsi pesan berikutnya, yang dapat mengurangi tekanan pada broker untuk mencoba kembali pesan.
Ikhtisar RocketMQMari kita cari tahu apakah RocketMQ memecahkan masalah yang dihadapi oleh middleware pesan yang disebutkan di atas.
Apa itu RocketMQ?
Gambar di atas adalah model khas pengiriman dan penerimaan pesan middleware pesan, RocketMQ juga dirancang dengan cara ini, singkatnya, RocketMQ memiliki karakteristik sebagai berikut:
- Ini adalah middleware pesan model antrian dengan kinerja tinggi, keandalan tinggi, real-time tinggi, dan karakteristik terdistribusi.
- Produsen, Konsumen, dan Antrian semuanya dapat didistribusikan.
- Produsen mengirim pesan ke beberapa antrean secara bergantian, kumpulan antrean disebut Topik, Konsumen Jika konsumsi siaran, satu instans konsumen menggunakan semua antrean yang sesuai dengan topik ini, dan jika konsumsi kluster, beberapa instans konsumen menggunakan kumpulan antrean yang sesuai dengan topik ini secara merata.
- Urutan pesan yang ketat dapat dijamin
- Menyediakan mode tarik pesan yang kaya
- Kemampuan penskalaan pelanggan horizontal yang efisien
- Mekanisme langganan pesan real-time
- Kapasitas akumulasi ratusan juta pesan
- Lebih sedikit dependensi
Struktur penyebaran fisik RocketMQ
Seperti yang ditunjukkan pada gambar di atas, struktur penyebaran RocketMQ memiliki karakteristik sebagai berikut:
- Name Server adalah simpul tanpa kewarganegaraan yang dapat disebarkan dalam kluster tanpa sinkronisasi informasi antar simpul.
- Penyebaran Broker relatif rumit, Broker dibagi menjadi Master dan Slave, Master dapat berhubungan dengan beberapa Slave, tetapi Slave hanya dapat berhubungan dengan satu Master, korespondensi antara Master dan Slave didefinisikan dengan menentukan BrokerName yang sama, BrokerId yang berbeda, BrokerId adalah 0 untuk Master, dan non-0 berarti Slave. Master juga dapat digunakan dalam beberapa. Setiap broker membuat koneksi panjang dengan semua simpul dalam kluster Server Nama dan mendaftarkan informasi topik ke semua Server Nama secara berkala.
- Produser membuat koneksi panjang dengan salah satu simpul di kluster Server Nama (dipilih secara acak), secara berkala mengambil informasi perutean topik dari Server Nama, membuat koneksi panjang ke master yang menyediakan layanan topik, dan mengirim detak jantung ke master secara berkala. Producer benar-benar stateless dan dapat disebarkan dalam kluster.
- Konsumen membuat koneksi panjang dengan salah satu simpul dalam kluster Server Nama (dipilih secara acak), secara teratur mengambil informasi perutean topik dari Server Nama, dan membuat koneksi panjang ke Master dan Slave yang menyediakan layanan topik, dan mengirim detak jantung ke Master dan Slave secara berkala. Konsumen dapat berlangganan pesan dari Master dan Slave, dan aturan langganan ditentukan oleh konfigurasi Broker.
Struktur penyebaran logis RocketMQ
Seperti yang ditunjukkan pada gambar di atas, struktur penerapan logis RocketMQ memiliki dua karakteristik: Produsen dan Konsumen.
Digunakan untuk mewakili aplikasi perpesanan, Grup Produsen berisi beberapa instans Produser, yang dapat berupa beberapa mesin, beberapa proses mesin, atau beberapa objek Produser dari suatu proses. Grup Produsen dapat mengirim beberapa pesan Topik, dan Grup Produsen berfungsi sebagai berikut:
- Mengidentifikasi jenis Produsen
- Anda dapat mengkueri apakah ada beberapa instans Producer dalam aplikasi perpesanan ini melalui alat O&M
- Saat mengirim pesan transaksi terdistribusi, jika produsen turun secara tak terduga, broker akan secara aktif memanggil kembali mesin mana pun di grup produsen untuk mengonfirmasi status transaksi.
Digunakan untuk mewakili aplikasi perpesanan konsumen, grup konsumen berisi beberapa instans konsumen, yang dapat berupa beberapa mesin, beberapa proses, atau beberapa objek konsumen dari suatu proses. Beberapa Konsumen dalam Grup Konsumen mengonsumsi pesan dengan cara yang didistribusikan secara merata, dan jika diatur untuk disiarkan, setiap instans di bawah Grup Konsumen ini menggunakan jumlah penuh data.
Struktur penyimpanan data RocketMQ
Seperti yang ditunjukkan pada gambar di atas, RocketMQ mengadopsi metode penyimpanan yang memisahkan data dari indeks. Secara efektif mengurangi hilangnya sumber daya file, sumber daya IO, dan sumber daya memori. Bahkan dengan data besar seperti Alibaba, skenario konkurensi tinggi dapat secara efektif mengurangi latensi end-to-end dan memiliki kemampuan penskalaan horizontal yang kuat.
|
Diposting pada 28/07/2017 20.26.52
|
|
|
|
Diposting pada 29/07/2017 08.09.37