Hata toleransı ve yüksek kullanılabilirlik önemli konulardır, bu nedenle RabbitMQ ve Kafka'ya ayrı makaleler ayıracağız. Bu makale RabbitMQ hakkındadır ve bir sonraki makale ise RabbitMQ ile karşılaştırmalı olarak Kafka hakkındadır. Bu uzun bir makale, o yüzden rahat olun.

Hata toleransı, tutarlılık ve yüksek kullanılabilirlik (HA) stratejilerine ve her stratejinin yaptığı ödünleşimlere bakalım. RabbitMQ bir düğüm kümesi üzerinde çalışabilir ve daha sonra dağıtılmış bir sistem olarak sınıflandırılır. Dağıtılmış sistemler söz konusu olduğunda sıklıkla tutarlılık ve kullanılabilirlikten bahsederiz.

Bu kavramlar bir sistemin arızalandığında nasıl davranacağını tanımlar. Ağ bağlantısı hatası, sunucu hatası, sabit sürücü hatası, çöp toplama, paket kaybı veya ağ bağlantısı yavaşlaması nedeniyle sunucunun geçici olarak kullanılamaması. Bütün bunlar veri kaybına veya çakışmalara yol açabilir. Tüm başarısızlık senaryoları için hem tamamen tutarlı (veri kaybı yok, veri farklılığı yok) hem de kullanılabilir (okuma ve yazma işlemlerini kabul edecek) bir sistem kurmanın neredeyse imkansız olduğu ortaya çıktı.

Tutarlılık ve kullanılabilirliğin yelpazenin karşıt uçlarında olduğunu göreceğiz ve hangi yolu optimize edeceğinizi seçmeniz gerekiyor. İyi haber şu ki RabbitMQ ile bu seçim mümkün. Dengeyi daha fazla tutarlılığa veya daha fazla erişilebilirliğe doğru kaydırmak için bu tür "inek" kaldıraçlara sahipsiniz.

Onaylanan kayıtlar nedeniyle hangi konfigürasyonların veri kaybına yol açtığına özellikle dikkat edeceğiz. Yayıncılar, komisyoncular ve tüketiciler arasında bir sorumluluk zinciri vardır. Mesaj komisyoncuya iletildikten sonra mesajı kaybetmemek onun görevidir. Aracı, yayıncının mesajı aldığını onayladığında mesajın kaybolmasını beklemiyoruz. Ancak bunun aracınızın ve yayıncınızın yapılandırmasına bağlı olarak gerçekleşebileceğini göreceğiz.

Tek Düğüm Esnekliği İlkeleri

Esnek Kuyruklama/Yönlendirme

RabbitMQ'da iki tür kuyruk vardır: dayanıklı ve dayanıklı olmayan. Tüm kuyruklar Mnesia veritabanına kaydedilir. Dayanıklı kuyruklar, düğüm başlangıcında yeniden duyurulur ve böylece yeniden başlatmalardan, sistem çökmelerinden veya sunucu çökmelerinden (veriler kalıcı olduğu sürece) hayatta kalır. Bu, yönlendirme (değişim) ve kuyruğun dayanıklı olduğunu beyan ettiğiniz sürece kuyruk/yönlendirme altyapısının tekrar çevrimiçi olacağı anlamına gelir.

Düğüm yeniden başlatıldığında geçici kuyruklar ve yönlendirme kaldırılır.

Kalıcı mesajlar

Bir kuyruğun dayanıklı olması, tüm mesajlarının düğümün yeniden başlatılmasından sonra hayatta kalacağı anlamına gelmez. Yalnızca yayıncı tarafından şu şekilde ayarlanan iletiler: sürekli (kalıcı). Kalıcı mesajlar aracıya ek yük oluşturur, ancak mesaj kaybı kabul edilemezse başka seçenek yoktur.

Pirinç. 1. Sürdürülebilirlik matrisi

Kuyruk yansıtma ile kümeleme

Bir komisyoncunun kaybından kurtulmak için fazlalığa ihtiyacımız var. Birden fazla RabbitMQ düğümünü bir kümede birleştirebiliriz ve ardından birden fazla düğüm arasındaki kuyrukları çoğaltarak ek yedeklilik ekleyebiliriz. Bu şekilde, bir düğüm arızalanırsa veri kaybetmeyiz ve kullanılabilir durumda kalırız.

Kuyruk yansıtma:

• tüm yazma ve okuma komutlarını alan bir ana kuyruk (ana)
• ana kuyruktan tüm mesajları ve meta verileri alan bir veya daha fazla ayna. Bu aynalar ölçeklendirme için değil, tamamen yedeklilik için oradadır.

Pirinç. 2. Kuyruk yansıtma

Yansıtma uygun politika tarafından ayarlanır. İçinde çoğaltma katsayısını ve hatta kuyruğun bulunması gereken düğümleri bile seçebilirsiniz. Örnekler:

• ha-mode: all
• ha-mode: exactly, ha-params: 2 (bir ana ve bir ayna)
• ha-mode: nodes, ha-params: rabbit@node1, rabbit@node2

Yayıncı onayı

Tutarlı kayıt elde etmek için Yayıncı Onayları gereklidir. Bunlar olmadan mesajların kaybolma riski vardır. Mesaj diske yazıldıktan sonra yayıncıya bir onay gönderilir. RabbitMQ, mesajları alındıktan sonra değil, periyodik olarak birkaç yüz milisaniyelik bir sürede diske yazar. Bir kuyruk yansıtıldığında, yalnızca tüm yansıtmalar mesajın kendi kopyasını diske yazdıktan sonra bir onay gönderilir. Bu, onayların kullanılmasının gecikmeye neden olduğu, ancak veri güvenliği önemliyse bunların gerekli olduğu anlamına gelir.

Yük devretme kuyruğu

Bir aracı kapandığında veya çöktüğünde, o düğümdeki tüm kuyruk liderleri (ana düğümler) onunla birlikte çöker. Küme daha sonra her ana öğenin en eski aynasını seçer ve onu yeni ana öğe olarak yükseltir.

Pirinç. 3. Çoklu yansıtılmış kuyruklar ve politikaları

Komisyoncu 3 düşer. Aracı 2'deki Kuyruk C aynasının ana konuma yükseltildiğini unutmayın. Ayrıca Broker 1'deki Kuyruk C için yeni bir ayna oluşturulduğunu unutmayın. RabbitMQ her zaman politikalarınızda belirtilen çoğaltma faktörünü korumaya çalışır.

Pirinç. 4. Aracı 3 başarısız olur ve C kuyruğunun başarısız olmasına neden olur

Bir sonraki Broker 1 düşüyor! Sadece bir komisyoncumuz kaldı. Kuyruk B aynası ana seviyeye yükseltilir.

Şek. 5

Aracı 1'e geri döndük. Aracının kaybolması ve kurtarılması durumunda verilerin ne kadar iyi hayatta kaldığına bakılmaksızın, tüm yansıtılmış kuyruk mesajları yeniden başlatma sonrasında atılır. Bunu not etmek önemlidir çünkü sonuçları olacaktır. Bu sonuçlara birazdan bakacağız. Yani Broker 1 artık yeniden kümenin bir üyesidir ve küme politikalara uymaya çalışarak Broker 1 üzerinde aynalar oluşturur.

Bu durumda, veriler gibi Broker 1'in kaybı da tamamlandı, dolayısıyla aynalanmayan Kuyruk B tamamen kaybedildi.

Pirinç. 6. Broker 1 hizmete geri döner

Broker 3 tekrar çevrimiçi olduğundan A ve B kuyrukları, HA politikalarını karşılamak için üzerinde oluşturulan aynaları geri alır. Ancak artık tüm ana kuyruklar tek bir düğümde! Bu ideal değildir; düğümler arasında eşit bir dağılım daha iyidir. Ne yazık ki, ustaları yeniden dengelemek için burada pek fazla seçenek yok. Bu konuya daha sonra tekrar döneceğiz çünkü önce kuyruk senkronizasyonuna bakmamız gerekiyor.

Pirinç. 7. Broker 3 hizmete geri döner. Tüm ana kuyruklar tek bir düğümde!

Artık aynaların nasıl yedeklilik ve hata toleransı sağladığına dair bir fikriniz olmalı. Bu, tek bir düğüm arızası durumunda kullanılabilirliği sağlar ve veri kaybına karşı koruma sağlar. Ancak henüz işimiz bitmedi çünkü gerçekte durum çok daha karmaşık.

senkronizasyon

Yeni bir ayna oluştururken, tüm yeni mesajlar her zaman bu aynaya ve diğer aynalara kopyalanacaktır. Ana kuyruktaki mevcut verilere gelince, onu yeni bir aynaya kopyalayabiliriz, bu da ana sunucunun tam bir kopyası haline gelir. Ayrıca mevcut mesajları kopyalamamayı ve ana kuyruk ile yeni aynanın zamanla birleşmesine, yeni mesajların kuyruğa gelmesine ve mevcut mesajların ana kuyruğun başından ayrılmasına izin vermeyi de seçebiliriz.

Bu senkronizasyon otomatik veya manuel olarak gerçekleştirilir ve bir kuyruk ilkesi kullanılarak yönetilir. Bir örneğe bakalım.

İki yansıtılmış kuyruğumuz var. Kuyruk A otomatik olarak senkronize edilir ve Kuyruk B manuel olarak senkronize edilir. Her iki kuyruk da on mesaj içerir.

Pirinç. 8. Farklı senkronizasyon modlarına sahip iki kuyruk

Şimdi Broker 3'ü kaybediyoruz.

Pirinç. 9. Broker 3 düştü

Komisyoncu 3 hizmete geri döner. Küme, yeni düğümdeki her kuyruk için bir ayna oluşturur ve yeni A Kuyruğu'nu ana düğümle otomatik olarak senkronize eder. Ancak yeni Kuyruk B'nin aynası boş kalıyor. Bu şekilde, Kuyruk A'da tam yedekliliğe ve mevcut Kuyruk B mesajları için yalnızca bir aynaya sahip oluyoruz.

Pirinç. 10. A Kuyruğunun yeni aynası mevcut tüm mesajları alır, ancak B Kuyruğunun yeni aynası almaz.

Her iki kuyruğa da on mesaj daha geliyor. Daha sonra Aracı 2 çöker ve Sıra A, Aracı 1'deki en eski yansıtmaya geri döner. Başarısız olduğunda veri kaybı olmaz. Kuyruk B'de ana mesajda yirmi mesaj var ve yansıtmada yalnızca on mesaj var çünkü bu kuyruk hiçbir zaman orijinal on mesajı kopyalamadı.

Pirinç. 11. Kuyruk A, mesajları kaybetmeden Broker 1'e geri döner

Her iki sıraya da on mesaj daha geliyor. Şimdi Broker 1 çöküyor. Kuyruk A, mesajları kaybetmeden kolayca aynaya geçiş yapar. Ancak Kuyruk B'de sorunlar yaşanıyor. Bu noktada kullanılabilirliği veya tutarlılığı optimize edebiliriz.

Erişilebilirliği optimize etmek istiyorsak politika ha-başarısızlık durumunda terfi kurulmalı her zaman. Bu varsayılan değerdir, dolayısıyla politikayı hiçbir şekilde belirtemezsiniz. Bu durumda aslında senkronize olmayan aynalardaki hatalara izin vermiş oluyoruz. Bu, mesajların kaybolmasına neden olur ancak kuyruk okunabilir ve yazılabilir kalır.

Pirinç. 12. A kuyruğu, mesajları kaybetmeden Broker 3'e geri alınır. Sıra B, on mesajın kaybolmasıyla Aracı 3'e geri dönüyor

Ayrıca kurulum yapabiliriz ha-promote-on-failure anlam içine when-synced. Bu durumda, aynaya geri dönmek yerine sıra, Broker 1'in verileriyle birlikte çevrimiçi moda dönmesini bekleyecektir. Geri döndükten sonra ana kuyruk herhangi bir veri kaybı olmadan Broker 1'e geri döner. Veri güvenliği için kullanılabilirlikten fedakarlık edilir. Ancak bu, birazdan ele alacağımız, tamamen veri kaybına bile yol açabilecek riskli bir moddur.

Pirinç. 13. Komisyoncu 1'i kaybettikten sonra B Sırası kullanılamıyor

"Otomatik senkronizasyonu hiç kullanmamak daha mı iyi?" diye sorabilirsiniz. Cevap, senkronizasyonun bir engelleme işlemi olduğudur. Senkronizasyon sırasında ana kuyruk herhangi bir okuma veya yazma işlemi gerçekleştiremez!

Bir örneğe bakalım. Artık önümüzde çok uzun kuyruklar var. Nasıl bu kadar büyüyebiliyorlar? Birkaç nedenden dolayı:

• Kuyruklar aktif olarak kullanılmıyor
• Bunlar yüksek hızlı kuyruklardır ve şu anda tüketiciler yavaştır
• Yüksek hızlı kuyruklar oluştu, bir aksaklık yaşandı ve tüketiciler yetişiyor

Pirinç. 14. Farklı senkronizasyon modlarına sahip iki büyük kuyruk

Şimdi Broker 3 düşüyor.

Pirinç. 15. Broker 3 düşüyor ve her kuyrukta bir master ve ayna kalıyor

Broker 3 tekrar çevrimiçi olur ve yeni aynalar oluşturulur. Ana Kuyruk A, mevcut mesajları yeni yansıtmaya kopyalamaya başlar ve bu süre zarfında Kuyruk kullanılamaz. Verilerin kopyalanması iki saat sürer, bu da bu Kuyruk için iki saatlik kesintiye neden olur!

Ancak Kuyruk B tüm dönem boyunca kullanılabilir durumda kalır. Erişilebilirlik için bazı fazlalıkları feda etti.

Pirinç. 16. Senkronizasyon sırasında kuyruk kullanılamıyor

İki saat sonra Kuyruk A da kullanılabilir hale gelir ve okuma ve yazma işlemlerini yeniden kabul etmeye başlayabilir.

Güncellemeler

Senkronizasyon sırasındaki bu engelleme davranışı, çok büyük kuyruklara sahip kümelerin güncellenmesini zorlaştırır. Bir noktada ana düğümün yeniden başlatılması gerekir; bu, sunucu yükseltilirken ya bir yansıtmaya geçmek ya da kuyruğu devre dışı bırakmak anlamına gelir. Geçiş yapmayı seçersek, aynalar senkronize edilmezse mesajları kaybederiz. Varsayılan olarak, aracı kesintisi sırasında senkronize edilmemiş bir yansıtmaya yük devretme gerçekleştirilmez. Bu, komisyoncu geri döner dönmez hiçbir mesajı kaybetmeyeceğimiz anlamına gelir, tek hasar basit bir kuyruktur. Bir komisyoncunun bağlantısı kesildiğinde davranış kuralları politika tarafından belirlenir ha-promote-on-shutdown. İki değerden birini ayarlayabilirsiniz:

• always= senkronize edilmemiş yansıtmalara geçiş etkinleştirildi
• when-synced= yalnızca senkronize aynaya geçiş, aksi takdirde kuyruk okunamaz ve yazılamaz hale gelir. Aracı geri döner dönmez kuyruk hizmete geri döner

Öyle ya da böyle, büyük kuyruklarda veri kaybı ile kullanılamama arasında seçim yapmanız gerekir.

Kullanılabilirlik Veri Güvenliğini Artırdığında

Karar vermeden önce dikkate alınması gereken bir komplikasyon daha var. Yedeklilik açısından otomatik senkronizasyon daha iyi olsa da veri güvenliğini nasıl etkiler? Tabii ki, daha iyi yedeklilik sayesinde RabbitMQ'nun mevcut mesajları kaybetme olasılığı daha düşüktür, peki ya yayıncılardan gelen yeni mesajlar?

Burada aşağıdakileri dikkate almanız gerekir:

• Yayıncı bir hata döndürüp yukarı akış hizmetinin veya kullanıcının daha sonra tekrar denemesini sağlayabilir mi?
• Yayıncı daha sonra tekrar denemek üzere mesajı yerel olarak veya bir veritabanına kaydedebilir mi?

Yayıncı yalnızca mesajı silebiliyorsa, aslında erişilebilirliği artırmak veri güvenliğini de artırır.

Bu nedenle bir denge aranmalıdır ve çözüm özel duruma bağlıdır.

Ha-promote-on-failure=when-synced ile ilgili sorunlar

Fikir ha-başarısızlık durumunda terfi= senkronize edildiğinde senkronize edilmemiş bir aynaya geçişi önleyerek veri kaybını önlememizdir. Kuyruk okunamaz veya yazılabilir durumda kalır. Bunun yerine, çöken aracıyı verileri bozulmadan kurtarmaya çalışırız, böylece veri kaybı olmadan ana öğe olarak çalışmaya devam edebilir.

Ancak (ve bu büyük bir ama) komisyoncu verilerini kaybettiyse, o zaman büyük bir sorunumuz var: kuyruk kayboluyor! Tüm veriler gitti! Çoğunlukla ana kuyruğu yakalayan aynalarınız olsa bile o aynalar da atılır.

Aynı ada sahip bir düğümü yeniden eklemek için kümeye kayıp düğümü unutmasını söyleriz (komutla) tavşanmqctl unut_cluster_node) ve aynı ana bilgisayar adıyla yeni bir aracı başlatın. Küme kayıp düğümü hatırlarken eski kuyruğu ve senkronize olmayan aynaları da hatırlar. Bir kümeye artık bir düğümü unutması söylendiğinde o sıra da unutulur. Şimdi bunu yeniden ilan etmemiz gerekiyor. Kısmi bir veri kümesine sahip aynalarımız olmasına rağmen tüm verileri kaybettik. Senkronize olmayan bir aynaya geçmek daha iyi olurdu!

Bu nedenle, manuel senkronizasyon (ve senkronizasyon başarısızlığı) ile birlikte ha-promote-on-failure=when-syncedbence oldukça riskli. Dokümanlar bu seçeneğin veri güvenliği için mevcut olduğunu söylüyor ancak bu iki ucu keskin bir bıçak.

Usta yeniden dengeleme

Söz verdiğimiz gibi, tüm ustaların bir veya daha fazla düğümde birikmesi sorununa dönüyoruz. Bu, sürekli bir küme güncellemesinin sonucu olarak bile gerçekleşebilir. Üç düğümlü bir kümede tüm ana kuyruklar bir veya iki düğümde toplanır.

Ustaları yeniden dengelemek iki nedenden dolayı sorunlu olabilir:

• Yeniden dengelemeyi gerçekleştirmek için iyi bir araç yok
• Kuyruk senkronizasyonu

Yeniden dengeleme için üçüncü bir taraf var Eklentisiresmi olarak desteklenmiyor. RabbitMQ kılavuzundaki üçüncü taraf eklentilerle ilgili olarak söyleniyor: “Eklenti bazı ek yapılandırma ve raporlama araçları sağlıyor ancak RabbitMQ ekibi tarafından desteklenmiyor veya doğrulanmıyor. Riski size ait olmak üzere kullanın."

Ana kuyruğu HA politikaları aracılığıyla taşımanın başka bir yolu daha var. Kılavuzda bahsediliyor senaryo bunun için. Bu şekilde çalışır:

• Mevcut HA ilkesinden daha yüksek önceliğe sahip geçici bir ilke kullanarak tüm yansıtmaları kaldırır.
• Ana kuyruğun aktarılması gereken düğümü belirterek HA geçici ilkesini düğüm modunu kullanacak şekilde değiştirir.
• Push geçişi için kuyruğu senkronize eder.
• Geçiş tamamlandıktan sonra geçici politikayı siler. İlk HA ilkesi yürürlüğe girer ve gerekli sayıda yansıma oluşturulur.

Dezavantajı ise, büyük kuyruklarınız veya sıkı artıklık gereksinimleriniz varsa bu yaklaşımın işe yaramamasıdır.

Şimdi RabbitMQ kümelerinin ağ bölümleriyle nasıl çalıştığını görelim.

Bağlantı kaybı

Dağıtılmış bir sistemin düğümleri ağ bağlantılarıyla bağlanır ve ağ bağlantılarının bağlantısı kesilebilir ve kesilecektir. Kesintilerin sıklığı yerel altyapıya veya seçilen bulutun güvenilirliğine bağlıdır. Her durumda, dağıtılmış sistemlerin bunlarla başa çıkabilmesi gerekir. Bir kez daha kullanılabilirlik ve tutarlılık arasında bir seçim yapmamız gerekiyor ve yine iyi haber şu ki RabbitMQ her iki seçeneği de sunuyor (aynı anda değil).

RabbitMQ ile iki ana seçeneğimiz var:

• Mantıksal bölünmeye (bölünmüş beyin) izin verin. Bu kullanılabilirliği sağlar ancak veri kaybına neden olabilir.
• Mantıksal ayırmayı devre dışı bırakın. İstemcilerin kümeye nasıl bağlandığına bağlı olarak kısa süreli kullanılabilirlik kaybına neden olabilir. Ayrıca iki düğümlü bir kümede tamamen kullanılamamaya da yol açabilir.

Peki mantıksal ayırma nedir? Bu, ağ bağlantılarının kaybı nedeniyle bir kümenin ikiye bölünmesidir. Her iki tarafta da aynalar bir ustaya yükseltilir, böylece her turda sonunda birden fazla usta olur.

Pirinç. 17. Ana kuyruk ve her biri ayrı bir düğümde bulunan iki ayna. Daha sonra bir ağ arızası meydana gelir ve bir ayna ayrılır. Ayrılan düğüm diğer ikisinin düştüğünü görür ve aynalarını ustaya tanıtır. Artık hem yazılabilir hem de okunabilir iki ana kuyruğumuz var.

Yayıncıların her iki ana bilgisayara da veri göndermesi durumunda kuyruğun iki farklı kopyası elde edilir.

RabbitMQ'nun farklı modları kullanılabilirlik veya tutarlılık sağlar.

Yoksayma modu (varsayılan)

Bu mod erişilebilirliği sağlar. Bağlantı kaybının ardından mantıksal bir ayrım meydana gelir. Bağlantı yeniden sağlandıktan sonra yöneticinin hangi bölüme öncelik vereceğine karar vermesi gerekir. Kaybeden taraf yeniden başlatılacak ve o tarafta biriken tüm veriler kaybolacaktır.

Pirinç. 18. Üç yayıncı, üç komisyoncuyla ilişkilidir. Dahili olarak küme, tüm istekleri Aracı 2'deki ana kuyruğa yönlendirir.

Şimdi Broker 3'ü kaybediyoruz. Diğer brokerlerin düştüğünü görüyor ve ustaya aynasını tanıtıyor. Mantıksal bir ayrım bu şekilde gerçekleşir.

Pirinç. 19. Mantıksal bölünme (bölünmüş beyin). Kayıtlar iki ana sıraya ayrılır ve iki kopya birbirinden ayrılır.

Bağlantı yeniden sağlandı ancak mantıksal ayrım devam ediyor. Yöneticinin kaybeden tarafı manuel olarak seçmesi gerekir. Aşağıdaki durumda yönetici Broker 3'ü yeniden başlatır. İletmeyi başaramadığı tüm mesajlar kaybolur.

Pirinç. 20. Yönetici Broker 3'ü devre dışı bırakır.

Pirinç. 21. Yönetici Broker 3'ü başlatır ve kümeye katılarak orada kalan tüm mesajları kaybeder.

Bağlantı kaybı sırasında ve geri yükleme sonrasında küme ve bu kuyruk okuma ve yazma için mevcuttu.

Otomatik iyileştirme modu

Bağlantıyı bölüp geri yükledikten sonra kümenin kendisinin otomatik olarak kaybeden tarafı seçmesi dışında Yoksay moduna benzer şekilde çalışır. Kaybeden taraf kümeye boş olarak döner ve sıra yalnızca o tarafa gönderilen tüm mesajları kaybeder.

Azınlık Modunu Duraklat

Mantıksal bölümlemeye izin vermek istemiyorsak tek seçeneğimiz, küme bölümünden sonra daha küçük olan taraftaki okuma ve yazma işlemlerini atmaktır. Broker daha küçük tarafta olduğunu gördüğünde işi askıya alır, yani mevcut tüm bağlantıları kapatır ve yenilerini reddeder. Saniyede bir kez bağlantının yeniden sağlanıp sağlanmadığını kontrol eder. Bağlantı yeniden sağlandığında çalışmaya devam eder ve kümeye katılır.

Pirinç. 22. Üç yayıncı, üç komisyoncuyla ilişkilidir. Dahili olarak küme, tüm istekleri Aracı 2'deki ana kuyruğa yönlendirir.

Broker 1 ve 2 daha sonra Broker 3'ten ayrılır. Broker 3, aynalarını master'a yükseltmek yerine askıya alır ve kullanılamaz duruma gelir.

Pirinç. 23. Broker 3 tüm istemcileri duraklatır, bağlantısını keser ve bağlantı isteklerini reddeder.

Bağlantı yeniden kurulduğunda kümeye geri döner.

Ana kuyruğun Broker 3'te olduğu başka bir örneğe bakalım.

Pirinç. 24. Broker 3'teki ana kuyruk.

Daha sonra aynı bağlantı kaybı meydana gelir. Broker 3 daha küçük tarafta olduğu için duraklıyor. Diğer tarafta, düğümler Broker 3'ün düştüğünü görür, dolayısıyla Broker 1 ve 2'nin eski aynası master konumuna yükseltilir.

Pirinç. 25. Broker 2 mevcut değilse Broker 3'ye geçiş.

Bağlantı yeniden sağlandığında Broker 3 kümeye katılacaktır.

Pirinç. 26. Küme normal çalışmaya geri döndü.

Burada anlamamız gereken önemli şey tutarlılık elde ettiğimizdir ancak aynı zamanda kullanılabilirlik de elde edebiliriz. eğer Müşterileri bölümün çoğuna başarıyla aktaracağız. Çoğu durumda, şahsen Azınlığı Duraklat modunu seçerdim, ancak bu gerçekten bireysel duruma bağlıdır.

Kullanılabilirliği sağlamak için istemcilerin ana bilgisayara başarıyla bağlandığından emin olmak önemlidir. Seçeneklerimize bakalım.

Müşteri Bağlantısının Sağlanması

Bağlantı kaybından sonra istemcileri kümenin ana kısmına veya çalışan düğümlere (bir düğüm arızalandıktan sonra) nasıl yönlendireceğimize ilişkin çeşitli seçeneklerimiz vardır. Öncelikle, belirli bir kuyruğun belirli bir düğümde barındırıldığını ancak yönlendirme ve politikaların tüm düğümlerde çoğaltıldığını hatırlayalım. İstemciler herhangi bir düğüme bağlanabilir ve dahili yönlendirme onları gitmeleri gereken yere yönlendirir. Ancak bir düğüm askıya alındığında bağlantıları reddeder, dolayısıyla istemcilerin başka bir düğüme bağlanması gerekir. Düğüm düşerse yapabileceği çok az şey var.

Seçeneklerimiz:

• Kümeye, düğümler arasında geçiş yapan bir yük dengeleyici kullanılarak erişilir ve istemciler, başarılı olana kadar yeniden bağlanmayı dener. Bir düğüm kapalı veya askıya alınmışsa, o düğüme bağlanma girişimleri başarısız olur, ancak sonraki girişimler diğer sunuculara (döngüsel bir şekilde) gider. Bu, kısa süreli bağlantı kaybı veya hızlı bir şekilde yeniden çalıştırılacak olan kapalı bir sunucu için uygundur.
• Kümeye bir yük dengeleyici aracılığıyla erişin ve askıya alınan/başarısız düğümleri tespit edilir edilmez listeden kaldırın. Bunu hızlı bir şekilde yaparsak ve istemciler bağlantıyı yeniden deneyebilirse sürekli kullanılabilirlik elde edebiliriz.
• Her müşteriye tüm düğümlerin bir listesini verin ve istemci bağlanırken bunlardan birini rastgele seçer. Bağlanmaya çalışırken hata alırsa bağlanana kadar listedeki bir sonraki düğüme geçer.
• Arızalı/askıya alınmış bir düğümden gelen trafiği DNS kullanarak kaldırın. Bu küçük bir TTL kullanılarak yapılır.

Bulgular

RabbitMQ kümelemenin avantajları ve dezavantajları vardır. En ciddi dezavantajları şunlardır:

• bir kümeye katılırken düğümler verilerini atar;
• senkronizasyonun engellenmesi kuyruğun kullanılamaz hale gelmesine neden olur.

Tüm zor kararlar bu iki mimari özellikten kaynaklanmaktadır. RabbitMQ kümeye yeniden katıldığında verileri kaydedebilseydi senkronizasyon daha hızlı olurdu. Engellemeyen senkronizasyon yeteneğine sahip olsaydı, büyük kuyrukları daha iyi desteklerdi. Bu iki sorunun düzeltilmesi, RabbitMQ'nun hataya dayanıklı ve yüksek oranda kullanılabilir bir mesajlaşma teknolojisi olarak performansını büyük ölçüde artıracaktır. Aşağıdaki durumlarda RabbitMQ'yu kümeleme ile tavsiye etmekte tereddüt ederim:

• Güvenilmez ağ.
• Güvenilmez depolama.
• Çok uzun kuyruklar.

Yüksek kullanılabilirlik ayarları söz konusu olduğunda aşağıdakileri göz önünde bulundurun:

• ha-promote-on-failure=always
• ha-sync-mode=manual
• cluster_partition_handling=ignore (ya autoheal)
• kalıcı mesajlar
• Bazı düğümler başarısız olduğunda istemcilerin etkin düğüme bağlandığından emin olun

Tutarlılık (veri güvenliği) için aşağıdaki ayarları göz önünde bulundurun:

• Tüketici tarafında Yayıncı Onayları ve Manuel Teşekkür
• ha-promote-on-failure=when-synced, eğer yayıncılar daha sonra tekrar deneyebilirse ve çok güvenilir bir depolama alanınız varsa! Aksi takdirde koymak =always.
• ha-sync-mode=automatic (ancak büyük etkin olmayan kuyruklar için manuel mod gerekli olabilir; ayrıca kullanılabilir olmamanın mesajların kaybolmasına neden olup olmayacağını da göz önünde bulundurun)
• Azınlık modunu duraklat
• kalıcı mesajlar

Henüz hata toleransı ve yüksek kullanılabilirlik konularının tamamını ele almadık; örneğin idari prosedürlerin güvenli bir şekilde nasıl gerçekleştirileceği (güncellemelerin devam etmesi gibi). Ayrıca federasyon ve Shovel eklentisinden de bahsetmemiz gerekiyor.

Başka bir şeyi kaçırırsam lütfen bana bildirin.

Ayrıca bakınız postalamakBu makalede açıklanan mesaj kaybı senaryolarından bazılarını test etmek için Docker ve Blockade'i kullanarak RabbitMQ kümesinde hasara yol açıyorum.

Serideki önceki makaleler:
1 - habr.com/ru/company/itsumma/blog/416629
2 - habr.com/ru/company/itsumma/blog/418389
3 - habr.com/ru/company/itsumma/blog/437446

Kaynak: habr.com