【问题标题】:Service fabric reliable collections and immutabilityService Fabric 可靠的集合和不变性
【发布时间】:2016-09-28 00:53:43
【问题描述】:

我在这里读了一篇文章 https://azure.microsoft.com/en-in/documentation/articles/service-fabric-work-with-reliable-collections/ 它说“一旦将对象提供给可靠的集合,就不得修改它。”

为什么会这样?我可以不修改对象并将其添加回可靠集合吗?不会覆盖之前的值吗?

【问题讨论】:

    标签: c# azure azure-service-fabric


    【解决方案1】:

    理论上,您可以修改同一个对象并将其写回可靠的集合。但是这种方法是有问题的。当您对 object 进行更改时,该值仅在本地修改,不会写入主副本和辅助副本的磁盘。直到您将修改后的对象显式写回可靠集合,对象的本地副本和持久副本将不一样。因此,将对象视为不可变对象并对对象的深层副本进行修改始终是一种很好的做法。

    【讨论】:

      【解决方案2】:

      在传统的 .net 集合中,来自字典中键控查找的值(或来自队列的 pop/peek)返回指向堆上对象的指针。当您修改此指针时,堆中的值将被修改。结果,状态在字典中发生了变化。

      可靠的集合是围绕更复杂的交互的外观。虽然集合确实在内存中*,但可靠的状态管理器还负责将任何更改复制到辅助副本。发生这种情况的机制是在 ITransaction 上调用 CommitAsync。

      如果您只改变对象在内存中的表示,则更改将永远不会复制到辅助分区,并且会导致未定义/意外的行为。 (比如当活动的主节点切换到辅助节点时)如果你调用了 CommitAsync(即使你做了一个 Get -> Modify -> Set),事务可能无法提交,并且内存中的当前表示将与辅助节点的表示不同分区和主分区的磁盘表示。这又会导致未定义/意外的行为。

      *在大多数情况下,除非集合的大小大于可用内存。在这种情况下,值是从磁盘分页的,只有键和最近使用的值保存在内存中。将来,我听说过有关在磁盘压力增加时进一步分页到 Blob 存储的讨论。

      【讨论】:

        【解决方案3】:

        完整的声明是:

        但是,对于可靠的集合,此代码表现出相同的 已经讨论过的问题:一旦你不能修改一个对象 已将其交给可靠的收藏。

        该陈述是在与处理可靠集合相关的问题的背景下进行的。使用 SF 可靠字典时,API 看起来像标准的 .NET 字典。在幕后,它更像是管理状态。有了这种区别,我们需要记住使用这些数据结构时的常见缺陷。在第一个代码演示中,它看起来会更新对象但不会。在本文后面,它为您提供了修改可靠集合中对象的正确方法。

        【讨论】:

          猜你喜欢
          • 2017-12-07
          • 2017-12-08
          • 2016-08-09
          • 1970-01-01
          • 2017-12-01
          • 2016-03-14
          • 2022-06-18
          • 2017-01-28
          • 2018-07-04
          相关资源
          最近更新 更多