Zookeeper nedir?
Zhang Dapang'ın çalıştığı şirket son birkaç yılda oldukça iyi gelişti. İş hızla arttı ve personel de hızla genişledi. Bir anda Zhang Dapang şirketin "kıdemli" bir çalışanı oldu. Daha da önemlisi, bu yıl aralıksız çabaların ardından, o Sonunda mimarın tahtına oturdu.
Ancak Big Fat, bu mimarın gerçekten iyi bir iş olmadığını çabucak keşfetti.Teknik seçim ve mimari tasarım, özellikle herkesin başa çıkamayacağı teknik zorluklar, er ya da geç kendi başınıza halledilmek zorunda kalacak. İletişim, ikna, uzlaşma ve hatta kavgalar sıradan şeylerdir, sadece geliştirme yaptığım zamandan çok daha zordur.
Şirketin BT sistemi zaten tek bir makineden dağıtılmış bir sisteme geçti ve dağıtılmış sistem büyük zorluklar getirdi. Bu Pazartesi işe gider gitmez, Dapang Zhang'ın posta kutusu acil durum postasıyla doluydu.
Burada büyük veriyi öğrenmek isteyen birçok öğrenci olduğuna inanıyorum.Büyük veri öğrenme eteğini indirebilirsin: 740041381, ücretsiz olarak bir dizi sistem büyük veri öğrenme eğitimleri alabilirsiniz.
1
Xiaoliang'ın Postası
Xiaoliangın e-postasında bir RPC araması sorunundan bahsedildi. Başlangıçta, şirketin mimari ekibi çeşitli grupların kullanması için bir RPC çerçevesi geliştirdi, ancak geliştirme ekipleri bu RPC çerçevesinin dinamik hizmet kaydı ve keşfini desteklemediğinden şikayet etti.
Zhang Dapang, bu resme bakarak neler olup bittiğini anlayabilir.Yüksek eşzamanlılığı desteklemek için OrderService 4 kopya dağıttı ve her müşteri bir servis sağlayıcı listesi kaydetti, ancak bu liste statiktir (yapılandırma dosyasında Servis sağlayıcı değişirse, örneğin, bazı makineler çalışmazsa veya yeni OrderService örnekleri eklenirse, istemci hiç bilmiyor ve yine de aptalca bozulmuş örnekleri deneyebilir!
Servis sağlayıcıların en son URL listesini almak için, gerçekten rahatsız edici olan yapılandırma dosyasını manuel olarak güncellemeniz gerekir.
Böyle bir sorun için Big Fat, bunun müşteri ile servis sağlayıcı arasındaki sıkı bağ olduğunu hemen fark etti.
Bu kaplini serbest bırakmak için bir ara katman eklemelisiniz!
Zhang Dapang, bir kayıt olması gerektiğini düşündü. İlk olarak, bu hizmetleri adlandırın (orderService gibi). Ardından, tüm OrderServices buradan kaydedilebilir. Müşteriler burada sorgulama yapabilir. Sadece orderService adını verin ve kayıt defteri verebilir Kullanılabilir bir URL ile artık servis sağlayıcıların dinamik artışından veya azalmasından korkmuyorsunuz.
Bilinçaltı bir davranış olup olmadığını bilmiyorum, Zhang Dafang bu kayıt defterinin veri yapısını bir ağaç yapısında tasarladı:
/ orderService bir hizmet kavramını ifade eder ve aşağıdaki her düğüm bir hizmetin bir örneğini temsil eder. Örneğin, / orderService / node2 ile temsil edilen sipariş hizmetinin ikinci örneği, örneğin url'si sorgulanabilmesi için her düğümde kaydedilebilir.
Tabii ki, bu kayıt defteri her hizmet örneğiyle iletişim kurabilmelidir.Eğer bir hizmet örneği maalesef çalışmıyorsa, istemcinin sorgulayamaması için ağaç yapısındaki düğümü de silinmelidir.
Eh, kayıt defterinde ve her hizmet örneğinde doğrudan bir oturum oluşturabilir ve her hizmet örneğinin periyodik olarak sinyal göndermesine izin verebilirsiniz.Eğer belirli bir süre sonra sinyal alınmazsa, servis örneğinin çalışmadığı kabul edilir ve oturumun süresi dolar ve ağaçtan kaldırılır. Yapıdan silindi.
Zhang Dapang, Xiao Liang'a düşünceleriyle cevap verdi ve ardından Xiao Wang'ın e-postasını okudu.
2
Xiao Wang'ın Usta Seçimi
Xiao Wangın e-postasının söylediği şey, üç Toplu İşin koordinasyonuydu. Bu üç Toplu İş, üç makinede konuşlandırıldı, ancak bu üç Toplu İşten yalnızca biri aynı anda çalışabilir. Bunlardan biri maalesef çalışmıyorsa, Kalan ikisinin seçilmesi ve seçilen toplu işin "mirası devralması" ve çalışmaya devam etmesi gerekir.
Aslında, bu bir Master seçim meselesidir ve Zhang Dafang, özünü bir bakışta görebilir.
Sadece bir Master seçmek için, bu üç toplu işin birbiriyle iletişim kurması ve birbiriyle koordine olması gerekir ki bu zahmetlidir!
Veritabanı tablosu almaya ne dersiniz? Veritabanı tablosunun birincil anahtarının çakışamayacağı özelliğinden yararlanın, bu üç toplu işin aynı verileri aynı tabloya eklemesine izin verin, ilk önce kim başarılı olursa Ana'dır!
Ama Efendiyi yakalayan Toplu İş ölürse, diğerleri onu asla yakalayamaz! Kayıt zaten mevcut olduğundan, diğer toplu işler veri ekleyemez!
Pekala, düzenli bir güncelleme mekanizması eklemelisiniz.Bir süre için güncelleme olmazsa, Master ölü kabul edilir ve diğer toplu işler yakalanmaya devam edebilir ... Ama bu zahmetlidir!
Başka bir şekilde, onlar da bir kayıt merkezine gidip bağırsınlar: "Ben efendiyim!" Sesi daha yüksek olan, Efendi'dir.
Aslında bu bir kükreme değildir. Üç Toplu İş başlatıldıktan sonra, hepsi bir ağaç düğümü (örneğin, / ana) oluşturmak için görüşmek üzere kayıt defterine gider. Onu başarıyla oluşturan kişi Ana'dır (Elbette, kayıt defteri yalnızca bir kez oluşturulabilmesini sağlamalıdır, diğer İstek başarısız olur) ve diğer iki Toplu İş bu düğümü hevesle izler.Bu düğüm silinirse, / ana düğümü oluşturmak için yeni bir yarışma turu başlayacaktır.
Düğüm ne zaman silinecek? Evet, şu anki Üstadın makinesi çalışmıyor! Açıkçası, kayıt defterinin canlı olup olmadıklarını görmek için her makineyle iletişim kurması gerekir.
Bekleyin, burada karmaşık bir durum var.Makine 1 ölmezse, ancak kayıt defterine uzun süre bağlanamazsa, kayıt defteri Oturumun zaman aşımına uğradığını görür ve makine 1 tarafından oluşturulan / master'ı siler. Makine 2 ve makine 3 onu kapsın Makine 3 ana iş olursa, toplu işi çalıştırmaya başlar, ancak makine 1 ana işten çıkarıldığını bilmez ve hala toplu işi çalıştırmak için çok çalışmaktadır, bu bir çelişkidir!
Görünüşe göre makine 1, kayıt merkezi ile bağlantının kesildiğini ve Toplu İşin durdurulması gerektiğini hissedebilmelidir.Kayıt merkezine tekrar bağlandıktan sonra artık usta olmadığını bilir. Dürüst olmak gerekirse bir sonraki fırsatı bekleyin. .
Hangi plan olursa olsun, uygulanması çok zahmetli, bu lanet dağıtıldı!
Burada büyük veriyi öğrenmek isteyen birçok öğrenci olduğuna inanıyorum.Büyük veri öğrenme eteğini indirebilirsin: 740041381, ücretsiz olarak bir dizi sistem büyük veri öğrenme eğitimleri alabilirsiniz.
Lütfen önce Xiao Wang'a cevap verin. Ardından Xiao Cai'nin e-postasına bakın.
3
Xiao Cai'nin dağıtılmış kilidi
Xiao Cainin e-postasında bahsedilen sorun daha da zahmetli. Birden fazla farklı sistem var (elbette farklı makinelere dağıtılmış!) Ve aynı kaynak üzerinde çalışmaları gerekiyor.
Bu, Java'nın senkronize edilmiş hali gibi belirli bir dilin yerleşik kilidi kullanılarak bir makinede yapılırsa, ancak şimdi dağıtılırsa, programların tümü farklı makinelerde farklı işlemlerde çalışır, senkronizasyon hiç işe yaramaz!
Bu, dağıtılmış bir kilit sorunudur!
Usta seçim sorusunun yolunu düşünebilir ve herkesin onu yakalamasına izin verebilir misiniz? Kayıt defterinde / distribute_lock düğümünü kim oluşturabilir, ilk önce kilidi yakaladığınız, ardından kaynakları okuyup yazdığınız ve okuduktan ve yazdıktan sonra / distribute_lock düğümünü sildiğiniz ve herkes onu tekrar yakalayacağı anlamına gelir.
Ancak bu durumda, belirli bir sistem onu birçok kez yakalayabilir ki bu adil değildir.
Bu sistemlerin kayıt defterinde / distribute_lock altında alt düğümler oluşturmasına izin verirseniz ve ardından her sisteme bir numara verirseniz, aşağıdaki gibi görünecektir:
Sonra her sistem kendi numarasını kontrol eder ve sayısı az olan kişi, sistem 1 gibi kilidi kimin tuttuğunu düşünür.
Sistem 1 kilidi tutar ve paylaşılan kaynaklar üzerinde çalışabilir. İşlem tamamlandıktan sonra, işlem_01 düğümü silinir ve yeni bir düğüm oluşturulur (sayı işlem_04 olur):
Diğer sistemlere baktığımızda, 01 sayısı silindi, bakalım en küçüğü kim, süreç_02. Sonra sistem 2 kilidi tutuyor ve paylaşılan kaynaklar üzerinde çalışabilir. İşlem tamamlandıktan sonra işlem_02 düğümünü silin ve yeni bir düğüm oluşturun. Şu anda process_03 en küçüğüdür ve kilidi tutabilir.
Bu döngü devam ediyor ... Dağıtılmış kilitler gerçekleştirilebilir!
Bakın tasarladığım merkezi ağaç yapısı çok iyi, her türlü sorunu çözebilir! Zhang Dapang gurur duymaktan kendini alamadı.
Tamam, önce Xiao Cai'ye bu fikri anlatayım ve öğleden sonra uygulama ayrıntılarını tartışayım.
4
Hayvan bakıcısı
Xiao Cai'ye cevap vermek üzereyken, Da Pang aniden önemli bir noktayı gözden kaçırdığını fark etti ve bu kayıt defterinin yüksek erişilebilirliğiydi.Kayıtta sadece bir makine olsaydı, kapatıldığında tüm sistem biterdi.
Bu kayıt defterinin aynı zamanda yüksek kullanılabilirliği sağlamak için birden fazla makineye sahip olması gerekiyor Gurur duyduğum ağaç yapısının da birden çok makine arasında senkronize edilmesi gerekiyor.Ya bir makine kapatırsa? İletişim zaman aşımına uğrarsa ne yapmalıyım? Ağaç yapılı veriler, makineler arasında güçlü tutarlılığı nasıl sağlar?
Xiao Wang, Xiao Liang ve Xiao Cai'nin orijinal sorunları çözülmedi ve kayıt merkezi tek başına ölecek. Kendi şirketinin teknik gücü ile böyle bir kayıt merkezi oluşturmak, sadece Misyon İmkansızdır!
Da Fatty, benzer bir çözüm olup olmadığını görmek için İnternette hızlı bir şekilde arama yaptı. Neyse ki Da Fatty için, Zookeeper adında bir tane var!
Zookeeper'ın kullandığı ağaç yapısı hayal ettiğime çok benziyor.Daha da önemlisi, insanlar ağaç yapısı verilerinin birden çok makine arasında güvenilir şekilde çoğaltıldığını fark ettiler ve birden çok makine arasında veri tutarlılığı sağladılar. Ve bu birden fazla makineden bazıları çalışmıyorsa / ağ nedeniyle bağlanamıyorsa, tüm sistem yine de çalışabilir.
Zookeeper'ın temel kavramlarını ve API'sini görmek için acele edin:
1. Oturum: Bir istemci sistemi (Toplu İş gibi) ve ZooKeeper arasındaki bir bağlantı oturumunu gösterir. Toplu İş, ZooKeeper'a bağlandıktan sonra, periyodik olarak sinyal bilgisi gönderir. ZooKeepr, belirli bir süre içinde bir kalp atışı almazsa, bunu dikkate alır Toplu İş öldü ve Oturum sona erecek.
2. znode: Ağaç yapısındaki her düğüme znode adı verilir. Türüne göre kalıcı znode (aktif olarak silinmediği sürece her zaman var olacaktır), geçici znode (oturumun sonunda silinecektir) ve sıralı znode (Xiaocai) olarak ikiye ayrılabilir. İşlem_01, işlem_02 ...) dağıtılmış kilit içinde.
3. İzleyin: Bir istemci sistemi (Toplu İş gibi) znode'u izleyebilir ve znode değişiklikleri (silme, verileri değiştirme vb.) Toplu İşi bildirebilir, böylece Toplu İş, düğümler oluşturmak için acele etme gibi ilgili eylemleri gerçekleştirebilir .
Peki, bu kavramlar ve arayüzler gereksinimlerimizi karşılayabilmelidir, işte bu kadar.Öğleden sonra bir toplantı yapalım ve Zookeeper öğrenmeye başlayalım.
Postscript: Bu makale Zookeeper'ın kullanıcı açısından ne kadar yararlı olduğunu açıklamaktadır.İçeriden nasıl çalıştığına gelince, bu başka bir Büyük konu, daha sonra konuşacağız.
