Java 内存缓存，每个客户端都有子缓存

Question

我有一个 ConcurrentMap，它是我的网络应用程序的内存缓存/数据库。我在那里存储了以 id 作为键的实体。这就是我的实体的基本样子。

public class MyEntity {
     private int id;
     private String name;
     private Date start;
     private Date end;
     ...
}

现在我有多个用户从我的 map 请求不同的数据。User1 有一个开始日期过滤器。例如，他只获得我 map 的第 1、2 和 3 项。 User2 也有一个过滤器，只获取 map 的第 2、3、4、5 项。所以他们只能得到完整 map 的一部分。我正在我的服务器上进行过滤，因为 map 太大，无法发送完整的 map ，并且我需要检查其他属性。

我现在的问题是， map 中的条目可以从其他一些 API 调用中更新/删除/添加，我想实时更新用户端的条目。

现在我正在向用户发送 map 已更新的通知，然后每个用户都会加载用户需要的完整数据。例如第 8 项已更新。即使更新仅针对项目 8，用户 1 也会收到通知并再次加载项目 1、2、3。因此，在这种情况下，用户 1 无需更新，因为他不需要项目 8。

现在我正在寻找一个好的解决方案，以便用户只收到必要的更新。

我想到的一种方法是临时存储用户请求的所有项目 ID。因此，在更新通知中，我可以检查更新的项目是否在列表中，然后仅当更新的项目在用户列表中时才将其发送给用户。但我担心如果我有很多用户并且带有项目 ID 的用户列表也可能非常大，这将创建内存使用量。

仅当用户需要该项目时才将添加/更新/删除的项目发送给用户，什么是一个好的解决方案？例如，仅观察 basemap (缓存)的一部分，但对每个操作(如添加、更新和删除项目)发出通知。

Answer 1

基本上没有“银弹”。可能的解决方案取决于使用模式、您的资源和要求。

要问的问题:

• 现在和 future 的总数据集有多大？
• 显示的数据集有多大？
• 有多少用户进行过搜索？
• 它是具有封闭用户组的业务应用程序还是需要扩展的公共(public) Web 应用程序？
• 更新频率是多少？常见的更新类型是什么？
• 存在多少种不同的搜索模式？

最大的问题:

真的需要吗？

看看一堆搜索界面，用户只在有交互时才期望更新。如果它类似于搜索，那么用户将不会期望即时更新。即时更新可能很有用且“创新”，但您确实在这个问题上花费了大量的工程成本。

因此，在开始工程任务之前，请确保 yield 能够证明成本的合理性。也许首先检查这些替代方法:

1. 别这么做。仅更新用户交互。也许添加一个重新加载按钮。
2. 仅通知用户发生了更新，但仅在用户点击“重新加载”时更新。这解决了用户可能无法聚焦浏览器选项卡而导致传输浪费的问题。

But I am concerning the memory usage that this will create in case I have a lot of users and the user list with the item ids can be very big too.

在我们的应用程序中，我们观察到没有那么多不同的搜索模式/过滤器。假设您可能有 1000 个用户 session ，但只有 20 个不同的热门搜索。如果这是真的，你可以这样做:

• 对于每个搜索过滤器，您可以存储结果的哈希值。
• 如果您更新主要数据，则会再次运行搜索，并且仅在哈希值发生变化时才向用户发送更新。

如果是公共(public)Web应用，则应该进行更多优化。例如。当应用程序没有焦点时不要发送更新。