本文介绍了可靠的集合缓存作为Service Fabric中的缓存的处理方法,对大家解决问题具有一定的参考价值,需要的朋友们下面随着小编来一起学习吧!

问题描述

我的系统使用一堆微服务来处理项目,并且我计划创建一个保存有项目最新状态的有状态MicroService.在该服务中,我计划将所有项目状态存储在可靠的字典中,并且每当访问一个项目时,都会更新该项目的上次访问"字段.

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.

我的要求是,我只想将最近使用过的项目存储在可靠的集合中,并且需要将长时间不访问的项目移动到外部存储(例如天蓝色表存储)中,而且外部存储和可靠的收集需要同步.

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 ?

推荐答案

如果可靠字典旨在充当缓存,那么我真的看不到将未使用的项目卸载到Azure存储的意义.如果是缓存,我希望清除未使用的项目,调用者将需要返回真相,以查找缓存中过期的所有内容.但这听起来像您希望可靠字典成为真理的最新来源.因此,我认为您必须首先确定您是否实际上是在构建高速缓存,或者是可以将数据分页到内存中的真相数据存储源.听起来更像后者.

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.

在任何一种情况下,都可以按照您所描述的进行操作,但是要始终保持同步并不容易,因为您没有跨可靠字典和外部存储的事务.

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.

是否需要将数据卸载到外部存储?您可以卸载到本地磁盘吗?可靠的集合很快就会自动将状态卸载到磁盘上.

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中的缓存的文章就介绍到这了,希望我们推荐的答案对大家有所帮助,也希望大家多多支持!

10-14 03:09