Pemahaman konseptual yang baik tentang apa yang protokol AMQP lakukan "di bawah tenda" berguna di sini. Saya akan menawarkan bahwa dokumentasi dan API yang AMQP 0.9.1 pilih untuk digunakan membuat ini sangat membingungkan, jadi pertanyaannya sendiri adalah salah satu yang harus dihadapi banyak orang.
TL; DR
Sebuah koneksi adalah fisik dinegosiasikan TCP socket dengan server AMQP. Klien yang diimplementasikan dengan benar akan memiliki salah satu dari ini per aplikasi, aman untuk benang, dapat digunakan di antara utas.
Sebuah saluran adalah sesi aplikasi tunggal pada sambungan. Utas akan memiliki satu atau lebih dari sesi ini. Arsitektur AMQP 0.9.1 adalah bahwa ini tidak untuk dibagikan di antara utas, dan harus ditutup / dihancurkan ketika utas yang membuatnya selesai dengannya. Mereka juga ditutup oleh server ketika berbagai pelanggaran protokol terjadi.
Sebuah konsumen adalah membangun virtual yang mewakili kehadiran "kotak" pada saluran tertentu. Penggunaan konsumen memberi tahu broker untuk mendorong pesan dari antrian tertentu ke titik akhir saluran itu.
Fakta Koneksi
Pertama, seperti yang orang lain tunjukkan dengan benar, koneksi adalah objek yang mewakili koneksi TCP yang sebenarnya ke server. Koneksi ditentukan pada tingkat protokol di AMQP, dan semua komunikasi dengan broker terjadi melalui satu atau lebih koneksi.
- Karena ini adalah koneksi TCP yang sebenarnya, ia memiliki Alamat IP dan Port #.
- Parameter protokol dinegosiasikan berdasarkan per-klien sebagai bagian dari pengaturan koneksi (proses yang dikenal sebagai jabat tangan) .
- Ini dirancang untuk berumur panjang ; ada beberapa kasus di mana penutupan koneksi merupakan bagian dari desain protokol.
- Dari perspektif OSI, itu mungkin berada di suatu tempat di sekitar Layer 6
- Detak jantung dapat diatur untuk memantau status koneksi, karena TCP tidak mengandung apa pun untuk melakukan hal ini.
- Yang terbaik adalah memiliki thread khusus mengelola membaca dan menulis ke soket TCP yang mendasarinya. Sebagian besar, jika tidak semua, klien RabbitMQ melakukan ini. Dalam hal itu, mereka umumnya aman-benang.
- Secara relatif, koneksi adalah "mahal" untuk dibuat (karena jabat tangan), tetapi secara praktis, ini benar-benar tidak masalah. Sebagian besar proses hanya membutuhkan satu objek koneksi. Tetapi, Anda dapat mempertahankan koneksi dalam kumpulan, jika Anda menemukan Anda membutuhkan lebih banyak throughput daripada satu thread / socket dapat menyediakan (tidak mungkin dengan teknologi komputasi saat ini).
Fakta Saluran
Sebuah Saluran adalah sesi aplikasi yang dibuka untuk setiap bagian dari aplikasi Anda untuk berkomunikasi dengan broker RabbitMQ. Ini beroperasi melalui satu koneksi , dan mewakili sesi dengan broker.
- Karena ini merupakan bagian logis dari logika aplikasi, setiap saluran biasanya ada di utasnya sendiri.
- Biasanya, semua saluran yang dibuka oleh aplikasi Anda akan berbagi satu koneksi (itu adalah sesi ringan yang beroperasi di atas koneksi). Koneksi aman, jadi ini OK.
- Sebagian besar operasi AMQP dilakukan melalui saluran.
- Dari perspektif OSI Layer, saluran mungkin sekitar Layer 7 .
- Saluran dirancang untuk bersifat sementara ; bagian dari desain AMQP adalah bahwa saluran biasanya ditutup sebagai respons terhadap kesalahan (misalnya, mendeklarasikan ulang antrian dengan parameter yang berbeda sebelum menghapus antrian yang ada).
- Karena bersifat sementara, saluran tidak boleh digabungkan dengan aplikasi Anda.
- Server menggunakan integer untuk mengidentifikasi saluran. Ketika utas yang mengelola koneksi menerima paket untuk saluran tertentu, ia menggunakan nomor ini untuk memberi tahu broker saluran / sesi mana milik paket itu.
- Saluran umumnya tidak aman karena tidak masuk akal untuk membaginya di antara utas. Jika Anda memiliki utas lain yang perlu menggunakan broker, saluran baru diperlukan.
Fakta Konsumen
Seorang konsumen adalah objek yang didefinisikan oleh protokol AMQP. Ini bukan saluran atau koneksi, sebaliknya menjadi sesuatu yang aplikasi khusus Anda gunakan sebagai semacam "kotak surat" untuk menjatuhkan pesan.
- "Menciptakan konsumen" berarti Anda memberi tahu broker (menggunakan saluran melalui koneksi ) bahwa Anda ingin pesan didorong kepada Anda melalui saluran itu. Sebagai tanggapan, broker akan mendaftar bahwa Anda memiliki konsumen di saluran dan mulai mengirimkan pesan kepada Anda.
- Setiap pesan yang didorong melalui koneksi akan merujuk nomor saluran dan nomor konsumen . Dengan cara itu, utas pengelola koneksi (dalam hal ini, dalam Java API) tahu apa yang harus dilakukan dengan pesan; kemudian, utas penanganan saluran juga tahu apa yang harus dilakukan dengan pesan tersebut.
- Implementasi konsumen memiliki jumlah variasi terluas, karena ini benar-benar spesifik untuk aplikasi. Dalam implementasi saya, saya memilih untuk melakukan tugas setiap kali pesan tiba melalui konsumen; dengan demikian, saya memiliki utas yang mengelola koneksi, utas yang mengelola saluran (dan dengan ekstensi, konsumen), dan satu atau lebih utas tugas untuk setiap pesan yang dikirim melalui konsumen.
- Menutup koneksi menutup semua saluran pada koneksi. Menutup saluran menutup semua konsumen di saluran. Dimungkinkan juga untuk membatalkan konsumen (tanpa menutup saluran). Ada berbagai kasus ketika masuk akal untuk melakukan salah satu dari tiga hal ini.
- Biasanya, implementasi konsumen dalam klien AMQP akan mengalokasikan satu saluran khusus untuk konsumen untuk menghindari konflik dengan kegiatan utas atau kode lainnya (termasuk penerbitan).
Dalam hal apa yang Anda maksud dengan kumpulan utas konsumen, saya menduga bahwa klien Java melakukan sesuatu yang serupa dengan apa yang saya programkan untuk dilakukan klien saya (milik saya didasarkan pada klien .Net, tetapi sangat dimodifikasi).
