Apa solusi untuk masalah Antrian Terdistribusi?


23

Saya mencoba mempelajari lebih lanjut tentang berbagai cara agar masalah Antrian Terdistribusi dapat diselesaikan. Jadi saya ingin tahu produk, layanan, implementasi, dan makalah penelitian apa yang sudah ada.

Suatu implementasi akan menghadapi banyak tantangan dan akan dipaksa untuk melakukan pengorbanan:

  • Apakah ada pesanan kuat atau longgar?
  • Apakah sudah idempoten?
  • Bisakah kita memiliki lebih banyak antrian daripada yang dapat ditampung pada satu mesin?
  • Bisakah kita memiliki lebih banyak data dalam antrian daripada yang dapat ditampung di satu mesin?
  • Berapa banyak mesin yang bisa lumpuh sebelum kita berpotensi kehilangan data?
  • Bisakah itu mentolerir pemisahan bersih?
  • Bisakah itu merekonsiliasi data secara otomatis ketika suatu net-split diperbaiki?
  • Bisakah itu menjamin pengiriman ketika klien bisa crash?
  • Bisakah itu menjamin bahwa pesan yang sama tidak terkirim lebih dari satu kali?
  • Dapatkah sebuah node mogok pada suatu titik tertentu, muncul kembali, dan tidak mengirim sampah?
  • Bisakah Anda menambahkan node ke, atau menghapus node dari, sebuah cluster berjalan tanpa down time?
  • Bisakah Anda memutakhirkan node di cluster yang sedang berjalan tanpa down time?
  • Bisakah itu berjalan tanpa masalah di server heterogen?
  • Bisakah Anda "menempel" antrian ke sekelompok server? (contoh: "antrian ini hanya diperbolehkan di pusat data Eropa")
  • Bisakah itu memastikan untuk menempatkan replika data di setidaknya dua pusat data, jika tersedia?

Saya tidak punya ilusi bahwa implementasi apa pun akan dapat mengatakan "ya" untuk semua itu. Saya hanya tertarik mendengar tentang berbagai implementasi; bagaimana mereka bekerja, pengorbanan apa yang telah mereka buat dan mungkin mengapa mereka memutuskan serangkaian pengorbanan khusus mereka.

Juga jika ada tantangan yang mungkin saya lewatkan dalam daftar di atas.

Jawaban:


13

Menulis sistem antrian dasar cukup sederhana, tetapi seperti yang Anda catat di atas dengan semua tantangan, melakukannya dengan benar adalah masalah lain. Saya telah menggunakan sistem yang dikembangkan sendiri di mana saya menulis kode sumber, sistem pihak ke-3, dan berbagai penyedia JMS. JMS (Java Messaging Service) sejauh ini adalah solusi paling lengkap yang saya temui sejauh ini. Banyak dari apa yang Anda tanyakan tersedia di JMS. Penyedia JMS favorit saya adalah ActiveMQ. Gratis, berkinerja tinggi, mudah dipasang, dan yang lebih penting mudah disematkan di aplikasi saya dengan Spring. Penyedia JMS tidak menyediakan semua yang Anda minta di luar kotak, tetapi mereka menyediakan seperangkat alat untuk menangani sebagian besar dari apa yang Anda tanyakan seandainya aplikasi Anda membutuhkannya. Saya belum menemukan banyak aplikasi yang membutuhkan semua yang Anda daftarkan. Memesan mungkin tidak penting (lebih baik jika tidak),

http://activemq.apache.org/what-open-source-integration-solution-works-best-with-activemq-.html

Apakah ada pesanan kuat atau hilang? Iya nih. Ini memiliki keduanya tergantung pada kebutuhan program Anda. Berikut detailnya: http://activemq.apache.org/total-ordering.html .

Apakah sudah idempoten? Tidak, tapi ini sepele untuk diterapkan di lapisan aplikasi Anda jika Anda membutuhkannya.

Bisakah kita memiliki lebih banyak antrian daripada yang dapat ditampung pada satu mesin? Iya nih. Anda dapat memiliki server cluster, dan jika Anda ingin mengatur beberapa mesin dengan antrian yang berbeda, Anda dapat melakukannya, dan tarik dari keduanya.

Bisakah kita memiliki lebih banyak data dalam antrian daripada yang dapat ditampung di satu mesin? Ya, sebagian besar penyedia JMS harus menggunakan semacam DB / penyimpanan persisten untuk memastikan pesan tidak hilang atau hilang jika penyedia JMS turun.

Berapa banyak mesin yang bisa lumpuh sebelum kita berpotensi kehilangan data? Ini sedikit lebih sulit dijawab karena terkait waktu. Namun, Anda dapat merusak penyedia JMS dan asalkan disk tidak rusak itu akan muncul kembali dan mulai di mana ia menerima komit terakhir. Ini berarti pesan dapat dikirimkan dua kali, tetapi jika Anda memberi kode pada aplikasi Anda untuk menangani ini, itu bukan masalah. Selama Anda memiliki setidaknya satu dari setiap jenis (produsen, konsumen, atau server JMS) itu akan selesai. Anda juga dapat memiliki load / balance / failover untuk redundansi jika disk keluar pada Anda.

Bisakah ini menghilangkan net-splits?Saya pikir saya mengerti apa yang Anda maksud dengan "net-split", tapi saya tidak sepenuhnya yakin. Saya kira maksud Anda jika server JMS berkerumun, dan kami kehilangan koneksi dengan salah satu server akan melompat ke server lain dan mengambil di mana itu tinggalkan. Ya, tapi sekali lagi situasi seperti ini dapat menyebabkan pesan duplikat tergantung pada titik apa koneksi terputus.

Bisakah itu merekonsiliasi data secara otomatis ketika suatu net-split diperbaiki? Jika Anda menggunakan sesi yang ditransaksikan, itu hanya akan mengirimkan kembali pesan yang telah memiliki komitmen yang memintanya untuk klien yang sudah ada yang sedang naik.

Bisakah itu menjamin pengiriman ketika klien bisa crash? Ya ini adalah salah satu tujuan utama JMS. Pengiriman yang dijamin berarti bahwa jika suatu pesan diantrekan, itu dijamin akan ditangani oleh klien.

Bisakah itu menjamin bahwa pesan yang sama tidak terkirim lebih dari satu kali? Ya jika sesi yang ditransaksikan sedang digunakan. Itu berarti klien telah menerima pesan dan disebut commit / rollback. Setelah komit dipanggil, komit tidak akan mengirim pesan.

Dapatkah sebuah node mogok pada suatu titik tertentu, muncul kembali, dan tidak mengirim sampah? Dalam kasus di mana Anda memiliki antrian berkerumun yang tahan lama. Ya itu tidak akan memuntahkan "sampah" jika simpul lain di cluster telah mengirimkan pesan. Itu masih dapat mengirimkan kembali apa pun yang belum diakui.

Bisakah Anda menambahkan node ke, atau menghapus node dari, sebuah cluster berjalan tanpa down time? Iya nih.

Bisakah Anda memutakhirkan node di cluster yang sedang berjalan tanpa down time? Ini agak sulit bagi saya untuk menjawab, tetapi saya yakin ya Anda bisa melakukan ini.

Bisakah itu berjalan tanpa masalah di server heterogen? Apa artinya ini sebenarnya? Saya telah menemukan sebagian besar penyedia JMS sangat mudah dijalankan di lingkungan menggunakan perangkat keras, OS, dll yang berbeda. Meskipun, jika Anda maksud kinerja, itu adalah hal lain. Setiap sistem pemrosesan terdistribusi dapat dipengaruhi secara negatif oleh simpul lambat. Saya memiliki 2 8 server Core Intel yang menjalankan antrian dan konsumen. Itu 16 core bersama, dan saya mendapat kinerja yang lebih baik dengan hanya menggunakan dua kotak itu, daripada ketika saya menambahkan mesin single core sebagai konsumen. Mesin single core itu jauh lebih lambat sehingga memperlambat seluruh grid dengan faktor 2x. Ini tidak ada hubungannya dengan JMS per se.

Bisakah Anda "menempel" antrian ke sekelompok server? Jawaban singkatnya ya. Saya bisa memikirkan cara di mana Anda dapat menjalankan cluster yang hanya di pusat data Eropa, dan mengkonfigurasi antrian di sana. Kemudian pada konfigurasi pegas Anda, konsumen Anda akan mengkonsumsi antrian itu dan juga antrian lainnya di kluster lain. Anda mungkin ingin berkonsultasi dengan dokumen:

http://activemq.apache.org/clustering.html

Bisakah itu memastikan untuk menempatkan replika data di setidaknya dua pusat data, jika tersedia? Sekali lagi saya percaya begitu, tetapi yang terbaik adalah berkonsultasi dengan dokumen pengelompokan.

Sekali lagi JMS memiliki banyak opsi yang dapat Anda atur sesuai kebutuhan Anda. Menggunakan sesi yang ditransaksikan dan antrian yang tahan lama hadir dengan biaya kinerja. Saya telah melihat menyalakan semua lonceng dan peluit berdampak kinerja sebanyak 10x. Ketika saya menggunakan JBossMQ jika kita mematikan beberapa fitur ini kita bisa mendapatkan sekitar 10.000 pesan / s, tetapi menyalakannya membawa kita ke 1000 pesan / s. Penurunan besar.


Terima kasih telah meluangkan waktu dengan jawaban ini. Net-split adalah ketika beberapa node dalam sebuah cluster tidak dapat lagi berkomunikasi dengan yang lain. Dengan server heterogen, kebanyakan saya maksudkan jumlah RAM yang berbeda - beberapa sistem terdistribusi lebih suka ketika server mirip.
Chris Vest

Maka pasti ya di netsplits. Jika seorang konsumen turun atau tidak dapat berkomunikasi, ia akan terus mencoba terhubung. Pekerjaan yang diberikan kepadanya yang tidak menerima komit nantinya akan dikirim ke konsumen lain. Jika penyedia JMS turun dan Anda memiliki anggota lain dari pesan cluster dapat diduplikasi di seluruh cluster agar tidak kehilangan pesan.
chubbsondubs

Tidak ada persyaratan untuk memiliki mesin yang identik apakah itu RAM, Perangkat Keras, atau OS. Anda dapat menjalankan kantong campuran mesin jika perlu. Satu-satunya perhatian adalah yang saya perhatikan yang terkait kinerja di bahwa mesin yang tidak sama akan memproses pesan pada tingkat yang berbeda yang dapat menyebabkan throughput yang lebih rendah. Namun, model JMS agak mengurangi ini dengan fakta bahwa itu menarik bukan model push. Model dorong jauh lebih sensitif terhadap jenis masalah ini.
chubbsondubs
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.