Почему Akka хорош для параллелизма?

Я новичок в Akka и актерском фреймворке - я уверен, что упускаю что-то очевидное, пожалуйста, примите мои извинения заранее.

Я постоянно читаю, что одним из главных моментов при выборе Akka является управление параллелизмом.

Мне не ясно, почему Акка такой особенный; Я понимаю, что есть много маленьких актеров, которые очень легки и быстры; однако, как это может помочь мне, когда два пользователя сохраняют форму одновременно?

Разве мне по-прежнему не нужна какая-то блокировка параллелизма (пессимистичная / оптимистическая / и т. Д.)?

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

В вашем примере, когда пользователи сохраняют форму, предполагая, что субъект хранит список некоторых данных из каждой формы, он может обновлять список без блокировок, поскольку среда гарантирует, что за один раз будет обрабатываться только одна форма. Традиционно вам придется блокировать доступ к списку или использовать параллельный список.

Стратегия параллелизма - это немного другой вопрос, и вы по-прежнему несете за него ответственность (при этом ни одна из стратегий не является самой распространенной стратегией). Чтобы немного изменить ваш пример, допустим, что оба пользователя пытаются обновить один и тот же экземпляр формы одновременно. Без стратегии параллелизма, изменения одного заменит другой (вероятно, последний выигрывает). Это нормально, но в лучшем случае это приводит к неожиданному поведению пользователя, чьи изменения были перезаписаны. Если они просматривают только что измененную форму, она будет иметь неожиданные значения (от другого пользователя). В худшем случае (когда мы говорим не только об обновлениях форм, но и о таких вещах, как отправка заказов), это может привести к различным потерям (время, доход и т. Д.).

Использование стратегии параллелизма помогает идентифицировать эти случаи и иметь возможность разрешать их на основе бизнес-правил. Например, в Optimistic Concurrency пользователь отправляет версию формы, которую он обновляет. Когда субъект отправляется на обработку изменения, он замечает, что второй пользователь думает, что он обновляет версию 5, когда форма фактически находится на версии 6 из-за обновления первого пользователя. Теперь, по крайней мере, мы можем уведомить второго пользователя, что форма уже изменилась с тех пор, как он начал ее редактировать. Или какие-либо правила, которые бизнес хочет применить там.

В случае обновления формы вы, вероятно, не слишком заботитесь о параллелизме (я полагаю, это зависит). Но в других случаях очень важно, по крайней мере, иметь возможность проверять и обрабатывать нарушения. Возможно, вы даже захотите игнорировать нарушение параллелизма, например, если пользователи изменили разные разделы (чтобы продолжить аналогию с формой). Или, если изменение оказывает большое влияние на бизнес (большой заказ), вы хотите принять его и разрешить незначительные конфликты позже (например, ежегодное обновление контактной информации не было завершено).

Я считаю, что у Akka есть ряд других аспектов, таких как то, как она обрабатывает сбои, контролеров и т. Д., Которые являются важными факторами для devops.

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

преимущества

1. Более простая концепция для понимания и использования

   • Блокировка параллелизма сложна; в частности, очень трудно понять это правильно, потому что есть много понятий, которые нужно понять и использовать, чтобы быть правильными и эффективными: блокировки, семафоры, потоки, синхронизация, взаимное исключение, барьер памяти и т. д.

   • Актеры, с другой стороны, являются более абстрактным понятием; у вас есть актеры, которые отправляют и получают сообщения. Не нужно понимать и использовать низкоуровневые понятия, такие как барьер памяти.

2. Обеспечивает неизменность

   • Изменчивость является источником многих ошибок и ошибок в программировании, особенно в многопоточных приложениях. Модель актора решает эту проблему путем обеспечения неизменности.

3. Меньше ошибок

   • Из-за вышеупомянутых двух причин

4. эффективное

   • Не так эффективно, как хорошо написанные на основе блокировок, но в целом более эффективны, чем программная транзакционная память.

5. Легко масштабируемый

   • Теоретически, по крайней мере, приложение должно масштабироваться достаточно хорошо, добавляя больше актеров для выполнения вашей работы. С блокировкой довольно сложно масштабироваться.

Недостатки

1. Не все языки легко обеспечивают неизменность;

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

2. Все еще довольно сложный

   • Актеры основаны на асинхронной модели программирования, которая не так проста, и ее легко моделировать во всех сценариях; особенно трудно обрабатывать ошибки и сценарии сбоев.

3. Не предотвращает тупик или голодание

   • Два субъекта могут находиться в состоянии ожидания сообщения друг от друга; таким образом, у вас тупик, как с блокировками, хотя его гораздо легче отлаживать. Однако с транзакционной памятью вы гарантированно свободны от тупиковой ситуации.

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

   • Из-за принудительной неизменности и из-за того, что многим субъектам приходится переключаться, используя одни и те же потоки, они не будут такими эффективными, как параллелизм на основе блокировок.

Вывод

Параллелизм на основе блокировок является наиболее эффективным, но его трудно программировать и он подвержен ошибкам; Программная транзакционная память является наиболее понятной, простой в программировании и менее подверженной ошибкам, но при этом наименее эффективной. Актеры находятся где-то посередине между этими двумя моделями во всех аспектах: простота программирования, эффективность и предрасположенность к ошибкам.