Ne zaman akka / erlang'da oyuncu kullanmak iyi değil?


58

Akka ile günde 7-8 aydır çalışıyorum. Başladığımda, uygulamalar üzerinde çalışacak ve çoğu oyuncunun arasında iletişim kurmak için oyuncuların temelde bir kez aktör sisteminin içinde bir yerde kullanılacağını fark edecektim. Ben de aynısını yaptım - x / y / z için başka bir oyuncu daha döndürdüm.

Bana öyle geliyor ki, bunun gereğinden fazla ayırt edilemeyeceği, ihtiyaç duyulmadığı bir yere karmaşıklık eklenmiş olabileceği anlaşılıyor - ancak oyuncuların düz eşzamanlılara karşılık gelecek zamanlar ve hatta vadeli işlemler yoluyla asenkron mantığın kullanılması gerektiği konusunda herhangi bir tartışma bulamıyorum. İş arkadaşım benzer bir şeyden bahsettikten sonra duruşumu düşünmeye başladım. Son zamanlarda bir görevi düşündüğüm ve daha sonra başka bir aktör yaratmaktan kaçındığım birkaç durumu fark ettim, çünkü aynı sonucu değişmez bir uygulamada güvenle elde edebilirim - örneğin, çok nadiren erişeceğiniz bir yerde bir db veya dosyadan yapılandırma değerleri almak gibi bir şey sonucu bekleyin gerçek kullanım durumudur.

Özellikle, bana göre, değişmez durumla oynadığınız herhangi bir durum, aktörler karmaşıklık yaratıyor ve verimi sınırlıyorlar - örneğin bir nesnede saf bir işlev, eşzamanlı olarak, herhangi bir eşzamanlılık seviyesiyle aynı anda çağrılabilir. Bir oyuncu aynı anda sadece bir mesajı işleyebilir. Alternatif mesele, geleceği kullanmaya başlamadığınız sürece sonucu beklemeniz gerekiyorsa ipliği park edersiniz, ancak zaman uyumsuz mesajlaşma ya da ölçeklendirme konusunda endişelenmenize gerek duymadığınız durumlarda, bir aktör istihdam etmenin aşırı zor olacağı düşünülür.

Yani benim sorum şu - oyuncu kullanmak için kötü bir zaman var mı? Erlang'ın nasıl göründüğünü ve diğer insanların içgörülerini gerçekten çok istediğini merak ediyorum. Ya da oyuncu kullanımıyla ilgili bazı ilkeler varsa.


Ne tür bir iş Akka ile her ay aylarca çalışmak için bir fırsat verir?
Den

3
İyi olanlar. :) Veya değişikliği kendiniz yapın.
JasonG

Özellikle askbir oyuncu seçmek ve sadece bir ova kullanmak arasındaki dengenin ne olduğunu bilmek isterdim Future.
Max Heiber

2
Birkaç yıl sonra Akka hakkında bir kitap yazdım ve şöyle özetleyebileceğimi düşünüyorum: Eğer bir durumunuz varsa - örneğin bir sayaç varsa - bu değerden okuma / yazma çok sayıda konu birbirinin üzerinde durur senkronizasyon ve kilitleme olmadan. Bu durumu bir oyuncunun içine koyarsanız, aniden güvenli bir şekilde eriştiğinden ve yazmayı bırakmadığınızdan veya eski okumalar almadığınızdan emin olabilirsiniz. Erlang ve akka'daki aktörler de devletin kötü gidebileceğini ve oyuncu kendi kendine iyileşen sistem özelliklerine sahip olmanız için hatalar atabileceğini varsayıyor.
Mutasyona

yıllar sonra ben bir erlang / iksir programcı ve ben :) yeni bilgiler sayesinde buna geri gelmesini sağlayacak İhtiyacınız olduğunda işlemler her zaman inşa edilir, böylece işlemlere alternatif olarak hiçbir nesne olduğu gibi İksir oldukça farklıdır devlet . Sadece eşzamanlı olur. Bu hala en iyi sezgisel buluşma.
JasonG

Yanıtlar:


23

Bu ilgilendiğim bir soru ve üzerinde biraz araştırma yapıyorum. Diğer bakış açıları için, Noel Walsh'un bu blog gönderisine veya Yığın Taşması ile ilgili bu soruya bakın . Sunmak istediğim bazı görüşlerim var:

  • Bence Akka, mesajlarla çalıştığı için "itme zihniyetini" teşvik ediyor. Sık sık, eşzamanlılık için, istediğin şeyin bu olmadığını iddia ediyorum. Çekmek çok daha güvenli. Örneğin, dağıtılmış sistemler için ortak bir model , bir kuyruğa bilgi işleyen bir dizi işçiye sahip olmaktır . Açıkçası bu Akka'da mümkün, ancak mutlaka insanların denediği ilk yaklaşım gibi görünmüyor . Akka, dayanıklı posta kutuları da sunar, ancak yine de onları nasıl kullandığınıza bağlıdır - tek bir paylaşılan sıra, iş dengeleme / yeniden atama için çalışan sıralarına göre çok daha esnektir.
  • Sınıflarınızı oyuncularla değiştirmenin zihniyetine girmek kolaydır. Aslında, bazı insanlar bile oyuncuların sadece bir şey yapması gerektiğini söyleyerek savunuculuğa benziyorlar . Mantıklı bir sonuç alındığında, bu Jason'ın tanımladığı gibi kod karmaşıklığını arttırır, çünkü her sınıf bir oyuncu ise, bu çok fazladan fazla mesaj alır ve blok alır / gönderir. Ayrıca, kodu anlamayı ve test etmeyi zorlaştırır, çünkü arayüzlerin formalitesini yitirirsiniz - ve yorumların bunun için bir çözüm olduğuna ikna olmadım . Ayrıca Akka'nın efsanevi verimliliğine rağmen , oyuncunun yayılmasının iyi bir fikir performansı olmadığını düşünüyorum - Java ipliklerini kullandığımızda değerli olduklarını biliyoruz ve onları buna göre koruyoruz.
  • Bir önceki nokta ile ilgili, ancak başka bir sıkıntı Noel ve Pino'nun vurguladığı tür bilgilerinin kaybolması, çoğumuz için olduğu gibi Python gibi diğer dillerden ziyade Scala kullanıyoruz. Bunu aşmak için bazı yolları vardır ama bunlar ya standart dışı , değil tavsiye veya deneysel .
  • Sonunda eşzamanlılık, "çökmesine izin ver" zihniyetiniz olsa bile zordur. Alternatif programlama modelleri yardımcı olabilir, ancak sorunları ortadan kaldırmazlar - değiştirirler - bu yüzden onları resmi olarak düşünmek iyidir . Ayrıca, Joe Average geliştiricisinin RabbitMQ, Storm, Hadoop, Spark, Kafka veya NoSQL veritabanları gibi hazır araçlara ulaşmasının nedeni de budur. Akka, bazı serin önceden oluşturulmuş araçlara ve bileşenlere sahip, ancak oldukça düşük seviyede hissediyor, bu nedenle dağıtılmış sistemlerin daha hazır inşa edilmiş ortak elemanları geliştiricilere yardımcı olacak ve sistemlerin doğru yapılmasını sağlayacak.

Jason gibi ben de burada başkalarının görüşlerini duymak istiyorum. Yukarıdaki sorunlardan bazılarını nasıl ele alabilirim ve Akka'yı daha iyi kullanabilirim?


1
Bu yazı Akka spot-on testinde bulundu timgilbert.wordpress.com/2013/07/07/…
Mark Butler

Bağımlılık enjeksiyonunda "kalıtımsal kompozisyon" hala faydalıdır. Örneğin, bağımlılığı sahne olarak iletin (yapıcı paramları kullanır). O zaman sorun denetleme olur - yaratılan oyuncu, oyuncu dışında başka bir yerde denetlenir. Bir yönlendirici, üst düzeyde yaratılan aktörlerin etrafına bir denetim stratejisi sarmak için kullanılabilir, ancak bu şimdi oldukça karmaşıktır! Sanırım pasta daha iyi bir çözüm olurdu - örneğin bir db servis oyuncusu için oyuncu oluşturma konusunda bir özelliği var. Sonra sadece metin bağlamında bir test mock / stub db servis özelliğini kullanın.
JasonG

1
Evet, aynen - denetleme bağımlılık enjeksiyonunda iyi çalışmıyor. Ayrıca sınıftan ziyade bir fabrika enjekte etmenin gerekli olduğu durumlar vardı, aksi halde garip kapatma problemleri vardı - Akka'nın iplik işlemesi nedeniyle tahmin ediyorum.
Mark Butler

Bunun kötü bir fikir olmadığını düşünüyorum - teşekkürler işareti - Bu konuda biraz yazmaya ve sosyalleşmeye çalışabilirim. Sahne'ye belki veren bir şey enjekte edebilirsin? Bir aktör fabrikası, tüketicinin aktörü başlatabileceği bir tür fabrika. örn. def method (arg) = bu (psuedo?) fabrikadan Props (yeni ActorWithArgs (arg)) döndürür, böylece aktörü doğru bağlamda yapabilirsiniz. Bu da di için pasta çözümleri için iyi bir fikir ve iyi bir hedef gibi görünüyor.
JasonG

Bu kursu izlemeye yeni başladım: coursera.org/course/posa Öncelikle Android'i programlayan insanlara yönelik olmasına rağmen, aynı zamanda Java'da eşzamanlılık hakkında da iyi bir genel bakış. Yani merak ettiğim tek şey "Akka, bazı zillerle ve ıslıklarla sadece olayların süslü bir biçimi değil midir (çünkü farklı iş parçacıklarına olay döngüleri koyabilirsiniz)?"
Mark Butler

21

Aktör modelinin ne için kullanıldığı göz önünde bulundurulmaya değer: aktör modeli

  1. eşzamanlılık modeli
  2. değişken duruma eşzamanlı erişimi engelleyen
  3. eşzamanlılık sağlamak için eşzamansız iletişim mekanizmalarını kullanmak.

Bu değerlidir, çünkü birden fazla iş parçacığından paylaşılan durumun kullanılması, özellikle paylaşılan durumun senkronize edilmesi gereken farklı bileşenleri arasındaki ilişkiler olduğunda, gerçekten zorlaşır. Ancak, etki alanı bileşenleriniz varsa:

  • Eşzamanlılığa izin vermiyorsunuz, VEYA
  • Değişken duruma izin veremezsiniz (işlevsel programlamadaki gibi), VEYA
  • Bazı senkron iletişim mekanizmalarına güvenmelisiniz,

o zaman aktör modeli (varsa) fayda sağlamamaktadır.

Umarım yardımcı olur.


Teşekkürler - Sanırım o zaman iki şeyi değerlendirmek zorundasın - değişken devlet ve eşzamanlılık? Bir sınıfın vatansız olması veya eşzamanlı olmaması durumunda çözülecek sorun yok Bir değerlendirme daha - Bence hata toleransı başka bir nokta mı? Örneğin, değişmez bir redis istemciniz varsa ancak çalışırken başarısız olabilir - bu iyi bir kullanım örneği olmaz mıydı? bu oyuncuyu yeniden başlatmak gerekebilir? Zira - sınıf tamamen değişmez olsa da - değişmez aktörün dışında bozuk bir durumun olması, başarısız olmasına neden olabilir.
JasonG 28:13

Sanırım redis ile iletişim kurmaktan sorumlu olan aktör istisna olur ve yeniden başlar.
JasonG 28:13

@JasonG Aklıma göre, "hata toleransı" genel olarak oyuncu modelinin bir yönü değil - Erlang'daki (ve belki de Akka?) Oyuncu modelinin uygulanmasıyla gelen bir şey. Redis ile konuşamıyorum, itiraf etmeliyim ki, "değişmez müşteri" bana garip geliyor ... Bir yazılım bileşeni başarısız olursa, bunun nasıl değişken sayılabileceğini göremiyorum.
Aidan Cully

Akkada hata toleransı ve denetimi var ve erlang'a çok benziyor. Değişmez müşteri hakkında ne söylediğinizi anlıyorum ama değişmez, kod durumunun hiçbir yerde değişmediği anlamına gelir. Başlangıçta bir bağlantı başlatırsam, müşteri kodunun herhangi bir hata türünde kullanılan yeniden başlatma stratejisi ile değiştirilemez olması olasıdır, bir sorunla karşılaşıldığında aktörü yeniden başlatmanız yeterlidir.
JasonG.

12

Sezginiz doğru, IMHO. Oyuncuları her yerde kullanmak meşhur çekiçlere sahip olmak ve sadece çivileri görmek gibidir.

Erlang'ın en iyi uygulaması, aynı anda gerçekleşen tüm etkinlikler için süreçleri / aktörleri kullanmaktır. Bu, tıpkı gerçek hayatta olduğu gibi. Bazen doğru ayrıntı derecesini bulmak zordur, ancak çoğu zaman sadece modellenmiş alana bakarak ve biraz sağduyu kullanarak bilirsiniz. Korkarım bundan daha iyi bir yöntemim yok, ama umarım yardımcı olur.


Harika teşekkürler. Bu tartışmada ne olacağını görmekle gerçekten ilgileniyorum.
JasonG

0

Sipariş girişi / çıkışı mesajlaşma:

Geçenlerde aktör modelinin aslında eşzamanlılık sorunlarına neden olduğu akka tabanlı bir uygulama ile tanıştım, daha basit bir model yük altında daha iyi olurdu.

Sorun, gelen mesajların farklı 'şeritlerde' (farklı aktör yolları aracılığıyla) hareket etmesiydi ancak kod, mesajların geldikleri sırayla son hedeflerine ulaşacağını varsayıyordu. Veriler yeterince geniş aralıklarla geldiği sürece bu işe yaradı, çünkü hedefe yarışan sadece tek bir çakışan mesaj olacaktı. Aralıklar düştüğünde sıra dışı gelmeye ve tuhaf davranışlara neden olmaya başladılar.

Sorun, daha az aktörle doğru bir şekilde çözülebilirdi, ancak aşırı doldururken yapmak kolay bir hata.


Bu temeldir ve yaygın olarak ilgilidir. Yalnızca iki oyuncu arasında sipariş vermeyi garanti edebilirsiniz. doc.akka.io/docs/akka/current/scala/general/… Fan / in kullandığınız herhangi bir sistemde sipariş teslimini garanti edemezsiniz. andreasohlund.net/2012/01/18/dont-assume-message-ordering
JasonG

-1

Bence Aktörler için iki kullanım durumu var. Limanlar ve benzerleri gibi paylaşılan kaynaklar ve büyük devlet. İlki şu ana kadarki tartışmalarla iyi bir şekilde ele alındı, ancak büyük devlet de geçerli bir neden.

Her prosedür çağrısında geçirilen büyük bir yapı çok fazla yığın kullanabilir. Bu durum ayrı bir işleme sokulabilir, yapı bir işlem kimliği ile değiştirildi ve bu işlem istenildiği şekilde sorgulandı.

Mnesia gibi veritabanları, sorgulama işlemine dışarıdan devlet depolama olarak düşünülebilir.


1
Açıklayabilir misin? Ağda büyük devlet mi demek istiyorsun? Yerel bir süreç içinde değişmez bir yapıya yapılan bir referansı geçmek neredeyse hiçbir maliyeti yoktur ve değişken yapıları geçemezsiniz. Göndermek için kopyalanması gereken büyük bir değişken yapı hakkında konuştuğunuzu varsayalım. Yani bu temelde yine aynı şey - paylaşılan durum. Boyut gerçekten hiçbir şeyi değiştirmez. Yanlış anlıyorsam bana haber ver.
JasonG,

Peki referans olarak nasıl geçersiniz? Elbette, bunu yapmanın yolu yapıyı bir sürece sokmak ve işlemden geçirmektir. Yerel aramalar veriyi yığına koyacaktır ve her özyinelemeli çağrı tekrar yapacaktır (kuyruk özyinelemesi hariç). Yapının özyinelemeli işlemi, bir çağrıdan diğerine durum aktarımı için listeler kullanılarak yapılabilir, bu durum daha sonra diğer işlemdeki yapıya referans verebilir.
Tony Wallace
Sitemizi kullandığınızda şunları okuyup anladığınızı kabul etmiş olursunuz: Çerez Politikası ve Gizlilik Politikası.
Licensed under cc by-sa 3.0 with attribution required.