Message Queue. Veritabanı vs Adanmış MQ

İleti kuyruğuyla ilgili tavsiyeden sonra geldim. "İşler" in bir ileti kuyruğuna gönderilmesi için gereksinimlerimiz var.

Orijinal öneri sadece bir SQL Server örneği kullanmak ve bundan gelen mesajları işlemekti. İnternette okuduğum her şey bir Message Queue için veritabanı kullanmanın ölçeklenebilir bir çözüm olmadığını gösteriyor. Bu nedenle, RabbitMQ veya başka bir 3. taraf MQ kullanma fikri önerildi.

Dikkate alınması gereken diğer bir şey, "iş işleme" gereksiniminin 30 saniyeden daha az olmayacağıdır, bu nedenle işi yapan işlem her 30 saniyede bir veritabanını yoklayacaktır. Bana göre, bu çok kötü görünmüyor ve Veritabanına büyük bir yük eklemeden muhtemelen işe yarayacaktır.

Müşterilerimiz için bunun için kullanabileceğimiz bir Veritabanımız zaten var, bu yüzden müşterilerimize çok fazla destek eklemeyecek, oysa 3. taraf bir MQ eklersek, ağ yapılandırması vb. İçin ekstra destek olurdu. dikkate değer bir çok kullanıcı var.

Düşündüğüm diğer seçenek, kullanıcıların ikisi arasında seçim yapmasına izin vermekti. Küçük bir kullanıcıysa, Sql Server çözümü iyi olacaktır, ancak daha büyük bir kullanıcıysa, 3. taraf MQ çözümünü yapılandırmalarına izin veririz.

Herhangi bir çözüm üzerinde satılmıyorum, kimsenin düşünmem gereken bir şey olup olmadığını merak ediyorum.

İnternette okuduğum her şey bir Message Queue için veritabanı kullanmanın ölçeklenebilir bir çözüm olmadığını gösteriyor.

" X'i kullanmayın çünkü ölçeklemiyor " (bağlantı bazılarının sakıncalı bulabileceği bir dil içeriyor) kalabalığı tarafından sıklıkla göz ardı edilen gerçeklik , ölçeğin her zaman önemli olmadığıdır. Gezegenin yüzündeki her uygulamaya toplu olarak bakarsanız, ölçeğin nadiren önemli olduğunu söyleyecek kadar ileri gideceğim .

Yorumunuz günde 20.000 mesajlık bir orana işaret ediyor, bu da saniyede 0.23 mesajlık ortalama bir hızı (4.3 saniyede bir) desteklemeye ihtiyaç duyacağınız anlamına geliyor. Projeniz beklediğinizden daha başarılı iki büyüklük sırası ortaya çıkarsa, gereksinimleriniz saniyede 23 mesaj işlemeye atlar, bu da dört yaşındaki cep telefonuma veya Ahududu'ya vermekten çok rahat olacağım bir görev Pi. Bunun üstünde bir kaç büyüklük daha ele geçirseniz bile, bu hala yüksek ölçekli bir uygulama değildir.

(Neyse ki, kenarlıklardan) projelerin kötü sona erdiğini izledim çünkü ya ölmeyecek çok fazla zaman saptamak için çok fazla zaman harcadılar ya da üzerinde hiç zaman olmadılar ve sonunda yapılan ölçekle ezildiler. Diğer her şey gibi, mutlu bir ortam var. Uygulamanız için büyük ölçeklendirmenin gerçekçi bir olasılık olduğunu düşünüyorsanız, şu anda dağıtılması ucuz olan ölçeklenebilir olmayan parçalar etrafında yeterli soyutlama oluşturmak için az miktarda ekstra iş yapmak için bir iş vakası yapmak zor olmamalıdır . Bunu yapmak, daha sonra , bir ölçek ihtiyacı ortaya çıkarsa, tüm sistemi yeniden düşünmek zorunda kalmadan bu parçaların toptan değiştirilmesini sağlayacak bir yolunuz (ve muhtemelen geliriniz) olduğu anlamına gelir.

Uygulamanızın mesaj hacmi, bir veritabanını veya bir mesaj kuyruğu sistemini mütevazı bir donanımda bile terletmeyecek olsa da, muhtemelen bir veya diğerini daha iyi bir seçim haline getiren mesaj işlemlerinizin nasıl ele alındığına dair başka gereksinimleriniz vardır. Bu gereksinimler, değerlendirmeniz gereken şeydir.

Mesaj Kuyrukları gerçekten birçoğunuz olduğunda kendi başlarına gelir ve aralarındaki mesajları yönlendirir, fanout birden fazla tüketiciye vb.

'Çevrimdışı' işlemek istediğiniz tek bir 'iş kuyruğunuz' varsa, bir SQL tablosu iyi olur.

Devam eden işleri işaretlemenin, eskilerini temizlemenin ve sistem durduğunda uyarı vermenin bir yolunu bulunduğundan emin olun. Ancak tek bir kuyruk için bunları elle yönetmek ayrı bir kuyruk çözümünü sürdürmekten daha az iş olacaktır.

Diğerlerinin de belirttiği gibi ölçek muhtemelen burada önemli değildir. İki farklı depolama mekanizması kullanma problemi işlemsel bütünlüktür.

Özel bir mesaj kuyruğuyla devam ediyorsanız, hata durumunda aşağıdakilerden birini seçmeniz gerekir.

1. Verilerin mb üzerinde olmasına izin ver, ancak db'de olmamasına izin ver
2. Verilerin db cinsinden olabileceğini, ancak mb cinsinden olmamasına izin ver
3. Db an mq arasında karmaşık olabilen iki aşamalı kesinleştirme veya dağıtılmış işlemler oluşturma

Normal bir işlem kullanarak verileri tek bir yerde kaydederseniz tüm bu sorunlar ortadan kalkar. Bu nedenle db'yi bir görev kuyruğu olarak kullanmak mükemmel bir çözümdür.

Pratik olması için, bir mesaj kuyruğu kullanmamın ana nedenleri:

• Tekerleği yeniden icat etmek zorunda değildim. Veritabanı kullanarak en basit mesaj kuyruğunu tasarlamak için en az birkaç saat düşünme, birkaç saat kodlama vb. Gerekir. Bir ileti kuyruğu uygulamakla karşılaştırıldığında, yapılandırmayı yapılandırmak ve / veya otomatikleştirmek için gereken süre önemsizdir
• Mesaj kuyrukları, üretici ve tüketici için güzel ve net bir arayüze sahiptir. Bu muhtemelen başvuru yazmada en önemli şeydir. Arayüz olmadan, mesaj kuyrukları temelde sadece bir veri topluluğudur
• İleti kuyrukları, gelecekte ihtiyaç duyulabilecek daha fazla özellik sunar

Kullanıcıların seçmesine izin vermekle ilgili olarak, bu gerçekten kullanıcıların umursamaması gereken bir uygulama detayıdır. Kullanıcılar aynı arabirime sahip olmalı ve veritabanı veya mesaj kuyruğu kullanılıyorsa kullanıcılar arasında fark olmamalıdır. Tek bir tasarım ayarlandıktan sonra, kullanıcılar için olası bir seçim, ihtiyaçlarını karşılamak için kaç düğümün dağıtılması gerektiğidir.

Bir performans testine göre saniyede 20k işlem yapabilen bir Mssql mesaj kuyruğu çözümü oluşturdum ve çoğu zaman 10 / saniyeye ihtiyacımız var. Ben aslında yerleşik öncelik olabilir aslında özel mesaj kuyruğu eksikliği bir özellik olduğunu düşünüyorum. Ve bu benim durumumda büyük bir gereklilikti.