Programcı sert yemek kavun Song Hye Kyo Song Zhongji boşandı, Fan Bingbing ve Li Chen ayrıldı
Yazar | Huperzia sinensis
Sorumlu Editör | Wu Xingling
Bu makale Shishan'ın mimari notlarından izin alınarak yeniden basılmıştır.
[CSDN editörünün notu] Dün arka arkaya 4 sıcak haber vardı: Shuangsong boşanması, Tang Yixin Zhang Ruoyun'un evliliği, Baoqiang'ın annesi öldü, Li Chen ve Fan Bingbing ayrıldı. Kavun yemenin yanı sıra, birçok netizen Sina programcıları için üzülüyor:
İlk üç ateşli Weibo'dan sonra nihayet dayanamadım:
Programcının biraz yorgun olduğu ve biraz nefes alması gerektiği tahmin ediliyor.
Bir programcı olarak kavun yerken şunu düşünüyor musunuz: Günde dört sıcak noktayı sürdürebilmek için arka planı nasıl tasarlamanız gerekir?
Bu makalenin yazarı, on yıldan fazla deneyime sahip kıdemli bir programcıdır ve bu makalede sorularınızı ayrıntılı olarak yanıtlayacaktır.
Öncelikle arka planı popüler hale getirelim: okuma isteklerini barındırmak için bir önbellek kümesi nasıl kullanılır?
Neden bir önbellek kümesi kullanmalısınız?
Aslında, bir önbellek kümesi kullanılırken en çok korkulan iki kısayol tuşu ve büyük değer durumudur.Peki kısayol tuşu ve büyük değer nedir?
Basitçe söylemek gerekirse, kısayol tuşu, önbellek kümenizdeki bir anahtarın anında on binlerce hatta yüzbinlerce eşzamanlı istek tarafından patlatıldığı anlamına gelir. Büyük bir değer, bir anahtara karşılık gelen değerin GB boyutuna sahip olabileceği anlamına gelir ve bu, değer sorgulanırken ağla ilgili hatalara neden olur.
Öncelikle aşağıdaki resme bir göz atalım: Elinizde bir sistem olduğunu varsayarsak, bir kümede konuşlandırılır ve ardından bir dizi önbellek kümesi vardır. Bu kümenin Redis Kümesi, Memcached veya şirketin kendi geliştirdiği önbellek kümesini kullanmanız fark etmez. Her şey yolunda.
Peki, bu sistem bir önbellek kümesiyle ne yapıyor?
Çok basit. Önbelleğe fazla değişmeyen bazı veriler koyun ve sonra kullanıcı çok fazla değişmeyen büyük miktarda veriyi sorguladığında, doğrudan önbellekten gidemez mi?
Önbellek kümesinin eşzamanlılığı çok güçlüdür ve okuma önbelleğinin performansı çok yüksektir. Örneğin, saniyede 20.000 isteğiniz olduğunu, ancak bunların% 90'ının okuma isteği olduğunu ve saniyede 18.000 isteğinizin veri yazmak yerine daha az değişen veri okuduğunu varsayalım.
Şu anda bu verileri veri tabanına koyup veri okuma ve yazma için veri tabanına saniyede 20.000 istek gönderiyorsunuz, sizce uygun mu?
Elbette uygun değil.Saniyede 20.000 istek taşımak için bir veritabanı kullanmak istiyorsanız, özür dilerim, veritabanı ve tablo + okuma-yazma ayrımına girmeniz gerekebilir.
Örneğin, saniyede 2000 yazma isteği taşıyan üç ana kitaplık puanlanabilir ve daha sonra her ana kitaplık, saniyede 18.000 okuma isteği taşıyacak toplam 9 bağımlı kitaplık için üç bağımlı kitaplığa sahip olabilir.
Bu durumda, çok pahalı, çok maliyetli ve çok uygun olmayan toplam 12 yüksek konfigürasyonlu veritabanı sunucusu gerekebilir.
Bu durumu anlamak için aşağıdaki resme bir göz atalım.
Bu nedenle, genellikle değişmeyen verileri önbellek kümesine koyabiliriz.Önbellek kümesi 2 master ve 2 slave kullanabilir.Ana düğüm önbelleği yazmak için ve slave düğüm önbelleği okumak için kullanılır.
Önbellek kümesinin performansıyla, saniyede 18.000 gibi çok sayıda okuma isteği taşımak için 2 bağımlı düğüm kullanılabilir ve ardından üç ana veritabanı veritabanı saniyede 2000 yazma isteğini ve az sayıda başka okuma isteğini taşıyabilir.
Bu şekilde, maliyetli makineler anında 4 önbellek makinesi + 3 veritabanı makinesi = 7 makine haline gelir.Önceki 12 makineye kıyasla çok fazla kaynak ek yükünü azaltmak mümkün müdür?
Evet, önbellek aslında sistem mimarisinin çok önemli bir parçasıdır. Pek çok durumda, nadiren değişen ancak çok sayıda eşzamanlı okuma içeren veriler için, bir önbellek kümesi aracılığıyla yüksek eşzamanlı okumalara direnmek çok uygundur.
Bu süreci deneyimlemek için aşağıdaki resme bir göz atalım.
Buradaki tüm makine sayısı ve eşzamanlı taleplerin sadece örnek olduğu unutulmamalıdır, bu anlamı herkesin deneyimlemesi iyidir.
Temel amaç, önbelleğe alma ile ilgili teknolojilere aşina olmayan öğrenciler için bazı arka plan açıklamaları vermektir, böylece bu öğrenciler sistemde okuma isteklerini barındırmak için bir önbellek kümesi kullanmanın ne anlama geldiğini anlayabilirler.
200.000 kullanıcı aynı anda bir sıcak nokta önbelleğine erişir
Pekala, arka plan size net bir şekilde açıklandı ve şimdi size bugün tartışılacak olan konuyu anlatabilirim: sıcak nokta önbelleği.
Bir varsayım yapalım Şimdi çok sayıda okuma isteğine direnecek 10 önbellek düğümü var. Normal koşullar altında, okuma istekleri eşit olarak 10 önbellek düğümüne düşmelidir.
Bu 10 önbellek düğümü saniyede 10.000 istek taşır.
Öyleyse başka bir varsayım yapalım: Bir düğümün 20.000 istek taşıma sınırıdır, bu nedenle genellikle bir düğümü normalde 10.000 istek taşıyacak şekilde sınırlarsınız ve sorun olmaz, biraz arabellek bırakarak.
bu iyi, Sıcak önbellek sorunu ne anlama geliyor? Çok basit: Birdenbire, bilinmeyen bir nedenden dolayı çok sayıda kullanıcı aynı önbelleğe alınmış verilere erişir.
Örneğin dünkü gibi Shuangsong'un boşanması, Baoqiang'ın annesinin ölümü ve Li Chen ile Fan Bingbing'in dağılması ... Bu, yüz binlerce kullanıcıyı kısa bir süre içinde bu sıcak haberleri kontrol etmeye sevk edecek mi?
Yukarıdaki üç haber öğesinin, üç önbellek anahtarına karşılık gelen üç önbellek olduğunu ve bu anahtarların hepsinin bir önbellek makinesinde bulunduğunu varsayalım.
Daha sonra, belirli bir haber duyurulur duyurulmaz, örneğin Fan Bingbing Weibo'yu yayınlar yayınlamaz, yüz binlerce istek anında o makineye koşabilir.
Ne olacak şimdi? Bu çaresiz duyguyu yaşamak için aşağıdaki resme bir göz atalım.
Açıkçası, az önce farz ettiğimiz şey, bir cache slave node'un saniyede en fazla 20.000 isteği olduğudur.Tabii ki, tek bir cache'nin 50.000 ila 100.000 okuma isteği taşıması da mümkündür.
Her saniye bu makineye aniden 200.000 istek gelirse ne olur? Basitçe söylemek gerekirse, yukarıdaki resimde 200.000 istekle gösterilen önbellek makinesi fazla çalıştırılacak ve çalışmama süresi olacaktır.
Öyleyse, önbellek kümesi makinenin kapalı kalma süresi yaşamaya başlarsa ne olur?
Bu sırada, okuma isteği verilerin okunamadığını bulur, orijinal verileri veritabanından çıkarır ve ardından geri kalan diğer önbellek makinelerine koyar. Bununla birlikte, saniyede 200.000 istek bir kez daha diğer önbellek makinelerini zorlayacaktır.
Benzer şekilde, önbellek kümesi sonunda çökecek ve tüm sistem çökecektir.
Aşağıdaki resme bir göz atalım ve bu korkunç sahneyi yeniden hissedelim.
Akış bilgi işlem teknolojisine dayalı önbellek etkin noktalarının otomatik keşfi
Aslında, buradaki kilit nokta, bu tür bir sıcak nokta önbelleği için, sistemin, etkin nokta önbelleğinin aniden oluştuğunu doğrudan algılaması ve ardından milisaniye düzeyinde otomatik yük dengelemeyi anında gerçekleştirmesi gerektiğidir.
Öyleyse önce bunun hakkında konuşalım, sıcak önbellek sorunlarını otomatik olarak nasıl keşfedersiniz?
İlk önce bilmen gerekiyor, Genel olarak, önbellek etkin noktaları göründüğünde, saniye başına eşzamanlılık kesinlikle çok yüksektir. Saniyede yüz binlerce hatta milyonlarca istek olabilir.
Bu nedenle, şu anda Storm, Spark Streaming ve Flink gibi büyük veri alanında akışlı bilgi işlem teknolojisine dayalı gerçek zamanlı veri erişim istatistikleri gerçekleştirmek tamamen mümkündür.
Örneğin, gerçek zamanlı veri erişim sayım istatistikleri sürecine girdikten sonra, bir saniye içinde belirli bir veri parçasına aniden 1.000'den fazla kez erişildiği keşfedilir ve bu veri parçası doğrudan sıcak veri olarak değerlendirilir ve keşfedilen sıcak veriler yazılabilir. Örneğin ZooKeeper'a.
Elbette, sistemin sıcak nokta verilerini nasıl belirlediği, kendi iş ve deneyim değerlerinize bağlı olabilir.
Tüm sürecin nasıl ilerlediğini görmek için aşağıdaki resme bir göz atalım.
Burada birileri kesinlikle soracaktır, akışlı bilgi işlem sisteminiz veri erişimlerinin sayısı hakkında istatistikler yaparken, saniyede yüzbinlerce kez tek bir makinenin istenmesi gibi bir sorun var mı?
Cevap hayır.
Akış bilgi işlem teknolojisi, özellikle de Storm sistemi sayesinde, ilk olarak yerel hesaplamalar için birçok makineye dağıtılan aynı veri parçasını talep edebilir ve son olarak yerel hesaplama sonuçlarını küresel toplama için bir makinede toplayabilir.
Böylece, yüz binlerce istek, örneğin 100 makineye dağıtılabilir ve her makine bu veri parçası için binlerce isteği sayar.
Ardından, yerel olarak hesaplanan 100 sonuç, global hesaplama için tek bir makinede toplanabilir, böylece akışlı bilgi işlem teknolojisine dayalı istatistikler için sıcak sorunlar yaşanmaz.
Hotspot önbelleği, JVM yerel önbelleği olarak otomatik olarak yüklenir
Kendi sistemimiz, ZooKeeper tarafından belirlenen hotspot cache'ine karşılık gelen Znode'u izleyebilir ve bir değişiklik olması durumunda hemen algılayabilir.
Bu noktada sistem katmanı ilgili önbellek verilerini veritabanından anında yükleyebilir ve daha sonra doğrudan kendi sistemi içindeki yerel önbelleğe koyabilir.
Bu yerel önbellek için Ehcache veya Hashmap kullanabilirsiniz, aslında hepsi iş ihtiyaçlarınıza bağlıdır. Burada esas olarak bahsettiğimiz şey, önbellek kümesindeki merkezi önbelleği doğrudan her sistem için yerel bir önbelleğe dönüştürmektir ve her sistem yerel olarak çok fazla veriyi önbelleğe alamaz.
Bu tür sıradan sistemin genel tek örnekli dağıtım makinesi, yerel önbellek için çok az yer bırakan 4 çekirdekli bir 8G makinesi olabileceğinden, bu tür sıcak verileri depolamak için yerel önbellek en uygun olanıdır, en doğrusu.
Sistem katmanı kümenizde 100 makine dağıttığınızı varsayalım. Bu iyi. Şu anda, 100 makine anında etkin nokta önbelleğinin bir kopyasını yerel olarak alacak.
Daha sonra, sıcak nokta önbelleğinin okuma işlemi doğrudan sistemin yerel önbelleğinden okunur ve geri döndürülür ve önbellek kümesine gitmeye gerek yoktur.
Bu durumda, önbellek makinesinin bir makinesinin sıcak bir önbelleği okuyabilmesi için saniyede 200.000 okuma isteğine izin vermek imkansızdır. Bunun yerine, 100 makine olur ve her makine binlerce istek taşır, bu nedenle bu binlerce istek doğrudan Veriler, makinenin yerel önbelleğinden döndürülür, bu da sorun değildir.
Başka bir resim çizelim ve bu sürece birlikte bakalım:
Akım sınırlayıcı sigorta koruması
Ek olarak, her sistemde, aslında, sıcak veri erişimi için özel bir akım sınırlayıcı sigorta koruma önlemi eklenmelidir.
Her sistem örneğine bir sigorta koruma mekanizması eklenebilir Önbellek kümesinin saniyede 40.000'e kadar okuma isteği taşıyabileceği varsayıldığında, toplam 100 sistem örneği vardır.
Bu durumda, sınır iyi olmalıdır. Her sistem örneği, önbellek kümesi okuma işlemlerini saniyede en fazla 400 kez isteyebilir. Aşıldığında, birleştirilebilir. Önbellek kümesi istenmezse, doğrudan boş bir ileti döndürülür ve kullanıcı bunu daha sonra tekrar yapar. Sayfayı veya başka bir şeyi yenileyin.
Sistem katmanının kendisine doğrudan akım sınırlayıcı sigorta koruma önlemleri ekleyerek, aşağıdaki önbellek kümeleri ve veritabanı kümeleri öldürülmekten korunabilir.
Başka bir fotoğraf çekelim ve birlikte bakalım:
sonuç olarak
Özellikle, bu karmaşık önbellek etkin nokta optimizasyon mimarisini sistemde uygulamalı mıyız? Bu, kendi sisteminizde böyle bir senaryo olup olmadığına bağlıdır.
Sisteminizde bir etkin nokta önbellek sorunu varsa, bu makaleye benzer karmaşık bir sıcak nokta önbellek destek mimarisi uygulamanız gerekir. Ancak değilse, aşırı tasarım yapmayın, aslında sisteminizin bu kadar karmaşık bir mimariye ihtiyacı olmayabilir.
İkincisi ise, ilgili mimari fikirlerini anlamak için herkes bu makaleyi okumalıdır.
Yazar hakkında: Huperzia chinensis, BAT mimarisinde on yıldan fazla deneyim, herkes tarafından öğretildi
Kamu Hesabı: Shishan'ın Mimari Notları (id: shishan100)
SON
Sıcak metin Önermek
Apple'ın baş tasarım sorumlusu ayrılacak; Huawei dünyanın dört bir yanından yetenekli gençleri işe alacak; yeni Edge güncellemesi | Geek Headlines
Liu Weitu'yu gördün mü? Python çizildi!
5G'ye geçmek isteyen geliştiriciler ne yapmalı?
Eski sürücü, kimsenin korumaya cesaret edemediği kodların nasıl yazılacağını öğretir!
Python'un teknik avantajları nelerdir? Diğer dillerden daha iyi olan nedir?
Pin Üniversitesi'nin "Turing" e veya Tsinghuanın "Yao Sınıfına" gidemem.
Kamu Zincirinin Tarihsel Kayıtları | Hongmeng'in başlangıcından her şeyin büyümesine ...
Edge bilişimi kapsayıcı hale getirmek gerekli mi?
Bir zamanlar idol olan Jack Ma, sonunda Ali'nin bıraktığı 140 milyar doları yendi!
Orijinal metni okumak, anahtar sözcükler girmek ve CSDN makalelerini aramak için tıklayın.
Sipariş ettiğiniz her "izlemeyi" cidden bir favori olarak değerlendirdim
