Dengan akka ada beberapa bahan tentang Habré. Saya memutuskan untuk menerjemahkan beberapa antipattern yang dijelaskan oleh Manuel di blog-nya. Mereka mungkin benar-benar tidak jelas bagi orang yang pertama kali menemukan kerangka kerja.
Terpikir oleh saya bahwa saya belum menulis tentang anti-pola yang sangat sering ini. Ini sering ditemukan dalam kode pengembang yang baru mulai bekerja dengan model aktor.
Ada dua cara untuk mendapatkan terlalu banyak aktor:
- telah mengembangkan sistem dengan berbagai jenis aktor, banyak di antaranya tidak diperlukan
- membuat sejumlah besar aktor dalam runtime ketika tidak diperlukan dan tidak efisien
Mari kita lihat opsi-opsi ini secara rinci.
Terlalu banyak jenis aktor
Gagasan umumnya adalah seperti ini: "kita memiliki aktor, jadi semuanya harus menjadi aktor."
Model aktor menyederhanakan penulisan aplikasi asinkron. Itu melakukan ini dengan memberikan ilusi eksekusi kode sinkron di dalam aktor - tidak perlu khawatir tentang akses bersamaan ke keadaan satu aktor, karena hanya aktor yang dapat mengakses statusnya, dan pesan diproses satu per satu, pada gilirannya.
Namun nyatanya, tidak semuanya perlu dilakukan secara serempak. Pemanggilan metode yang secara eksklusif dikaitkan dengan CPU (dan tidak "diblokir" dalam arti bahwa mereka tidak sepenuhnya membebani CPU, misalnya, menghitung nilai Pi), tidak boleh dilakukan secara tidak sinkron.
Saya cukup sering melihat kode dengan sejumlah besar aktor yang berbeda berinteraksi satu sama lain dan tidak melakukan apa-apa, yang memiliki keuntungan besar dalam eksekusi asinkron atau simultan. Dalam proyek-proyek ini, negara yang sama harus disimpan oleh masing-masing aktor ini atau dikirimkan kepada mereka dalam setiap pesan.
Pendekatan ini memiliki dua kelemahan:
"Kau tidak mendapatkan apa-apa dari segi kinerja." Sebaliknya, ada overhead yang terkait dengan pembuatan pesan dan transmisi mereka.
- Dengan masing-masing jenis aktor dan pesan terkait, sistem menjadi lebih sulit untuk dipahami dan dipelihara.
Oleh karena itu, ketika merancang sistem aktor, Anda perlu memikirkan apa yang seharusnya tidak sinkron, pada dasarnya ini:
- panggilan ke sistem eksternal (di luar jvm Anda)
- panggilan untuk memblokir operasi (API usang, komputasi berat, ...)
Terlalu banyak aktor dalam runtime
Gagasan umumnya adalah seperti ini: "semakin banyak aktor yang kita miliki, semakin cepat segalanya berjalan."
Sebenarnya, aktornya ringan, dan
Anda bisa menjalankan jutaan dari mereka dalam satu mesin virtual . Ya kamu bisa. Tetapi apakah itu perlu?
Jika Anda bisa, itu tidak berarti Anda harus melakukannya
Jawaban singkat: tidak selalu - itu tergantung pada apa yang Anda lakukan dengan para aktor.
Jika sistem Anda memiliki banyak aktor berumur panjang, yang masing-masing berisi sedikit keadaan, dan berinteraksi satu sama lain dari waktu ke waktu, Anda mungkin bersama satu juta aktor - dan ini adalah kasus penggunaan yang sah, sangat didukung oleh Akka. Misalnya, Anda dapat membuat sistem dengan sejumlah besar pengguna, di mana setiap pengguna diwakili oleh aktor. Aktor murni Akka hanya membutuhkan 300 byte memori, jadi sangat mungkin untuk membuat jutaan pada satu mesin dan membuat mereka bekerja tanpa khawatir tentang apa pun. Dan jika pada akhirnya Anda membuat banyak aktor atau aktor dengan kekayaan besar sehingga mereka tidak lagi sesuai dengan memori satu mesin, cluster sharding akan menyederhanakan distribusi aktor di beberapa mesin.
Namun, jika Anda memiliki beberapa jenis aktor yang terlibat dalam menghitung sesuatu - misalnya, mengurai dokumen XML - diragukan untuk membuat jutaan aktor seperti itu (itu tidak masalah secara langsung atau melalui router).
Prosesor memiliki sejumlah inti (utas perangkat keras) yang dapat digunakan, dan aktor Akka memproses pesan dalam Konteks Eksekusi berdasarkan pada kumpulan utas. Secara default, ini adalah fork-join-executor berdasarkan ForkJoinPool yang ditambahkan di Java 7.
Namun, terlepas dari keunggulan teknisnya, forkjoinpool bukanlah sihir yang membatalkan hukum fisika. Jika Anda memiliki satu juta aktor, yang masing-masing mem-parsing dokumen XML (sudah dimuat ke dalam memori) dan 4 utas perangkat keras, sistem tidak akan bekerja jauh lebih baik daripada jika Anda hanya memiliki 4 aktor yang mem-parsing dokumen XML ini (saat kondisi beban homogen). Faktanya, sistem Anda akan bekerja jauh lebih baik dengan 4 aktor karena hanya akan ada sedikit overhead dalam hal perencanaan dan manajemen memori. Omong-omong, jika sistem Anda hanya memiliki beberapa aktor, periksa kumpulan utas Anda, yang mungkin mencoba menggunakan kembali utas yang sama untuk aktor yang sama.
Secara umum, sistem tidak akan bekerja lebih cepat jika Anda membuat banyak aktor.
Aktor Stateless
Aktor berorientasi objek dengan benar (tidak seperti, katakanlah, objek di Jawa): keadaannya tidak terlihat dari luar, dan mereka berkomunikasi melalui pesan. Tidak mungkin untuk memecahkan enkapsulasi, karena Anda tidak dapat melihat keadaan aktor selama pekerjaannya. Ini adalah keseluruhan poin aktor: mereka memberi Anda ilusi ruang aman di mana pesan dieksekusi secara berurutan, satu demi satu, memungkinkan Anda untuk menggunakan keadaan yang bisa berubah di dalam aktor Anda tanpa khawatir tentang kondisi balapan (kondisi lomba - sekitar Per). (Ya, hampir tanpa khawatir: yang utama adalah tidak membiarkan negara bocor).
Itulah sebabnya penggunaan aktor yang tidak memiliki negara agak aneh, untuk sedikitnya. Dengan pengecualian aktor yang mengontrol pengamatan sebagian besar hierarki sistem aktor (misalnya, mengatur pengawas cadangan), aktor benar-benar dirancang untuk bekerja dengan perhitungan panjang yang memiliki status. Berbicara panjang, maksud saya bahwa aktor akan memproses beberapa pesan sepanjang hidupnya, menghasilkan hasil yang berbeda tergantung pada kondisinya, yang bertentangan dengan perhitungan satu kali. Bagi mereka, futures adalah abstraksi yang hebat: mereka memungkinkan eksekusi kode asinkron, ideal untuk kasus-kasus bekerja dengan jaringan atau komputasi yang terkait dengan disk (atau tugas prosesor yang benar-benar intens), dapat disusun dan memiliki mekanisme pemrosesan kegagalan. Mereka juga berintegrasi dengan baik dengan aktor Akka (menggunakan pola pipa).
Secara umum: jangan gunakan aktor jika Anda tidak memiliki negara - mereka tidak dimaksudkan untuk ini.