g u t x .com.tr İpek yolu - Çin'i anlamaya götürürüm

Sistem performansını kod seviyesinden optimize etmeye yönelik çözümler

Yazar Cheng Chao

Düzenle Xiaozhi

Daha önce gördüğümüz mimari değişiklikler veya evrimle ilgili makalelerin çoğu, çoğunlukla mimariye girişler ve kod düzeyinde performans optimizasyonuna çok az giriş. Bu makale kodun bazı ayrıntılarını tanıtacak, herkesi şikayet etmeye ve önerilerde bulunmaya davet edecektir.

Önüne yaz

İçinde Önceki Esas olarak karşılaşılan sorunların beş noktasını tanıttık, bu yüzden bugün kalan sorunları tartışacağız, daha önce tartışılan sorunları gözden geçirelim:

Tek bir 40TPS, neredeyse hiçbir ölçeklenebilirlik olmadan 4 sunucuya eklendiğinde 60TPS'ye ulaşabilir.

Gerçek üretim ortamında, veritabanı kilitlenmeleri sıklıkla meydana gelir ve tüm hizmet kesintiye uğrar ve kullanılamaz.

Veritabanı işlemlerinin kötüye kullanılması, çok uzun işlem süresine neden olur.

Gerçek üretim ortamında, sunucu genellikle bellek taşmasına ve tam CPU süresine sahiptir.

Program geliştirme sürecinde, değerlendirme kapsamlı değildir, hata toleransı çok zayıftır ve küçük bir hata nedeniyle hizmet genellikle kullanılamamaktadır.

Kritik günlük programda yazdırılmaz veya günlük yazdırılır, ancak bilgiler işe yaramaz ve referans değeri yoktur.

Konfigürasyon bilgileri ve küçük değişiklikler içeren bilgiler yine de veritabanından sık sık okunacak ve bu da büyük veritabanı IO'suna neden olacaktır.

Proje tamamen bölünmemiş ve birden çok proje WAR paketi bir tomcat içinde konuşlandırılacak.

Temel platformdaki hata veya işlev hatası nedeniyle programın kullanılabilirliği azalır.

Program arayüzünde mevcut sınırlayıcı bir strateji yoktur, bu da birçok VIP satıcının üretim ortamımızı stres testi için doğrudan kullanmasına neden olur ve bu da gerçek hizmet kullanılabilirliğini doğrudan etkiler.

Başarısızlık düşürme stratejisi yoktur ve projenin bir sorunu olduğunda veya proje kabaca geri alındıktan sonra sorunu çözmek uzun zaman alır, ancak sorun çözülemeyebilir.

Uygun bir izleme sistemi olmadan, proje darboğazları gerçek zamanlı veya önceden bulunamaz.

Optimizasyon çözümü

Önbellek optimizasyon şeması

Çok fazla değişmeyen yapılandırma bilgileri ve bilgileri önbelleğe koyabilirsiniz. Eşzamanlılığı artırmak GÇ önbelleğini de azaltabilir. Belirli önbellek optimizasyon stratejileri için lütfen daha önce yazdıklarıma bakın:

Hata toleransı optimizasyon programı programı

Bu bölümde, hata toleransının ne olduğunu göstermek için bir program örneği vermek istiyorum, önce programa bakın:

Not:

Öyleyse, hizmet katmanının yöntemi dao katmanının yöntemini çağırırsa, veri ekleme başarısız olduğunda, bu istisna işleme yöntemi hataya dayanıklı mıdır?

İstisna yenilir Servis katmanı çağrıldığında, hata mesajı yazdırılmamasına rağmen, bu hata toleransı olabilir mi?

Sözde hata toleransı, bilgisayar sisteminin arızalanmaması ve bir arıza durumunda normal şekilde çalışabilmesi özelliğini ifade eder. .

Önbelleğe almayı açıklamak için bir vaka olarak ele alalım, önce bir resme bakalım:

Bu en basit resimdir.Uygulama hizmeti düzenli olarak konfigürasyon bilgisini redis'ten alır.Bazı arkadaşlar bunun zaten çok kararlı olduğunu düşünebilir, ama ya Redis ile ilgili bir sorun varsa? Bazı arkadaşlar Redis'in herhangi bir sorun olmayacağından emin olmak için bir küme, parça veya ana-bağımlı olacağını söyleyebilir. Aslında bu şekilde düşünüyorum, uygulama sunucusu programını olabildiğince hafif tutmak iyi olsa da, tüm umutları ara bileşenlere bağlamak mümkün değil.Başka bir deyişle, şu anda Redis tek bir nokta ise, o zaman sonuçları Nasıl görünecek? Çok sayıda eşzamanlı istek geldiğinde, programda çok sayıda hata rapor edilecek ve normal süreç devam edemez ve iş kesintiye uğrayabilir.

Yani bu senaryoda, benim çözümüm önbellek kullanımını seviyelere bölmektir.Bazı önbellek senkronizasyonları, ödeme limiti yapılandırması gibi çok yüksek bir zamanlama gerektirir.Arka planda değişiklik tamamlandıktan sonra, ön büro anında algı kazanabilir ve başarılı olabilir. Geçiş, bu durumda, Redis'ten gerçek zamanlı olarak yalnızca en son veriler elde edilebilir, ancak yerel önbellek, en son veriler her alındığında eşzamanlı olarak güncellenebilir.Tek noktalı Redis kilitlendiğinde, uygulama en azından yerel olarak okuyabilir Bilgiler servisi anında durdurmaz. Bazı önbellekler yüksek zamanlılık gerektirmez ve belirli bir gecikmeye izin verir. Bu durumda benimsediğim çözüm, aşağıdaki şekilde gösterildiği gibi yerel önbellek ve uzak önbellek kombinasyonunu kullanmaktır:

Seçenek bir:

Bu şekilde, uygulama sunucusunun Ehcache, yerel önbelleği daha eşzamanlı olarak güncellemek için Redis önbellek sunucusunu periyodik olarak sorgular.Dezavantajı, her sunucunun farklı bir Ehcache süresine sahip olması, daha sonra farklı sunucuların en son önbelleği yenileme süresinin farklı olması, veri tutarsızlığına neden olmasıdır. Tutarlılık için yüksek gereklilikler olmadan kullanılabilir

Seçenek II:

MQ kuyruğunu tanıtarak, her uygulama sunucusunun Ehcache'si MQ mesajlarını senkronize olarak dinleyebilir, böylece belirli bir dereceye ulaşabilir. Plesiochronous Güncelleme verileri MQ aracılığıyla itilir veya çekilir, ancak farklı sunucular arasındaki ağ hızı nedeniyle güçlü tutarlılık tam olarak sağlanamaz. Bu ilkeye dayanarak, aynı şey Zookeeper gibi dağıtılmış koordinasyon bildirim bileşenlerini kullanmak için de geçerlidir.

Bazı projelerin eksik bölünmesi

Bölünmeden önce

Not:

Tomcat'te birden çok uygulama savaş paketi konuşlandırılır ve eşzamanlılık çok büyük olduğunda performans önemli ölçüde düşer.

Ayrıldıktan sonra

Not:

Bölünmeden önceki bu durum aslında oldukça yaygın, bu durumun projede olmayacağını hep düşünmüştüm ama aslında hala var. Çözüm çok basit.Her uygulama savaşı yalnızca bir tomcat içinde konuşlandırılıyor, böylece kaynaklar için rekabet olmayacak ve uygulamalar arasındaki bağlantı sayısı ve performans ve eşzamanlılık gönderimleri daha belirgindir.

Temel platform bileşenlerinin kusurlu işlevleri nedeniyle performans düşüşü

Önce bir kod parçasına bakın:

Not:

Öncelikle bu kodun formatından bahsetmeyelim, önce fonksiyon uygulamasına bakalım.Zaman aşımı kontrolü için Future'ı kullanın Neden bu? Nedeni aslında bizim dediğimiz Dubbo arayüzünde, çünkü Dubbo iki kez kapsüllenmiş ve beraberinde gelen zaman aşımı aşılmış durumda.Programcı zaman aşımını ancak bu şekilde kontrol edebilir.Bu kullanımın çok olduğunu görebilirsiniz. Kötü, program performansı üzerinde belirli bir etkiye sahiptir.

Program performans darboğazlarını hızlı bir şekilde bulma

Jcmd, Jstack, jmap, jhat, jstat, iostat, vmstat vb. Gibi jdk ile birlikte gelen komutları kullanmak gibi program performans sorunlarını bulmanın birçok yolu olduğuna inanıyorum. Ayrıca VisualVM, MAT, JRockit'i de kullanabilirsiniz. Görselleştirme araçları için, bugün söylemek istediğim, programın hangi bölümünde performans sorunları olabileceğini bulmak için en basit komutun kullanılabileceğidir.Lütfen aşağıdaki girişe bakın:

Genel olarak, her bir işlemin cpu ve bellek kullanımını üst komut aracılığıyla görüntüleyeceğiz ve işlem kimliğimizi elde edeceğiz ve ardından içindeki her iş parçacığının kimliğini ve karşılık gelen iş parçacığının şu anda ne yaptığını görüntülemek için pstack komutunu kullanacağız ve birden fazla veri kümesini analiz edeceğiz. Sunucunun performansını etkileyen yavaş işlemlere sahip olan evreler elde edilebilir ve bir çözüm elde edilebilir. Örnekler aşağıdaki gibidir:

Bundan, LWP 30222'nin iş parçacığının bir performans sorunu olduğu yargılanabilir.Çalışma süresi 31.4 milisaniyeye kadar uzundur. Tekrar gözlemlerseniz, aşağıdaki ifadelerdeki sorundan başka bir şey değildir.Sadece sorunu gidermeniz ve sorunun darboğazını bulmanız gerekir.

Dizin optimizasyonu hakkında

Birleşik dizinin ilkesi sol ilkedir, bu nedenle onu kullanırken daha fazla dikkat etmeniz gerekir;

Dizin sayısının çok fazla eklenmesine gerek yoktur.Ekleme yaparken, kümelenmiş dizini ve yardımcı dizini göz önünde bulundurun İkisinin performansı farklıdır;

Dizin, değeri olan bir sütun içermeyecektir: sütun bir değer içerdiği sürece dizine dahil edilmeyecektir. Bileşik dizindeki bir sütun bir değer içerdiği sürece, bu sütun bu bileşik dizin için geçersizdir. Bu yüzden veritabanı tasarımında alanın varsayılan değerine izin vermeyiz.

MySQL indeks sıralaması: MySQL sorguları yalnızca bir indeks kullanır, bu nedenle where cümlesinde bir indeks zaten kullanılmışsa, sıradaki sütun indeksi kullanmaz. Bu nedenle, veritabanı varsayılan sıralaması gereksinimleri karşılayabiliyorsa sıralama işlemini kullanmayın; birden çok sütun sıralaması eklememeye çalışın ve gerekirse bu sütunlar için bir bileşik dizin oluşturmak en iyisidir.

Dizinlerin kullanımına ilişkin notlar

Aşağıdaki operatörler dizinleri uygulayabilir:

büyük veya eşit
Arasında
İÇİNDE
LIKE% ile başlamıyor

Aşağıdaki operatörler dizinleri uygulayamaz:

DEĞİL
% _ LIKE ile başlayın

İndeksleme becerileri

Aynısı 1234567890'dır ve sayısal türlerin depolanması, depolama alanından dizelerden çok daha fazla tasarruf sağlar.
Depolamadan tasarruf etmek, IO'dan tasarruf etmek, IO'yu azaltmak ise performansı artırmak anlamına gelir
Genel olarak, sayıları indekslemek ve aramak dizeleri indekslemek ve aramaktan daha etkilidir.

Redis'i kullanırken dikkat edilmesi gereken bazı noktalar

Anahtarı artırırken sona erme süresini ayarlamayı deneyin, aksi takdirde Redis Sunucusunun bellek kullanımı sistemin maksimum fiziksel belleğine ulaşacak ve Redis'in sistem performansını düşürmek için VM'yi kullanmasına neden olacaktır.
Redis Anahtarı olabildiğince kısa tasarlanmalı ve Değer, karmaşık nesneleri olabildiğince fazla kullanmamalıdır.
Nesneyi bir JSON nesnesine dönüştürün (hazır JSON kitaplığını kullanarak) ve Redis'te depolayın,
Nesneleri Google açık kaynaklı ikili protokol nesnelerine dönüştürün (Google Protobuf, JSON veri biçimine benzer, ancak ikili bir gösterim olduğu için performans verimliliği ve alan kullanımı JSON'dan daha küçüktür; Dezavantaj, Protobuf'un öğrenme eğrisinin JSON'dan çok daha büyük olmasıdır)
Redis'i kullandıktan sonra, aşağıdaki örnekte gösterildiği gibi bağlantıyı kesmeniz gerekir:

Bağlantı havuzuna döndürülmesine veya doğrudan serbest bırakılmasına bakılmaksızın, kısaca bağlantı döndürülür.

Uzun zaman alan yöntemlerin bölünmesi hakkında

Uzun zaman alan yöntemleri bölmek için genel tekniğimiz:

İşletmedeki gereksiz noktaları arayın Kodda, uygun şekilde basitleştirilebilecek birçok tekrarlayan kod vardır.
Veritabanı tablosu dizininin doğru şekilde eklenip eklenmediğini kontrol edin.
Kitaplıktan büyük miktarlarda veri okuma veya uzun vadeli döngü işlemleri veya sonsuz döngü işlemleri gibi algoritma düzeyini optimize etmek için uzun zaman alan işlemler için birim testi veya stres testi kullanın.
İşletmenin ayrılma noktasını bulun ve eşzamanlı işlemi iş ihtiyaçlarına göre eşzamansız olarak bölün; örneğin, bir ileti kuyruğu veya çok iş parçacıklı eşzamansız kullanabilirsiniz.

Yukarıdaki analizden sonra, yöntemin uygulama süresi hala çok uzunsa, bu, aşağıdaki şekilde gösterildiği gibi iş ihtiyaçlarından kaynaklanıyor olabilir:

Öyleyse, uzun zaman alan bir yöntemi, başlatan tarafından ayrı ayrı çağrılmak üzere birden çok kısa zaman alan yönteme bölmeyi düşünebilir miyiz, böylece yüksek eşzamanlılık durumunda belirli bir yöntem uzun süre engellenmez. Aşağıdaki şekilde gösterildiği gibi eşzamanlılığı belirli bir ölçüde iyileştirebilir:

yazar hakkında

InfoQ imzalı yazar Cheng Chao, 10 yıllık Java iş tecrübesi, dağıtılmış ve büyük verinin teknik alanında iyi ve ilgileniyor, şu anda esas olarak finansal ödeme yönünde çalışıyor.

Bugünün Tavsiyesi

Okumak için aşağıdaki resme tıklayın