我只是在寻找关于如何解决这个问题的标题的一些建议。
我目前有一个 asp.net 核心应用程序，它由使用 DDD 模式的实体框架支持，我们希望将其迁移到具有服务结构的微服务架构。
我知道演员可以被持久化到磁盘和内存中，但是有没有人有任何关于将演员持久化到外部存储（如 MSSQL）的经验？
出现这种情况的原因是，目前我们遇到了实体框架的并发问题，并且 Actor 似乎很适合这个问题，因为它们是单线程和分布式的，但是我似乎找不到任何材料来建议 Actor应该或可以得到数据库持久性的支持。
我们需要数据库（而不是这样的有状态参与者）的唯一原因是 SSRS 链接到数据库以提供报告。
所以问题真的是
非常感谢任何帮助、指导或建议。
【问题讨论】：
标签： entity-framework-core azure-service-fabric
您可以通过编写IActorStateManager 的自定义实现将SQL 用作后备存储（不推荐，非常困难），但您也可以从Actor 访问数据库。您可以像在任何其他 .NET（核心）项目中一样使用 EFx（核心）。
但不确定它是否能帮助您解决并发问题，因为您可能有许多 Actors 使用同一个数据库。 仅使用单个 Actor 访问您的数据库时可以工作，但这将成为您系统的瓶颈。
我建议您使用retry design pattern 处理数据库中的并发问题。 （例如，通过使用像 Polly 这样的包）、locking and row versioning。
【讨论】：
您没有找到有关此方法的示例，因为 Service Fabric 中参与者的主要思想是使用平台的状态管理功能来为您处理。
该框架可以灵活地编写您自己的提供程序，但比在 Akka.Net 或 Orleans 等不是构建在 SF 等平台之上的另一个 Actor 框架上更难。
SF Actors 具有来自 Orleans 的 DNA，SF Actor 是从该框架移植而来的。
Orleans 不提供数据平台，需要 Storage Providers 来处理持久性，对于 SQL 存储，您可以创建一个 custom provider 并将其注册到运行时并完成。他们已经有一个用于 Azure 表存储。
如果您仍计划将状态存储在 DB 中，您可以选择其中一种解决方案，或者按照 Loek 的建议创建自定义提供程序，并基于从其他框架之一中获取的想法。
关于主要问题，您不必实际使用actor状态管理来解决并发问题，您可以使用它的隔离和通信方面来防止对单个项目的并发操作（每个项目都是actor) 并且所有针对 item 数据的操作都应该由 actor 自己处理。
但是，因为您使用的是外部持久性，所以没有什么可以阻止其他参与者、服务或外部系统更改参与者状态，并且从技术上讲，它再次对并发开放。如果您可以保证只有参与者可以更改它，则可能不是问题，例如，Azure 存储您可以租用一个 blob，并且只有租约持有者可以更改它。
这也是actor状态应该由actor封装和管理的原因之一，否则管理它的复杂性会外泄 演员。
【讨论】：