FSM 与 Akka 中的成为/不成为答案

【问题标题】：FSM vs become/unbecome in AkkaFSM 与 Akka 中的成为/不成为
【发布时间】：2013-06-11 04:40:37
【问题描述】：

Akka 提供了两种有些重叠的方式来管理actor 状态，Finite State Machines 和unbecome/become。它们各自的优点/缺点是什么？什么时候应该选择其中一个而不是另一个？

【问题讨论】：

标签： akka fsm

【解决方案1】：

与 FSM 相比，Become/Unbecome 非常轻量级。因此，除非您有超过 2 个状态（例如开/关）和/或复杂的状态更改策略，否则我不会将成为/取消成为完整的 FSM。除此之外，我认为只有微小的差异......例如，FSM 为您提供了一个不错的内置计时器 DSL：

setTimer("TimerName", msg, 5 seconds, repeat = true)
// ...
cancelTimer("TimerName")

或者例如，我不确定在 FSM 中是否可以“返回”到先前的状态，只有“前进”，因为您必须明确指定要进入的状态。而unbecome 正是这样。

【讨论】：

【解决方案2】：

FSM 是一种 DSL，它允许您构建比使用核心 Actor API 更复杂、可读的状态机。您可以将 FSM 代码展示给业务人员，他们可以验证业务规则。

FSM DSL 允许您更干净地组合事物。例如，transitions 允许您排除必须在演员 become 行为之间复制的逻辑。您还可以订阅其他参与者以获取有助于解耦和测试的转换的通知。

定时器也很好地集成到 DSL 中，并且可以干净地处理取消之类的事情。使用调度程序编码超时消息有许多陷阱。

FSM 的缺点是它是一种 DSL 和一种新语法，可供其他团队成员消化。好的一面是它是一种 DSL 和更高级别的抽象。我认为agilesteel 的2 个状态阈值是一个很好的阈值。但是，一旦您超过 2 个状态，FSM 的好处就会非常引人注目。

请务必阅读 the FSM docs 和 accompanying examples 对比 become 和 FSM。

请注意：使用unbecome“弹出”行为 - 默认行为是不使用行为堆叠。它仅与少数用例相关（即，通常与状态机无关）。

【讨论】：