Kasing penggunaan yang bagus untuk Akka [ditutup]


605

Saya telah mendengar banyak mengoceh tentang kerangka kerja Akka (platform layanan Java / Scala), tetapi sejauh ini belum melihat banyak contoh aktual dari kasus penggunaan itu akan baik untuk. Jadi saya akan tertarik untuk mendengar tentang hal-hal yang berhasil digunakan pengembang.

Hanya satu batasan: tolong jangan sertakan kasus penulisan server obrolan. (mengapa? karena ini telah digunakan secara berlebihan sebagai contoh untuk banyak hal serupa)


10
Bukankah lebih mudah untuk memulai dengan masalah dan menemukan solusi untuk itu, daripada memiliki solusi dan mencari masalah untuk menerapkannya? Dugaan saya adalah bahwa alih-alih menggunakan RMI, Akka dan aktornya terlihat lebih mudah / sederhana untuk menulis kode.
Kennet

67
Ya, jika saya memiliki masalah khusus untuk dipecahkan. Saya tidak mencari "alasan untuk menggunakan Akka" dengan cara apa pun, tetapi saya tertarik untuk belajar sedikit lebih banyak. Ini mungkin membantu menyelesaikan masalah di masa depan juga, tetapi sebagian besar untuk proses pembelajaran yang sedang berlangsung.
StaxMan

Ada pertanyaan terkait tetapi tentang penerapan AKKA untuk aplikasi yang ada + beberapa kasus penggunaan: stackoverflow.com/questions/16595685/…
ses

2
Akka adalah solusi yang lebih baik daripada JMS atau sistem antrian pesan yang didistribusikan gaya MQ. Itulah cara terbaik untuk memahaminya bagi diri saya sendiri yang baru-baru ini mengajukan pertanyaan yang sama persis: "Saya mengerti bagaimana menggunakannya dan melihat di mana saya bisa menggunakannya, tetapi saya tidak bisa melihat di mana ini akan memberikan keuntungan nyata". Asumsi desain inti di belakang Akka jauh lebih baik daripada di belakang JMS / MQ, khususnya mengenai isolasi proses, desain tanpa kunci, dan coba lagi / kegagalan penanganan. Kedua, API jauh lebih elegan daripada alat JMS / MQ.
user2684301

2
@ user2684301 hmmh. Saya menemukan jawaban itu agak tidak adil, dalam cara apel ke jeruk. MQ adalah (secara logis) blok bangunan sederhana yang jauh lebih sedikit daripada Akka, dan saya tidak akan membandingkannya berdampingan. Tapi saya kira jika saya membacanya sebagai "dibandingkan dengan sistem terdistribusi yang dibangun menggunakan JMS, ditulis secara deklaratif" maka itu akan lebih masuk akal.
StaxMan

Jawaban:


321

Saya telah menggunakannya sejauh ini dalam dua proyek nyata dengan sangat sukses. keduanya berada dalam bidang informasi lalu lintas real-time (lalu lintas seperti dalam mobil di jalan raya), didistribusikan melalui beberapa node, mengintegrasikan pesan antara beberapa pihak, sistem backend yang dapat diandalkan. Saya belum bebas untuk memberikan spesifik tentang klien, ketika saya mendapatkan OK mungkin dapat ditambahkan sebagai referensi.

Akka benar-benar berhasil dalam proyek-proyek itu, meskipun kami mulai ketika itu pada versi 0.7. (Omong-omong, kami menggunakan scala)

Salah satu keuntungan besar adalah kemudahan di mana Anda dapat menyusun sistem dari aktor dan pesan dengan hampir tidak ada boilerplating, itu menskala dengan sangat baik tanpa semua kompleksitas threading linting tangan dan Anda mendapatkan pesan asinkron melewati antara objek hampir gratis.

Ini sangat baik dalam memodelkan semua jenis penanganan pesan asinkron. Saya lebih suka menulis semua jenis sistem layanan (web) dengan gaya ini daripada gaya lainnya. (Apakah Anda pernah mencoba untuk menulis layanan web asinkron (sisi server) dengan JAX-WS? Itu banyak pipa ledeng). Jadi saya akan mengatakan sistem apa pun yang tidak ingin menggantung pada salah satu komponennya karena semuanya secara implisit disebut menggunakan metode sinkron, dan bahwa satu komponen mengunci sesuatu. Ini sangat stabil dan solusi kegagalan + pengawas let-it-crash + benar-benar berfungsi dengan baik. Semuanya mudah diatur secara program dan tidak sulit untuk unit test.

Lalu ada modul tambahan yang luar biasa. Modul Camel benar-benar terhubung dengan baik ke Akka dan memungkinkan pengembangan layanan asinkron yang mudah dengan titik akhir yang dapat dikonfigurasi.

Saya sangat senang dengan frameworknya dan ini menjadi standar de facto untuk sistem terhubung yang kami bangun.


14
Apa manfaat dari pendekatan ini dibandingkan dengan menggunakan backend perpesanan (mis. ActiveMQ) untuk menyampaikan pesan menurut pendapat Anda?
magiconair

27
Produk MQ benar-benar untuk kasus penggunaan yang berbeda. jaminan berbeda dan kinerja sangat berbeda. Produk MQ membutuhkan banyak pengaturan, Anda tidak akan menggunakan antrian dalam produk seperti itu dengan cara yang sama seperti Anda akan menggunakan objek. Aktor adalah warga negara kelas satu di akka, Anda menggunakannya sesuka hati, mirip dengan bagaimana Anda akan menggunakan objek, jadi ada jauh lebih sedikit overhead di kedua model pemrograman Anda seperti di setup. Produk MQ yang akan Anda gunakan lebih banyak untuk diintegrasikan dengan sistem eksternal lain, bukan untuk membangun 'internal' sistem, yang merupakan sesuatu yang ingin Anda gunakan untuk aktor.
Raymond Roestenburg

26
URL baru untuk studi kasus DBP adalah downloads.typesafe.com/website/casestudies/…
Bas

2
Membangun @RaymondRoestenburg re: sistem dan alternatif MQ. RabbitMQ, misalnya, dibangun di atas bahasa pemrograman berbasis aktor, Erlang. Itu salah satu cara untuk memikirkan hubungan (dan perbedaan) antara aktor dan MQ. Sementara Apache Spark bukan berbasis pekerja dan antrian atau berbasis Aktor, TETAPI dapat digunakan dengan Akka: Typesafe menunjukkan cara menggunakan Spark Streaming dengan Akka .
driftcatcher

6
@RaymondRoestenburg Anda lupa menyebutkan bahwa model Actor as-is mempromosikan struktur seperti spaghetti. Buku "Akka in Action" yang Anda tulis adalah demonstrasi terbaik untuk "fitur" ini. Contoh kode menangani cerita yang cukup mendasar. Namun alur kerja sangat sulit untuk dipahami dan diikuti dari kode. Masalah terkait adalah bahwa kode Akka akan IRREVERSIBLY di seluruh logika bisnis Anda dengan cara yang paling mengganggu yang dapat Anda bayangkan. Jauh lebih banyak daripada kerangka kerja non-aktor lainnya. Tidak mungkin untuk menulis alur kerja dasar tanpa membedahnya menjadi beberapa bagian terpisah.
buka

222

Penafian: Saya PO untuk Akka

Selain menawarkan smorgasbord konkurensi yang jauh lebih mudah untuk dipikirkan dan diperbaiki (aktor, agen, konkurensi dataflow) dan dengan kontrol konkurensi dalam bentuk STM.

Berikut beberapa kasus penggunaan yang dapat Anda pertimbangkan:

  1. Pemrosesan transaksi (game online, keuangan, statistik, taruhan, media sosial, telekomunikasi, ...)
    • meningkatkan, meningkatkan, toleransi kesalahan / HA
  2. Backend layanan (industri apa pun, aplikasi apa pun)
    • layanan REST, SOAP, cometd dll
    • bertindak sebagai hub pesan / lapisan integrasi
    • meningkatkan, meningkatkan, toleransi kesalahan / HA
  3. Konkurensi / paralelisme snap-in (aplikasi apa pun)
    • Benar
    • Mudah digunakan dan dimengerti
    • Cukup tambahkan toples ke proyek JVM Anda yang sudah ada (gunakan Scala, Java, Groovy atau JRuby)
  4. Pemrosesan batch (industri apa saja)
    • Integrasi unta untuk dihubungkan dengan sumber data batch
    • Aktor membagi dan menaklukkan beban kerja batch
  5. Hub komunikasi (telekomunikasi, media web, media seluler)
    • meningkatkan, meningkatkan, toleransi kesalahan / HA
  6. Server game (game online, taruhan)
    • meningkatkan, meningkatkan, toleransi kesalahan / HA
  7. BI / datamining / general purpose crunching
    • meningkatkan, meningkatkan, toleransi kesalahan / HA
  8. masukkan case use bagus lainnya di sini

10
Saya memahami manfaat Futures dan STM tetapi tidak menemukan kasus penggunaan yang baik untuk para aktor. Untuk server permainan atau taruhan, apa keuntungan menggunakan Aktor vs beberapa server aplikasi di belakang load balancer?
Martin Konicek

8
@ViktorKlang POs! = Tek Teknologi. Mereka bekerja bersama, tetapi berbeda peran.
taylorcressy

79

Contoh cara kami menggunakannya adalah pada antrian prioritas transaksi kartu debit / kredit. Kami memiliki jutaan ini dan upaya pekerjaan tergantung pada tipe string input. Jika transaksi bertipe CHECK, kami memiliki sedikit pemrosesan tetapi jika ini merupakan titik penjualan maka ada banyak yang harus dilakukan seperti menggabungkan dengan data meta (kategori, label, tag, dll) dan menyediakan layanan (peringatan email / sms, deteksi penipuan, saldo dana rendah, dll). Berdasarkan tipe input, kami membuat kelas dari berbagai sifat (disebut mixin) yang diperlukan untuk menangani pekerjaan dan kemudian melakukan pekerjaan. Semua pekerjaan ini masuk ke antrian yang sama dalam mode realtime dari berbagai lembaga keuangan. Setelah data dibersihkan, data dikirim ke penyimpanan data yang berbeda untuk kegigihan, analitik, atau didorong ke koneksi soket, atau untuk Mengangkat aktor komet. Aktor yang bekerja terus-menerus menyeimbangkan pekerjaan sehingga kita dapat memproses data secepat mungkin. Kami juga dapat memanfaatkan layanan tambahan, model ketekunan, dan untuk poin keputusan kritis.

Pesan gaya Erlang OTP lewat JVM membuat sistem yang bagus untuk mengembangkan sistem waktu nyata di pundak perpustakaan dan server aplikasi yang ada.

Akka memungkinkan Anda untuk melakukan message passing seperti pada tradisional tapi dengan kecepatan! Ini juga memberi Anda alat dalam kerangka kerja untuk mengelola sejumlah besar aktor kolam, node jarak jauh, dan toleransi kesalahan yang Anda butuhkan untuk solusi Anda.


1
Jadi apakah adil untuk mengatakan bahwa itu adalah kasus (beberapa) permintaan latensi panjang, di mana utas tunggal per permintaan tidak akan dapat diukur dengan baik?
StaxMan

7
Saya pikir bagian penting dari pemrograman aktor pada umumnya adalah aliran pesan. Setelah Anda mulai membuat konsep dalam aliran data yang tidak memiliki efek samping, Anda hanya ingin sebanyak mungkin aliran terjadi per node. Ini jauh berbeda dari High Performance Computing seandainya Anda memiliki pekerjaan semi homogen yang tidak mengirim pesan dan membutuhkan waktu lama untuk diproses. Saya pikir implementasi Fibonacci berbasis aktor adalah contoh yang sangat terbatas karena tidak menunjukkan mengapa menggunakan aktor tetapi hanya aktor yang melumpuhkan pengambilan. Pikirkan arsitektur yang digerakkan oleh Peristiwa untuk kasus penggunaan.
Wade Arnold

4
Arsitektur berbasis peristiwa adalah cara berpikir yang berbeda tentang masalah. Sebaiknya baca Erlang OTP in Action dari manning jika Anda berpikir tentang pengkodean di Akka. Banyak konstruksi dalam akka dipengaruhi oleh Erlang OTP dan buku ini memberi Anda prinsip mengapa Jonas Boner membangun akka api seperti yang dilakukannya. Akka adalah gunung besar tempat Anda berdiri! Jika aktor Anda gigih melalui perubahan negara, Anda benar-benar membutuhkan 10rb menulis yang kedua berkelanjutan
Wade Arnold

8
Wade, bagaimana kalian menangani jaminan pesan? Anda menyebutkan: (peringatan email / sms, deteksi penipuan, saldo dana rendah, dll), saya menganggap ini berpotensi dikirim ke pelaku jarak jauh? Bagaimana Anda memastikan operasi itu benar-benar terjadi? bagaimana jika simpul gagal saat memproses peringatan penipuan? Apakah sudah hilang selamanya? Apakah Anda memiliki sistem yang pada akhirnya konsisten yang membersihkannya? Terima kasih!
James

2
Pertanyaan bagus, James. Jelas bahwa itu cocok dalam suatu sistem di mana balasan tidak diperlukan segera. Misalnya Anda dapat memproses tagihan kartu kredit; menghitung; kirim e-mail dll. Saya benar-benar ingin tahu bagaimana hal-hal ini (transaksi) ditangani ketika balasan dibutuhkan. Pada akhirnya; jika permintaan dibuat dari eksternal (pengguna internet; perwakilan dari pusat panggilan, dll.); dia menunggu balasan. Bagaimana saya bisa yakin bahwa sub tugas (yang dieksekusi async) dieksekusi; dalam transaksi xa sehingga saya bisa membalas balasan?
Kaan Yy

44

Kami menggunakan Akka untuk memproses panggilan REST secara tidak sinkron - bersama dengan server web async (berbasis Netty) kami dapat mencapai peningkatan 10 kali lipat pada jumlah pengguna yang dilayani per node / server, dibandingkan dengan thread tradisional per model permintaan pengguna.

Katakan kepada bos Anda bahwa tagihan hosting AWS Anda akan turun dengan faktor 10 dan itu adalah no-brainer! Shh ... jangan katakan itu ke Amazon ... :)


3
Dan saya lupa menyebutkan bahwa sifat monadik dari akka futures, yang mengarah pada kode paralel yang jauh lebih bersih menyelamatkan kita ribuan dalam pemeliharaan kode ...
piotrga

8
Saya menganggap panggilan adalah latensi tinggi, throughput rendah? Suka melakukan panggilan ke server lain, menunggu respons (proxy)?
StaxMan

38

Kami menggunakan Akka dalam proyek Telco skala besar (sayangnya saya tidak bisa mengungkapkan banyak detail). Akka aktor digunakan dan diakses dari jarak jauh oleh aplikasi web. Dengan cara ini, kami memiliki model RPC yang disederhanakan berdasarkan pada protobuffer Google dan kami mencapai paralelisme menggunakan Akka Futures. Sejauh ini, model ini telah bekerja dengan sangat baik. Satu catatan: kami menggunakan Java API.


Bisakah Anda memberi tahu kami lebih banyak? Afaik Futures tidak dapat dikirim melalui kawat (serial). Apakah Anda menggunakan banyak masa depan dan beberapa aktor atau campuran antara keduanya atau ...? Anda menggunakan protobuf untuk semua serialisasi dan mengirim sebagai pesan ke aktor?
Aktau

Sepertinya ini bisa ditangani dengan mudah tanpa Akka.
Erik Kaplun

1
TDC adalah perusahaan Telco dalam kasus Fiaddesio.
Roman Kagan

37

Jika Anda mengabstraksi server obrolan naik tingkat, maka Anda mendapatkan jawabannya.

Akka menyediakan sistem pengiriman pesan yang mirip dengan mentalitas Erlang "let it crash".

Jadi contohnya adalah hal-hal yang membutuhkan berbagai tingkat daya tahan dan keandalan pesan:

  • Server obrolan
  • Lapisan jaringan untuk MMO
  • Pompa data keuangan
  • Sistem pemberitahuan untuk iPhone / seluler / aplikasi apa pun
  • SISA Server
  • Mungkin sesuatu yang mirip dengan WebMachine (tebak)

Hal-hal baik tentang Akka adalah pilihannya untuk kegigihan, implementasi STM, server REST dan toleransi kesalahan.

Jangan jengkel dengan contoh server obrolan, anggap itu sebagai contoh kelas solusi tertentu.

Dengan semua dokumentasi mereka yang sangat bagus, saya merasa ada celah dalam pertanyaan, kasus penggunaan dan contoh yang tepat ini. Ingatlah bahwa contoh-contohnya tidak sepele.

(Ditulis dengan hanya pengalaman menonton video dan bermain dengan sumbernya, saya tidak menerapkan apa pun menggunakan akka.)


2
Terima kasih - saya tidak bermaksud server obrolan selalu buruk, hanya saja saya ingin contoh pelengkap; lebih mudah mendapatkan ide potensi yang lebih baik.
StaxMan

Ingin tahu bagaimana server REST cocok di sini? Apakah Anda menyebutkannya dalam konteks server async gaya Node.js? Terima kasih telah membagikan contoh kasus penggunaan. Saya menemukan mereka berguna.
software.wikipedia

24

Kami menggunakan Akka di beberapa proyek di tempat kerja, yang paling menarik terkait dengan perbaikan kecelakaan kendaraan. Terutama di Inggris tetapi sekarang berkembang ke AS, Asia, Australasia, dan Eropa. Kami menggunakan aktor untuk memastikan bahwa informasi perbaikan kecelakaan diberikan secara real-time untuk memungkinkan perbaikan kendaraan yang aman dan efektif biaya.

Pertanyaan dengan Akka sebenarnya lebih 'apa yang tidak bisa kamu lakukan dengan Akka'. Kemampuannya untuk berintegrasi dengan kerangka kerja yang kuat, abstraksi yang kuat, dan semua aspek toleransi kesalahan menjadikannya alat yang sangat komprehensif.


Jadi aspek mana yang paling Anda sukai jika Anda harus memilih? Integrasi yang ada untuk kerangka kerja lain, toleransi kesalahan otomatis, atau yang lainnya?
StaxMan

6
Dari sudut pandang pribadi, ini adalah level abstraksi yang diangkat yang dibawa Akka ke meja yang paling saya sukai. Dari perspektif perusahaan itu adalah kemampuan integrasi. Harus mencari nafkah dan Akka meliput bisnis dan kesenangan keduanya dengan sangat baik :-)
rossputin

Bisakah Anda menguraikan bagaimana aliran pesan? Apakah pengguna adalah orang di bengkel dan memasukkan detail tentang kerusakan ke dalam bentuk http dan kemudian mengirim data ke server. Apakah ini membuat pesan yang ditangani oleh akka? Untuk melakukan apa dengan pesan ini? Ekstrak informasi yang dimasukkan untuk menanyakan database dan kemudian antri balasan untuk mengirimnya kembali ke web-frontend?
surfmuggle

24

Anda dapat menggunakan Akka untuk beberapa hal.

Saya sedang mengerjakan sebuah situs web, tempat saya memigrasikan tumpukan teknologi ke Scala dan Akka. Kami menggunakannya untuk hampir semua yang terjadi di situs web. Meskipun Anda mungkin berpikir bahwa contoh Obrolan itu buruk, semua pada dasarnya sama:

  • Pembaruan langsung di situs web (mis. Tampilan, suka, ...)
  • Menampilkan komentar pengguna langsung
  • Layanan pemberitahuan
  • Cari dan semua jenis layanan lainnya

Terutama pembaruan langsung mudah karena mereka turun ke apa yang contoh Chat dulu. Bagian layanan adalah topik menarik lainnya karena Anda dapat memilih untuk menggunakan aktor jarak jauh dan bahkan jika aplikasi Anda tidak dikelompokkan, Anda dapat menyebarkannya ke mesin yang berbeda dengan mudah.

Saya juga menggunakan Akka untuk aplikasi autorouter PCB dengan gagasan untuk dapat skala dari laptop ke pusat data. Semakin banyak kekuatan yang Anda berikan, semakin baik hasilnya. Ini sangat sulit diterapkan jika Anda mencoba menggunakan konkurensi biasa karena Akka juga memberi Anda transparansi lokasi.

Saat ini sebagai proyek waktu luang, saya sedang membangun kerangka web hanya menggunakan aktor. Sekali lagi manfaatnya adalah skalabilitas dari satu mesin ke seluruh sekelompok mesin. Selain itu, menggunakan pendekatan berbasis pesan membuat layanan perangkat lunak Anda berorientasi sejak awal. Anda memiliki semua komponen yang bagus itu, berbicara satu sama lain tetapi tidak harus saling mengenal, hidup di mesin yang sama, bahkan di pusat data yang sama.

Dan karena Google Reader ditutup, saya mulai dengan pembaca RSS, menggunakan Akka tentu saja. Ini semua tentang layanan enkapsulasi bagi saya. Sebagai kesimpulan: Model aktor itu sendiri adalah apa yang harus Anda adopsi terlebih dahulu dan Akka adalah kerangka kerja yang sangat andal yang membantu Anda menerapkannya dengan banyak manfaat yang akan Anda terima di sepanjang jalan.


Halo Joe, dapatkah Anda menjelaskan bagaimana pesan digunakan untuk memperbarui situs? Apakah Anda memiliki satu sistem untuk pembuat konten; dia membuat artikel baru dan klik simpan. Apakah ini membuat pesan yang dikirim ke beberapa server yang menangani lalu lintas masuk. Setiap server memproses pesan pembaruan sesegera mungkin. Setiap permintaan browser baru kemudian mendapatkan versi halaman yang diperbarui? Terima kasih
surfmuggle

18

Kami menggunakan akka dengan plugin untanya untuk mendistribusikan analisis dan pemrosesan tren kami untuk twimpact.com . Kami harus memproses antara 50 dan 1000 pesan per detik. Selain pemrosesan multi-simpul dengan unta, ia juga digunakan untuk mendistribusikan pekerjaan pada prosesor tunggal ke beberapa pekerja untuk kinerja maksimum. Bekerja cukup baik, tetapi membutuhkan pemahaman tentang bagaimana menangani kemacetan.


apakah Anda juga menggunakan toleransi kesalahan Akka?
Erik Kaplun

Bagaimana dengan Spark Streaming jika kami memiliki akses ke cluster Spark?
skjagini

18

Saya mencoba tangan saya pada Akka (Java api). Apa yang saya coba adalah membandingkan model konkurensi berbasis aktor Akka dengan model konkurensi Java biasa (kelas java.util.concurrent).

Kasus penggunaan adalah peta kanonik sederhana mengurangi implementasi jumlah karakter. Dataset adalah kumpulan string yang dihasilkan secara acak (panjang 400 karakter), dan menghitung jumlah vokal di dalamnya.

Untuk Akka saya menggunakan BalancedDispatcher (untuk load balancing di antara utas) dan RoundRobinRouter (untuk menjaga batas pada aktor fungsi saya). Untuk Java, saya menggunakan teknik fork join sederhana (diimplementasikan tanpa algoritma mencuri pekerjaan) yang akan memetakan / mengurangi eksekusi dan menggabungkan hasilnya. Hasil antara diadakan dalam memblokir antrian untuk membuat sambungan sejajar mungkin. Mungkin, jika saya tidak salah, itu akan meniru konsep "kotak surat" aktor Akka, di mana mereka menerima pesan.

Pengamatan: Hingga beban menengah (~ input string 50000) hasilnya sebanding, sedikit berbeda dalam iterasi yang berbeda. Namun, ketika saya menambah beban saya ke ~ 100000, itu akan menggantung solusi Java. Saya mengkonfigurasi solusi Java dengan 20-30 utas di bawah kondisi ini dan gagal di semua iterasi.

Meningkatkan muatan menjadi 10.000, juga berakibat fatal bagi Akka. Saya dapat berbagi kode dengan siapa pun yang tertarik untuk melakukan pemeriksaan silang.

Jadi bagi saya, tampaknya Akka lebih baik daripada solusi multithreaded Java tradisional. Dan mungkin alasannya adalah sihir Scala di bawah tenda.

Jika saya bisa memodelkan domain masalah sebagai pesan yang didorong oleh peristiwa lewat satu, saya pikir Akka adalah pilihan yang baik untuk JVM.

Tes dilakukan pada: Versi Java: 1.6 IDE: Eclipse 3.7 Windows Vista 32 bit. Ram 3GB. Prosesor Intel Core i5, kecepatan clock 2,5 GHz

Harap dicatat, domain masalah yang digunakan untuk pengujian dapat diperdebatkan dan saya mencoba untuk bersikap adil sejauh pengetahuan Java saya diizinkan :-)


3
"Aku bisa membagikan kodenya dengan siapa saja yang tertarik melakukan cross check." Saya ingin jika Anda tidak keberatan.
n1r3

3
Saya juga ingin kode itu, dapatkah Anda memposting tautan github?
Gautam

Terima kasih atas minat Anda. Sayangnya saya memiliki beberapa masalah dalam menyiapkan repo github. Jika Anda bisa memberi saya email Anda, saya bisa mengirimkan kode sumber. Dan menyesal atas jawaban yang terlambat!
sutanu dalui

@sutanudalui Anda masih punya kodenya, kalau begitu saya bisa membagikan email saya?
Jay

16

Kami menggunakan Akka dalam sistem dialog yang diucapkan ( primetalk ). Baik secara internal maupun eksternal. Untuk secara bersamaan menjalankan banyak saluran telepon pada satu node cluster, jelas perlu memiliki beberapa kerangka kerja multithreading. Akka bekerja dengan sempurna. Kami memiliki mimpi buruk sebelumnya dengan java-concurrency. Dan dengan Akka itu seperti ayunan - itu hanya bekerja. Kuat dan dapat diandalkan. 24 * 7, tanpa henti.

Di dalam saluran kami memiliki aliran peristiwa waktu-nyata yang diproses secara paralel. Khususnya: - pengenalan ucapan otomatis yang panjang - dilakukan dengan aktor; - produsen output audio yang mencampur beberapa sumber audio (termasuk ucapan yang disintesis); - Konversi teks-ke-suara adalah seperangkat aktor terpisah yang dibagi di antara saluran; - pemrosesan semantik dan pengetahuan.

Untuk membuat interkoneksi dari pemrosesan sinyal yang kompleks, kami menggunakan SynapseGrid . Ini memiliki keuntungan dari pemeriksaan waktu kompilasi DataFlow dalam sistem aktor yang kompleks.


14

Saya baru-baru ini menerapkan contoh pengurangan peta kanonik di Akka: Jumlah kata. Jadi ini adalah salah satu kasus penggunaan Akka: kinerja yang lebih baik Itu lebih merupakan eksperimen aktor JRuby dan Akka daripada yang lain, tetapi juga menunjukkan bahwa Akka bukan Scala atau Java saja: ini bekerja pada semua bahasa di atas JVM.


Apakah Anda tahu apa yang bertanggung jawab untuk kinerja yang lebih baik (dan juga dibandingkan dengan alternatif mana)? Apakah itu karena menggunakan JRuby di JVM (vs Ruby asli), skalalibiliy karena I / O non-blocking atau yang lainnya?
StaxMan

2
Perbandingan yang saya tulis adalah: Jruby berurutan VS Jruby dengan aktor. Oleh karena itu, satu-satunya hal yang dapat bertanggung jawab untuk eksekusi lebih cepat adalah partisipasi para aktor. Tidak ada I / O yang berpartisipasi dalam percobaan (file dimuat dari disk, tetapi dilakukan sebelum penghitung waktu benchmark diatur).
Daniel Ribeiro

Saya baru-baru ini menerapkan contoh pengurangan peta juga, tapi itu hanya vanilla java github.com/chaostheory/jibenakka
chaostheory
Dengan menggunakan situs kami, Anda mengakui telah membaca dan memahami Kebijakan Cookie dan Kebijakan Privasi kami.
Licensed under cc by-sa 3.0 with attribution required.