Topik JMS vs Antrian


191

Saya bertanya-tanya apa perbedaan antara Antrian JMS dan Topik JMS.

Halaman ActiveMQ mengatakan

Topik

Dalam JMS a Topic mengimplementasikan menerbitkan dan berlangganan semantik. Saat Anda mempublikasikan pesan, pesan itu ditujukan untuk semua pelanggan yang tertarik - jadi nol bagi banyak pelanggan akan menerima salinan pesan tersebut. Hanya pelanggan yang memiliki langganan aktif pada saat broker menerima pesan akan mendapatkan salinan pesan tersebut.

Antrian

Antrian JMS mengimplementasikan semantik penyeimbang beban . Satu pesan akan diterima oleh satu konsumen. Jika tidak ada konsumen yang tersedia pada saat pesan terkirim, pesan itu akan disimpan sampai ada konsumen yang dapat memproses pesan tersebut. Jika konsumen menerima pesan dan tidak mengakuinya sebelum menutup maka pesan tersebut akan dikirim ke konsumen lain. Sebuah antrian dapat memiliki banyak konsumen dengan pesan dimuat secara seimbang di seluruh konsumen yang tersedia.

Saya ingin memiliki 'sesuatu' yang akan mengirim salinan pesan ke setiap pelanggan dalam urutan yang sama dengan di mana pesan tersebut diterima oleh broker ActiveMQ.

Adakah pikiran?

Jawaban:


147

Itu artinya suatu topik sudah pantas. Antrian berarti pesan masuk ke satu dan hanya satu pelanggan yang mungkin. Topik dibagikan ke setiap pelanggan.


4
Adakah yang tahu bagaimana cara kerja load balancing untuk Antrian di JMS atau WSO2 MB?
Kulasangar

itu menarik karena saya mencoba men-debug beberapa pelanggan dan ketika mengirim topik pelanggan tidak dipanggil tetapi ketika mengirim ke antrian itu berhasil
vmrvictor

54

Topik adalah untuk model penerbit-pelanggan, sedangkan antrian adalah untuk point-to-point.


31

Sebuah topik JMS adalah jenis tujuan dalam model 1-ke-banyak distribusi. Pesan yang diterbitkan sama diterima oleh semua pelanggan yang mengkonsumsi . Anda juga dapat menyebut ini model 'siaran'. Anda dapat menganggap suatu topik setara dengan Subjek dalam pola desain Pengamat untuk komputasi terdistribusi. Beberapa penyedia JMS secara efisien memilih untuk mengimplementasikan ini sebagai UDP daripada TCP. Untuk topik, pengiriman pesan adalah 'api-dan-lupakan' - jika tidak ada yang mendengarkan, pesannya hilang begitu saja. Jika bukan itu yang Anda inginkan, Anda dapat menggunakan 'langganan tahan lama'.

Sebuah JMS antrian adalah tujuan 1-to-1 pesan. Pesan hanya diterima oleh salah satu penerima yang mengonsumsi (harap dicatat: secara konsisten menggunakan pelanggan untuk 'topik klien dan penerima untuk klien antrian menghindari kebingungan). Pesan yang dikirim ke antrian disimpan di disk atau memori hingga seseorang mengambilnya atau kedaluwarsa. Jadi antrian (dan langganan yang tahan lama) memerlukan manajemen penyimpanan yang aktif, Anda perlu memikirkan konsumen yang lambat.

Dalam sebagian besar lingkungan, saya berpendapat, topik adalah pilihan yang lebih baik karena Anda selalu dapat menambahkan komponen tambahan tanpa harus mengubah arsitektur. Komponen yang ditambahkan bisa berupa pemantauan, pencatatan, analisis, dll. Anda tidak pernah tahu di awal proyek seperti apa persyaratannya dalam 1 tahun, 5 tahun, 10 tahun. Perubahan tidak bisa dihindari, terima :-)


28

Sederhana seperti itu:

Antrian = Sisipkan> Tarik (kirim ke satu pelanggan) 1: 1

Topik = Sisipkan> Siaran (kirim ke semua pelanggan) 1: n

masukkan deskripsi gambar di sini


2
Contohnya bisa untuk jejaring sosial sederhana. Seseorang suka posting. Backend menerbitkan acara 'POST LIKE' untuk topik tersebut. Ini dikonsumsi oleh 3 pelanggan: notificationProcessor(mengirimkan pemberitahuan ke poster), karmaProcessor(memberikan karma ke liker dan poster), feedProcessor(memindahkan catatan ke atas ke feed orang). Semua asinkron tentu saja.
Siddhartha

@ Siddhartha, ini bisa menjadi jawaban yang dibungkus contoh, terima kasih!
selem mn

8

Adapun pelestarian pesanan, lihat halaman ActiveMQ ini . Singkatnya: pesanan dipertahankan untuk konsumen tunggal, tetapi dengan banyak konsumen, pesanan pengiriman tidak dijamin.


7

Antrian

Pro

  • Pola pesan sederhana dengan aliran komunikasi yang transparan
  • Pesan dapat dipulihkan dengan mengembalikannya ke antrian

Cons

  • Hanya satu konsumen yang bisa mendapatkan pesan
  • Menyiratkan hubungan antara produsen dan konsumen karena itu adalah hubungan satu-ke-satu

Topik

Pro

  • Banyak konsumen bisa mendapatkan pesan
  • Decoupling antara produsen dan konsumen (pola publish-and-subscribe)

Cons

  • Alur komunikasi yang lebih rumit
  • Pesan tidak dapat dipulihkan untuk pendengar tunggal

4

Jika Anda memiliki konsumen N maka:

Topik JMS mengirimkan pesan ke N dari N Antrian JMS mengirim pesan ke 1 dari N

Anda mengatakan bahwa Anda "mencari untuk memiliki 'barang' yang akan mengirim salinan pesan ke setiap pelanggan dalam urutan yang sama dengan saat pesan diterima oleh pialang ActiveMQ."

Jadi, Anda ingin menggunakan Topik agar semua pelanggan N mendapatkan salinan pesan.


1

TOPIC :: topik adalah komunikasi satu ke banyak ... (multipoint atau publikasikan / berlangganan) EX: -bayangkan penerbit menerbitkan film di youtub maka semua pelanggannya akan mendapat notifikasi .... QUEVE :: antve adalah satu-ke-satu -satu komunikasi ... Mis: -Ketika mempublikasikan permintaan untuk mengisi ulang itu akan pergi ke satu penerima saja ... selalu ingat jika permintaan menerima semua penerima lalu terjadi beberapa pengisian ulang sehingga saat mengembangkan analisis yang sesuai untuk aplikasi


-1

Antrian adalah objek yang dikelola JMS yang digunakan untuk menyimpan pesan yang menunggu pelanggan untuk mengkonsumsi. Ketika semua pelanggan mengkonsumsi pesan, pesan akan dihapus dari antrian.

Topiknya adalah bahwa semua pelanggan topik menerima pesan yang sama ketika pesan tersebut diterbitkan.


2
Pesan antrian hanya akan dikonsumsi sekali oleh satu konsumen, itu sebabnya antrian mengimplementasikan penyeimbang beban. Langganan topik bisa tahan lama : pelanggan dapat menerima pesan lama setelah publikasi (jika pelanggan dimatikan dan muncul lagi, misalnya).
Gruber
Dengan menggunakan situs kami, Anda mengakui telah membaca dan memahami Kebijakan Cookie dan Kebijakan Privasi kami.
Licensed under cc by-sa 3.0 with attribution required.