问题描述
我的系统使用一堆微服务来处理一个项目，我计划创建一个有状态的微服务来保存项目的最新状态.在该服务中，我计划将所有项目状态存储在可靠字典中，并且每当访问项目时更新项目的上次访问字段.
My system uses a bunch of micro service to process an item and I am planning to create a Stateful MicroService which holds the latest state of the item. In that service, I am planning to store all the item state in a reliable dictionary and whenever an item is accessed update the Last accessed field of the item.
我的需求是，我只想将最近使用过的物品存放在可靠集合中，需要将长时间未访问的物品移动到像azure table storage这样的外部存储中，并且 External storage 和 Reliable 集合需要同步.
My requirement is that, I only want to store the recently used items in the reliable collection and need to move the items that are not accessed for long time to an external storage like azure table storage,And the External storage and Reliable collection needs to be in sync.
意思是所有的物品都应该在外部存储中，最近使用的物品应该在可靠的收藏中.
Meaning all the items should be in external storage and the recently used items in reliable collection.
这是为了减少可靠收集的开销.
This is to reduce the overhead in reliable collection.
就像可靠集合充当缓存一样.
Like the reliable collection acts as a cache.
如上所述实施我的解决方案是最佳实践吗?枚举 ReliableCollection 是一种好习惯吗?
Is it best practice to implement my solution as mentioned above?Is it good practice to enumerate a ReliableCollection ?
推荐答案
如果 Reliable Dictionary 旨在充当缓存，那么我真的不认为将未使用的项目卸载到 Azure 存储有什么意义.如果它是一个缓存，我希望未使用的项目被清除，并且调用者需要回到缓存中过期的任何内容的真实来源.但听起来您希望 Reliable Dictionary 成为最新的事实来源.所以我认为你必须首先决定你是否真的在构建一个缓存，或者一个可以从内存中分页数据的真实数据存储源.听起来更像是后者.
If the Reliable Dictionary is meant to act as a cache, then I don't really see the point of offloading unused items to Azure Storage. If it's a cache, I would expect unused items to be purged, and caller would need to go back to the source of truth for anything that has expired from the cache. But it sounds like you want the Reliable Dictionary to be an up-to-date source of truth. So I think you have to first decide if you're actually building a cache, or a source of truth data store that can page data out of memory. It sounds more like the latter.
在任何一种情况下，都可以按照您的描述完成，但保持它们始终同步并不容易，因为您没有跨 Reliable Dictionary 和外部存储的事务.
In either case, it can be done as you described, but keeping them in sync consistently won't be easy because you don't have a transaction across a Reliable Dictionary and an external store.
枚举集合很好，但它是一项昂贵的操作，因此我不建议在热路径(例如用户请求路径)中对大量数据执行此操作.可以按计划定期执行此操作.
Enumerating a collection is fine but it is an expensive operation, so I would not recommend doing it on large amounts of data in a hot path, such as a user request path. It's ok to do it periodically in a scheduled manner.
您是否需要将数据卸载到外部存储?你可以卸载到本地磁盘吗?Reliable Collections 很快就会自动将状态卸载到磁盘.
Do you need to offload data to external storage? Can you offload to local disk? Reliable Collections will soon do offloading of state to disk automatically.
这篇关于可靠的集合缓存作为 Service Fabric 中的缓存的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持！