1

我有多个用例需要根据特定用户操作触发预定义事件。

例如，假设在应用程序中创建时，NewUser它必须异步调用。还有许多其他这种性质的业务案例，其中将基于用例预定义事件。我可以使用 Promises/Futures 对这些事件进行建模，如下所示CreateUserInWorkflowSystemFireEmailToTheUser

if 'NewUser' then 
    call `CreateUserInWorkflowSystem` (which will be Future based API)
    call `FireEmailToTheUser` (which will be Future based API)
if 'FileImport' then
   call `API3` (which will be Future based call)
   call `API4` (which will be Future based call)

所有这些Future调用都必须在某处记录失败，因此可以重试失败的调用等。注意NewUser调用不会等待那些Futures（每个说的事件）完成。

那是使用普通的Futures/PromisesAPI。但是我认为Akka Persistence将是一个合适的选择，并且阻塞调用仍然会遇到Futures. 使用 Akka 持久性，处理失败将很容易，因为它提供了开箱即用等。我知道 Akka 持久性仍处于实验阶段，但这似乎不是一个大问题，因为类型安全通常会在推广之前将这些新框架保持在实验状态进入未来的版本等（宏也是如此）。鉴于这些要求，您认为Futures/PromisesAkka 持久性更适合这里吗？

4

1 回答 1

1

这是一个基于意见的问题——不是关于 SO 的最佳类型。无论如何，试图回答。

这实际上取决于您更喜欢什么以及您的要求是什么。您是否需要稍后将系统扩展到单个 JVM之外- 使用 Akka。你想让它更简单吗- 使用期货。

如果您使用 Futures，您可以将所有状态和操作存储在作业队列/数据库中执行。这很合理。

如果您使用 Akka Persistence，那么显然它将帮助您保持持久性。Akka 将有助于更轻松地执行监督、恢复和重试。如果您的CreateUserInWorkflowSystem操作失败，结果将传播给监督演员，监督演员可能会重新启动失败的演员并使其重试 N 次。如果你的监督演员失败了，那么他的监督会做正确的事，或者最终整个应用程序会崩溃，这很好。使用 Futures，您必须自己实现此机制，并确保应用程序可以在需要时崩溃。

如果你有完全独立的动作，那么 Futures 和 Actors 听起来差不多。如果您必须链接操作并组合它们，那么使用 Futures 将是一件更自然的事情：对于理解等。在 Akka 中，您必须等待消息并根据消息的类型执行下一个操作。

尝试使用两者来模拟一个简单的实现，并根据您的特定应用程序要求比较您喜欢/不喜欢的内容。总的来说，这两种选择都不错，但在这种情况下，我稍微倾向于演员。

于 2014-06-24T18:45:50.710 回答