Dağıtılmış Kuyruk sorununun çözümleri nelerdir?


23

Dağıtılmış Kuyruk sorununun çözülebileceği çeşitli yollar hakkında daha fazla bilgi edinmeye çalışıyorum. Bu yüzden zaten orada olan ürün, hizmet, uygulama ve araştırma makalesini bilmek istiyorum.

Bir uygulama birçok zorlukla karşı karşıya kalacak ve değişimler yapmaya zorlanacaktır:

  • Siparişi güçlü mü yoksa gevşek mi?
  • Idempotent koymak var mı?
  • Tek bir makineye sığabilecek olandan daha fazla kuyruğa sahip olabilir miyiz?
  • Kuyruktaki tek bir makineye sığabilecek olandan daha fazla veriye sahip olabilir miyiz?
  • Potansiyel olarak veri kaybetmeden kaç makine çökebilir?
  • Ağ bölünmelerini tolere edebilir mi?
  • Bir net bölünmesi düzeltildiğinde verileri otomatik olarak uzlaştırabilir mi?
  • Müşteriler çökebilir teslimini garanti edebilir mi?
  • Aynı mesajın bir kereden fazla teslim edilmediğini garanti edebilir mi?
  • Bir düğüm herhangi bir noktada çökebilir, geri gelebilir ve önemsiz gönderemez mi?
  • Çalışmamayan bir kümeye, çalışma süresi olmadan çalışan düğümler ekleyebilir veya düğümleri kaldırabilir misiniz?
  • Çalışan bir kümedeki düğümleri çalışma süresi olmadan yükseltebilir misiniz?
  • Heterojen sunucularda sorunsuzca çalışabilir mi?
  • Sıraları bir grup sunucuya “yapıştırabilir misin”? (örnek: “bu sıralara yalnızca Avrupa veri merkezinde izin verilir”)
  • Varsa, veri kopyalarını en az iki veri merkezine yerleştirdiğinizden emin olabilir misiniz?

Herhangi bir uygulamanın hepsine “evet” diyebileceği konusunda hiçbir fikrim yok. Sadece çeşitli uygulamaları duymakla ilgileniyorum; nasıl çalıştıklarını, ne tradeofflarını yaptıklarını ve belki de kendi özel tradeoff'larına neden karar verdiklerini.

Ayrıca, yukarıdaki listede kaçırmış olabileceğim herhangi bir zorluk varsa.

Yanıtlar:


13

Temel bir kuyruk sistemi yazmak oldukça basittir, ancak yukarıda belirtilen tüm zorluklarla birlikte belirttiğiniz gibi, doğru yapmak başka bir konudur. Kaynak kodunu yazdığım evde yetiştirilen sistemleri, 3. taraf sistemlerini ve çeşitli JMS sağlayıcılarını kullandım. JMS (Java Messaging Service) şu ana kadar karşılaştığım en eksiksiz çözüm. İstediğiniz şeylerin çoğu JMS'de mevcuttur. Favori JMS sağlayıcım ActiveMQ. Spring ile uygulamamda yerleştirmek için ücretsiz, performanslı, kurulumu kolay ve daha da önemlisi kolay. JMS sağlayıcıları kutudan istenen her şeyi sağlamaz, ancak uygulamanızın ihtiyaç duyması durumunda sorduğunuz şeylerin çoğunu idare etmek için bir dizi araç sunarlar. Listelenen her şeye ihtiyaç duyan birçok uygulama bulamadım. Sipariş vermek önemli olmayabilir (değilse en iyisidir),

http://activemq.apache.org/what-open-source-integration-solution-works-best-with-activemq-.html

Siparişi güçlü mü yoksa kaybetti mi? Evet. Programınızın ihtiyaçlarına bağlı olarak her ikisi de vardır. İşte detaylar: http://activemq.apache.org/total-ordering.html .

Idempotent koymak var mı? Hayır, ancak buna ihtiyacınız olması durumunda uygulama katmanınıza uygulamak çok önemlidir.

Tek bir makineye sığabilecek olandan daha fazla kuyruğa sahip olabilir miyiz? Evet. Kümelenmiş sunuculara sahip olabilirsiniz ve birden fazla makineyi farklı sıralara sahip olarak ayarlamak istiyorsanız ve her ikisinden de çekebilirsiniz.

Kuyruktaki tek bir makineye sığabilecek olandan daha fazla veri alabilir miyiz? Evet, çoğu JMS sağlayıcısı, JMS sağlayıcısı düşerse mesajların düşmemesini veya kaybolmamasını sağlamak için bir çeşit DB / kalıcı depolama kullanmak zorundadır.

Potansiyel olarak veri kaybetmeden kaç makine çökebilir? Bu cevaplaması biraz zor çünkü zamanlama ile ilgili. Bununla birlikte, bir JMS sağlayıcısını çökertebilir ve diskin bozuk olmaması şartıyla, geri gelir ve son işlemi aldığı yerden başlayacaktır. Bu, mesajların iki kez gönderilebileceği anlamına gelir, ancak uygulamanızı bu işlemle kodlarsanız sorun olmaz. Her türden en az birine (üreticiler, tüketiciler veya JMS sunucuları) sahip olduğunuz sürece tamamlayacaktır. Ayrıca, bir diskin size çıkması durumunda artıklık için yükleme / denge / yük devretme düzenine sahip olabilirsiniz.

Ağ bölünmelerini tolere edebilir mi? Sanırım "net-split" ile ne demek istediğinizi anlıyorum ama tam olarak emin değilim. Sanırım JMS sunucuları kümelenmişse, sunuculardan biriyle olan bağlantımızı koparsak başka bir sunucuya atlayacağız ve bıraktığı yerden alacağız. Evet, ancak yine de bu tür durumlar, istemcinin bağlantısını kaybettiği noktaya bağlı olarak çift mesajlara yol açabilir.

Bir net bölünmesi düzeltildiğinde verileri otomatik olarak uzlaştırabilir mi? İşlem uygulanmış oturumları kullanıyorsanız, yalnızca varolan istemciler için üzerinde çağrılan bir taahhüdü olan herhangi bir iletiyi yeniden gönderir.

Müşteriler çökebilir teslimini garanti edebilir mi? Evet, bu JMS'nin temel amaçlarından biridir. Garantili teslimat, bir mesajın sıraya alınması durumunda, bir müşteri tarafından yapılmasının garanti edileceği anlamına gelir.

Aynı mesajın bir kereden fazla teslim edilmediğini garanti edebilir mi? Evet, gerçekleştirilen oturumlar kullanılıyorsa. Bu, müşterinin mesajı kabul ettiği ve taahhüt / geri alma olarak adlandırdığı anlamına gelir. Taahhüt çağrıldığında, mesajı tekrar teslim etmeyecektir.

Bir düğüm herhangi bir noktada çökebilir, geri gelebilir ve önemsiz gönderemez mi? Dayanıklı kümelenmiş sıraların olduğu durumda. Evet, kümedeki diğer düğüm iletiyi ilettiğinde "önemsiz" kalmaz. Hala onaylanmayan bir şeyi teslim edebilir.

Çalışmamayan bir kümeye, çalışma süresi olmadan çalışan düğümler ekleyebilir veya düğümleri kaldırabilir misiniz? Evet.

Çalışan bir kümedeki düğümleri çalışma süresi olmadan yükseltebilir misiniz? Bu cevap vermem için biraz zor, ama evet, bunu yapabileceğine inanıyorum.

Heterojen sunucularda sorunsuzca çalışabilir mi? Bu tam olarak ne anlama geliyor? Çoğu JMS sağlayıcısının farklı donanım, işletim sistemi vb. Kullanan ortamlarda çalıştırılmasının çok kolay olduğunu öğrendim. Herhangi bir dağıtılmış işleme sistemi, yavaş bir düğümden olumsuz olarak etkilenebilir. Sırayı ve tüketicileri çalıştıran 2 8 Core Intel sunucum vardı. Bu 16 çekirdekten oluşuyor ve tüketici olarak tek bir çekirdekli makineyi eklediğimden sadece iki kutuyu kullanmaktan daha iyi performans elde ettim. Bu tek çekirdekli makine çok daha yavaştı, tüm ızgarayı 2x oranında yavaşlattı. Bunun JMS ile hiçbir ilgisi yoktu.

Sıraları bir grup sunucuya “yapıştırabilir misin”? Kısa cevap evet. Yalnızca Avrupa veri merkezindeki bir kümeyi çalıştırabileceğiniz ve buradaki kuyruğu yapılandırabileceğiniz bir yol düşünebilirim. Daha sonra bahar konfigürasyonunuzda tüketicilerinizi, bu kümenin yanı sıra diğer kümelerdeki diğer kuyrukları da tüketecek şekilde ayarlayın. Dokümanlara bakmak isteyebilirsiniz:

http://activemq.apache.org/clustering.html

Varsa, veri kopyalarını en az iki veri merkezine yerleştirdiğinizden emin olabilir misiniz? Yine buna inanıyorum, ama kümelenme belgelerine bakmak en iyisi.

Yine JMS, ihtiyaç duyduğunuz şekilde ayarlayabileceğiniz birçok seçeneğe sahiptir. İşlem gören oturumların ve dayanıklı kuyrukların kullanılması performans maliyeti ile birlikte gelir. Bütün çanları ve ıslıkları, performansı 10x'e kadar etkileyebildiğimi gördüm. JBossMQ’yu kullandığımda, bu özelliklerden bazılarını kapatırsak, yaklaşık 10.000 mesaj / s elde edebiliriz, ancak bunları devreye sokmak bizi 1000 mesaj / s'ye düşürdü. Büyük damla.


Bu cevapla zaman ayırdığınız için teşekkür ederiz. Net bölünme, kümedeki bazı düğümlerin geri kalanıyla iletişim kuramadığı durumdur. Heterojen sunucularda çoğunlukla farklı RAM miktarları kastediyorum;
Chris Vest,

Sonra kesinlikle ağları üzerinde evet. Tüketici düşerse veya iletişim kuramıyorsa, bağlanmaya çalışmaya devam edecektir. Taahhüt almayan kendisine verilen işler daha sonra diğer tüketicilere iade edilecektir. Bir JMS sağlayıcısı düşerse ve mesaj kümelerinin diğer üyelerine sahipseniz, mesajları kaybetmemek için küme genelinde yinelenebilir.
chubbsondubs,

Makinelerin RAM, Donanım veya İşletim Sistemi olmasından farklı olup olmadığına dair hiçbir gereklilik yoktur. İhtiyacınız olursa karma bir makine torbası çalıştırabilirsiniz. Tek endişe, aynı olmayan makinelerin performansla ilgili olduğunu belirttiğim ve mesajları daha düşük verime yol açabilecek farklı oranlarda işleyeceği. Bununla birlikte, JMS modeli bunu push modeli yerine çekerek gerçeği ile biraz azaltır. Push modelleri bu tür sorunlara karşı çok daha hassastır.
chubbsondubs,
Sitemizi kullandığınızda şunları okuyup anladığınızı kabul etmiş olursunuz: Çerez Politikası ve Gizlilik Politikası.
Licensed under cc by-sa 3.0 with attribution required.