命令对象缓存失效

发布于 2024-09-30 00:10:15 字数 419 浏览 1 评论 0原文

我有一个应用程序,它实现命令对象模式以从服务器获取数据。现在我想实现一个客户端缓存,并且需要一些关于如何处理缓存 eviction 失效的指示。

问题

为了获取对象,我传递 GetObject(id) 命令并接收包含该 id 结果的 GetObjectResponse。我有一个缓存可以很好地缓存 GetObject(id) 的响应。

但是,当我看到像 DeleteObject(id) 或 UpdateObject(id) 这样的命令时,GetObject(id) 的缓存响应需要失效。

我应该说,现实并不一定像单个 id 参数那么简单。某些响应对象依赖于命令对象中的多个参数。此外,传递一个命令对象可能会使多个响应对象无效。

关于如何实现这一目标有什么想法吗?提前致谢!

I've got an app that implements a command object pattern to get data from a server. Now I'd like to implement a client side cache and I need some pointers on how to deal with cache eviction invalidating.

The problem

To get an object I pass the GetObject(id) command and receieve a GetObjectResponse with the results for that id. I've got a cache going that can cache the response for GetObject(id) nicely.

However, when I see a command like DeleteObject(id) or UpdateObject(id), the cached response for GetObject(id) needs to be invalidated.

I should say that the reality is not necessarily this simple as with a single id parameter. Some response objects depend on more than one parameter in the command object. Also, passing one command object could invalidate more than one response objects.

Any thoughts on how to accomplish this? Thanks in advance!

如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。

扫码二维码加入Web技术交流群

发布评论

需要 登录 才能够评论, 你可以免费 注册 一个本站的账号。

评论(3

若相惜即相离 2024-10-07 00:10:15

首先,这个问题被称为缓存失效,而不是驱逐。 (我看到您使用了这两个术语。)缓存逐出意味着当缓存已满时从缓存中删除元素。这是一个完全不同的话题。

其次,我没有看到命令模式和缓存之间的联系。无论如何,让我们关注缓存。

当使一个元素无效时,您必须在缓存中找到它。这与检索元素的工作方式相同:通过使用缓存查找值。这样的键可以是您提到的 id,或其他一些唯一的值元组。这个 id 或元组的外观取决于您的域(您使用命令模式的方式)。

关于您的上一个问题,必须有一条规则告诉您当某个其他元素无效时哪些元素将无效。这取决于命令模式应用程序背后的逻辑。我无法从你的描述中看出这样的规则到底是什么样子。

Firstly, the problem is called cache invalidation, not eviction. (I see you use both terms.) Cache eviction means removing elements from the cache when the cache is full. This is a completely different topic.

Secondly, I don't see the connection between the command pattern and the cache. Anyway, let's focus on the cache.

When invalidating an element you have to find it in the cache. This works the same way as for retrieving the element: by looking up the value using a cache key. Such a key can be the id you mention, or some other unique tuple of values. How this id, or tuple looks like depends on your domain (the way you use the command pattern).

Regarding your last issue, there has to be a rule that tells you which elements are to be invalidated when a certain other element is invalidated. This depends on the logic behind your command pattern application. I can't tell from your description how exactly such a rule would look like.

滿滿的愛 2024-10-07 00:10:15

据我了解,您的客户端需要有服务器状态的本地缓存。
当服务器状态发生变化时,您的客户端需要得到通知并更新。
我的建议是从使整个缓存失效的极端情况开始,然后研究更小、更精细的更新缓存的方法,而不发送服务器的整个状态。进行更精细更新的一个想法是“标记”服务器状态上的每个更改,以便客户端可以发送他的最后一个标记,然后服务器可以根据其当前标记计算更新客户端的最佳方式(整个更新或只是字段)。

As far as I understand, your client needs to have a local cache of a server state.
When the server state changes, your client needs to be notified and updated.
My suggestion is to start with the extreme case of invalidating the whole cache and then work down smaller and finer ways of updating the cache without sending the whole state of the server. An idea on doing finer updates would be to "tag" each change on the server state so the client can send his last tag, and then the server can compute the best way of updating the client based on his current tag (whole updating or just fields).

长安忆 2024-10-07 00:10:15

我最终用这个方法编写了一个 CacheInvalidationGenerator 类:

public ArrayList<Action> getInvalidForAction(Action action) {
  ArrayList<Action> result = new ArrayList<Action>();
  if (action.getClass()==UpdateObject.class) {
    UpdateObject a = (UpdateObject) action;
    result.add(new GetObject(a.getObjectId()));
  }
  return result;
}

该方法只是返回要从缓存中失效的操作对象。当然,这些也可能会产生失效,因此应该递归调用该方法。

I ended up writing a CacheInvalidationGenerator class with this method:

public ArrayList<Action> getInvalidForAction(Action action) {
  ArrayList<Action> result = new ArrayList<Action>();
  if (action.getClass()==UpdateObject.class) {
    UpdateObject a = (UpdateObject) action;
    result.add(new GetObject(a.getObjectId()));
  }
  return result;
}

The method simply returns action objects to be invalidated from the cache. Of course, these can also generate invalidations, so this method should be called recursively.

~没有更多了~
我们使用 Cookies 和其他技术来定制您的体验包括您的登录状态等。通过阅读我们的 隐私政策 了解更多相关信息。 单击 接受 或继续使用网站,即表示您同意使用 Cookies 和您的相关数据。
原文