我花了我的晚上评估Azure Service Fabric作为我们当前的WebApps / CloudServices堆栈的替代品，并且对于如何确定具有州的服务/演员何时应该是有状态的演员以及何时他们感到有点不确定应该是具有外部持久化状态的无状态actor（Azure SQL，Azure存储和DocumentDB）。我知道这是一个相当新的产品（至少对普通大众而言），所以可能还没有很多关于此的最佳实践，但我已经阅读了大部分{{3微软提供的，没有找到明确的答案。
我接近的当前问题领域是我们的活动商店;我们的部分应用程序基于事件源和CQRS，我正在评估如何将此事件存储移动到Service Fabric平台。事件存储将包含很多时间序列 - 数据，因为它是我们保存在那里的数据的唯一真实来源，它必须是一致的，复制的并存储到某种形式的持久存储中。
我考虑过这样做的一种方法是使用有状态的＆＃34; EventStream＆＃34;演员;使用事件源的聚合的每个实例将其事件存储在隔离的流中。这意味着有状态的演员可以跟踪自己的流的所有事件，并且我已经满足了关于数据如何存储（事务，复制和持久）的要求。但是，有些流可能会变得非常大（数十万甚至数百万的事件），而这正是我开始变得不确定的地方。我想，如果需要将这些大型数据模型序列化或从磁盘反序列化，那么拥有大量状态的actor会对系统性能产生影响。
另一种选择是让这些演员无国籍，让他们只是从Azure SQL等外部存储中读取他们的数据 - 或者只使用无状态服务而不是演员。
基本上，演员/服务的状态数量是多少＆＃34;太多＆＃34;你应该开始考虑其他处理状态的方法吗？
此外，documentation文档中的这一部分让我有点疑惑：
将Azure Service Fabric Actors视为事务系统。 Azure Service Fabric Actors不是基于提交ACID的两阶段提交系统。如果我们没有实现可选的持久性，并且actor在die上运行，那么它的当前状态将随之而来。演员将非常快地进入另一个节点，但除非我们实现了支持持久性，否则状态将会消失。但是，在利用重试，重复过滤和/或幂等设计之间，您可以实现高水平的可靠性和一致性。
＆＃34;如果我们不实施可选的持久性＆＃34;在这说明？我的印象是，只要您的事务修改状态成功，您的数据就会持久存储到持久存储并复制到至少一部分副本。这一段让我想知道是否存在我的演员/服务中的状态会丢失的情况，如果这是我需要处理的事情。我从文档其他部分的状态模型中获得的印象似乎抵消了这种说法。
答案 0 :(得分：24)
您拥有的一个选择是在演员中保留“部分”状态（假设可以被认为是需要快速获取的热门数据）并将其他所有内容存储在“传统”存储基础设施上作为SQL Azure，DocDB，.... 关于太多的本地状态很难有一个通用规则，但也许，考虑热数据和冷数据有帮助。 Reliable Actors还提供自定义StateProvider的功能，因此您还可以考虑使用特定策略实现自定义StateProvider（通过实现IActorStateProvider），这些策略需要更高效地满足您在数据量，延迟方面的要求，可靠性等（注意：StateProvider接口上的文档仍然很少，但如果你想要这样做，我们可以发布一些示例代码）。
关于反模式：说明更多的是关于跨多个参与者实现交易。可靠的演员为演员界限内的数据可靠性提供全面保证。由于Actor模型的分布式和松散耦合性，实现涉及多个actor的事务并不是一项简单的任务。如果“分布式”事务是一个强烈要求，可靠服务编程模型可能更适合。
答案 1 :(得分：5)
我知道这已经得到了解答，但最近发现自己处于与CQRS / ES系统相同的困境中，以及我如何解决这个问题：
答案 2 :(得分：2)
回答@ Trond的二次问题，即“什么做，如果我们不实施可选的持久性”，请在此处说明？
一个actor总是一个有状态服务，它的状态可以使用actor类的属性进行配置，以三种模式之一运行：
可以找到关于该主题的完整讨论in the Microsoft documentation