我正在使用Spring-boot编写一个服务器端应用程序，例如app1。该app1访问专用DB服务器上的数据库db1。为了加快数据库访问速度，我将我的某些JPARepository标记为@Cacheable(<some_cache_key)，其有效时间为1小时。
问题是：db1在多个应用程序中共享，每个应用程序都可能更新其中的条目。
问题 ：通过使用应用程序（app1）内的缓存，我的@Cacheable能否获得性能提升？ （请注意，缓存位于我的应用程序内部，而不是数据库内部，即使用Redis这样的缓存管理器屏蔽整个数据库）
这是我的想法：
app2修改了数据库条目，那么app1中的缓存将如何知道该条目已更新？然后我的app1的缓存过时了，不是吗？ （直到在固定的1小时刷新周期后开始刷新）答案 0 :(得分：1)
那里有很多问题。
通过使用我内部的缓存，我的app1会获得性能提升吗？ 应用程序（@Cacheable）？
您应该始终对其进行基准测试，但是从理论上讲，访问缓存比数据库要快
如果另一个应用程序app2修改了数据库条目，缓存将如何 app1内部知道条目已更新？然后我的app1的缓存去了 陈旧，不是吗？ （直到固定的1小时后开始刷新 刷新周期）
除非使用集群缓存，否则不会更新。使用Terracotta群集的Ehcache就是这样的缓存。但是，如果您坚持使用基本的应用程序缓存，它将变得过时。
如果＃1是正确的，那么这是否意味着正确的设置方式 缓存应使用某种缓存管理器屏蔽整个数据库。是 Redis有这种用途吗？
现在它变得微妙了。我不是Redis专家。但据我所知，Redis经常用作缓存，但实际上是NoSQL数据库。而且它不会在前面（据我所知），它会放在一边。因此，您将首先查询Redis，以查看您的数据是否存在，然后查询数据库。如果数据库访问速度慢得多，并且缓存命中率很高，那么它将提高性能。但是请进行基准测试。
实际缓存（如Ehcache）效率更高。它们增加了近缓存的概念。因此，您的应用程序会将缓存条目保留在内存中，但也保留在缓存服务器上。如果条目被更新，则近缓存将被更新。这样一来，您不仅可以获得应用程序缓存的性能，而且还可以获得服务器之间的一致性。