Question

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

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

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

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

现在，我向用户发送一条通知，告知地图已更新，然后每个用户都加载用户所需的完整数据。例如，项目8已更新。即使更新仅在项目8上，User1也会收到通知并再次加载项目1、2、3。因此，在这种情况下，无需为User1进行更新，因为他不需要项目8。

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

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

仅将添加/更新/删除的项目发送给用户并且仅在用户需要该项目的情况下，这才是一个好的解决方案？因此，就像只观察基本地图（缓存）的一部分，但是对每项操作（例如添加，更新和删除项目）都发出通知。

Answer 1

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

要问的问题：

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

最大的问题：

真的需要吗？

查看大量搜索界面，用户只有在存在交互时才期望进行更新。如果它类似于搜索，则用户将不会期望即时更新。即时更新可能是有用且“创新的”，但是您确实为此花费了很多工程成本。

因此，在执行工程任务之前，请确保收益可证明成本合理。也许先检查这些替代方法：

不要这样做。仅更新用户交互。也许添加一个重新加载按钮。
仅通知用户发生了更新，但仅在用户单击“重新加载”时更新。这解决了用户可能没有将浏览器选项卡放在焦点上并且转移是浪费的问题。

但是我担心的是，如果我有很多用户，并且带有项目ID的用户列表也可能很大，这将造成内存使用情况。

在我们的应用程序中，我们观察到没有太多不同的搜索模式/过滤器。假设您可能有1000个用户会话，但是只有20种不同的热门搜索。如果是这样，您可以执行以下操作：

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

如果它是公共Web应用程序，则应进行更多优化。例如。当应用程序没有焦点时，请勿发送更新。

Java内存缓存以及每个客户端的子缓存

1 个答案: