Чому Акка хороша для одночасності?

Я новачок у програмі Akka та актора - я впевнений, що мені не вистачає чогось очевидного, будь ласка, прийміть мої вибачення заздалегідь.

Я продовжую читати, що одним із головних моментів вибору Акки є спосіб управління паралельністю.

Мені незрозуміло, чому Акка така особлива; Я розумію, що є багато маленьких акторів, які дуже легкі і швидкі; проте як мені це допомогти, коли два користувачі зберігають форму одночасно?

Чи не все-таки мені знадобиться якесь блокування одночасності (песимістичне / оптимістичне / тощо)?

Однією з переваг моделей обробки повідомлень, таких як актори та агенти, є те, що традиційні проблеми одночасності (насамперед синхронізація спільного стану) вже не є проблемою. Актор може зберігати приватну державу та вільно її оновлювати без замків. Рамка актора забезпечує, що за один раз обробляється лише одне повідомлення. При серіалізованій обробці код можна записати без замкненого способу.

У вашому прикладі, коли користувачі зберігають форму, припускаючи, що актор зберігає Перелік деяких даних з кожної форми, актор може оновити список без блокування, оскільки рамка гарантує, що одночасно буде оброблена лише одна форма. Традиційно вам доведеться замкнути доступ до списку або використовувати паралельний список.

Стратегія кон'юнктури - дещо інша справа, і все одно ви відповідаєте (при цьому жодна стратегія не є найбільш поширеною стратегією). Щоб трохи змінити ваш приклад, скажімо, що обидва користувачі намагаються одночасно оновити екземпляр форми SAME. Без стратегії одночасності зміни однієї замінять іншу (ймовірно, остання виграє). Це добре, але в кращому випадку це призводить до несподіваної поведінки для користувача, зміни якого були перезаписані. Якщо вони переглянуть форму, яку вони просто змінили, вона матиме несподівані значення (від іншого користувача). У гіршому випадку (коли ми говоримо не лише про оновлення форми, а про такі речі, як замовлення на доставку), це може призвести до різного роду втрат (часу, доходу тощо).

Використання стратегії паралельної валюти допомагає виявити ці випадки та мати можливість їх вирішити на основі правил бізнесу. Наприклад, Optimistic Concurrency має надіслати користувачем версію оновленої форми. Коли актор йде на обробку зміни, він помічає, що другий користувач думає, що вона оновлює версію 5, коли форма фактично є у версії 6 через оновлення першого користувача. Тепер принаймні ми можемо повідомити другого користувача про те, що форма вже змінилася з моменту її редагування. Або будь-які правила, які бізнес хоче там застосовувати.

Що стосується оновлення форми, то, ймовірно, не так сильно піклується про одночасність (я думаю, залежить). Але в інших випадках може бути дуже важливою справою принаймні мати можливість перевіряти та вирішувати порушення. Ви навіть можете ігнорувати порушення одночасності, наприклад, якщо користувачі змінили різні розділи (щоб продовжити аналогію форми). Або якщо зміна має великий вплив на бізнес (велике замовлення), ви хочете прийняти його та вирішити незначні конфлікти пізніше (наприклад, щорічне оновлення контактної інформації не завершено).

Я вважаю, що Акка має ряд інших аспектів, таких як, як вона справляється з невдачами, наглядачами тощо.

Я збираюся писати про Акторську модель взагалі (не тільки Акку) порівняно з іншими моделями одночасності, такими як класична паралельність на основі блокування та акуратна операційна пам'ять.

Переваги

1. Простіша концепція для розуміння та використання

   • Паралельність на основі блокування є складною; зокрема, дуже важко це правильно зрозуміти, оскільки існує багато понять, які потрібно зрозуміти та використовувати для правильності та ефективності: замки, семафори, нитки, синхронізація, взаємне виключення, бар'єр пам’яті тощо.

   • Актори, з іншого боку, є більш абстрактним поняттям; у вас є актори, які надсилають та отримують повідомлення. Не потрібно розуміти та використовувати такі поняття низького рівня, як бар'єр пам'яті.

2. Забезпечує незмінність

   • Змінюваність - це джерело багатьох помилок і помилок у програмуванні, особливо у багатопотокових програмах. Акторська модель вирішує це питання, забезпечуючи незмінність.

3. Менше схильних до помилок

   • Через дві вищезгадані причини

4. Ефективний

   • Не настільки ефективна, як хороша письмова блокування, але в цілому більш ефективна, ніж транзакційна пам'ять програмного забезпечення.

5. Легко масштабується

   • Принаймні теоретично, додаток має бути досить масштабним, додаючи більше акторів для виконання вашої роботи. З використанням замків досить складно масштабувати.

Недоліки

1. Не всі мови легко застосовують незмінність;

   • Ерланг, мова, яка вперше популяризувала дійових осіб, незмінна в основі, але Java та Scala (фактично JVM) не примушують до незмінність.

2. Ще досить складний

   • Актори базуються на асинхронній моделі програмування, яку не так просто вперед і легко моделювати у всіх сценаріях; особливо важко обробляти помилки та сценарії відмов.

3. Не запобігає тупиковість або голодування

   • Два суб'єкти можуть перебувати в стані, які чекають повідомлення один від одного; таким чином, у вас є глухий кут, як і з замками, хоча набагато простіше налагоджувати. З транзакційною пам’яттю, проте, вам гарантовано відсутній тупик.

4. Не так ефективно

   • Через насильницьку незмінність та через те, що багатьом акторам доводиться переходити на використання одних і тих же ниток, актори не будуть настільки ефективними, як паралельність на основі блокування.

Висновок

Паралельність на основі блокування є найбільш ефективною, але її важко запрограмувати та схильну до помилок; транзакційна пам'ять програмного забезпечення є найбільш зрозумілою, легкою для програмування та схильністю до менших помилок, але також є найменш ефективною. Актори знаходяться десь між цими двома моделями з усіма аспектами: простотою програмування, ефективністю та схильністю до помилок.