我有一堆用户生成的消息，分别包含时间戳，短信，个人资料图片和其他内容。使用我的Web API的所有客户端（电话）都能够请求最后的消息，然后向下滚动它们并请求最旧的项目。显然，热门消息是整个列表中最热门的数据。显然，我想创建一个缓存，它具有缓存策略并且明确地说明了所请求的新消息 - 请求消息是否很热？
我使用MemoryCache创建了一个无状态服务，现在将它用于我的目的。在我的工作中，是否有任何水下石头需要考虑？当然，除了点，我有五个节点，用户可以向内部没有缓存的服务发出请求。在这种情况下，此服务转到数据层服务，然后从中获取并加载一些数据。
忘记提及此消息列表会使用新条目更新时间。
我在MemoryCache实现中包装了IReliableDictionary，并使用我自己的StateManager实现在有状态服务下掌握它。每次请求都没有在集合中找到项目时，我会转到Azure存储并检索实际数据。在我完成后，我意识到我的实验没有用，因为没有办法扩展这种方法。我的意思是如果我的应用程序将固定分区的可靠服务作为缓存工作，我没有可能通过升级我的Service Fabric来扩展它们。如果在一段时间后负荷增加，这个事实会让我感到震惊：）
我仍然不知道如何为我的超级热门最可读的消息制作缓存更有效的方法。我仍然怀疑可靠的演员方法。它创建了大量的复制数据。
答案 0 :(得分：1)
我认为这是演员的理想用途。
演员将在一段时间后被垃圾收集，因此数据不会留在内存中。
每位用户一名演员。