PostgreSQL gibi bir veritabanı üzerinden neden RabbitMQ gibi mesaj aracılarına ihtiyacımız var?

Kereviz gibi bir zamanlama sistemi için görevler / mesaj kuyrukları oluşturmak için kullanabileceğimiz RabbitMQ gibi mesaj aracılarına yeniyim .

Şimdi soru şudur:

• PostgreSQL'de yeni görevlerle eklenebilen ve Kereviz gibi tüketici programı tarafından tüketilebilen bir tablo oluşturabilirim .

• Neden yeryüzünde bunun için yepyeni bir teknoloji kurmak istiyorum?

Şimdi, PostgreSQL gibi veritabanımız dağıtılmış bir ortamda çalışabileceğinden ölçeklemenin cevap olamayacağına inanıyorum.

Veritabanı belirli bir sorun için hangi sorunları yapar googled ve buldum:

• yoklama, veritabanını meşgul ve düşük performanslı tutar
• tablanın kilitlenmesi -> tekrar düşük performans
• milyonlarca görev sırası -> yine, yoklama düşük performans

Şimdi, RabbitMQ veya bunun gibi başka bir mesaj komisyoncusu bu sorunları nasıl çözer?

Ayrıca, AMQPprotokolün takip ettiği şey olduğunu öğrendim . Bunda harika olan ne var?

Can Redis da bir mesaj komisyoncu olarak kullanılabilir? Memcached'a RabbitMQ'dan daha benzer buluyorum.

Lütfen buna biraz ışık tut!

Tavşanların kuyrukları bellekte bulunur ve bu nedenle bunu bir veritabanına uygulamaktan çok daha hızlı olacaktır. (İyi) özel bir mesaj kuyruğu da kısma / akış kontrolü ve çiftleri adlandırmak için farklı yönlendirme algoritmaları seçme yeteneği gibi sıra ile ilişkili temel özellikleri sağlamalıdır (tavşan bunları ve daha fazlasını sağlar). Projenizin boyutuna bağlı olarak, mesaj geçirme bileşenini veritabanınızdan ayrı olarak da isteyebilirsiniz, böylece bir bileşen ağır yük yaşıyorsa, diğerinin çalışmasını engellemesi gerekmez.

Bahsettiğiniz sorunlara gelince:

• Veritabanı Buzy ve düşük performans gösteren tutarak yoklama : RabbitMQ kullanarak, üretici olabilir itmek çok daha fazla ölçülebilir yoklama daha hangi tüketicilere güncellemeler. Veriler, yalnızca gerektiğinde tüketiciye gönderilir ve bu da savurgan kontrollere olan ihtiyacı ortadan kaldırır.

• tablanın kilitlenmesi -> tekrar düşük performans: Kilitlenecek masa yok: P

• milyonlarca görev sırası -> yine yoklama düşük performans gösterir: Yukarıda belirtildiği gibi, Rabbitmq RAM'de bulunduğu için daha hızlı çalışacak ve akış kontrolü sağlayacaktır. Gerekirse, RAM bittiğinde iletileri geçici olarak saklamak için diski de kullanabilir. 2.0'dan sonra, Tavşan RAM kullanımında önemli ölçüde iyileşti. Kümeleme seçenekleri de mevcuttur.

AMQP ile ilgili olarak, gerçekten harika bir özellik "değişim" ve diğer borsalara yönlendirme yeteneği olduğunu söyleyebilirim. Bu size daha fazla esneklik sağlar ve ölçekleme sırasında çok kullanışlı olabilecek çok çeşitli ayrıntılı yönlendirme tipolojileri oluşturmanıza olanak tanır. İyi bir örnek için bkz:

_{(kaynak: springsource.com )}

ve: http://blog.springsource.org/2011/04/01/routing-topolojiler-for-performans-and-scalability-with-rabbitmq/

Son olarak, redis ile ilgili olarak, evet, bir mesaj komisyoncusu olarak kullanılabilir ve iyi yapabilir. Ancak, Rabbitmq, redis'ten daha fazla mesaj kuyruğu özelliğine sahiptir, çünkü rabbitmq baştan sona tam özellikli kurumsal düzeyde özel bir mesaj kuyruğu olacak şekilde inşa edilmiştir. Öte yandan Redis, öncelikle bellek içi bir anahtar / değer deposu olarak yaratıldı (şimdi bundan çok daha fazlasını yapıyor olsa da, İsviçre çakısı olarak da adlandırılır). Yine de, daha küçük boyutlu projeler için Redis ile iyi sonuçlar elde eden birçok insanı okudum / duydum, ancak daha büyük uygulamalarda pek fazla şey duymadım.

Uzun oylama sohbet uygulamasında kullanılan yeniden kullanım örnekleri: http://eflorenzano.com/blog/2011/02/16/technology-behind-convore/

PostgreSQL 9.5

PostgreSQL 9.5 içerir SELECT ... FOR UPDATE ... SKIP LOCKED. Bu, çalışma kuyruğu sistemlerinin uygulanmasını çok daha basit ve kolay hale getirir . Artık başka bir oturumun kilitlenmediği 'n' satırları getirmek ve işin tamamlandığını onaylayana kadar kilitli tutmak için artık harici bir kuyruk sistemine ihtiyacınız olmayabilir. Dış koordinasyon gerektiğinde iki aşamalı işlemlerle bile çalışır.

Dış kuyruk sistemleri, konserve işlevsellik, kanıtlanmış performans, diğer sistemlerle entegrasyon, yatay ölçeklendirme ve federasyon için seçenekler, vb. Sağlayarak kullanışlı kalır. Bununla birlikte, basit durumlar için artık onlara gerçekten ihtiyacınız yoktur.

eski versiyonlar

Böyle araçlara ihtiyacınız yoktur , ancak birini kullanmak hayatı kolaylaştırabilir. Veritabanında kuyruklama yapmak kolay görünüyor, ancak pratikte yüksek performanslı, güvenilir eşzamanlı kuyruklamanın ilişkisel bir veritabanında gerçekten zor olduğunu keşfedeceksiniz .

Bu yüzden PGQ gibi araçlar var.

Sen kullanarak PostgreSQL içinde yoklama kurtulabilirsiniz LISTENve NOTIFYfakat son derece eşzamanlı operasyon koruyarak ve eklere engellemediğini ederken o tam olarak bir tüketiciye kuyruğun üst kapalı girdileri dışarı güvenilir teslim sorununu çözmez. Bu sorunu çözeceğini düşündüğünüz tüm basit ve bariz çözümler gerçek dünyada yok ve tek işçi kuyruğu getirmenin daha az verimli sürümlerine dönüşme eğilimindedir.

Eşzamanlı çok çalışanlı kuyruk getirmelerine ihtiyacınız yoksa PostgreSQL'de tek bir kuyruk tablosu kullanmak tamamen mantıklıdır.