Azure Service Fabric中的有状态服务和外部持久性之间的转换

mba*_*amo 17 azure orleans azure-service-fabric

Azure Service Fabric似乎专注于所有数据都适合RAM并且持久性用作后备存储的场景.可靠服务旨在将信息存储在可靠集合中,该集合使用日志检查点系统将记录的信息写入RAM.同时,对于Reliable Actors,默认的actor状态提供者是"Service Fabric平台提供的分布式Key-Value存储".这似乎表明同样的限制将适用.

然而,可能存在这样的情况:人们想要将Service Fabric用于"热数据",而是将"冷数据"写入某种形式的永久存储器.处理此转换的最佳做法是什么?

在Orleans中,这似乎是使用Azure表等持久性存储自动处理的.但似乎Service Fabric和Reliable Collections的主要设计目的是避免需要外部服务,从而增强数据局部性.当前的文档预计可能会有人希望将数据移动到某个永久存储库以进行灾难恢复和分析,但它没有讨论在持久性支持的内存中的actor和更永久的存储形式之间来回移动数据的可能性.

一个可能的答案是Service Fabric已经这样做了.也许可靠字典有一些内置机制,用于在持久性支持的内存存储和永久存储之间进行切换.

或者,也许答案是必须管理自己.一种方法可能是让Actor跟踪它的"热"程度并根据需要切换其持久性存储.但这牺牲了Actor模型的一个好处,即演员的自动分配和释放.同样,我们可能会定期从Reliable Dictionary中删除项目并将其添加到其他持久性存储中,然后将其添加回来.但是,这又要求了解何时进行转换是有意义的.

一些例子可能有助于明确这一点:

(1)假设我们正在实施一个有许多不同"房间"的多人游戏.我们不需要同时在内存中的所有房间,但我们需要将它们移动到内存中,并在玩家加入后使用本地持久性作为备份.

(2)假设我们正在实现一个仅附加的B树作为数据库的一部分.诱惑是让每个B-Tree节点成为有状态的角色.我们希望热b树保留在内存中,但当然整个索引不能在内存中.看来这是一个已经为DocumentDB这样的东西实现的核心场景,但是从文档中我不清楚如何做到这一点.

我找到的一个相关问题就在这里.但是,该问题主要关注何时使用Azure Service Fabric与外部服务.我的问题是是否需要在它们之间进行转换,或者Azure Service Fabric是否已具备此处所需的所有功能.

Abh*_*SFT 14

在key-value存储状态提供程序要求所有内容被保存在内存中.此提供程序实际上存储本地磁盘上所有actor的状态,并且状态也会复制到其他节点上的本地磁盘.因此,KVS商店被认为是一个持久而可靠的商店.

除此之外,活动 actor 的状态也存储在内存中.当一个演员有一段时间没有被使用时,它会被取消激活并收集垃圾.发生这种情况时,将释放内存中的副本,并且仅保留磁盘上的副本.当actor再次被激活时,只要actor处于活动状态,就从磁盘获取状态并保留在内存中.

此外,KVS不是唯一的内置状态提供商.我们还有VolatileActorStateProvider(http://azure.microsoft.com/en-gb/documentation/articles/service-fabric-reliable-actors-platform/#actor-state-provider-choices).这是将所有内容保存在内存中的状态提供程序.

  • 可靠的集合也将其状态保留在磁盘上.此页面上的文档明确提到了它.http://azure.microsoft.com/en-us/documentation/articles/service-fabric-reliable-services-reliable-collections/."持久化:数据持久存储到磁盘以防止大规模中断(例如,数据中心停电)." 文档中是否有任何其他建议的地方? (2认同)

Dar*_*ran 6

KvsActorStateProvider确实将actor状态存储在KeyValueStore中,KeyValueStore是与ReliableDictionary类似的结构.

我要问的第一个问题是,你是否需要将旧演员国家置于冷库?将所有内容保存在内存中的限制并不仅限于演员的总数,而是每个副本的总数.因此,您必须首先考虑分区策略,以便您的actor分布在多个不同的副本中.随着您的需求增长,您可以向群集添加更多计算机,ServiceFabric将协调副本到新计算机的移动.有关Actor服务分区的更多信息,请参阅http://azure.microsoft.com/en-gb/documentation/articles/service-fabric-reliable-actors-platform/

如果您确实想在一段时间后使用冷藏,那么您有几个选择.首先,您可以使用自定义的ActorStateProviderAttribute来装饰您的actor,该自定义的ActorStateProviderAttribute返回您自己的IActorStateProvider实现,它可以根据您的决定处理持久性.

或者,您可以在Actor实现中完全处理它.挂钩到Actor生命周期和OnDeactivateAsync,这样当实例被垃圾收集,或者在将来的某个指定时间内使用Actor Reminder时,可以序列化状态并存储在冷存储(如blob或表存储)中,并将状态置空属性.然后,可以使用ActivateAsync覆盖从脱机存储和反序列化中检索此状态.