我的系统使用一堆微服务来处理项目，我计划创建一个Stateful MicroService来保存项目的最新状态。在该服务中，我计划将所有项状态存储在可靠的字典中，并且每当访问项时，更新项的上次访问字段。
我的要求是，我只想将最近使用的项目存储在可靠的集合中，并且需要将长时间未访问的项目移动到外部存储，如azure表存储，并且外部存储和可靠集合需要是同步中。
意味着所有项目应该在外部存储和最近使用的项目中可靠收集。
这是为了减少可靠收集的开销。
像可靠的集合充当缓存。
如上所述，实施我的解决方案是最佳做法吗？枚举ReliableCollection是一种好习惯吗？
如果Reliable Dictionary意味着充当缓存，那么我真的没有看到将未使用的项目卸载到Azure存储的重点。如果它是一个缓存，我希望清除未使用的项目，并且调用者需要回到从缓存中过期的任何事实的真相来源。但听起来你希望Reliable Dictionary成为最新的真相来源。因此，我认为您必须首先确定您是否实际构建了一个缓存，或者是一个可以将数据从内存中分页的真实数据存储源。听起来更像是后者。
在任何一种情况下，都可以按照您的描述完成，但保持它们一致同步并不容易，因为您没有可靠字典和外部存储中的事务。
枚举集合很好，但这是一项昂贵的操作，因此我不建议在热路径中对大量数据执行此操作，例如用户请求路径。可以按计划的方式定期进行。
您需要将数据卸载到外部存储吗？你可以卸载到本地磁盘吗？ Reliable Collections很快就会自动将状态卸载到磁盘。
SoCreate的团队刚刚发布了一个名为Service Fabric Distributed Cache的开源项目，该项目可能会帮助您或其他人使用Service Fabric并需要缓存。我们构建了这个，所以我们不需要在Service Fabric中运行Redis或类似的客户端exe。这为您提供了一种运行，监视和管理缓存作为Service Fabric可靠服务的方法。您可以在此处了解更多信息：
http://service-fabric-distributed-cache.socreate.it/
或者在GitHub上：https://github.com/SoCreate/service-fabric-distributed-cache
我会用一个演员。给每个项目它自己的actor并在那里存储状态。当actor被垃圾收集时，你可以将状态保存在其他地方，或者只是在actor计时器上执行。
这样做意味着您不必复制很多actor代码来管理大量实例。
警告
如果您的整体设计有意义，这是有道理的。正如Vaclav在下面的评论所说，由于演员的单线程模型，演员不适合通用缓存。但是，如果您的设计有一个代表单个实体的actor并且缓存与该实体（例如用户）相关，那么将actor视为缓存可以很好地工作。