Pengantar protokol AMQP
AMQP (Advanced Message Queuing Protocol) adalah protokol standar lapisan aplikasi yang menyediakan layanan pesan terpadu, dan merupakan standar terbuka untuk protokol lapisan aplikasi yang dirancang untuk middleware berorientasi pesan. AMQP adalah protokol jaringan untuk meneruskan pesan asinkron antar proses.
Klien dan middleware pesan berdasarkan protokol ini dapat mengirimkan pesan tanpa dibatasi oleh produk klien/middleware yang berbeda, bahasa pengembangan yang berbeda, dll.
Karakteristik utama AMQP adalah berorientasi pesan, antrian, perutean (termasuk peer-to-peer dan publikasi/langganan), keandalan, dan keamanan. AMQP menegakkan perilaku penyedia pesan dan klien, memungkinkan interoperabilitas sejati antara vendor yang berbeda.
AMQP dan JMS
JMS adalah upaya untuk menstandarkan middleware pesan awal, hanya distandarisasi di tingkat API, dan jauh dari menciptakan interoperabilitas.
Tidak seperti JMS, AMQP adalah protokol tingkat kawat yang menggambarkan format data yang ditransmisikan melalui jaringan, mengalir dalam byte. Akibatnya, alat apa pun yang mematuhi format data ini, yang membuat dan menafsirkan pesan, dapat dioperasikan dengan alat lain yang kompatibel.
Komposisi inti AMQP
Produser
Berita produksi.
Pabrik Koneksi
Pabrik yang memproduksi Connection.
Sambungan
Koneksi, koneksi jaringan aplikasi dengan Broker TCP / IP / Triple Handshake dan Quad Wave.
Koneksi AMQP biasanya koneksi panjang. AMQP adalah protokol lapisan aplikasi yang menggunakan TCP untuk memberikan pengiriman yang andal. AMQP menggunakan mekanisme autentikasi dan menyediakan perlindungan TLS (SSL). Ketika aplikasi tidak perlu lagi terhubung ke proxy AMQP, aplikasi perlu melepaskan koneksi AMQP dengan anggun alih-alih hanya mematikan koneksi TCP.
Channel
Saluran jaringan adalah koneksi ringan yang dibangun di atas Koneksi. Hampir semua operasi dilakukan di Saluran, yang merupakan saluran untuk membaca dan menulis pesan, dan klien dapat membuat pasangan untuk setiap saluran, yang masing-masing mewakili tugas sesi.
Jika Koneksi dibandingkan dengan kabel serat optik, maka saluran Saluran dibandingkan dengan salah satu serat dalam kabel serat optik. Sejumlah saluran dapat dibuat di Koneksi.
Sebagian besar operasi bisnis kami dilakukan di antarmuka Saluran, termasuk:
- antrianDeklarasikan
- PertukaranDeklarasikan untuk sakelar
- queueBind queueBind
- Menerbitkan dasar pesanPublikasikan
- Berita konsumendasarKonsumsi, dll.
Pialang
Terima koneksi klien untuk mengimplementasikan layanan entitas AMQP, seperti rabbitmq.
VirtualHost (Hosting Web)
Hosting virtual, digunakan untuk isolasi logis, host virtual dapat memiliki beberapa pertukaran dan antrian, dan host virtual yang sama tidak dapat memiliki pertukaran dengan nama yang sama.
Untuk mengimplementasikan beberapa lingkungan terisolasi (pengguna, grup pengguna, sakelar, antrian, dll.) pada satu proxy, AMQP menyediakan konsep host virtual (host virtual - vhost). Ini sangat mirip dengan konsep hosting web server, yang menyediakan lingkungan yang benar-benar terisolasi untuk entitas AMQP. Saat koneksi dibuat, klien AMQP menentukan host virtual mana yang akan digunakan.
Tukar
Pengalih, menerima pesan, dan mengirim pesan ke antrean terikat berdasarkan kunci perutean (tanpa kemampuan penyimpanan pesan).
Sakelar adalah entitas AMQP yang digunakan untuk mengirim pesan. Setelah sakelar mendapatkan pesan, itu merutekannya ke satu atau nol antrian. Algoritma perutean yang digunakannya ditentukan oleh jenis sakelar dan aturan pengikatan.
Jenis Sakelar:
- Pertukaran langsung
- Pertukaran fanout
- Pertukaran topik
- Pertukaran header
Properti Switch:
- Nama: Nama sakelar
- Daya tahan: Bendera persistensi yang menunjukkan apakah pengalihan ini dipertahankan atau tidak
- Hapus otomatis: Hapus bendera, menunjukkanKetika semua antrean selesai menggunakan pertukaran ini, apakah mereka dihapus
- Argumen: Tergantung pada agen itu sendiri
Beralih Status:
Sakelar persisten akan ada setelah broker dimulai ulang, sedangkan sakelar pementasan tidak akan ada (mereka perlu dideklarasikan ulang setelah broker kembali online).
Sakelar default
Pertukaran default sebenarnya adalah pertukaran langsung yang telah dideklarasikan sebelumnya oleh broker pesan dan tidak memiliki nama (namanya adalah string kosong).
Anda dapat menganggap sakelar default sebagai sakelar khusus yang terpasang langsung.
Nama sakelar default: String null (default AMQP)
Jenis sakelar default: Sakelar terpasang langsung
Saat membuat antrean, selama sakelar yang akan terikat tidak ditentukan, itu akan secara otomatis terikat ke sakelar default, dan nama kunci perutean pengikatan akan sama dengan nama antrean.
Koneksi langsung ke sakelar
Sakelar yang terpasang langsung mengirimkan pesan ke antrean kunci pengikatan yang sesuai berdasarkan kunci perutean yang dibawa oleh pesan. Perutean unicast yang digunakan oleh sakelar langsung untuk menangani pesan.
Saat membuat Antrean, jika terikat ke sakelar langsung, tidak perlu menentukan nama kunci perutean, karena akan memiliki nama kunci perutean default, yang sama dengan nama Antrean.
Antrean sakelar terpasang langsung biasanya mendistribusikan tugas ke beberapa konsumen dalam satu loop (kami menyebutnya polling).
Alur kerja:
- Saat mengikat antrean ke sakelar, berikan kunci pengikatan, dengan asumsi R;
- Saat pesan dengan Kunci Perutean dikirim ke sakelar yang terpasang langsung, sakelar merutekannya ke antrean dengan Kunci Perutean.
Sakelar kipas
Sakelar kipas merutekan pesan ke semua antrean yang terikat padanya, terlepas dari kunci perutean terikat.
Jika N antrean terikat ke sakelar sektor, ketika pesan dikirim ke sakelar sektor ini, sakelar mengirimkan salinan pesan ke semua N antrean secara terpisah. Sakelar kipas umumnya digunakan untuk menangani perutean siaran pesan.
Skenario Aplikasi:
menyiarkan pesan;
Fungsi obrolan grup.
Sakelar tema
Pengalihan topik mengirim pesan ke satu atau beberapa Antrean sesuai dengan kunci perutean dan jenis Exchange, dan kami sering menggunakannya untuk mengimplementasikan berbagai publikasi/langganan, yaitu menerbitkan langganan.
Aturan perutean untuk sakelar yang terpasang langsung sangat cocok, yang berarti bahwa Kunci Perutean harus cocok dengan Kunci Pengikatan sebelum mengirim pesan ke Antrean.
Aturan perutean dari sakelar topik adalah kecocokan kabur yang dapat disampaikan dengan memenuhi beberapa aturan melalui wildcard.
Ini menetapkan:
- Mungkin ada dua karakter khusus * dan # di kunci pengikatan untuk pencocokan fuzzy. di mana * digunakan untuk mencocokkan kata, #用于匹配多个单词 (bisa nol)
- Kunci perutean adalah string yang dipisahkan titik (kita menyebut setiap string individu yang dipisahkan oleh tanda titik sebagai kata)
- Saat produsen mengirim pesan Routing Key=A.A.A, hanya A.*.* yang terpenuhi, dan hanya akan dirutekan ke antrian1.
- Ketika produser mengirim pesan Routing Key=A.B.A, A.*.* dan *.B.* yang memuaskan akan diarahkan ke antrian1 dan antrian2.
- Ketika produser mengirim pesan Routing Key=ABC, maka A.*.* dan *.B.* dan *.B.* dan *.* terpenuhi. C dirutekan ke antrian1, antrian2, antrian3.
Skenario Aplikasi:
- pembaruan berita yang melibatkan kategori atau tag;
- Tugas latar belakang yang diselesaikan oleh beberapa pekerja, yang masing-masing bertanggung jawab untuk menangani tugas-tugas tertentu tertentu.
Saklar kepala
Sakelar header tidak bergantung pada aturan yang cocok dari kunci perutean untuk mengikat kunci ke merutekan pesan, melainkan cocok berdasarkan atribut header dalam konten pesan yang dikirim.
Sakelar kepala dapat dianggap sebagai manifestasi lain dari sakelar yang terpasang langsung. Namun, kunci perutean sakelar langsung harus berupa string, dan nilai atribut header tidak dibatasi oleh ini, bahkan bisa berupa bilangan bulat atau nilai hash (kamus), dll. Lebih banyak fleksibilitas (tetapi dalam praktiknya kami jarang menggunakan sakelar kepala).
Alur kerja:
- Saat antrean terikat ke sakelar header, beberapa header terikat secara bersamaan untuk pencocokan.
- Pesan masuk membawa header dan parameter "x-match". Ketika "x-match" diatur ke "any", nilai header apa pun dapat dicocokkan, dan ketika "x-match" diatur ke "all", semua nilai header harus cocok.
Ringkasan Beralih
Mengikat
Koneksi virtual antara Exchange dan Antrean.
BindingKey adalah deskripsi aturan untuk pengikatan Exchange dan Antrean. Kunci pengikatan menentukan jenis Kunci Perutean apa yang akan ditetapkan ke Antrean yang saat ini terikat di bawah bursa saat ini.
Kunci Perutean
Aturan perutean, yang dapat digunakan komputer virtual untuk menentukan cara merutekan pesan tertentu.
Kunci Pengikat vs. Kunci Perutean
- Kunci pengikat adalah kunci pengikat antara antrian dan sakelar;
- Kunci Perutean adalah informasi yang dikirim oleh produsen ke sakelar;
- Saat Kunci Pengikat dan Kunci Perutean sesuai, letakkan pesan dalam antrean yang sesuai.
Kunci Pengikat adalah deskripsi aturan pengikatan Exchange dan Antrean, yang digunakan untuk mengurai saat Exchange menerima pesan, pesan yang diterima oleh Exchange akan memiliki bidang Kunci Perutean, dan Exchange mencocokkan Kunci Perutean ini dengan semua Kunci Pengikatan Exchange saat ini, dan jika persyaratan terpenuhi, itu akan dikirim ke Pengikatan Key terikat ke Antrean untuk mengirim pesan.
Kunci Pengikatan vs. Kunci Perutean di berbagai sakelar
Sakelar default: Kunci Pengikat adalah nama Antrean, yang tidak dapat disesuaikan. Kunci Perutean juga merupakan nama Antrean sebelum berhasil dirutekan ke antrean
Sakelar koneksi langsung: Kunci Pengikat adalah nama Antrean, yang dapat disesuaikan. Kunci Perutean hanya dapat berhasil dirutekan ke antrean jika Kunci Pengikatan sama
Sakelar kipas: Tidak ada kunci pengikat; Tentu saja, tidak ada Kunci Perutean. Secara otomatis dirutekan ke semua antrean yang terikat ke sakelar
Sakelar tema: Kunci Pengikat khusus; Sesuaikan kunci perutean. Kunci Perutean==Kunci Pengikatan, dan kecocokan kabur harus berhasil dirutekan ke antrean
Sakelar kepala: tidak ada kunci pengikat; Tentu saja, tidak ada Kunci Perutean. Pencocokan berdasarkan atribut header dalam konten pesan yang dikirim
Antre
Menyimpan pesan yang akan dikonsumsi oleh aplikasi.
Properti Antrean:
- Nama: Nama antrean
- Tahan lama: Antrean masih ada setelah broker pesan dimulai ulang
- Eksklusif: Hanya digunakan oleh satu koneksi, dan antrean dihapus saat koneksi ditutup
- Hapus otomatis: Dihapus saat konsumen terakhir berhenti berlangganan
- Argumen: Beberapa broker pesan menggunakannya untuk melakukan beberapa fungsi tambahan yang mirip dengan TTL
Pembuatan antrean:
Antrean hanya dapat digunakan setelah dideklarasikan. Jika antrean belum ada, mendeklarasikan antrean akan membuatnya. Jika antrean yang dideklarasikan sudah ada dan atributnya identik, deklarasi tidak berpengaruh pada antrean asli. Jika atribut dalam deklarasi berbeda dari yang ada dalam antrean yang ada, pengecualian tingkat saluran dengan kode kesalahan 406 akan dilemparkan.
Persistensi antrean:
Antrean persistensi disimpan di disk dan tetap ada saat broker dimulai ulang. Antrean yang tidak dipertahankan disebut antrean sementara. Tidak semua skenario dan kasus memerlukan persistensi antrean.
Antrean yang diteruskan tidak membuat pesan yang dirutekan ke sana persisten. Jika agen pesan menutup telepon dan dimulai ulang, antrean persistensi akan dideklarasikan ulang selama restart, dan bagaimanapun, hanya pesan yang disimpan yang dapat dipulihkan kembali.
Konsumen
Berita Konsumsi Konsumen. Di AMQP, ada dua cara bagi konsumen untuk mendapatkan pesan yang tertunda:
Middleware pesan mengirimkan pesan ke konsumen (push API)
Konsumen secara aktif mendapatkan pesan (pull API)
Catatan: Saat beberapa konsumen mendengarkan antrean yang sama, pesan dalam antrean hanya akan dikonsumsi oleh salah satu konsumen (tidak sekali untuk setiap konsumen)
Pesan
Data yang dikirimkan antara pesan, layanan, dan aplikasi terdiri dari Properti dan isi.
Atribut memodifikasi pesan, seperti prioritas pesan, penundaan, dan fitur lanjutan lainnya, dan isi utama adalah konten isi pesan.
Properti Pesan:
- Jenis konten
- Pengodean konten
- Kunci perutean
- Mode pengiriman (persisten atau tidak)
- Mode pengiriman (persisten atau non-persisten)
- Prioritas pesan
- Stempel waktu penerbitan pesan
- Periode kedaluwarsa
- ID aplikasi penerbit
Isi pesan:
Selain atribut, pesan AMQP juga berisi payload (data yang benar-benar dibawa pesan), yang diperlakukan oleh proksi AMQP sebagai array byte buram.
Broker pesan tidak memeriksa atau memodifikasi payload. Pesan hanya dapat berisi atribut tanpa membawa muatan. Ini biasanya menggunakan data dalam format berseri seperti JSON, dan untuk menghemat uang, buffer protokol dan MessagePacks akan membuat serial data terstruktur untuk diterbitkan sebagai muatan pesan. AMQP dan rekan-rekannya biasanya menggunakan bidang "content-type" dan "content-encoding" untuk berkomunikasi dengan pesan guna mengidentifikasi payload, tetapi ini hanya didasarkan pada konvensi.
Persistensi pesan:
Pesan diterbitkan dengan cara yang persisten, dan agen AMQP menyimpan pesan ini di disk. Jika server dimulai ulang, sistem mengonfirmasi bahwa pesan persistensi yang diterima tidak hilang.
Hanya mengirim pesan ke sakelar persisten atau merutekannya ke antrean persisten tidak membuat pesan persisten: persistensi pesan sepenuhnya bergantung pada mode persistensi pesan itu sendiri.
Menerbitkan pesan dengan cara yang terus-menerus dapat berdampak pada kinerja.
Proses kerja AMQP
Penerbit menerbitkan pesan melalui Exchange.
Sakelar mendistribusikan pesan masuk ke antrean yang terikat ke sakelar sesuai dengan aturan perutean.
Terakhir, agen AMQP akan mengirimkan pesan kepada konsumen yang telah berlangganan antrean ini, atau konsumen akan mendapatkannya sendiri sesuai kebutuhan.
Mekanisme pesan AMQP
Konfirmasi pesan
Konsumen terkadang gagal memproses pesan atau terkadang mogok secara langsung. Dan alasan jaringan juga dapat menyebabkan berbagai masalah.
Ini memberi kita pertanyaan kapan waktu yang tepat bagi agen AMQP untuk menghapus pesan.
Dua mode pengakuan pesan AMQP:
Mode Konfirmasi Otomatis: Hapus pesan segera setelah dikirim ke konsumen oleh middleware pesan. (Menggunakan metode AMQP: basic.deliver atau basic.get-ok)
Mode konfirmasi eksplisit: Tunggu konsumen mengirim pengakuan sebelum menghapus pesan. (Menggunakan metode AMQP: basic.ack)
Jika konsumen menutup telepon tanpa mengirim tanda terima konfirmasi, agen AMQP mengirimkan kembali pesan ke konsumen lain. Jika tidak ada konsumen yang tersedia pada saat itu, broker pesan menunggu konsumen berikutnya mendaftar di antrean ini dan kemudian mencoba mengirimkannya lagi.
Tolak pesan
Ketika konsumen menerima pesan, proses pemrosesan mungkin berhasil atau gagal. Konsumen dapat menunjukkan kepada broker pesan (middleware pesan) bahwa pesan gagal diproses (atau gagal diselesaikan pada saat ini) karena "pesan yang ditolak".
Ketika pesan ditolak, konsumen dapat memberi tahu broker pesan apa yang harus dilakukan dengan pesan tersebut - hancurkan atau masukkan kembali ke dalam antrean.
Jika hanya ada satu konsumen dalam antrean ini, pastikan Anda tidak menolak pesan dan memilih untuk memasukkannya kembali ke antrean, menyebabkan pesan berulang tanpa batas waktu pada konsumen yang sama.
Di AMQP, metode basic.reject digunakan untuk melakukan operasi menolak pesan. Namun, basic.reject memiliki batasan: Anda tidak dapat menggunakannya untuk menolak beberapa pesan dengan pengakuan. Tetapi jika Anda menggunakan RabbitMQ, Anda dapat menggunakan ekstensi AMQP 0-9-1 yang disebut pengakuan negatif (juga disebut nacks) untuk mengatasi masalah ini.
Asli:Login hyperlink terlihat.
|
Diposting pada 14/08/2022 23.22.55
|
|
|
|
