Mengapa kita membutuhkan broker pesan seperti RabbitMQ melalui database seperti PostgreSQL?

215

Saya baru mengenal broker pesan seperti RabbitMQ yang dapat kita gunakan untuk membuat tugas / antrian pesan untuk sistem penjadwalan seperti Celery .

Sekarang, inilah pertanyaannya:

  • Saya dapat membuat tabel di PostgreSQL yang dapat ditambahkan dengan tugas-tugas baru dan dikonsumsi oleh program konsumen seperti Celery.

  • Mengapa saya ingin mengatur teknologi baru untuk RabbitMQ seperti ini?

Sekarang, saya percaya penskalaan tidak bisa menjadi jawaban karena database kami seperti PostgreSQL dapat bekerja di lingkungan terdistribusi.

Saya mencari di Google untuk masalah apa yang diajukan oleh database untuk masalah tertentu, dan saya menemukan:

  • polling membuat database sibuk dan berkinerja rendah
  • mengunci meja -> lagi berkinerja rendah
  • jutaan baris tugas -> sekali lagi, polling berkinerja rendah

Sekarang, bagaimana RabbitMQ atau broker pesan lain seperti itu menyelesaikan masalah ini?

Juga, saya menemukan AMQPprotokol yang mengikuti. Apa bagusnya itu?

Bisakah Redis juga digunakan sebagai perantara pesan? Saya merasa lebih analog dengan Memcached daripada RabbitMQ.

Tolong jelaskan ini!

Yugal Jindle
sumber
9
Dampak penguncian harus jauh lebih sedikit dengan PostgreSQL karena menerapkan MVCC di mana pembaca tidak diblokir oleh penulis dan sebaliknya. Sebagian besar artikel yang saya temukan mengkritik penggunaan database sebagai antrian pesan memiliki MySQL dalam pikiran.
CadentOrange
Pialang pesan memindahkan data di antara node, sementara database menyimpan data di satu tempat. Kenyataan bahwa Anda dapat mengakses data dalam database dari banyak node tidak, pada wajahnya, menjadikannya alat yang baik untuk mentransfer data dengan cepat antar node.
theMayer
2
"sistem penjadwalan seperti celery" - Saya baru belajar sesuatu yang akan berguna dalam desain saya, dari pertanyaan . Sekarang untuk membaca jawabannya ...
Mark K Cowan
menggunakan produsen pesan broker dan konsumen dipisahkan.
giorgi dvalishvili
Anda dapat melihat tautan di bawah ini. Ini memiliki deskripsi luas: stackoverflow.com/a/51377756/3073945
Md. Sajedul Karim

Jawaban:

110

Antrian kelinci berada dalam memori dan karenanya akan jauh lebih cepat daripada mengimplementasikannya dalam database. Antrian pesan berdedikasi (baik) juga harus menyediakan fitur-fitur terkait antrian yang penting seperti pembatasan / kontrol aliran, dan kemampuan untuk memilih algoritme perutean yang berbeda, untuk menyebutkan pasangan (kelinci menyediakan ini dan banyak lagi). Bergantung pada ukuran proyek Anda, Anda mungkin juga ingin komponen lewat pesan terpisah dari database Anda, sehingga jika satu komponen mengalami beban berat, itu tidak perlu menghambat operasi yang lain.

Adapun masalah yang Anda sebutkan:

  • polling menjaga basis data dan berkinerja rendah : Menggunakan Rabbitmq, produsen dapat mendorong pembaruan kepada konsumen yang jauh lebih berkinerja daripada polling. Data hanya dikirim ke konsumen ketika perlu, menghilangkan kebutuhan untuk pemeriksaan yang boros.

  • mengunci meja -> lagi berkinerja rendah: Tidak ada meja untuk dikunci: P

  • jutaan baris tugas -> sekali lagi polling berkinerja rendah: Seperti disebutkan di atas, Rabbitmq akan beroperasi lebih cepat karena berada di RAM, dan menyediakan kontrol aliran. Jika perlu, ia juga dapat menggunakan disk untuk menyimpan sementara pesan jika kehabisan RAM. Setelah 2.0, Rabbit telah meningkatkan penggunaan RAM secara signifikan. Opsi pengelompokan juga tersedia.

Berkenaan dengan AMQP, saya akan mengatakan fitur yang sangat keren adalah "pertukaran", dan kemampuannya untuk merutekan ke pertukaran lain. Ini memberi Anda lebih banyak fleksibilitas dan memungkinkan Anda untuk membuat beragam tipologi perutean yang rumit yang bisa sangat berguna saat melakukan penskalaan. Untuk contoh yang baik, lihat:


(sumber: springsource.com )

dan: http://blog.springsource.org/2011/04/01/routing-topologies-for-performance-and-scalability-with-rabbitmq/

Akhirnya, dalam hal redis, ya, itu dapat digunakan sebagai pialang pesan, dan dapat melakukannya dengan baik. Namun, Rabbitmq memiliki lebih banyak fitur antrian pesan daripada redis, karena rabbitmq dibangun dari bawah ke atas untuk menjadi antrian pesan khusus tingkat perusahaan yang berfitur lengkap. Redis di sisi lain terutama diciptakan untuk menjadi toko-nilai kunci dalam memori (meskipun itu jauh lebih dari itu sekarang; bahkan disebut sebagai pisau tentara swiss). Meski demikian, saya sudah membaca / mendengar banyak orang yang mencapai hasil yang baik dengan Redis untuk proyek berukuran lebih kecil, tetapi belum banyak mendengar tentang hal itu dalam aplikasi yang lebih besar.

Berikut adalah contoh redis yang digunakan dalam implementasi obrolan polling panjang: http://eflorenzano.com/blog/2011/02/16/technology-behind-convore/

Jaigus
sumber
2
Saya telah mengimplementasikan implementasi JMS (yaitu sistem pesan lewat) di atas database. Saya dapat memberitahu Anda bahwa itu adalah mungkin, tapi itu tidak menyenangkan dan tidak biasanya membayar untuk melakukannya. Beberapa masalah yang Anda sebutkan dapat diselesaikan, tetapi hal itu meningkatkan kompleksitasnya cukup banyak. Secara keseluruhan saya setuju: gunakan sistem MQ khusus, jika Anda membutuhkannya. Namun, untuk beban kerja yang rendah, Anda dapat menggunakannya di DB.
Joachim Sauer
1
Anda hanya membahas semua masalah / keraguan. Jawaban yang luar biasa!
Yugal Jindle
Itu menarik. Bagaimana dengan konsistensi? Bagaimana jika ada ratusan pekerjaan dalam antrian dan simpul yang menahannya dalam crash ram?
Mahn
22
Sebenarnya, dengan PostgreSQL tidak ada polling (lihat PEMBERITAHUAN) juga tidak ada kunci tabel (lihat MVCC). Meskipun PostgreSQL masih tidak dirancang untuk antrian pesan, itu tidak sepenuhnya tidak cocok.
jkj
3
Seperti yang dikatakan @jkj, ada PEMBERITAHUAN dan tidak ada tabel yang terkunci. Satu-satunya masalah sepertinya bandwidth pesan yang tinggi. Tidak bisakah Anda memiliki turunan PostgreSQL khusus alih-alih mempertahankan sistem yang sama sekali baru seperti Rabbit? Anda dapat 1) menggunakan instance PostgreSQL tunggal sampai Anda mencapai bottleneck, kemudian 2) menggunakan Postgres khusus, lalu akhirnya 3) dengan mudah beralih ke Rabbit sebagai broker Anda. Sepertinya memulai dengan Kelinci adalah pra-optimalisasi.
Joe
72

PostgreSQL 9.5

Menggabungkan PostgreSQL 9.5 SELECT ... FOR UPDATE ... SKIP LOCKED. Ini merek menerapkan sistem antrian bekerja dengan banyak sederhana dan lebih mudah. Anda mungkin tidak lagi memerlukan sistem antrian eksternal karena sekarang mudah untuk mengambil baris 'n' yang tidak ada sesi lain yang terkunci, dan tetap terkunci sampai Anda melakukan konfirmasi bahwa pekerjaan telah selesai. Ia bahkan bekerja dengan transaksi dua fase ketika koordinasi eksternal diperlukan.

Sistem antrian eksternal tetap berguna, menyediakan fungsionalitas kalengan, kinerja terbukti, integrasi dengan sistem lain, opsi untuk penskalaan dan federasi horisontal, dll. Meskipun demikian, untuk kasus-kasus sederhana Anda tidak benar-benar membutuhkannya lagi.

Versi yang lebih lama

Anda tidak membutuhkan alat seperti itu, tetapi menggunakannya bisa membuat hidup lebih mudah. Melakukan antrian dalam basis data terlihat mudah, tetapi dalam praktiknya Anda menemukan bahwa antrian bersamaan yang berkinerja tinggi dan andal benar-benar sulit dilakukan dengan benar dalam database relasional.

Itu sebabnya alat seperti PGQ ada.

Anda dapat menyingkirkan polling di PostgreSQL dengan menggunakan LISTENdan NOTIFY, tetapi itu tidak akan memecahkan masalah dengan andal membagikan entri dari bagian atas antrian ke tepat satu konsumen sambil mempertahankan operasi yang sangat bersamaan dan tidak memblokir sisipan. Semua solusi sederhana dan jelas yang Anda pikir akan menyelesaikan masalah itu sebenarnya tidak ada di dunia nyata, dan cenderung merosot menjadi versi yang lebih efisien dari pengambilan antrian pekerja tunggal.

Jika Anda tidak memerlukan pengambilan antrian multi-pekerja yang sangat konkuren, maka menggunakan tabel antrian tunggal di PostgreSQL sepenuhnya masuk akal.

Craig Ringer
sumber
11
garis reliably handing out entries off the top of the queue to exactly one consumer while preserving highly concurrent operation and not blocking inserts. merangkumnya - Benar?
Yugal Jindle