Ответ 1
Да, есть. Прежде всего, всегда делегируйте опасную работу детям-актерам, дайте им все свои ножи, огнемет и тому подобное. если они сбой и сжигание, ваше состояние все еще остается нетронутым, и вы можете создавать новых детей.
Итак, для примера недостижимой базы данных;
Выдвиньте БД-коммуникатора.
Затем вы можете позволить этому актеру иметь два состояния: DB up и DB down, это можно моделировать как FSM или использовать Become/Unbecome.
Итак, когда приходит сообщение и запрашивает запрос БД, если что-то взорвано, агент-коммуникатор БД передает его в состояние DB-Down.
Если какой-либо запрос получен в состоянии DB-Down, вы можете немедленно ответить с событием Failure.
Итак, как мы переходим от DB-Down до DB-Up снова?
Актер DB-Communicator может выполнить ping сам, используя ScheduleOnce, например. передайте ему сообщение "CheckDBStatus" каждые x секунд.
Когда сообщение CheckDBStatus получено, вы проверяете, снова ли DB снова, и если да, то вы вернетесь в состояние DB-Up.
Таким образом, вы не будете наводнять свою БД в сценариях, где он не может реагировать из-за высокой нагрузки, добавив больше нагрузки в этом случае, это только ухудшит ситуацию. Таким образом, этот автоматический выключатель предотвратит это.
Короче говоря:
В состоянии DB-Up:
Если получено сообщение DBQuery, попробуйте запустить запрос и отправить ответ. если что-то взорвалось, перейдите непосредственно в состояние DB-Down и ответьте на событие сбоя.
В состоянии DB-Down:
если получено сообщение DBQuery, ответьте событием Failure непосредственно, не касаясь БД.
Пинг себе каждые х секунд, чтобы увидеть, есть ли БД, и, если возможно, вернуться в состояние DB-Up.
В этом случае вы не будете использовать какой-либо супервизор для транзита состояния, нормального try/catch будет достаточно, чтобы справиться с этим.
Надеюсь, что это ясно.