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

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!

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/

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.