我正在使用带有maven的spring boot创建一个存储库来存储搜索文章的结果，我通过pagination显示这些结果，界面如下：
public interface HelpArticleSearchRepository extends CrudRepository<HelpArticleSearchResults, Integer> {
Page<HelpArticleSearchResults> findAll(Pageable pageable);
}
我的问题是：我从REST API查询中获取搜索文章的结果，响应非常慢。
所以，我在网上搜索缓存解决方案，但我找到的解决方案似乎只适用于methods，它返回用于将数据存储到存储库中的同一个类实例。像：
我希望得到一个适用于pagination的解决方案，但我还是刚刚开始使用的新手，所以这是一个巨大的挑战。
请指出我正确的方向，我很乐意提供任何其他信息。
答案 0 :(得分：2)
缓存和分页是独立的问题。假设您有一些Rest API用作主要数据源，并且运行缓慢。因此，您想创建一些响应速度更快的缓存（尚无分页问题）。当然，与您的缓存一起出现的所有相关问题，例如过时的数据，“命中和遗漏”等等。假设您已解决了这些问题，现在您已经有了一个分层的数据源，该数据源具有主要的慢速数据源并在其前面进行了缓存。现在，在您的findAll方法中，您依赖于Spring boot为您提供的分页功能（无论使用何种数据源）。顺便说一句，您的存储库应该扩展PagingAndSortingRepository，而扩展CrudRepository。参见参考文献here
答案 1 :(得分：1)
您可以缓存findAll结果（而不是缓存分页结果）并处理服务层中的分页部分。
详细： 第1步：对于第一个请求-我们将缓存findAll结果，即对于List findAll（）; 第2步：现在将在serviceLayer上处理分页并发布结果 第3步：从下一个请求开始，您将引用缓存的结果并从缓存中发送所需的记录集
根据您的应用程序正在处理的业务类型，可以配置缓存寿命，以便定期刷新缓存。还请记住设置缓存的最大大小。
答案 2 :(得分：1)
如果我不会受到字符数的限制，我不会将其发布为Aswer，因为这不是您问题的实际答案。正如您所说的那样，这将是对您的需求的质疑，因为您是这个领域的新手。看。在开发的早期阶段进行缓存的典型方法是：不进行缓存。这可能是您错了。如果您需要从一开始就进行缓存，那么我认为这不好，除非您有特殊情况。
下一步。您的用例是什么？您使用缓存，因为有人经常调用findAll？这是非常奇怪的设计，因为假设您的数据库具有数百万条记录。如果以这种方式进行缓存，则只需将整个数据库（理论上）移入内存即可。如果“所有数据”没有那么大，那么findAll将不需要那么多时间，并且不需要缓存。但是，如果有很多，那么每次都可能没人想要它们，即使它们这样做并且您以某种方式使用了缓存，您的整个表（500M行表）是否也适合内存？因此，正如其他人所说，您想要分页。如果发现这不太可能，那么其他客户端将经常调用findAll，对于具有大量记录的数据库表，我根本不会公开此端点。
好的，所以您有分页或相对较小的桌子。您想要缓存这些记录。如果您使用休眠模式，也许您想使用L2缓存，它将为您正确地缓存持久性上下文（实际上，缓存并不那么容易。）
总结：如果可能，请更改设计以不使用findAll。如果不可能，请使用现有的解决方案，例如L2缓存。仅当您确实没有其他选择或确实知道自己在做什么时，才使用自己的db结果缓存实现。