@Cacheable 会加速使用共享数据库的应用程序吗？
Will @Cacheable speed up application using a shared database?
我正在编写一个服务器端应用程序，比如 app1，使用 Spring-boot。此 app1 访问专用数据库服务器上的数据库 db1。为了加快数据库访问速度，我将我的一些 JPARepository 标记为 @Cacheable(<some_cache_key)，并带有过期时间，比如 1 小时。
问题是：db1 在多个应用程序之间共享，每个应用程序都可以更新其中的条目。
问题：通过在我的应用程序中使用缓存，我的 app1 会获得性能提升吗（@Cacheable)? （注意，缓存在我的应用程序中，而不是在数据库中，即用 Redis 等缓存管理器屏蔽整个数据库）
这是我的想法：
- 如果另一个应用程序
app2 修改了数据库条目，app1 中的缓存如何知道该条目已更新？然后我的 app1 的缓存就过时了，不是吗？ （直到它在固定的 1 小时刷新周期后开始刷新）
- 如果#1 是正确的，那么是否意味着设置缓存的正确方法应该是用某种缓存管理器屏蔽整个数据库。 Redis 适合这种用途吗？
所以，有很多问题。
Will I have performance gain in my app1 by using caches inside my
application (@Cacheable)?
您应该始终对其进行基准测试，但理论上，访问缓存比访问数据库要快
If another application app2 modifies a DB entry, how would the cache
inside app1 know that entry is updated? Then my app1's cache went
stale, isn't it? (until it starts to refresh after the fixed 1hr
refresh cycle)
除非您使用集群缓存，否则不会更新。使用Terracotta集群的Ehcache就是这样的缓存。但是，是的，如果您坚持使用基本的应用程序缓存，它会变得陈旧。
if #1 is correct, then does it mean the correct way of setting up
cache should mask the entire DB with some sort of cache manager. Is
Redis for such kind of usage?
现在它变得微妙了。我不是 Redis 专家。但据我所知，Redis 经常被用作缓存，但它实际上是一个 NoSQL 数据库。而且它不会在前面（再次，据我所知），它会放在一边。因此，您将首先查询 Redis 以查看您的数据是否存在，然后再查询您的数据库。如果您的数据库访问速度慢得多并且您的缓存命中率非常高，它将提高您的性能。但是请做一个基准测试。
真正的缓存（如 Ehcache）效率更高一些。他们添加了近缓存的概念。因此，您的应用程序会将缓存条目保存在内存中，但也会保存在缓存服务器上。如果条目被更新，近缓存将被更新。因此，您可以获得应用程序缓存性能以及服务器之间的一致性。
我正在编写一个服务器端应用程序，比如 app1，使用 Spring-boot。此 app1 访问专用数据库服务器上的数据库 db1。为了加快数据库访问速度，我将我的一些 JPARepository 标记为 @Cacheable(<some_cache_key)，并带有过期时间，比如 1 小时。
问题是：db1 在多个应用程序之间共享，每个应用程序都可以更新其中的条目。
问题：通过在我的应用程序中使用缓存，我的 app1 会获得性能提升吗（@Cacheable)? （注意，缓存在我的应用程序中，而不是在数据库中，即用 Redis 等缓存管理器屏蔽整个数据库）
这是我的想法：
- 如果另一个应用程序
app2修改了数据库条目，app1中的缓存如何知道该条目已更新？然后我的app1的缓存就过时了，不是吗？ （直到它在固定的 1 小时刷新周期后开始刷新） - 如果#1 是正确的，那么是否意味着设置缓存的正确方法应该是用某种缓存管理器屏蔽整个数据库。 Redis 适合这种用途吗？
所以，有很多问题。
Will I have performance gain in my app1 by using caches inside my application (@Cacheable)?
您应该始终对其进行基准测试，但理论上，访问缓存比访问数据库要快
If another application app2 modifies a DB entry, how would the cache inside app1 know that entry is updated? Then my app1's cache went stale, isn't it? (until it starts to refresh after the fixed 1hr refresh cycle)
除非您使用集群缓存，否则不会更新。使用Terracotta集群的Ehcache就是这样的缓存。但是，是的，如果您坚持使用基本的应用程序缓存，它会变得陈旧。
if #1 is correct, then does it mean the correct way of setting up cache should mask the entire DB with some sort of cache manager. Is Redis for such kind of usage?
现在它变得微妙了。我不是 Redis 专家。但据我所知，Redis 经常被用作缓存，但它实际上是一个 NoSQL 数据库。而且它不会在前面（再次，据我所知），它会放在一边。因此，您将首先查询 Redis 以查看您的数据是否存在，然后再查询您的数据库。如果您的数据库访问速度慢得多并且您的缓存命中率非常高，它将提高您的性能。但是请做一个基准测试。
真正的缓存（如 Ehcache）效率更高一些。他们添加了近缓存的概念。因此，您的应用程序会将缓存条目保存在内存中，但也会保存在缓存服务器上。如果条目被更新，近缓存将被更新。因此，您可以获得应用程序缓存性能以及服务器之间的一致性。