Eşzamanlılık: Tasarıma nasıl yaklaşıyor ve uygulamanın hatalarını ayıklıyorsunuz?

Birkaç yıldır eş zamanlı sistemler geliştiriyorum ve örgün eğitim olmamasına rağmen konuyu çok iyi kavradım (derece değil). Erlang ve Go gibi eşzamanlılığı kolaylaştırmak için tasarlanmış, en azından son zamanlarda konuşmaları popüler olan birkaç yeni dil var. Eşzamanlılık yaklaşımlarının, sistemleri nasıl ölçeklendirilebileceği ve çoklu çekirdek / işlemciler / makinelerden nasıl yararlanılacağı konusundaki kendi deneyimlerimi yansıtıyor gibi görünüyor.

Ancak, ne yapmak istediğinizi görselleştirmenize yardımcı olacak çok az sayıda araç olduğunu ve en azından orijinal görüşünüze yakın olduğunuzu doğruladığımı tespit ediyorum. Eşzamanlı kodun hata ayıklaması, eşzamanlılık için tasarlanmamış dillerle kabus olabilir (C / C ++, C #, Java vb.). Özellikle, geliştirme ortamınızdaki bir sistemde kolayca olan koşulları yeniden oluşturmak neredeyse imkansız olabilir.

Öyleyse, eşzamanlılık ve paralel işleme ile başa çıkmak için bir sistem tasarlamadaki yaklaşımlarınız nelerdir? Örnekler:

• Neyin eşzamanlı yapılabileceğini ve ardışık ne olması gerektiğini nasıl anlarsınız?
• Hata koşullarını nasıl yeniden üretiyor ve uygulama yürütülürken neler olduğunu nasıl görüyorsunuz?
• Uygulamanın farklı eşzamanlı kısımları arasındaki etkileşimi nasıl görselleştirirsiniz?

Bunlardan bazıları için kendi cevaplarım var ama biraz daha fazla şey öğrenmek istiyorum.

Düzenle

Şimdiye kadar birçok girişimiz var. Bağlantılı makalelerin çoğu çok iyi ve bazılarını çoktan okudum.

Eşzamanlı programlama konusundaki kişisel deneyimim, sıralı programlama ile yaptığınızdan farklı bir zihniyete ihtiyacınız olduğuna inanmamı sağlıyor. Zihinsel bölünme muhtemelen nesne yönelimli programlama ve prosedürel programlama arasındaki fark kadar geniş. Bu soru kümesinin, cevaplara sistematik olarak yaklaşmak için gerekli düşünce süreçlerine (yani teori) odaklanmasını istiyorum. Daha somut cevaplar verirken, bir örnek sağlamaya yardımcı olur - şahsen yaşadığınız bir şey.

Ödülün Amacı

Bana ne yapmam gerektiğini söyleme. Zaten kontrolüm altında. Bana ne yaptığını söyle. Nasıl söyle sen bu sorunları çözmek.

Birkaç yıldır eşzamanlı sistemler geliştiriyorum ve örgün eğitim olmamasına rağmen (ör. Derece olmamasına rağmen) konuyu çok iyi kavradım.

Bildiğim en iyi programcıların çoğu üniversiteyi bitiremedi. Bana gelince Felsefe okudum.

C / C ++, C #, Java vb.) Özellikle, geliştirme ortamınızdaki bir sistemde kolayca olan koşulları yeniden oluşturmak neredeyse imkansız olabilir.

Evet

Neyin eşzamanlı yapılabileceğini ve ardışık ne olması gerektiğini nasıl anlarsınız?

mimarimizi kendimize (önce) ve diğerlerine (ikincisi) açıklığa kavuşturmak için genellikle 1000 mil yüksekliğinde bir metaforla başlıyoruz.

Bu sorunla karşılaştığımızda, eşzamanlı nesnelerin görünürlüğünü eşzamanlı olmayanlarla sınırlandırmanın bir yolunu bulduk.

Son zamanlarda Scala'da Actors'u keşfettim ve eski çözümlerimin scala'lardan çok daha az güçlü bir tür "miniaktör" olduğunu gördüm. Bu yüzden benim önerim oradan başlamak.

Başka bir öneri, mümkün olduğunca fazla sorunu atlamaktır: örneğin, haritaları hafızada tutmak yerine merkezi önbellek (terracotta), senkronize yöntemler yerine iç sınıf geri çağrıları kullanmak, paylaşılan hafıza yazmak yerine mesaj göndermek vb.

Scala ile zaten her şey çok daha kolay.

Hata koşullarını nasıl yeniden üretiyor ve uygulama yürütülürken neler olduğunu nasıl görüyorsunuz?

Burada gerçek bir cevap yok. Eşzamanlılık için bir birim testimiz var ve uygulamayı olabildiğince vurgulamak için bir yük testi paketimiz var.

Uygulamanın farklı eşzamanlı kısımları arasındaki etkileşimi nasıl görselleştirirsiniz?

Yine gerçek bir cevap yok: Metafor'umuzu beyaz tahta üzerinde tasarlıyoruz ve mimari tarafta hiçbir çelişki olmadığından emin olmaya çalışıyoruz.

Burada Arch için Neal Ford'un tanımını kastediyorum: Sw Mimarisi daha sonra değiştirmesi çok zor olan her şeydir.

programlama, sıralı programlama ile yaptığınızdan farklı bir zihniyete ihtiyacınız olduğuna inanmamı sağlar.

Belki ama benim için paralel bir şekilde düşünmek imkansızdır, bu yüzden yazılımımızı eşzamanlılık şeritleri arasında çarpışmalardan kaçınmak için paralel düşünme gerektirmeyen ve net korkuluklarla daha iyi tasarlayın.

Bana göre bütün veriler hakkında. Verilerinizi doğru kırın ve paralel işleme kolaydır. Tutma, kilitlenme vb. İle ilgili tüm sorunlar ortadan kalkar.

Paralelleşmenin tek yolu olmadığını biliyorum ama benim için en faydalı olanı.

(Çok hızlı değil) bir hikaye göstermek için:

2007'den 2009'a kadar büyük bir finansal (borsa kontrolü) sistemi üzerinde çalıştım ve verilerin işleme hacmi çok büyüktü. Örnek olarak, bir müşterinin tek bir hesabına yapılan tüm hesaplamalar ortalama iş istasyonlarında yaklaşık 1 ~ 3 saniye sürdü ve 30 binden fazla hesap vardı. Her gece, sistemi kapatmak kullanıcılar için büyük bir acıydı (genellikle 6 saatten fazla işlem yapıyorlardı, bunlar için herhangi bir hata payı olmadan).

Sorunu daha fazla incelemek, birkaç bilgisayar arasında hesaplamaları paralel hale getirebileceğimizi ortaya çıkardı, ancak yine de eski veritabanı sunucusunda (SQL 6.5'i taklit eden bir SQL 2000 sunucusu) büyük bir tıkanıklık yaşayacağımızı ortaya koydu.

Asgari işlem paketimizin tek hesabın hesaplanması olduğu ve belli başlı darboğazın veritabanı sunucusu alıkoyması olduğu oldukça açıktı ("aynı işlemi yapmayı bekleyen birkaç bağlantı" sp_who üzerinde görebiliyorduk). Böylece paralel süreç şöyle oldu:

1) Veri tabanını okumaktan veya üzerine yazmaktan sorumlu olan tek bir üretici. Burada eşzamanlılığa izin verilmiyor. Üretici, tüketiciler için bir iş sırası hazırladı. Veri tabanı sadece bu üreticiye aitti.

2) Birkaç tüketici, birkaç makinede. Tüketicilerin her biri, kuyruktan hesaplamaya hazır bir veri paketi aldı. Her düzenleme işlemi senkronize edilir.

3) Hesaplamadan sonra, her bir tüketici verileri devam ettirmek için verileri üreticiye bellekteki senkronize edilmiş bir kuyruğa geri gönderdi.

Birkaç kontrol noktası vardı, işlemlerin doğru şekilde kaydedilmesini sağlayan birkaç mekanizma vardı (hiçbiri geride bırakılmadı), ancak bütün çalışma buna değdi. Sonunda, 10 bilgisayar (artı üretici / sıra bilgisayarı) arasında yayılan hesaplamalar kapanma süresini tüm sistemden 15 dakikaya indirdi.

Sadece SQL eşzamanlılık yönetimi nedeniyle tutulan sorunların ortadan kaldırılması SQL 6.5 bize büyük bir avantaj sağladı. Gerisi hemen hemen doğrusaldı, "grid" e eklenen her yeni bilgisayar, veri tabanındaki sıralı okuma / yazma işlemlerinin "maksimum verimliliğine" ulaşana kadar işlem süresini kısalttı.

Çok iş parçacıklı ortamda çalışmak zordur ve kodlama disiplinine ihtiyaç duyar. Kilit almak, kilidi serbest bırakmak, global değişkenlere erişmek vb. İçin uygun yönergeleri izlemeniz gerekir.

Soruna tek tek cevap vermeye çalışayım.

* How do you figure out what can be made concurrent vs. what has to be sequential?

İçin eşzamanlılık kullan

1) Yoklama: - Sürekli olarak bir şeyi yoklamak ya da güncellemeyi düzenli olarak göndermek için bir iş parçacığına ihtiyacınız var. (Kalp atışları gibi kavramlar, merkeze sunucuya düzenli aralıklarla bazı veriler gönderdiğimi söylüyor.)

2) G / Ç'ye sahip işlemler paralel yapılabilir. En iyi örnek logger. Logger iş parçacığı ayrı bir iş parçacığı olabilir.

3) Farklı veriler üzerinde benzer görevler. Farklı verilerde gerçekleşen ancak doğada çok benzer bazı işler varsa, farklı iş parçacıkları bunu yapabilir. En iyi örnek sunucu istekleri olacak.

Ve elbette uygulama dışı olarak buna benzer pek çok kişi.

* How do you reproduce error conditions and view what is happening as the application executes?

Günlükleri ve hata ayıklama kullanarak günlükleri yazdırır. Ayrıca iş parçacığı kimliğini de günlüğe kaydetmeye çalışın, böylece her iş parçacığında neler olduğunu görebilirsiniz.
Hata durumu oluşturmanın bir yolu, sorunun gerçekleştiğini düşündüğünüz yerlere kasıtlı gecikmeyi (hata ayıklama kodunda) koymak ve zorla bu ipliği durdurmaktır. Benzer şeyler hata ayıklayıcılarda da yapılabilir, ancak şimdiye kadar yapmadım.

* How do you visualize the interactions between the different concurrent parts of the application?

Kütükleri kilitlerinize yerleştirin, böylece kimin neyi ne zaman kilitlediğini ve kimin kilitlemeyi denediğini bileceksiniz. Daha önce de söylediğim gibi, her bir başlıkta neler olup bittiğini anlamak için kütüğün kimliğini koymaya çalışın.

Bu sadece çok iş parçacıklı uygulama konusunda 3 yıla yakın bir tavsiyem ve bunun yardımcı olacağını umuyorum.

• Neyin eşzamanlı yapılabileceğini ve ardışık ne olması gerektiğini nasıl anlarsınız?

Öncelikle uygulamanın (veya bileşenin) eşzamanlı işlemden mi yoksa meslekten olmayanlar açısından bir fayda görüp görmeyeceğini sorgularım - darboğaz nerede? Eşzamanlılık açıkça çalışması için gereken yatırım için her zaman bir fayda sağlamayacaktır. Bir aday gibi görünüyorsa, o zaman aşağıdan yukarıya çalışacağım - çalışmasını etkin bir şekilde izole edebilecek en büyük işlemi veya işlem kümesini bulmaya çalışarak - önemsiz, maliyet açısından etkin olmayan konuları döndürmek istemiyorum işlemleri - Aktörler arıyorum .

Erlang ile çalışmak Eşzamanlılık için eşzamansız mesaj geçişi ve aktör modelini kullanma kavramını kesinlikle seviyorum - sezgisel, etkili ve temiz.

Off anlama Aktör eşzamanlılık

Aktör modeli birkaç temel prensipten oluşur:

• Paylaşılan durum yok
• Hafif süreçler
• Asenkron mesaj iletme
• Gelen mesajları arabelleğe almak için posta kutuları
• Desen eşleştirme ile posta kutusu işleme

Aktör, bir işlevi yerine getiren bir süreçtir. Burada bir işlem hafif bir kullanıcı-alanı dişidir (tipik bir ağır işletim sistemi işlemiyle karıştırılmamalıdır). Aktörler hiçbir zaman durumu paylaşmaz ve bu nedenle paylaşılan verilere erişim için kilitler için rekabet etmek zorunda kalmazlar. Bunun yerine, oyuncular değişmeyen mesajlar göndererek verileri paylaşırlar. Değiştirilemeyen veriler değiştirilemez, bu nedenle okumalar bir kilit gerektirmez.

Erlang eşzamanlılık modelini anlamak ve hata ayıklamak, verileri kilitlemek ve paylaşmaktan daha kolaydır. Mantığınızın izole edilme şekli, mesajlarını ileterek bileşenlerin test edilmesini kolaylaştırır.

Eşzamanlı sistemler ile çalışmak, tasarımımın herhangi bir dilde nasıl çalıştığıyla ilgilidir - birden fazla iş parçacığının verileri çekeceği, basit bir işlem gerçekleştireceği ve tekrar kuyruğa ya da tekrar çekeceği bir sıra. Erlang, yan etkileri önlemek ve yeni dişler yaratmanın maliyetini ve karmaşıklığını azaltmak için değişmez veri yapılarını zorlamaktadır.

Bu model Erlang'a özel değil, Java ve .NET dünyasında bile bunu yaratmanın yolları var - Eşzamanlılık ve Koordinasyon Çalışma Zamanı (CCR) ve Relang'a bakıyorum (Java için Jetlang da var).

• Hata koşullarını nasıl yeniden üretiyor ve uygulama yürütülürken neler olduğunu nasıl görüyorsunuz?

Tecrübelerime göre, yapabileceğim tek şey her şeyi izlemeye / kaydetmeye adanmışlık. Her işlem / iş parçacığının bir tanımlayıcı olması ve her yeni iş biriminin bir korelasyon kimliğine sahip olması gerekir. Günlüklerine bakıp tam olarak neyin işlendiğini ve ne zaman işlendiğini izleyebilmen gerekir - bunu ortadan kaldıracak bir sihir yoktur.

• Uygulamanın farklı eşzamanlı kısımları arasındaki etkileşimi nasıl görselleştirirsiniz?

Yukarıya bakın, çirkin ama işe yarıyor. Yaptığım diğer tek şey UML sıra şemalarını kullanmak - tabii ki bu tasarım süresi sırasında - ancak bileşenlerinizi de istediğiniz gibi konuştuğunu doğrulamak için bunları kullanabilirsiniz.

- Cevaplarım MS / Visual Studio'ya özgüdür -

Neyin eşzamanlı yapılabileceğini ve ardışık ne olması gerektiğini nasıl anlarsınız?

Bu etki alanı bilgisini alacak, burada ele almak için hiçbir battaniye ifadesi olmayacak.

Hata koşullarını nasıl yeniden üretiyor ve uygulama yürütülürken neler olduğunu nasıl görüyorsunuz?

Çok sayıda günlük kaydı, üretimde yakalamak için üretim uygulamalarında günlüğü açıp kapatabilir. VS2010 Intellitrace'in bu konuda yardımcı olabileceği sanılıyor, ancak henüz kullanmadım.

Uygulamanın farklı eşzamanlı kısımları arasındaki etkileşimi nasıl görselleştirirsiniz?

Buna iyi bir cevabım yok, bir tanesini görmek isterim.

C'nin eşzamanlılık için tasarlanmadığına dair ifadenize katılmıyorum. C, genel sistem programlaması için tasarlanmıştır ve alınacak kritik kararları belirtmek için bir azimiyete sahiptir ve gelecek yıllarda da bunu yapmaya devam edecektir. Bu, en iyi karar C'yi kullanmama ihtimali olsa bile geçerlidir. Ek olarak, C'deki eşzamanlılık yalnızca tasarımınızın karmaşık olduğu kadar zordur.

Elimden gelenin en iyisini yaparak, sonunda gerçek anlamda pratik kilitsiz programlamanın benim için gerçek olabileceği düşüncesiyle kilitler uygulamaya çalışıyorum . Kilitleyerek, karşılıklı dışlanma demek istemiyorum, sadece tahkim gerekmeden güvenli eşzamanlılık uygulayan bir işlem demek istiyorum. Pratik olarak, taşımaktan daha kolay olan bir şeyi kastediyorum. Çok az resmi CS eğitimi aldım, ancak dileyebilmeme izin verdiğimi sanıyorum :)

Bundan sonra, karşılaştığım hataların çoğu nispeten sığ hale geliyor ya da bir pub'a geri çekilmek için övünmekle tamamen ilgileniyorum. Pub, yalnızca bir programı profillemeye, bulmaya çalıştığım şeyle ilgili olmayan ek ırklar ortaya koymaya yetecek kadar yavaşladığında cazip bir seçenek haline geliyor.

Diğerlerinin de belirttiği gibi, tanımladığınız sorun son derece alana özgüdür. Mümkün olan her durumda (tahkim dışında) hakemlik gerektiren herhangi bir davadan kaçınmak için elimden geleni yapıyorum. Bu bir ağrı olabilir gibi gözüküyorsa, birden fazla iş parçacığı verme ya da bir şeye eşzamanlı ve seri hale getirilmemiş erişim sağlama seçeneğini yeniden değerlendiriyorum.

Sonra tekrar, oraya 'dağıtılmış' atmak ve tahkim bir zorunluluk haline gelir. Belirli bir örneğiniz var mı?

Hata koşullarını nasıl yeniden üretiyor ve uygulama yürütülürken neler olduğunu nasıl görüyorsunuz?

Uygulamanın farklı eşzamanlı kısımları arasındaki etkileşimi nasıl görselleştirirsiniz?

Tecrübelerime dayanarak, bu iki yönün cevabı şöyledir:

Dağıtılmış izleme

Dağıtılmış izleme, sisteminizin her bir eşzamanlı bileşeni için zamanlama verilerini yakalayan ve grafiksel olarak size sunan bir teknolojidir. Eşzamanlı uygulamaların temsilleri her zaman bir araya getirilir, bu da neyin paralel çalıştığını ve neyin paralel olmadığını görmenizi sağlar.

Dağıtılmış izleme, kökenlerini (elbette) tanım gereği asenkron ve çok eş zamanlı olan dağıtılmış sistemlerde borçludur. Dağıtılmış izlemeli dağıtık bir sistem, insanların şunları yapmasını sağlar:

a) önemli darboğazları tespit etmek, b) başvurunuzun ideal “çalıştırmalarının” görsel bir temsilini almak ve c) eşzamanlı davranışların yürütülmesine görünürlük sağlamak, d) uygulamanızdaki değişiklikler arasındaki farkları değerlendirmek için kullanılabilecek zamanlama verilerini elde etmek Sistem (güçlü SLA'larınız varsa çok önemlidir).

Bununla birlikte, dağıtılmış izlemenin sonuçları şunlardır:

1. Potansiyel olarak bir ağ üzerinden yürütmek ve göndermek için daha fazla koda dönüştürdüğü için tüm eşzamanlı işlemlerinize ek yük ekler. Bazı durumlarda, bu ek yük çok önemlidir - Google bile, kullanıcı deneyimini mahvetmemek için sadece kendi istek sistemlerini Dapper'ı tüm isteklerin küçük bir alt kümesinde kullanır.

2. Hepsi birbiriyle birlikte çalışamayan pek çok farklı araç var. Bu, OpenTracing gibi standartlarla biraz iyileştirildi, ancak tamamen çözülmedi.

3. Size paylaşılan kaynaklar ve mevcut durumları hakkında hiçbir şey söylemez . Uygulama kodunu ve gördüğünüz grafiğin size ne gösterdiğini temel alarak tahmin edebilirsiniz, ancak bu konuda kullanışlı bir araç değildir.

4. Mevcut araçlar, yedeklenecek hafızanız ve deponuz olduğunu varsayar. Bir zaman sunucusunu barındırmak, kısıtlamalarınıza bağlı olarak ucuz olmayabilir.

Hata izleme yazılımı

Öncelikle orada Sentry ile bağlantı kurdum, çünkü orada en yaygın kullanılan araçtı ve iyi bir nedenden dolayı - Sentry kaçırma çalışma zamanı yürütme gibi hata izleme yazılımı aynı anda merkezi bir sunucuda karşılaşılan hataların yığın izini iletmek için.

Bu tür özel yazılımların eşzamanlı koddaki net faydası:

1. Yinelenen hatalar çoğaltılmaz . Bir veya daha fazla eşzamanlı sistemlerinin aynı durum karşılaşırsanız Başka bir deyişle, Nöbetçi olacaktır artırır Bir olay raporu, ancak olayın iki kopyasını göndermeyin.

Bu, sayısız eşzamanlı hata raporundan geçmek zorunda kalmadan hangi eşzamanlı sistemin hangi hatayı yaşadığını anlayabilmeniz anlamına gelir. Dağıtılmış bir sistemden herhangi bir e-posta spamı yaşadıysanız, neye benzediğini biliyorsunuz.

Eşzamanlı sisteminizin farklı yönlerini bile 'etiketleyebilirsiniz' (bu, tam olarak tek bir iş parçacığı üzerinde işin bir araya gelmediğini varsayar; bu, teknik olarak zaten eşzamanlı olmayan bir iş olmadığı için, iş parçacığı sadece işler arasında verimli bir şekilde zıplar, ancak yine de olay işleyicileri işlemek zorundadır) tamamlamak için) ve hataların etikete göre dağılımını görün.

2. Çalışma zamanı istisnalarınızla ilgili daha fazla ayrıntı sağlamak için bu hata işleme yazılımını değiştirebilirsiniz. Sürecin hangi açık kaynakları vardı? Bu sürecin tuttuğu ortak bir kaynak var mı? Hangi kullanıcı bu sorunu yaşadı?

Bu, titiz yığın izlerine ek olarak (ve dosyalarınızın küçültülmüş bir sürümünü sağlamanız gerekiyorsa kaynak haritaları), zamanın büyük bir kısmının neyin yanlış gittiğini belirlemenizi kolaylaştırır.

3. (Sentry'e özel) Sistemin test çalışmaları için testte hatalar yakalamanıza izin veren ayrı bir Sentry raporlama panosu olabilir.

Bu gibi yazılımların dezavantajları:

1. Her şey gibi, toplu olarak eklerler. Örneğin gömülü donanımda böyle bir sistemi istemeyebilirsiniz. Bu tür bir yazılım denemesi yapmayı ve boşta çalışan bir makinede birkaç yüzün üzerinde çalışmayı örnekleyen ve olmayan basit bir yürütmeyi karşılaştırarak tavsiye ederim.

2. Tüm diller eşit olarak desteklenmemektedir, çünkü bu sistemlerin birçoğu örtük olarak bir istisna yakalamaya dayanmaktadır ve tüm diller sağlam istisnalar içermemektedir. Olduğu söyleniyor, çok sayıda sistem için müşteri var.

3. Bu sistemlerin çoğu temelde kapalı kaynaklı olduğundan, bir güvenlik riski olarak ortaya çıkabilir. Bu gibi durumlarda, onları araştırma konusundaki özeninizi yapın ya da tercih edilirse kendinizinkini kullanın.

4. Size her zaman ihtiyacınız olan bilgiyi vermeyebilirler. Bu, görünürlük eklemek için tüm girişimlerde bir risktir.

5. Bu hizmetlerin çoğu yüksek eşzamanlı web uygulamaları için tasarlanmıştır, bu nedenle her araç kullanım durumunuz için mükemmel olmayabilir.

Özetle : Görünürlük sahibi olmak, herhangi bir eşzamanlı sistemin en önemli kısmıdır. Yukarıda tarif ettiğim iki yöntem, herhangi bir zaman noktasında sistemin güncel bir görüntüsünü elde etmek için donanım ve veriler hakkındaki özel panolarla birlikte, sektörde tam olarak bu yönü ele almak için yaygın olarak kullanılmaktadır.

Bazı ek öneriler

Eşzamanlı sorunları korkunç yollarla çözmeye çalışan insanlar tarafından kod düzeltmeyi umduğumdan daha fazla zaman geçirdim. Her seferinde, aşağıdakilerin geliştirici deneyimini (kullanıcı deneyimi kadar önemlidir) büyük ölçüde geliştirebileceği durumlar buldum:

• Türlerine güveniyor . Yazma, kodunuzu doğrulamak için mevcuttur ve çalışma zamanında ekstra bir koruma olarak kullanılabilir. Yazmanın bulunmadığı yerlerde, hataları yakalamak için iddialara ve uygun bir hata işleyicisine güvenin. Eşzamanlı kod , savunma kodu gerektirir ve türler, mevcut en iyi doğrulama türü olarak görev yapar.

  • Yalnızca bileşenin kendisini değil, kod bileşenleri arasındaki bağlantıları test edin. Bunu, her bileşen arasındaki her bağlantıyı test eden tam gelişmiş bir entegrasyon testiyle karıştırmayın ve o zaman bile, yalnızca nihai durumun küresel bir onayını arar. Bu, hataları yakalamanın korkunç bir yoludur.

İyi bir bağlantı testi , bir bileşen yalıtılmış bir başka bileşenle konuştuğunda , mesajın ve gönderilen mesajın beklediğinizle aynı olup olmadığını kontrol eder. İletişim kurmak için paylaşılan bir servise dayanan iki veya daha fazla bileşeniniz varsa, hepsini toplayın, merkezi servis aracılığıyla mesaj alışverişinde bulunun ve en sonunda ne beklediğinizi alıp almadıklarını görün.

Bileşenlerin kendilerinin bir testine birçok bileşenin dahil olduğu ayrılma testleri ve bileşenlerin her birinin nasıl iletişim kurduğunun bir testi de kodunuzun geçerliliğine olan güveninizi arttırır. Böylesine titiz bir test kitlesine sahip olmak, hizmetler arasında sözleşmeleri uygulamanıza ve aynı anda çalışırken ortaya çıkan beklenmeyen hataları yakalamanıza izin verir.

• Uygulama durumunuzu doğrulamak için doğru algoritmaları kullanın. Örneğin, tüm çalışanlarının bir işi bitirmesini bekleyen bir ana süreciniz olduğunda ve sadece tüm çalışanlar tamamen yapılırsa bir sonraki adıma geçmek istediğiniz gibi, basit şeylerden bahsediyorum. Safra algoritması gibi bilinen metodolojilerin bulunduğu fesih.

Bu araçlardan bazıları, dillerle birlikte gelir - Rust, örneğin, kodunuzun derleme zamanında herhangi bir yarış koşuluna sahip olmayacağını garanti ederken, Go, derleme zamanında çalışan dahili bir kilitlenme algılayıcısına sahiptir. Üretime başlamadan önce sorunları yakalarsanız, bu her zaman bir kazançtır.

Genel bir kural: eşzamanlı sistemlerde başarısızlık için tasarım . Ortak hizmetlerin çökeceğini veya kırılacağını tahmin edin. Bu, makinelere dağıtılmayan kodlar için bile geçerlidir - tek bir makinedeki eşzamanlı kod, herhangi bir zamanda kaybolabilecek veya kaldırılabilecek harici bağımlılıklara (paylaşılan bir günlük dosyası, Redis sunucusu, lanet bir MySQL sunucusu gibi) güvenebilir .

Bunu yapmanın en iyi yolu zaman zaman uygulama durumunu doğrulamaktır - her hizmet için sağlık kontrolleri yaptırmak ve bu hizmetten tüketicilerin sağlık durumunun kötü şekilde bildirildiğinden emin olmak. Docker gibi modern konteyner araçları bunu oldukça iyi yapıyor ve işleri sanallaştırmak için kullanılmalı.

Neyin eşzamanlı yapılabileceğini ve neyin sırayla yapılabileceğini nasıl anlarsınız?

Çok eş zamanlı bir sistemde çalışmayı öğrendiğim en büyük derslerden biri şudur: Asla yeterince ölçüm alamazsınız . Metrikler uygulamanızdaki her şeyi kesinlikle kullanmalıdır - her şeyi ölçemiyorsanız bir mühendis değilsiniz.

Metrikler olmadan, birkaç önemli şey yapamazsınız:

1. Sistemdeki değişikliklerle yapılan farkı değerlendirin. Ayar A düğmesinin metrik B'nin yukarı çıkıp metrik C'nin aşağı inip girmediğini bilmiyorsanız, insanlar sisteminizde beklenmedik bir şekilde kötü niyetli kodlar bastığında sisteminizi nasıl düzelteceğinizi bilmiyorsunuz (ve sisteminize kodu itecekler) .

2. İşleri geliştirmek için yapmanız gerekenleri anlayın. Uygulamaların belleğinin azaldığını öğrenene kadar, sunucularınız için daha fazla bellek mi yoksa daha fazla disk mi almanız gerektiğini ayırt edemezsiniz.

Metrikler o kadar önemli ve önemlidir ki, bir sistemin neye ihtiyaç duyacağını bile düşünmeden önce neyi ölçmek istediğimi planlamak için bilinçli bir çaba gösterdim. Aslında, metrikler o kadar önemlidir ki , bu sorunun doğru cevabı olduklarına inanıyorum : programınızdaki bitlerin ne yaptığını ölçtüğünüzde sadece sıralı veya eşzamanlı yapılabilecek şeyleri bilirsiniz . Doğru tasarım, tahminde değil sayıları kullanır.

Olduğu söyleniyor, kesinlikle birkaç kural vardır:

1. Sıralı bağımlılığı ifade eder. Biri diğerine bağımlıysa, iki işlem sıralı olmalıdır. Bağımlılığı olmayan süreçler eşzamanlı olmalıdır. Bununla birlikte, aşağı akıştaki süreçlerin süresiz olarak beklemelerini engellemeyen arıza akışını ele almanın bir yolunu planlayın.

2. Bir G / Ç bağımlı görevini hiçbir zaman aynı çekirdekteki CPU bağlı bir görevle karıştırmayın. (Örneğin), aynı iş parçacığında on eşzamanlı istek başlatan, geldikleri anda bunları kazıyan ve beş yüze kadar ölçeklenmeyi bekleyen bir web tarayıcısı yazmayın; CPU hala seri olarak geçecek. (Bu tek iş parçacıklı olay odaklı model popüler bir modeldir, ancak bu yönü nedeniyle sınırlıdır - bunu anlamak yerine insanlar sadece ellerini sıkıyorlar ve Düğüm'ün ölçeklemediğini söylüyorlar, size bir örnek vermek için).

Tek bir diş çok fazla G / Ç çalışması yapabilir. Ancak, donanımınızın eşzamanlılığını tam olarak kullanmak için, birlikte tüm çekirdeği dolduran iş parçacıkları kullanın. Yukarıdaki örnekte, sadece CPU çalışması için beş Python işleminin (her biri altı çekirdekli bir makinede bir çekirdek kullanabilen) başlatılması ve sadece I / O çalışması için altıncı bir Python iş parçacığının düşündüğünüzden çok daha hızlı ölçeklendirilmesi.

CPU eşzamanlılığından faydalanmanın tek yolu özel bir threadpool. Tek bir iş parçacığı çoğu zaman G / Ç'ye bağlı iş için yeterince iyidir. Bu nedenle Nginx gibi olaya dayalı web sunucularının Apache'ye göre daha iyi ölçeklendirmelerine (tamamen G / Ç'ye bağlı işleri yapmalarına) neden olurlar (bu, G / Ç'ye bağlı işleri CPU gerektiren bir şeyle işler ve istek başına bir işlem başlatır), ancak neden Node'u gerçekleştirmek için Paralel olarak alınan onbinlerce GPU hesaplaması korkunç bir fikir.

Doğrulama işlemi için, büyük eşzamanlı bir sistem tasarlarken - Modeli LTSA - Etiketli Geçiş Sistemi Analizörü kullanarak test etme eğilimindeyim . Eşzamanlılık alanında usta bir şey olan ve şu an imparatorlukta bilgi işlem başkanı olan eski öğretmenim tarafından geliştirilmiştir.

Neyin eşzamanlı olabileceğini ve ne olamayacağını bulmak kadarıyla, proje yönetimi için yaptığınız gibi, kritik bölümler için zamanlama diyagramları çizme eğiliminde olduğum halde, inanıyorum ki statik analizörler var. Ardından aynı işlemi tekrarlayan bölümleri tanımlayın. Hızlı bir rota sadece döngüleri bulmaktır, çünkü paralel işlemden faydalanan alanlar olma eğilimindedirler.

Neyin eşzamanlı yapılabileceğini ve ardışık ne olması gerektiğini nasıl anlarsınız?

Yazdığınız hemen hemen her şey eşzamanlılıktan özellikle "fethetmek bir fethetmek" kullanım durumundan yararlanabilir. Çok daha iyi bir soru eşzamanlı olması gereken nedir?

Joseph Albahari'nin C # 'daki Threading'i, beş yaygın kullanımı listeler.

Çoklu kullanımın birçok kullanımı vardır; İşte en yaygın olanları:

Duyarlı bir kullanıcı arayüzü bakımı

Paralel bir "işçi" iş parçacığında zaman alan görevler çalıştırarak, ana UI iş parçacığı klavye ve fare olaylarını işlemeye devam etmek için ücretsizdir.

Aksi takdirde engellenen bir işlemciyi verimli kullanmak

Çoklu okuma, bir iş parçacığı başka bir bilgisayardan veya donanımdan bir yanıt beklerken faydalıdır. Görevi yerine getirirken bir iş parçacığı engellenmiş olsa da, diğer iş parçacığı, aksi halde yüklenmemiş bilgisayardan yararlanabilir.

Paralel programlama

Yoğun hesaplamalar yapan kod, iş yükü “böl ve yönet” stratejisinde birden fazla iş parçacığı arasında paylaşılıyorsa, çok çekirdekli veya çok işlemcili bilgisayarlarda daha hızlı çalışabilir (bkz. Bölüm 5).

Spekülatif yürütme

Çok çekirdekli makinelerde, yapılması gerekebilecek bir şeyi önceden tahmin ederek ve ardından vaktinden önce yaparak performansı iyileştirebilirsiniz. LINQPad bu tekniği yeni sorguların oluşturulmasını hızlandırmak için kullanır. Bir varyasyon, hepsi aynı görevi çözen paralel bir dizi farklı algoritma çalıştırmaktır. Hangisi önce birinciyi bitirirse “kazanır” - bu, hangi algoritmanın en hızlı şekilde uygulanacağını bilemeyeceğiniz zaman etkilidir.

İsteklerin aynı anda işlenmesine izin verme

Bir sunucuda istemci istekleri eşzamanlı olarak gelebilir ve bu nedenle paralel olarak ele alınması gerekir (ASP.NET, WCF, Web Hizmetleri veya Uzaktan Kumanda'yı kullanırsanız .NET Framework bunun için otomatik olarak iş parçacığı oluşturur). Bu aynı zamanda bir müşteride de faydalı olabilir (örneğin, eşler arası ağ bağlantısıyla - veya kullanıcıdan birden fazla istekle).

Yukarıdakilerden birini yapmayı denemiyorsanız, muhtemelen bunun hakkında gerçekten çok iyi düşünmelisiniz.

Hata koşullarını nasıl yeniden üretiyor ve uygulama yürütülürken neler olduğunu nasıl görüyorsunuz?

.NET kullanıyorsanız ve kullanım senaryoları yazdıysanız , düzeltmenizi test etmenizi sağlayan belirli bir iplik araya getirme koşullarını yeniden oluşturabilen CHESS kullanabilirsiniz .

Uygulamanın farklı eşzamanlı kısımları arasındaki etkileşimi nasıl görselleştirirsiniz?

Bu koşullara bağlıdır. İşçi senaryoları için bir yönetici-astı düşünüyorum. Manger, alt üyeye bir şey yapmasını söyler ve durum güncellemelerini bekler.

Eşzamanlı ilgisiz işler için, ayrı trafik şeritlerinde asansörler veya arabalar düşünüyorum.

Eşitleme için bazen trafik ışıklarını veya dönüş stillerini düşünüyorum.

Ayrıca C # 4.0 kullanıyorsanız, Görev Paralel Kütüphanesine bakmak isteyebilirsiniz.

Bu sorulara cevabım:

• Neyin eşzamanlı yapılabileceğini ve ardışık ne olması gerektiğini nasıl anlarsınız?

Öncelikle neden eşzamanlılık kullanmam gerektiğini bilmem gerekiyor, çünkü insanların eşzamanlılığın arkasındaki fikirden çıktıklarını ancak her zaman çözmeye çalıştıkları sorun hakkında düşünmediklerini anladım.

Kuyruklar, iş akışları vb. Gibi gerçek bir yaşam durumunu simüle etmek zorunda kalırsanız, büyük olasılıkla eşzamanlı bir yaklaşım kullanmanız gerekecektir.

Artık kullanmam gerektiğini bildiğim için, ticareti analiz etme zamanı, çok fazla işleminiz varsa, ek yükü düşünebilirsiniz, ancak yeni bir işlem yapmanız gerekiyorsa, eşzamanlı bir çözümle sonuçlanmayabilir (eğer sorunu yeniden değerlendirirseniz) yani.)

• Hata koşullarını nasıl yeniden üretiyor ve uygulama yürütülürken neler olduğunu nasıl görüyorsunuz?

Bu konuda uzman değilim ama eş zamanlı sistemler için bunun doğru yaklaşım olmadığını düşünüyorum. Kritik alanlarda 4 kilitlenme gereksinimi aranarak teorik bir yaklaşım seçilmelidir:

1. Öngörüsüzlük
2. Bekle ve bekle
3. Motifsel dışlama

4. Dairesel zincir

   • Uygulamanın farklı eşzamanlı kısımları arasındaki etkileşimi nasıl görselleştirirsiniz?

İlk önce etkileşime kimlerin katıldığını, sonra kimlerle nasıl iletişim kurduğunu belirlemeye çalışıyorum. Son olarak, grafikler ve etkileşim diyagramları görselleştirmeme yardımcı oluyor. Eski güzel beyaz tahta başka hiçbir tür medya tarafından yenilemez.

Künt olacağım. Aletlere bayılıyorum. Çok fazla alet kullanıyorum. İlk adımım, durum akışı için amaçlanan yolları belirlemektir. Bir sonraki adımım, buna değip değmeyeceğini veya gerekli bilgi akışının kodu çok sık seri hale getirip getirmeyeceğini bulmak. Sonra basit modeller çizmeye çalışacağım. Bunlar, ham kürdan heykellerinden oluşan bir yığından pitondaki bazı basit benzer örneklere kadar değişebilir. Sonra, birkaç semafor kitabı gibi, en sevdiğim kitaplarımı inceler ve birisinin sorunum için daha iyi bir çözüm bulup bulmadığını görürüm.

Sonra kodlamaya başlıyorum.
Şaka yapıyorum. İlk önce biraz daha araştırma. Bir bilgisayar korsanıyla oturmayı ve programın beklenen bir yürütmesini üst düzeyde yürütmeyi seviyorum. Sorular gelirse, daha düşük bir seviyeye çıkarız. Çözümünüzü sürdürecek kadar iyi bir başkasının çözümünü anlayabiliyor olup olmadığını anlamak önemlidir.

Sonunda kodlamaya başlıyorum. Önce çok basit tutmaya çalışıyorum. Sadece kod yolu, hiçbir şey fantezi. Mümkün olduğunca az devlet taşıyın. Yazmaktan kaçının. Yazma ile çakışabilecek okumalardan kaçının. Her şeyden önce, yazarlarla çakışabilecek yazmalardan kaçının. Olumlu bir şekilde toksik bir sayıya sahip olduğunuzu ve güzel çözümünüzün bir anda önbellek hırsızlığı yapan bir seri yaklaşımdan biraz daha fazla olduğunu bulmak çok kolaydır.

İyi bir kural, mümkün olan her yerde çerçeveleri kullanmaktır. Temel iş parçacığı bileşenlerini kendiniz yazıyorsanız, iyi senkronize edilmiş veri yapıları veya tanrıyı yasaklayan, gerçek senkronize ilkeler gibi, neredeyse tüm bacağınızı uçuracaksınız.

Sonunda araçlar. Hata ayıklama çok zor. PIN ile birlikte linux'ta valgrind \ callgrind ve pencerelerde paralel stüdyolar kullanıyorum. Bu şeyleri el ile hata ayıklamaya çalışmayın. Muhtemelen yapabilirsin. Ama muhtemelen istemeseydin dilersin. Bazı güçlü araçlara hakim olmanın on saati ve bazı iyi modeller yüzlerce saat sonra sizi kurtaracak.

Her şeyden önce, kademeli olarak çalışın. Dikkatli çalışın. Yorgunken eşzamanlı kod yazmayın. Açken yazmayın. Aslında, bundan kaçınabiliyorsanız, basitçe yazmayın. Eşzamanlılık zordur ve onu bir özellik olarak listeleyen pek çok uygulamanın çoğu zaman onunla tek özelliği olarak gönderildiğini buldum.

Özetle:
Başlayın: Konuşma Testi
düşünün Yazma sadece Okuma Testi Yazma Hata ayıklama GOTO