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