azure - Service Fabric - 有状态的服务持久性

Question

我是服务结构的新手，首先查看涵盖该主题的 MSDN 文章。我首先实现 Hello World 示例 here .

我将其原始 RunAsync 实现更改为:

var myDictionary = await this.StateManager.GetOrAddAsync<IReliableDictionary<int, DataObject>>("myDictionary");

while (!cancellationToken.IsCancellationRequested)
{
    DataObject dataObject;

    using (var tx = this.StateManager.CreateTransaction())
    {
        var result = await myDictionary.TryGetValueAsync(tx, 1);

        if (result.HasValue)
            dataObject = result.Value;
        else
            dataObject = new DataObject();
        //
        dataObject.UpdateDate = DateTime.Now;
        //
        //ServiceEventSource.Current.ServiceMessage(
        //    this,
        //    "Current Counter Value: {0}",
        //    result.HasValue ? result.Value.ToString() : "Value does not exist.");

        await myDictionary.AddOrUpdateAsync(tx, 1, dataObject, ((k, o) => dataObject));

        await tx.CommitAsync();
    }
    await Task.Delay(TimeSpan.FromSeconds(1), cancellationToken);
}

我还引入了 DataObject 类型，并公开了该类型的 UpdateDate 属性。

[DataContract(Namespace = "http://www.contoso.com")]
public class DataObject
{
    [DataMember]
    public DateTime UpdateDate { get; set; }
}

当我运行应用程序(在 Visual Studio 2015 中按 F5)时，在字典中找不到 dataObject 实例(键值为 1)，因此我创建一个实例，设置 UpdateDate，将其添加到字典中并提交交易。在下一个循环中，它找到dataObject(键值为1)并设置UpdateDate，更新字典中的对象并提交事务。完美。

这是我的问题。当我停止并重新启动服务项目(在 Visual Studio 2015 中按 F5)时，我希望在 RunAsync 的第一次迭代中能够找到 dataObject(键值为 1)，但事实并非如此。我希望所有状态都会刷新到其副本。

我是否需要对有状态服务执行任何操作才能将其内部状态刷新到其主副本？

从我读到的内容来看，这听起来好像所有这些都是由服务结构处理的，并且调用 commit (在事务上)就足够了。如果我找到主副本(在 Service Fabric Explorer -> 应用程序 View 中)，我可以看到在提交事务(单步执行时)后 RemoteReplicator_xxx LastACKProcessedTimeUTC 已更新。

非常感谢任何帮助。

谢谢!

-标记

Answer 1

这是 Visual Studio 中默认本地开发体验的功能。如果您在按 F5 后仔细观察“输出”窗口，您将看到如下消息:

部署脚本检测到已经注册了相同类型和版本的现有应用程序，因此它将删除它并部署新的应用程序。在此过程中，与旧应用程序关联的数据将被删除。

您有几种选择来处理这个问题。

在生产中，您将执行 application upgrade在维护状态的同时安全地推出更新的代码。但是，在开发盒上进行快速迭代的同时不断更新版本可能会很乏味。

另一种方法是将项目属性“启动时保留数据”更改为"is"。这将自动升级生成的应用程序包的所有版本(不影响源中的版本)，然后代表您执行应用程序升级。

请注意，由于升级路径中固有的一些系统检查，此部署选项可能比默认的删除和替换要慢一些。但是，当您考虑重新创建测试数据所需的时间时，您会发现这通常是一次浪费。