Mengapa Akka bagus untuk konkurensi?


9

Saya baru mengenal Akka dan kerangka aktor - Saya yakin saya kehilangan sesuatu yang jelas, mohon terima permintaan maaf saya sebelumnya.

Saya terus membaca bahwa salah satu poin utama untuk memilih Akka adalah cara mengelola konkurensi.

Tidak jelas bagi saya mengapa Akka begitu istimewa; Saya mengerti bahwa ada banyak aktor kecil yang sangat ringan dan cepat; namun, bagaimana ini bisa membantu saya ketika dua pengguna menyimpan formulir pada saat yang sama?

Bukankah saya masih memerlukan semacam kunci konkurensi (pesimistis / optimis / dll.)?


Apakah Anda bertanya mengapa aktor baik untuk konkurensi atau khusus Akka?
scriptin

Wouldn't I still need some sort of concurrency lock (pessimistic/optimistic/etc..)?- Ya, tapi itu tanggung jawab RDBMS yang mendasarinya, bukan aktor. Sangat mungkin aktor Akka tidak berbicara dengan pengguna Anda secara langsung. Sebaliknya, aktor Akka dan pengguna (aktor lain, pada dasarnya) keduanya berinteraksi dengan database, secara langsung.
Robert Harvey

Jawaban:


7

Salah satu keuntungan dari model pemrosesan pesan seperti aktor dan agen adalah bahwa masalah konkurensi tradisional (terutama sinkronisasi negara bersama) tidak lagi menjadi masalah. Aktor dapat menyimpan status pribadi dan memperbaruinya secara bebas tanpa kunci. Kerangka kerja aktor memastikan bahwa hanya satu pesan yang diproses pada satu waktu. Dengan pemrosesan serial, kode dapat ditulis dengan cara bebas kunci.

Dalam contoh Anda pengguna menyimpan formulir, dengan asumsi aktor menyimpan Daftar beberapa data dari setiap formulir, aktor dapat memperbarui daftar tanpa kunci, karena kerangka kerja menjamin bahwa hanya satu formulir yang akan diproses pada satu waktu. Secara tradisional, Anda harus mengunci akses Daftar atau menggunakan daftar bersamaan.

Strategi concurrency adalah masalah yang sedikit berbeda dan masih menjadi tanggung jawab Anda (tanpa strategi menjadi strategi yang paling umum). Untuk sedikit mengubah contoh Anda, misalkan kedua pengguna mencoba memperbarui contoh formulir SAMA sekaligus. Tanpa strategi konkurensi, perubahan seseorang akan menimpa yang lain (mungkin yang terakhir menang). Tidak apa-apa, tetapi paling tidak ini menghasilkan perilaku tak terduga untuk pengguna yang perubahannya ditimpa. Jika mereka melihat formulir yang baru saja mereka ubah, itu akan memiliki nilai yang tidak terduga (dari pengguna lain). Paling buruk (ketika kita tidak hanya berbicara tentang pembaruan formulir, tetapi hal-hal seperti pesanan pengiriman) dapat menyebabkan berbagai jenis kerugian (waktu, pendapatan, dll.).

Menggunakan strategi konkurensi membantu mengidentifikasi kasus-kasus ini dan dapat menyelesaikannya berdasarkan aturan bisnis. Misalnya, Optimistis Concurrency meminta pengguna mengirimkan versi formulir yang sedang diperbarui. Ketika aktor pergi untuk memproses perubahan, ia melihat bahwa pengguna ke-2 berpikir itu memperbarui Versi 5 ketika formulir sebenarnya di Versi 6 karena pembaruan pengguna pertama. Sekarang setidaknya kami dapat memberi tahu pengguna ke-2 bahwa formulir telah berubah sejak mereka mulai mengeditnya. Atau aturan apa pun yang ingin ditegakkan bisnis di sana.

Dalam hal memperbarui formulir, Anda mungkin tidak terlalu peduli tentang concurrency (tergantung, saya kira). Tetapi dalam kasus lain, mungkin merupakan hal yang sangat penting untuk setidaknya dapat memeriksa dan menangani pelanggaran. Anda bahkan mungkin ingin mengabaikan pelanggaran konkurensi, seperti jika pengguna mengubah bagian yang berbeda (untuk melanjutkan analogi formulir). Atau jika perubahan memiliki dampak besar pada bisnis (pesanan besar), Anda ingin menerimanya dan menyelesaikan konflik kecil nanti (mis. Pembaruan info kontak tahunan belum selesai).

Saya percaya Akka memiliki sejumlah dimensi lain seperti bagaimana menangani kegagalan, pengawas, dll. Yang merupakan pertimbangan penting bagi para devops.


9

Saya akan menulis tentang Model Aktor secara umum (bukan hanya Akka) dibandingkan dengan model konkurensi lainnya seperti konkurensi berbasis kunci klasik dan memori transaksional yang rapi.

Keuntungan

  1. Konsep yang lebih mudah dipahami dan digunakan

    • Konkurensi berbasis kunci sulit; khususnya sangat sulit untuk memperbaikinya karena ada banyak konsep untuk dipahami dan digunakan agar benar dan efisien: kunci, semaphores, utas, sinkronisasi, saling pengecualian, hambatan memori dll.

    • Aktor, di sisi lain adalah konsep yang lebih abstrak; Anda memiliki aktor yang mengirim dan menerima pesan. Tidak perlu memahami dan menggunakan konsep tingkat rendah seperti penghalang memori.

  2. Menegakkan kekekalan

    • Mutability adalah sumber dari banyak kesalahan dan bug dalam pemrograman, terutama dalam aplikasi multi-threaded. Model aktor menyelesaikan masalah ini dengan menegakkan imutabilitas.
  3. Lebih sedikit kesalahan

    • Karena dua alasan di atas
  4. Efisien

    • Tidak begitu efisien sebagai berbasis penguncian tertulis tetapi secara umum lebih efisien daripada memori transaksional perangkat lunak.
  5. Mudah terukur

    • Paling tidak secara teoritis, aplikasi harus skala cukup baik dengan menambahkan lebih banyak aktor untuk melakukan pekerjaan Anda. Dengan kunci berbasis cukup sulit untuk skala.

Kekurangan

  1. Tidak semua bahasa dengan mudah menegakkan ketetapan;

    • Erlang, bahasa yang menjadi aktor pertama yang dipopulerkan, memiliki inti yang tetap, tetapi Java dan Scala (sebenarnya JVM) tidak menegakkan keabadian.
  2. Masih cukup rumit

    • Aktor didasarkan pada model pemrograman asinkron yang tidak begitu lurus ke depan dan mudah dimodelkan dalam semua skenario; sangat sulit untuk menangani kesalahan dan skenario kegagalan.
  3. Tidak mencegah kebuntuan atau kelaparan

    • Dua aktor bisa berada di negara bagian yang menunggu pesan satu dari yang lain; dengan demikian Anda memiliki jalan buntu seperti halnya kunci, meskipun jauh lebih mudah untuk di-debug. Dengan memori transaksional namun Anda dijamin bebas dari kebuntuan.
  4. Tidak begitu efisien

    • Karena imutabilitas yang dipaksakan dan karena banyak aktor harus beralih menggunakan aktor thread yang sama tidak akan seefisien concurrency berbasis kunci.

Kesimpulan

Konkurensi berbasis kunci adalah yang paling efisien tetapi sulit untuk diprogram dan rawan kesalahan; memori transaksional perangkat lunak adalah yang paling jelas, mudah diprogram dan lebih sedikit kesalahan tetapi juga paling tidak efisien. Aktor berada di antara dua model ini dengan semua aspek: kemudahan pemrograman, efisiensi, dan rawan kesalahan.


Untuk keuntungan nomor 2 Anda, bukankah seharusnya " Mutabilitas adalah sumber dari banyak kesalahan ..." dan "... memecahkan masalah ini dengan melarang mutabilitas " daripada " immutabilitas "? Juga, kalimat kedua memiliki dua menyebutkan redundan untuk menyelesaikan masalah.
8bittree

@ 8bittree Yap, Anda benar; saya salah eja. Jika Anda tidak tahu, Anda dapat mengedit jawaban untuk memperbaiki masalah tersebut.
m3th0dman

Saya sadar akan hal itu, saya hanya enggan melakukan perubahan yang membalikkan atau secara drastis mengubah makna sesuatu seandainya ada kesalahpahaman di pihak saya.
8bittree

Bisakah Anda menguraikan kebuntuan? Sepertinya Anda harus membuat pengaturan aktor yang sangat canggung (komunikasi dua arah) untuk menemukan itu. Jika Anda menggunakan pola gaya bertanya (A meminta B untuk menjawab, B memproses permintaan dan membalas ke pengirim permintaan tetapi tidak pernah menghubungi A secara langsung) Saya tidak melihat bagaimana kebuntuan mungkin terjadi
Daenyth

1
@Daenyth Saya setuju bahwa Anda harus menggunakan konstruksi aneh untuk mencapai kebuntuan dengan aktor; tetapi dari perspektif yang sama Anda harus menggunakan konstruksi aneh untuk mencapai kebuntuan dengan konkurensi berbasis kunci (meskipun saya setuju itu jauh lebih mudah untuk membuat kebuntuan dengan mutex daripada dengan aktor). Bagaimanapun, idenya adalah bahwa hanya memori transaksional yang menjamin bahwa Anda tidak dapat memiliki jalan buntu, apa pun konstruk aneh yang Anda pilih untuk diterapkan.
m3th0dman
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.