Ölçeklenebilir bir mesaj kuyruğu mimarisi tasarlama

Yakın zamanda ölçeklenebilir ve kurumsal bilgisayar mimarisinin nüanslarını öğrenmeye başladım ve merkezi bileşenlerden biri de bir mesajlaşma kuyruğu. Herhangi bir programlama paradigmasından en iyisini öğrenmek için bir mesajlaşma kuyruğu servisi olan kendi versiyonumu uygulamaya çalışıyorum.

Şimdiye kadar, ilk tasarımım iş parçacığı bir soket dinleyicisi üzerinde çalışıyor, ancak aynı mesajın iki ayrı işlem düğümü tarafından iki kez indirilmesini önlemek için, bir mesaj başlatıldığında mesaj sırası indeks yazıcısı kilitlendi ve kayıt yapıldıktan sonra kilidi açıldı. güncellenmiş. Bu nedenle, bu iş parçacığı için gereksinimi ortadan kaldırır ve ileti dizisi hizmetinin çalıştığı sunucunun işlem hızına bağlı olarak ölçeklenebilir bir sistemin boyutu için bir tavan olduğu anlamına gelir.

Bunu çözmenin yolu, birden çok sunucuda ileti sırası hizmetini çalıştırmak olacaktır, ancak bu, aynı iletinin iki kez indirilme olasılığını artıracaktır. Bu tür sorunları önlemenin tek yolu, (sunucular, hatta tek bir sunucudaki iş parçacıkları, bilgilerini senkronize ettikten ve böyle bir yeniden yayınlama tespit ettikten sonra) işlem düğümüne durması için komut verecek olan bir iptal çağrısı eklemek olacaktır. mevcut iş ve bir sonraki mesaj için mesaj kuyruğunu yeniden sorgulamak, ancak yine, gönderilen trafiğin çoğunun senkronizasyon ve iptal çağrılarının alınacağı, bir tıkanıklığa neden olan ve bilgilerin işlenmesini yavaşlatan bir tavan olacaktır. işlem düğümlerinin çoğu boş işlem yapıyor ve zamanını boşa harcıyordu.

Bu sorunu çözmeyi düşünebildiğim son yol, her ileti kuyruğu sunucusunun (ve her sunucudaki her iş parçacığının) kuyruğun aradığı yerle ilgili olarak belirli bir uzaklığı olmasını sağlamaktır; Uygulamanın türü, özellikle işlemenin belirli bir sırada yapılması gerekiyorsa.

Söylenenlerin hepsi, mevcut kurumsal sınıf mesaj sırası servislerinin bu sorunları nasıl önlediğini gösterebilecek herhangi bir mesaj sırası mimarisinin tasarımları var mı?

Kısacası:

Bu zor bir sorun mu. Tekerleği yeniden icat etme.

İleti kuyruğu katmanını çözen birçok teknoloji vardır. İçerirler

• ZeroMQ
• RabbitMQ
• Apache Kafka
• Redis, BLPOP veya PubSub ile (ı bunun nasıl sordunuz burada ).
• RabbitMQ dışında diğer AMQP uygulamaları

Sanırım her birinin dezavantajlarını tartışmamın kapsamı dışında değil, en azından değil, çünkü bu iyi öksürük için uzmanlık iddiasında değilim, Tavşan öksürüğü kullanmıyorum .

Bu teknolojilerden herhangi birini kullanmak istemeseniz bile, belgelerini okuyun.

Bu sizi tek bir sistemde mümkün olan tasarım kalıpları konusunda eğitecektir. ZeroMQ'un belgelerinin okunması sizi, zarif bir şekilde uyguladıkları mimarileri sıraya koyan birçok klasik mesaj konusunda eğitecektir. ZeroMQ kullanmasanız bile, bu kalıpları bilmek, bu kalıpları orada uygulayıp uygulayamayacağınızı sorarak diğer kuyruk teknolojilerini değerlendirmenize yardımcı olacaktır.

RabbitMQ / AMQP'nin döviz sıra modeli hakkında bilgi edinin. Yönlendirme sizin için gelebilir - bu Redis PUBSUB tarafından desteklenir ancak ZeroMQ tarafından desteklendiğimi hatırlamıyorum - ve beğenilerim oldukça uzun bir süredir Memcached anketi (yuck!) Üzerinden kötü uygulanmış olsa da, dükkanımın kullandığı bir şey. .

Nasıl seçilir?

SLA'sı bir web uygulaması için tipik olan bir kuruluşta çalışıyorum; hizmeti hızlı bir şekilde küçük veri kaybıyla geri yükleyebildiğimiz sürece, bazı kesintiler tamamdır. Twitter veya Tumblr gibi problemleri ölçeklendirme hakkında düşünmek zorunda kalmadık, bu yüzden verimlilik hacmini düşünmek zorunda kalmadık. Söylenecek gibi, eğer benimkine benzer bir SLA uyguluyorsanız, bu düşünceler akla gelecektir:

• istemci kitaplıkları gerçekten çalışıyor mu? İçlerinde bağlantı kurmak kolay mı? (SıfırMQ, Redis: evet. TavşanMQ: hayır).
• Sunucu konsolundan izleme ve yönetim kolaydır? (Redis: evet, RabbitMQ: evet, ZeroMQ: hatırladığımdan değil ama bu kadar uzun süre kullanmadık)
• Müşteriler iç kuyrukları destekliyor mu? Böylece kısa kesintilerde veri kaybı az oluyor (ZeroMQ, Redis: evet. RabbitMQ: hayır.)

Elbette, yüksek frekanslı bir ticaret mağazası için çalışıyorsanız, bunlar daha az endişeniz olacaktır. Sonunda daha yüksek verim karşılığında, geliştirme süresini müşteri tarafındaki bir kütüphaneye koymaya daha istekli olursunuz. Ancak bunu, sizi bu teknolojilerin kullanıma hazır işlevleri yerine değil, performansları temelinde pazarlamaya meyilli oldukları konusunda uyarmak için daha fazla yazıyorum . Eğer bir web-girişimi iseniz , ikincisinden çok daha fazla ilgi duyuyorsunuz ve buna bağlı olarak, iyi performansta kullanım kolaylığı için daha iyi bir performansa sahip olan Redis gibi bir şey büyük olasılıkla RabbitMQ'dan daha iyi bir seçim. (Gerçekten RabbitMQ'den hoşlanmıyorum).