"Hadoop'ta büyük hacimli verilerin dağıtılmış işlenmesi için yöntemler" serisinden "Hadoop. ZooKeeper" dersinin transkriptini okumanızı öneririm.
ZooKeeper nedir, Hadoop ekosistemindeki yeri. Dağıtılmış hesaplamayla ilgili yalanlar. Standart dağıtılmış sistemin şeması. Dağıtık sistemleri koordine etmede zorluk. Tipik koordinasyon sorunları. ZooKeeper'ın tasarımının ardındaki ilkeler. ZooKeeper veri modeli. znode bayrakları. Oturumlar. İstemci API'si. İlkeller (yapılandırma, grup üyeliği, basit kilitler, lider seçimi, sürü etkisi olmadan kilitleme). ZooKeeper mimarisi. ZooKeeper DB. ZAB. İstek işleyicisi.
Bugün ZooKeeper'dan bahsedeceğiz. Bu şey çok faydalı. Tüm Apache Hadoop ürünleri gibi onun da bir logosu vardır. Bir adamı tasvir ediyor.
Bundan önce esas olarak verinin orada nasıl işlenebileceğinden, nasıl saklanacağından yani bir şekilde nasıl kullanılacağından ve onunla bir şekilde nasıl çalışılacağından bahsetmiştik. Bugün biraz dağıtılmış uygulamalar oluşturmaktan bahsetmek istiyorum. Ve ZooKeeper bu konuyu basitleştirmenize olanak tanıyan şeylerden biridir. Bu, dağıtılmış uygulamalarda, dağıtılmış sistemlerdeki süreçlerin etkileşiminin bir tür koordinasyonuna yönelik bir hizmet türüdür.
Bu tür uygulamalara olan ihtiyaç her geçen gün artıyor, bizim kursumuzun konusu da bu. Bir yandan MapReduce ve bu hazır çerçeve, bu karmaşıklığı ortadan kaldırmanıza ve programcıyı süreçlerin etkileşimi ve koordinasyonu gibi ilkelleri yazmaktan kurtarmanıza olanak tanır. Ancak öte yandan, bunun zaten yapılmasına gerek kalmayacağını da kimse garanti etmiyor. MapReduce veya diğer hazır çerçeveler, bunun kullanılarak uygulanamayan bazı durumların yerine her zaman tamamen geçmez. MapReduce'un kendisi ve diğer birçok Apache projesi de dahil olmak üzere aslında bunlar aynı zamanda dağıtılmış uygulamalardır. Ve yazmayı kolaylaştırmak için ZooKeeper'ı yazdılar.
Hadoop ile ilgili tüm uygulamalar gibi, Yahoo! Artık aynı zamanda resmi bir Apache uygulamasıdır. HBase kadar aktif olarak geliştirilmemiştir. JIRA HBase'e giderseniz, her gün bir sürü hata raporu vardır, bir şeyi optimize etmek için bir sürü teklif vardır, yani. projedeki hayat sürekli devam ediyor. Ve ZooKeeper bir yandan nispeten basit bir ürün, diğer yandan bu onun güvenilirliğini sağlıyor. Kullanımı da oldukça kolaydır, bu nedenle Hadoop ekosistemindeki uygulamalarda standart haline gelmiştir. Bu yüzden nasıl çalıştığını ve nasıl kullanılacağını anlamak için incelemenin faydalı olacağını düşündüm.
Bu, yaptığımız bir dersten bir resim. Şu ana kadar ele aldığımız her şeye dik olduğunu söyleyebiliriz. Ve burada belirtilen her şey, bir dereceye kadar ZooKeeper ile çalışır, yani tüm bu ürünleri kullanan bir hizmettir. Ne HDFS ne de MapReduce, özellikle kendileri için çalışacak benzer hizmetleri yazmamaktadır. Buna göre ZooKeeper kullanılmaktadır. Bu da geliştirmeyi ve hatalarla ilgili bazı şeyleri basitleştirir.
Bütün bunlar nereden geliyor? Görünüşe göre iki uygulamayı farklı bilgisayarlarda paralel olarak başlattık, bunları bir ip veya ağ ile bağladık ve her şey çalışıyor. Ancak sorun şu ki, Ağ güvenilmezdir ve trafiği koklarsanız veya orada olup bitenlere düşük düzeyde bakarsanız, istemcilerin Ağ üzerinde nasıl etkileşime girdiğine bakarsanız, bazı paketlerin kaybolduğunu veya yeniden gönderildiğini sıklıkla görebilirsiniz. Belirli bir oturum oluşturmanıza ve mesajların teslimini garanti etmenize olanak tanıyan TCP protokollerinin icat edilmesi boşuna değildir. Ancak her durumda TCP bile sizi her zaman kurtaramaz. Her şeyin bir zaman aşımı vardır. Ağ bir süreliğine düşebilir. Sadece yanıp sönebilir. Ve bunların hepsi Ağın güvenilir olduğuna güvenemeyeceğiniz gerçeğine yol açıyor. Bu, Ağın olmadığı, bellekte daha güvenilir bir veri değişim veri yolunun bulunduğu bir bilgisayarda veya bir süper bilgisayarda çalışan paralel uygulamalar yazmaktan temel farktır. Ve bu temel bir farktır.
Diğer şeylerin yanı sıra, Ağı kullanırken her zaman belirli bir gecikme vardır. Diskte de var, ancak Ağda daha fazlası var. Gecikme, küçük veya oldukça önemli olabilen bir gecikme süresidir.
Ağ topolojisi değişiyor. Topoloji nedir - bu, ağ ekipmanımızın yerleşimidir. Veri merkezleri var, orada duran raflar var, mumlar var. Bütün bunlar yeniden bağlanabilir, taşınabilir vb. Tüm bunların da dikkate alınması gerekir. IP adları değişir, trafiğimizin geçtiği yönlendirme değişir. Bunun da dikkate alınması gerekir.
Ağ, ekipman açısından da değişebilir. Uygulamadan, ağ mühendislerimizin mumlarla ilgili bir şeyi periyodik olarak güncellemeyi gerçekten sevdiklerini söyleyebilirim. Aniden yeni bir aygıt yazılımı çıktı ve bazı Hadoop kümeleriyle pek ilgilenmediler. Kendi işleri var. Onlar için asıl önemli olan Ağın çalışmasıdır. Buna göre oraya tekrar bir şeyler yüklemek istiyorlar, donanımlarına flashlama yapıyorlar, donanım da periyodik olarak değişiyor. Bütün bunların bir şekilde dikkate alınması gerekiyor. Bütün bunlar dağıtılmış uygulamamızı etkiliyor.
Genellikle bir nedenden dolayı büyük miktarda veriyle çalışmaya başlayan insanlar İnternet'in sınırsız olduğuna inanırlar. Orada birkaç terabaytlık bir dosya varsa, onu sunucunuza veya bilgisayarınıza götürebilir ve kullanarak açabilirsiniz. kedi ve izle. Başka bir hata da Gayret günlüklere bakın. Bunu asla yapmayın çünkü kötü. Çünkü Vim her şeyi arabelleğe almaya, her şeyi belleğe yüklemeye çalışır, özellikle de bu günlüğün içinde hareket etmeye ve bir şey aramaya başladığımızda. Bunlar unutulan ama dikkate alınması gereken şeyler.
Bir bilgisayarda çalışan bir programı tek işlemciyle yazmak daha kolaydır.
Sistemimiz büyüdüğünde hepsini paralelleştirmek istiyoruz, sadece bilgisayarda değil, bir kümede de paralelleştirmek istiyoruz. Şu soru ortaya çıkıyor: Bu konu nasıl koordine edilecek? Uygulamalarımız birbirleriyle etkileşime bile girmeyebilir, ancak birçok işlemi birkaç sunucuda paralel olarak çalıştırdık. Peki onlar için her şeyin yolunda gittiğini nasıl izleyebiliriz? Mesela internet üzerinden bir şeyler gönderiyorlar. Durumları hakkında bir yere, örneğin bir tür veritabanına veya kayıt defterine yazmaları, ardından bu günlüğü toplamaları ve ardından bir yerde analiz etmeleri gerekir. Artı, sürecin çalıştığını ve çalıştığını, aniden bir hatanın ortaya çıktığını veya çöktüğünü hesaba katmamız gerekiyor, o zaman bunu ne kadar çabuk öğreneceğiz?
Tüm bunların hızlı bir şekilde izlenebileceği açıktır. Bu da güzel ama izleme bazı şeyleri en üst düzeyde izlemenize olanak tanıyan sınırlı bir şey.
Süreçlerimizin birbirleriyle etkileşime girmesini istediğimizde, örneğin birbirimize veri göndermeyi istediğimizde şu soru da ortaya çıkıyor: Bu nasıl olacak? Bir tür yarış durumu olacak mı, birbirlerinin üzerine mi yazacaklar, veriler doğru şekilde ulaşacak mı, yol boyunca herhangi bir şey kaybolacak mı? Bir tür protokol vb. geliştirmemiz gerekiyor.
Tüm bu süreçlerin koordinasyonu önemsiz bir şey değil. Ve geliştiriciyi daha da düşük bir seviyeye inmeye ve sistemleri ya sıfırdan ya da sıfırdan yazmaya zorluyor, ancak bu o kadar basit değil.
Bir şifreleme algoritması bulursanız veya hatta uygularsanız, onu hemen atın çünkü büyük olasılıkla işinize yaramayacaktır. Büyük olasılıkla sağlamayı unuttuğunuz bir sürü hata içerecektir. Asla ciddi bir şey için kullanmayın çünkü büyük olasılıkla dengesiz olacaktır. Çünkü var olan tüm algoritmalar çok uzun zamandır zamanla test ediliyor. Toplum tarafından rahatsız ediliyor. Bu ayrı bir konudur. Ve burada da durum aynı. Bir tür süreç senkronizasyonunu kendiniz uygulamamak mümkünse, bunu yapmamak daha iyidir, çünkü bu oldukça karmaşıktır ve sizi sürekli hata aramanın titrek yoluna sürükler.
Bugün ZooKeeper'dan bahsediyoruz. Bir yandan çerçeve, diğer yandan geliştiricinin hayatını kolaylaştıran, mantığın uygulanmasını ve süreçlerimizin koordinasyonunu mümkün olduğunca basitleştiren bir hizmettir.
Standart bir dağıtılmış sistemin neye benzeyebileceğini hatırlayalım. Bahsettiğimiz şey buydu: HDFS, HBase. Çalışanları ve köle süreçlerini yöneten bir Master süreci vardır. Görevlerin koordine edilmesi ve dağıtılmasından, çalışanların yeniden başlatılmasından, yenilerinin başlatılmasından ve yükün dağıtılmasından sorumludur.
Daha gelişmiş bir şey Koordinasyon Hizmetidir, yani koordinasyon görevinin kendisini ayrı bir sürece taşımak, ayrıca bir tür yedek veya yedek Master'ı paralel olarak çalıştırmak, çünkü Master başarısız olabilir. Ve eğer Efendi düşerse sistemimiz çalışmayacaktır. Yedekleme yapıyoruz. Bazıları, Master'ın yedekleme için kopyalanması gerektiğini belirtir. Bu aynı zamanda Koordinasyon Servisine de emanet edilebilir. Ancak bu şemada, işçilerin koordinasyonundan Usta'nın kendisi sorumludur; burada hizmet, veri çoğaltma faaliyetlerini koordine etmektedir.
Daha gelişmiş bir seçenek, genellikle yapıldığı gibi tüm koordinasyonun hizmetimiz tarafından gerçekleştirilmesidir. Her şeyin yolunda gitmesini sağlama sorumluluğunu üstlenir. Ve eğer bir şeyler yolunda gitmezse, bunu öğrenip bu durumu aşmaya çalışırız. Her durumda, kölelerle bir şekilde etkileşime giren ve bazı hizmetler aracılığıyla veri, bilgi, mesaj vb. gönderebilen bir Efendiyle karşı karşıyayız.
Daha da gelişmiş bir şema var, bir Efendimiz olmadığında, tüm düğümler davranışları farklı olan usta kölelerdir. Ancak yine de birbirleriyle etkileşime girmeleri gerekiyor, dolayısıyla bu eylemleri koordine edecek hâlâ bir miktar hizmet kaldı. Muhtemelen bu prensiple çalışan Cassandra bu şemaya uyuyor.
Bu programlardan hangisinin daha iyi çalıştığını söylemek zor. Her birinin kendine göre artıları ve eksileri vardır.
Ve Üstadın bazı şeylerden korkmasına gerek yok, çünkü uygulamanın gösterdiği gibi, sürekli hizmet etmeye o kadar duyarlı değil. Burada önemli olan, bu hizmeti ayrı bir güçlü düğümde barındırmak için doğru çözümü seçmektir, böylece yeterli kaynağa sahip olur, böylece mümkünse kullanıcıların oraya erişimi olmaz, böylece yanlışlıkla bu süreci sonlandırmazlar. Ancak aynı zamanda böyle bir şemada çalışanları Master sürecinden yönetmek çok daha kolaydır, yani. bu şema uygulama açısından daha basittir.
Ve bu şema (yukarıda) muhtemelen daha karmaşık ama daha güvenilirdir.
Asıl sorun kısmi başarısızlıklardır. Örneğin Network üzerinden mesaj gönderdiğimizde bir tür kaza meydana gelir ve mesajı gönderen, mesajının alınıp alınmadığını, alıcı tarafında ne olduğunu bilemez, mesajın doğru işlenip işlenmediğini bilemez. yani herhangi bir onay almayacak.
Buna göre bu durumu işlememiz gerekiyor. Ve en basit şey bu mesajı tekrar göndermek ve bir yanıt alana kadar beklemektir. Bu durumda alıcının durumunun değişip değişmediği dikkate alınmaz. Bir mesaj gönderebilir ve aynı verileri iki kez ekleyebiliriz.
ZooKeeper bu tür retlerle başa çıkmanın yollarını sunuyor ve bu da hayatımızı kolaylaştırıyor.
Biraz önce de belirttiğimiz gibi bu, çok iş parçacıklı programlar yazmaya benzer, ancak temel fark, farklı makineler üzerine kurduğumuz dağıtılmış uygulamalarda iletişim kurmanın tek yolunun Ağ olmasıdır. Aslında bu, hiçbir şeyin paylaşılmadığı bir mimaridir. Bir makinede çalışan her işlem veya hizmetin kendi belleği, kendi diski, kendi işlemcisi vardır ve bunları kimseyle paylaşmaz.
Bir bilgisayara çok iş parçacıklı bir program yazarsak, veri alışverişi için paylaşılan belleği kullanabiliriz. Orada bir bağlam anahtarımız var, işlemler değişebilir. Bu performansı etkiler. Bir yandan kümedeki programda böyle bir şey yok ama Ağ ile ilgili sorunlar var.
Buna göre dağıtık sistemleri yazarken ortaya çıkan temel problemler konfigürasyondur. Bir çeşit uygulama yazıyoruz. Basitse, koddaki her türlü sayıyı sabit kodluyoruz, ancak bu sakıncalıdır, çünkü yarım saniyelik bir zaman aşımı yerine bir saniyelik bir zaman aşımı istediğimize karar verirsek, o zaman uygulamayı yeniden derlememiz gerekir ve her şeyi yeniden yuvarlayın. Tek bir makinede olduğunda, onu yeniden başlatabildiğinizde bir şey var, ancak çok sayıda makinemiz olduğunda sürekli olarak her şeyi kopyalamak zorundayız. Uygulamayı yapılandırılabilir hale getirmeye çalışmalıyız.
Burada sistem süreçleri için statik konfigürasyondan bahsediyoruz. Bu tamamen değil, belki işletim sistemi açısından bakıldığında süreçlerimiz için statik bir konfigürasyon olabilir, yani bu basitçe alınıp güncellenemeyecek bir konfigürasyondur.
Ayrıca dinamik bir yapılandırma da vardır. Bunlar, orada yakalanmaları için anında değiştirmek istediğimiz parametrelerdir.
Buradaki sorun ne? Yapılandırmayı güncelledik, kullanıma sunduk, ne olmuş yani? Sorun şu ki, bir yandan yapılandırmayı kullanıma sunduk, ancak yeni şeyi unuttuk, yapılandırma orada kaldı. İkinci olarak, biz kullanıma sunarken bazı yerlerde yapılandırma güncellendi, bazılarında ise güncellenmedi. Ve uygulamamızın bir makinede çalışan bazı işlemleri yeni bir yapılandırmayla ve bir yerde eski bir yapılandırmayla yeniden başlatıldı. Bu, dağıtılmış uygulamamızın yapılandırma açısından tutarsız olmasına neden olabilir. Bu sorun yaygındır. Dinamik bir konfigürasyon için bu daha uygundur çünkü anında değiştirilebileceğini ima eder.
Diğer bir sorun ise grup üyeliğidir. Her zaman bir takım çalışanlarımız olur, her zaman hangisinin hayatta olduğunu, hangisinin öldüğünü bilmek isteriz. Eğer bir Master varsa, hangi çalışanların hesaplamaları yürütmeleri veya verilerle çalışmaları için istemcilere yönlendirilebileceğini ve hangilerinin yapamayacağını anlaması gerekir. Sürekli olarak ortaya çıkan bir sorun, kümemizde kimin çalıştığını bilmemiz gerektiğidir.
Bir başka tipik sorun da kimin sorumlu olduğunu bilmek istediğimiz lider seçimleridir. Bunun bir örneği, yazma işlemlerini alan ve daha sonra bunları diğer süreçler arasında çoğaltan bir işlemimiz olduğunda çoğaltmadır. Lider olacak, herkes ona itaat edecek, onu takip edecek. Herkes için net olacak, iki liderin seçildiği ortaya çıkmasın diye bir süreç seçmek gerekiyor.
Ayrıca karşılıklı olarak özel erişim de vardır. Buradaki sorun daha karmaşıktır. Çok iş parçacıklı programlar yazdığınızda ve örneğin bir bellek hücresi gibi bazı kaynaklara erişimin yalnızca bir iş parçacığı tarafından sınırlandırılıp yürütülmesini istediğinizde muteks diye bir şey vardır. Burada kaynak daha soyut bir şey olabilir. Ve Ağımızın farklı düğümlerindeki farklı uygulamalar, herkesin onu değiştirebilmesi veya oraya bir şeyler yazabilmesi için değil, yalnızca belirli bir kaynağa özel erişim sağlamalıdır. Bunlar sözde kilitlerdir.
ZooKeeper tüm bu sorunları bir dereceye kadar çözmenize olanak sağlar. Ve bunu yapmanıza nasıl izin verdiğini örneklerle göstereceğim.
Engelleyici ilkeller yoktur. Bir şeyi kullanmaya başladığımızda bu ilkel herhangi bir olayın gerçekleşmesini beklemez. Büyük olasılıkla, bu şey eşzamansız olarak çalışacak ve böylece süreçlerin bir şey beklerken takılmamasına izin verecektir. Bu çok faydalı bir şey.
Tüm istemci istekleri genel sıraya göre işlenir.
Ve müşteriler, değişen verileri kendileri görmeden önce, bazı durumlardaki değişiklikler, verilerdeki değişiklikler hakkında bildirim alma fırsatına sahiptir.
ZooKeeper iki modda çalışabilir. İlki, tek bir düğümde bağımsızdır. Bu test için uygundur. Ayrıca herhangi bir sayıda sunucuda küme modunda da çalışabilir. Eğer 100 makinelik bir kümemiz varsa o zaman 100 makinede çalışmasına gerek yoktur. ZooKeeper'ı çalıştırabileceğiniz birkaç makine seçmeniz yeterlidir. Ve yüksek kullanılabilirlik ilkesini savunuyor. ZooKeeper, çalışan her örnekte verilerin tam bir kopyasını saklar. Daha sonra sana bunu nasıl yaptığını anlatacağım. Verileri parçalamaz veya bölmez. Bir yandan fazla depolayamamamız bir eksi, diğer yandan bunu yapmaya gerek yok. Bunun için tasarlanmadı, bir veritabanı değil.
Veriler istemci tarafında önbelleğe alınabilir. Hizmeti kesintiye uğratmamamız ve aynı isteklerle yüklemememiz için bu standart bir prensiptir. Akıllı bir istemci genellikle bunu bilir ve önbelleğe alır.
Mesela burada bir şeyler değişti. Bir çeşit uygulama var. Örneğin yazma işlemlerinin işlenmesinden sorumlu olan yeni bir lider seçildi. Ve verileri kopyalamak istiyoruz. Çözümlerden biri onu bir döngüye koymaktır. Ve sürekli olarak hizmetimizi sorguluyoruz; herhangi bir değişiklik oldu mu? İkinci seçenek daha optimaldir. Bu, müşterilere bir şeyin değiştiğini bildirmenizi sağlayan bir izleme mekanizmasıdır. Bu, kaynaklar açısından daha ucuz ve müşteriler için daha uygun bir yöntemdir.
İstemci, ZooKeeper'ı kullanan kullanıcıdır.
Sunucu, ZooKeeper işleminin kendisidir.
Znode, ZooKeeper'daki en önemli şeydir. Tüm znode'lar ZooKeeper tarafından hafızada saklanır ve bir ağaç şeklinde hiyerarşik bir diyagram şeklinde düzenlenir.
İki tür operasyon vardır. Bunlardan ilki, bazı işlemlerin ağacımızın durumunu değiştirdiği güncelleme/yazma işlemidir. Ağaç yaygındır.
İstemcinin bir isteği tamamlamaması ve bağlantısının kesilmesi, ancak ZooKeeper ile etkileşime gireceği bir oturum oluşturması da mümkündür.
ZooKeeper'ın veri modeli bir dosya sistemine benzer. Standart bir kök var ve sonrasında sanki kökten giden dizinler arasında gezindik. Ve sonra birinci seviyenin, ikinci seviyenin kataloğu. Bunların hepsi znode'lar.
Her znode, genellikle çok büyük olmayan, örneğin 10 kilobayt gibi bazı verileri depolayabilir. Ve her znode'un belirli sayıda çocuğu olabilir.
Znode'ların çeşitli türleri vardır. Oluşturulabilirler. Ve bir znode oluştururken ait olması gereken türü belirtiriz.
İki tip var. Birincisi geçici bayraktır. Znode bir oturum içinde yaşar. Örneğin istemci bir oturum kurmuştur. Ve bu oturum hayatta olduğu sürece var olacaktır. Gereksiz bir şey üretmemek için bu gereklidir. Bu aynı zamanda bir oturum içinde temel verileri saklamanın bizim için önemli olduğu anlar için de uygundur.
İkinci tip sıralı bayraktır. Znode'a giderken sayacı artırır. Örneğin 1_5 uygulamasına sahip bir dizinimiz vardı. Ve ilk düğümü oluşturduğumuzda p_1, ikincisini - p_2 aldı. Ve bu yöntemi her çağırdığımızda, yolun yalnızca bir kısmını belirterek tam yolu geçiyoruz ve düğüm tipini sıralı olarak belirttiğimiz için bu sayı otomatik olarak artırılıyor.
Düzenli znode. O her zaman yaşayacak ve ona söylediğimiz isme sahip olacak.
Bir diğer kullanışlı şey ise saat bayrağıdır. Eğer kurarsak, müşteri belirli bir düğüm için bazı etkinliklere abone olabilir. Bunun nasıl yapıldığını daha sonra size bir örnekle göstereceğim. ZooKeeper'ın kendisi müşteriye düğümdeki verilerin değiştiğini bildirir. Ancak bildirimler bazı yeni verilerin geldiğini garanti etmez. Sadece bir şeylerin değiştiğini söylüyorlar, bu yüzden verileri daha sonra ayrı aramalarla karşılaştırmanız gerekiyor.
Ve daha önce de söylediğim gibi verilerin sırası kilobaytlara göre belirleniyor. Büyük metin verilerinin orada depolanmasına gerek yoktur, çünkü bu bir veritabanı değil, bir eylem koordinasyon sunucusudur.
Size biraz seanslardan bahsedeceğim. Birden fazla sunucumuz varsa, oturum tanımlayıcıyı kullanarak şeffaf bir şekilde sunucudan sunucuya geçiş yapabiliriz. Oldukça kullanışlı.
Her oturumun bir tür zaman aşımı vardır. Oturum, istemcinin o oturum sırasında sunucuya herhangi bir şey gönderip göndermediğine göre tanımlanır. Zaman aşımı sırasında herhangi bir şey iletmezse oturum düşer veya istemci oturumu kendisi kapatabilir.
Çok fazla özelliği yok ama bu API ile farklı şeyler yapabilirsiniz. Create'i gördüğümüz bu çağrı bir znode oluşturur ve üç parametre alır. Bu, znode'a giden yoldur ve kökten itibaren tam olarak belirtilmesi gerekir. Ayrıca bu, oraya aktarmak istediğimiz bazı verilerdir. Ve bayrak türü. Ve yaratımdan sonra znode'un yolunu döndürür.
İkincisi, onu silebilirsiniz. Buradaki püf noktası, znode yoluna ek olarak ikinci parametrenin de sürümü belirtebilmesidir. Buna göre, aktardığımız sürümün gerçekte var olan sürüme eşdeğer olması durumunda o znode silinecektir.
Bu sürümü kontrol etmek istemiyorsak "-1" argümanını iletmeniz yeterlidir.
Üçüncüsü, bir znode'un varlığını kontrol eder. Düğüm varsa true, yoksa false değerini döndürür.
Ve sonra bu düğümü izlemenizi sağlayan bayrak izleme belirir.
Bu bayrağı var olmayan bir düğümde bile ayarlayabilir ve göründüğünde bildirim alabilirsiniz. Bu aynı zamanda yararlı olabilir.
Birkaç zorluk daha var veri almak. Znode aracılığıyla veri alabileceğimiz açıktır. Bayrak saatini de kullanabilirsiniz. Bu durumda düğüm yoksa kurulmayacaktır. Bu nedenle var olduğunu anlamanız ve ardından veri almanız gerekir.
Ayrıca birde şu var Verileri Ayarla. Burada versiyona geçiyoruz. Ve eğer bunu aktarırsak, belirli bir sürümün znode'undaki veriler güncellenecektir.
Bu kontrolü hariç tutmak için "-1" de belirtebilirsiniz.
Bir diğer faydalı yöntem ise Çocukları Al. Ayrıca ona ait tüm znode'ların bir listesini de alabiliriz. Bayrak izlemeyi ayarlayarak bunu takip edebiliriz.
Ve yöntem senkronize tüm değişikliklerin bir kerede gönderilmesine olanak tanır, böylece bunların kaydedilmesi ve tüm verilerin tamamen değiştirilmesi sağlanır.
Normal programlama ile benzetmeler yapacak olursak, yazma gibi diske bir şeyler yazan yöntemleri kullandığınızda ve size yanıt verdikten sonra verileri diske yazdığınızın garantisi yoktur. Ve işletim sistemi her şeyin yazıldığından emin olsa bile, diskin kendisinde, sürecin arabellek katmanlarından geçtiği ve ancak bundan sonra verilerin diske yerleştirildiği mekanizmalar vardır.
Çoğunlukla eşzamansız çağrılar kullanılır. Bu, müşterinin farklı isteklerle paralel çalışmasına olanak tanır. Eşzamanlı yaklaşımı kullanabilirsiniz, ancak daha az üretkendir.
Bahsettiğimiz iki işlem veriyi değiştiren güncelleme/yazma işlemidir. Bunlar oluştur, setData, senkronize et, sil. Ve okuma var, getData, getChildren.
Şimdi dağıtılmış bir sistemde çalışmak için ilkelleri nasıl oluşturabileceğinize dair birkaç örnek. Örneğin, bir şeyin konfigürasyonuyla ilgili. Yeni bir işçi ortaya çıktı. Makineyi ekleyip işlemi başlattık. Ve aşağıdaki üç soru var. ZooKeeper'ı yapılandırma için nasıl sorgular? Eğer konfigürasyonu değiştirmek istersek onu nasıl değiştiririz? Peki bunu değiştirdikten sonra, sahip olduğumuz işçiler bunu nasıl elde etti?
ZooKeeper bunu nispeten kolaylaştırır. Örneğin znode ağacımız var. Burada uygulamamız için bir node var, onun içinde konfigürasyondan gelen verileri içeren ek bir node oluşturuyoruz. Bunlar ayrı parametreler olabilir veya olmayabilir. Boyut küçük olduğundan, konfigürasyon boyutu da genellikle küçüktür, dolayısıyla onu burada saklamak oldukça mümkündür.
Yöntemi kullanıyorsun veri almak düğümden çalışanın yapılandırmasını almak için. Doğru olarak ayarlayın. Herhangi bir nedenle bu düğüm mevcut değilse, ortaya çıktığında veya değiştiğinde bundan haberdar olacağız. Bir şeyin değiştiğini bilmek istiyorsak bunu true olarak ayarlarız. Ve eğer bu düğümdeki veriler değişirse bundan haberimiz olacak.
Verileri Ayarla. Verileri ayarlıyoruz, “-1” olarak ayarlıyoruz, yani sürümü kontrol etmiyoruz, her zaman tek bir konfigürasyona sahip olduğumuzu varsayıyoruz, çok fazla konfigürasyon saklamamıza gerek yok. Çok fazla depolamanız gerekiyorsa başka bir seviye eklemeniz gerekecektir. Burada sadece bir tane olduğuna inanıyoruz, bu yüzden sadece en son olanı güncelliyoruz, bu yüzden sürümü kontrol etmiyoruz. Şu anda, daha önce abone olan tüm istemciler, bu düğümde bir şeylerin değiştiğine dair bir bildirim alıyor. Ve bunu aldıktan sonra verileri tekrar talep etmeleri gerekir. Bildirim, verilerin kendisini almamaları, yalnızca değişikliklerin bildirimini almalarıdır. Bundan sonra yeni veriler istemeleri gerekir.
İlkel kullanımın ikinci seçeneği grup üyeliği. Dağıtılmış bir uygulamamız var, bir grup çalışan var ve hepsinin yerinde olduğunu anlamak istiyoruz. Bu nedenle uygulamamıza çalıştıklarını kendilerinin kaydetmeleri gerekmektedir. Ayrıca Master sürecinden veya başka bir yerden şu anda sahip olduğumuz tüm aktif çalışanlar hakkında bilgi edinmek istiyoruz.
Bunu nasıl yapabiliriz? Uygulama için bir işçi düğümü oluşturuyoruz ve oraya create yöntemini kullanarak bir alt düzey ekliyoruz. Slayt üzerinde bir hatam var. Burada ihtiyacın var ardışık belirtin, ardından tüm çalışanlar tek tek oluşturulacaktır. Ve bu düğümün çocukları hakkındaki tüm verileri talep eden uygulama, mevcut tüm aktif çalışanları alır.
Bu, bunun Java kodunda nasıl yapılabileceğine dair çok korkunç bir uygulamadır. Ana yöntemle sondan başlayalım. Bu bizim sınıfımız, onun metodunu oluşturalım. İlk argüman olarak bağlandığımız hostu kullanırız, yani onu argüman olarak belirleriz. İkinci argüman ise grubun adıdır.
Bağlantı nasıl oluyor? Bu, kullanılan API'nin basit bir örneğidir. Burada her şey nispeten basit. Standart bir ZooKeeper sınıfı var. Ana bilgisayarları ona aktarıyoruz. Ve zaman aşımını örneğin 5 saniyeye ayarlayın. VeconnectedSignal adında bir üyemiz var. Esasen, iletilen yol boyunca bir grup oluştururuz. Bir şeyler yazılmış olmasına rağmen oraya veri yazmıyoruz. Ve buradaki düğüm kalıcı tiptedir. Esasen bu, her zaman var olacak sıradan, düzenli bir düğümdür. Oturumun oluşturulduğu yer burasıdır. Bu müşterinin kendisinin uygulanmasıdır. Müşterimiz periyodik olarak oturumun canlı olduğunu bildirecektir. Ve seansı bitirdiğimizde close diyoruz ve işte bu kadar, seans düşüyor. Bu, bizim için bir şeylerin ters gitmesi durumunda ZooKeeper'ın bunu öğrenmesi ve oturumu kesmesi için kullanılır.
Bir kaynak nasıl kilitlenir? Burada her şey biraz daha karmaşık. Bir dizi çalışanımız var, kilitlemek istediğimiz bazı kaynaklar var. Bunu yapmak için, örneğin lock1 adı verilen ayrı bir düğüm oluşturuyoruz. Eğer onu yaratabilseydik, o zaman burada bir kilitimiz olur. Ve eğer onu oluşturamazsak, işçi buradan getData'yı almaya çalışır ve düğüm zaten oluşturulduğu için buraya bir izleyici koyarız ve bu düğümün durumu değiştiği anda bunu bileceğiz. Ve onu yeniden yaratmak için zaman ayırmaya çalışabiliriz. Bu düğümü alırsak, bu kilidi alırsak, artık kilide ihtiyacımız kalmadığında, düğüm yalnızca oturum içinde var olduğu için onu terk edeceğiz. Buna göre ortadan kaybolacaktır. Ve başka bir müşteri, başka bir oturum çerçevesinde bu düğümdeki kilidi alabilecek veya daha doğrusu bir şeyin değiştiğine dair bir bildirim alacak ve bunu zamanında yapmaya çalışabilecek.
Ana lideri nasıl seçebileceğinize dair başka bir örnek. Bu biraz daha karmaşık ama aynı zamanda nispeten basit. Burada neler oluyor? Tüm işçileri bir araya getiren bir ana düğüm vardır. Lider hakkında veri toplamaya çalışıyoruz. Eğer bu başarıyla gerçekleştiyse, yani bazı veriler aldık, o zaman çalışanımız bu lideri takip etmeye başlar. Zaten bir liderin olduğuna inanıyor.
Lider herhangi bir nedenle öldüyse, örneğin düştüyse, o zaman yeni bir lider yaratmaya çalışırız. Ve eğer başarılı olursak, çalışanımız lider olur. Ve eğer biri şu anda yeni bir lider yaratmayı başarmışsa, o zaman onun kim olduğunu anlamaya çalışırız ve sonra onu takip ederiz.
Burada sürü etkisi denilen durum ortaya çıkıyor, yani sürü etkisi, çünkü bir lider öldüğünde zamanında ilk gelen lider olacak.
Bir kaynağı yakalarken, aşağıdaki gibi biraz farklı bir yaklaşım kullanmayı deneyebilirsiniz. Mesela bir kilit almak istiyoruz ama hert etkisi olmadan. Uygulamamızın, halihazırda mevcut olan ve kilitli bir düğüm için tüm düğüm kimliklerinin listesini talep etmesinden oluşacaktır. Ve bundan önce kilit oluşturduğumuz düğüm, aldığımız setin minimum değeriyse, bu, kilidi yakaladığımız anlamına gelir. Kilit aldığımızı kontrol ediyoruz. Kontrol olarak, yeni bir kilit oluştururken aldığımız kimliğin minimum düzeyde olması şartı aranacaktır. Ve eğer alırsak, daha fazla çalışırız.
Eğer kilidimizden daha küçük bir id varsa bu olaya bir gözlemci yerleştirip bir şeyler değişene kadar bildirim gelmesini bekleriz. Yani bu kilidi aldık. Ve düşene kadar minimum kimlik olmayacağız ve minimum kilidi alamayacağız ve böylece giriş yapabileceğiz. Ve eğer bu koşul karşılanmazsa hemen buraya gidip bu kilidi tekrar almaya çalışırız çünkü bu süre zarfında bir şeyler değişmiş olabilir.
ZooKeeper nelerden oluşur? 4 ana şey var. Bu süreçlerin işlenmesidir - Talep. Ve ayrıca ZooKeeper Atomik Yayını. Tüm işlemlerin kaydedildiği bir Commit Log bulunmaktadır. Ve Bellek İçi Çoğaltılan Veritabanının kendisi, yani tüm bu ağacın depolandığı veritabanının kendisi.
Tüm yazma işlemlerinin İstek İşlemcisinden geçtiğini belirtmekte fayda var. Ve okuma işlemleri doğrudan bellek içi veritabanına gider.
Veritabanının kendisi tamamen kopyalanmıştır. ZooKeeper'ın tüm örnekleri verilerin tam bir kopyasını saklar.
Bir çökme sonrasında veritabanını geri yüklemek için bir Commit günlüğü vardır. Standart uygulama, verinin belleğe alınmadan önce oraya yazılmasıdır, böylece çökerse bu kayıt oynatılabilir ve sistem durumu geri yüklenebilir. Ayrıca veritabanının periyodik anlık görüntüleri de kullanılır.
ZooKeeper Atomic Broadcast, çoğaltılmış verileri korumak için kullanılan bir şeydir.
ZAB, ZooKeeper düğümünün bakış açısından dahili olarak bir lider seçer. Diğer düğümler onun takipçisi olur ve ondan bazı eylemler bekler. Başvuru alırlarsa hepsini lidere iletirler. Önce bir yazma işlemi gerçekleştiriyor ve ardından takipçilerine nelerin değiştiğine dair bir mesaj gönderiyor. Bu aslında atomik olarak gerçekleştirilmelidir, yani her şeyin kayıt ve yayınlama işlemi atomik olarak gerçekleştirilmelidir, böylece veri tutarlılığı garanti edilir.
Yalnızca yazma isteklerini işler. Ana görevi, işlemi işlemsel bir güncellemeye dönüştürmektir. Bu özel olarak oluşturulmuş bir istektir.
Ve burada aynı işlem için güncellemelerin önemsizliğinin garanti edildiğini belirtmekte fayda var. Ne olduğunu? Bu şey iki kez yürütülürse aynı duruma sahip olacaktır, yani isteğin kendisi değişmeyecektir. Ve bunun, bir çökme durumunda işlemi yeniden başlatabilmeniz ve böylece o anda düşen değişiklikleri geri alabilmeniz için yapılması gerekiyor. Bu durumda sistemin durumu aynı olacaktır, yani bir dizi aynı güncelleme işleminin sistemin farklı son durumlarına yol açması söz konusu olmamalıdır.
Kaynak: habr.com