Коли НЕ добре використовувати акторів в акка / ерланг?

Я працюю з аккою вже 7-8 місяців щодня. Коли я починав, я працював над додатками і зауважував би, що актори використовуються в основному де-небудь всередині акторської системи для спілкування між більшістю об'єктів. Так що я зробив те саме - закрутив іншого актора на х / у / з.

Мені здається, що це може бути занадто безрозбірливим, додаючи складності там, де це не потрібно - але я не можу знайти жодних дискусій щодо того, де слід використовувати акторів проти простої синхронної або навіть асинхронної логіки через ф'ючерси. Я почав обмірковувати свою позицію після того, як мій колега згадав щось подібне. Нещодавно я зрозумів декілька випадків, коли я розмірковував над завданням, а потім ухилявся від створення іншого актора, тому що міг би досягти такого ж результату безпечно в незмінному виконанні - наприклад, щось на зразок отримання значень конфігурації з db або файлів десь, куди ви звертаєтесь дуже рідко і будете чекати результату - це фактичний випадок використання.

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

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

Це питання, яке мене цікавить, і я займався деякими дослідженнями. Для інших точок зору дивіться цю публікацію в блозі Ноеля Уолша або це запитання на стеку Overflow. У мене є кілька думок, які я хотів би запропонувати:

• Я думаю, що Акка, оскільки він працює з повідомленнями, заохочує "просунути розум". Часто, для паралельності, я б заперечував, що це не те, чого ви хочете. Потягнути набагато безпечніше. Наприклад, одна поширена схема для розподілених систем - це набір працівників, що обробляють інформацію в черзі . Очевидно, що це можливо в Akka, але це не обов'язково здається, що це перший підхід, який люди намагаються . Akka також пропонує довговічні поштові скриньки, але знову ж таки, залежить від того, як ви їх використовуєте - одна загальна черга набагато гнучкіша, ніж на черги працівників для балансування / повторного призначення роботи.
• Легко ввійти в розум замінити свої заняття акторами. Насправді деякі люди навіть, здається, виступають за це, кажучи, що актори повинні робити лише одне . Згідно з логічним висновком, це збільшує складність коду, як описує Джейсон, адже якщо кожен клас є актором, це багато зайвих повідомлень і блоків прийому / відправки. Це також ускладнює розуміння та тестування коду, оскільки ви втрачаєте формальність інтерфейсів - і я не переконаний, що коментарі є рішенням цього . Також, незважаючи на легендарну ефективність Акки , я підозрюю, що розповсюдження акторів - це не дуже гарна ідея продуктивності - коли ми використовуємо теми Java, ми знаємо, що вони дорогоцінні, і зберігаємо їх відповідно.
• Це пов’язано з попереднім пунктом, але ще одне роздратування - це втрата інформації про тип, яку виділяють Ноель і Піно, як для багатьох з нас, тому ми використовуємо Scala, а не інші мови, такі як Python. Існують деякі способи цього, але вони або нестандартні , не рекомендуються, ні експериментальні .
• Нарешті, паралельність, навіть якщо у вас є розум "нехай це впаде" , важко. Альтернативні моделі програмування можуть допомогти, але вони не змушують проблем зникати - вони змінюють їх - ось чому добре про них подумати формально . Ось чому розробник Joe Average досягає готових інструментів, таких як RabbitMQ, Storm, Hadoop, Spark, Kafka або NoSQL. У Akka є кілька попередньо вбудованих інструментів та компонентів, що класно, але він також відчуває себе досить низьким, тому більш готові побудовані загальні елементи розподілених систем допоможуть розробникам та забезпечать, щоб системи були побудовані правильно.

Як і Джейсон, я хочу почути тут прозріння інших людей. Як я можу вирішити деякі вищезазначені проблеми та краще використовувати Akka?

Варто подумати, для чого використовується модель актора: модель актора

1. модель одночасності
2. що дозволяє уникнути одночасного доступу до змінного стану
3. використання асинхронних механізмів зв'язку для забезпечення одночасності.

Це цінно тим, що використання спільного стану з декількох потоків стає дуже важким, особливо коли є зв'язки між різними компонентами спільного стану, які повинні зберігатися синхронізованими. Однак якщо у вас є компоненти домену, у яких:

• Ви не дозволяєте одночасності, АБО
• Ви не дозволяєте змінювати стан (як у функціональному програмуванні), АБО
• Ви повинні покластися на якийсь механізм синхронного зв'язку,

тоді модель актора не дасть великої (якщо є) вигоди.

Сподіваюся, що це допомагає.

Ваша інтуїція правильна, ІМХО. Використовувати акторів скрізь - це як мати прислівний молоточок і бачити лише цвяхи.

Найкраща практика Ерланга - використовувати процеси / дійових осіб для всіх видів діяльності, які відбуваються одночасно. Тобто, як і в реальному житті. Іноді важко знайти потрібну деталізацію, але більшість випадків ви просто знаєте, переглядаючи модельований домен та використовуючи трохи здорового глузду. Боюся, у мене немає кращого методу, ніж це, але сподіваюся, що це допоможе.

Для введення / виводу повідомлень:

Нещодавно я познайомився з додатком на основі акки, де модель актора насправді викликала проблеми з одночасністю, а простіша модель була б достатньою для навантаження.

Проблема полягала в тому, що вхідні повідомлення рухалися різними «смугами» (різними контурами акторів), але код передбачав, що повідомлення надійдуть до їх кінцевого пункту в тому ж порядку, в якому вони надійшли. Поки дані надходили з досить великими інтервалами, це спрацьовувало, тому що до пункту призначення буде лише одне конфліктне повідомлення. Коли інтервали скоротилися, вони почали виходити з ладу і викликати дивну поведінку.

Проблему можна було б вирішити правильно з трохи меншими акторами, але це легка помилка при їх надмірному використанні.

На мою думку, для акторів є два випадки використання. Спільні ресурси, такі як порти тощо, та велика держава. Перший добре висвітлювався дискусією, але велика держава також є вагомою причиною.

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

Бази даних, такі як mnesia, можна вважати збереженням стану зовні в процесі запиту.