Azure Service Fabric 似乎专注于所有数据都可以容纳在 RAM 中并且持久性用作后备存储的场景。 Reliable Services 旨在将信息存储在 Reliable Collections 中，该集合使用 log-checkpoint system记录的信息被写入 RAM。同时，对于可靠的参与者，default actor state provider是“Service Fabric 平台提供的分布式键值存储”。这似乎表明同样的限制也适用。
但是，在某些情况下，人们可能希望将 Service Fabric 用于“热数据”，但将“冷数据”写入某种形式的永久存储。处理这种转变的最佳实践是什么？
在奥尔良，这似乎是使用持久性存储(例如 Azure 表)自动处理的。但 Service Fabric 和 Reliable Collections 的主要设计目的似乎是避免需要外部服务，从而增强数据局部性。当前文档预计人们可能希望将数据移动到某个永久存储中 disaster recovery and analytics ，但它没有讨论在持久性支持的内存参与者和更永久的存储形式之间来回移动数据的可能性。
一个可能的答案是 Service Fabric 已经做到了这一点。也许可靠字典有一些内置机制，用于在持久性支持的内存存储和永久存储之间切换。
或者，也许答案是必须自己管理。一种方法可能是让 Actor 跟踪它的“热度”并根据需要切换其持久性存储。但这牺牲了Actor模型的好处之一，即Actor的自动分配和释放。同样，我们可以定期从可靠字典中删除项目并将其添加到其他持久性存储中，然后将它们添加回来。不过，这需要了解何时进行转变才有意义。
几个例子可能有助于阐明这一点:
(1) 假设我们正在实现一个具有许多不同“房间”的多人游戏。我们不需要一次将所有房间都存储在内存中，但我们需要将它们移至内存中，并在玩家加入后使用本地持久性作为备份。
(2) 假设我们正在实现一个仅追加 B 树作为数据库的一部分。让每个 B 树节点成为有状态的参与者是一种诱惑。我们希望热 B 树保留在内存中，但当然整个索引不能在内存中。似乎这是一个核心场景，已经为 DocumentDB 等实现，但从文档中我不清楚如何做到这一点。
我发现的一个相关问题是here 。但这个问题的重点是何时使用 Azure Service Fabric 与外部服务。我的问题是是否需要在它们之间进行转换，或者 Azure Service Fabric 是否已经具备此处所需的所有功能。
最佳答案
键值存储状态提供程序不要求将所有内容都保存在内存中。该提供程序实际上将所有参与者的状态存储在本地磁盘上，并且该状态也会复制到其他节点上的本地磁盘上。因此 KVS 存储被认为是持久且可靠的存储。
除此之外，事件参与者的状态也存储在内存中。当一个 Actor 一段时间没有使用时，它会被停用并被垃圾收集。发生这种情况时，内存中的副本将被释放，仅保留磁盘上的副本。当 actor 再次激活时，状态将从磁盘获取，并在 actor 处于事件状态时保留在内存中。
此外，KVS 并不是唯一的内置状态提供程序。我们还有 VolatileActorStateProvider (http://azure.microsoft.com/en-gb/documentation/articles/service-fabric-reliable-actors-platform/#actor-state-provider-choices)。这是将所有内容保存在内存中的状态提供者。
关于azure - Azure Service Fabric 中的有状态服务和外部持久性之间的转换，我们在Stack Overflow上找到一个类似的问题： https://stackoverflow.com/questions/30081718/