Spring Boot 3.2项目中使用缓存Cache的正确姿势！！!|boot|request|spring|服务器|调用|速度

点击下方“JavaEdge”，选择“设为星标”

第一时间关注技术干货！

免责声明~ 任何文章不要过度深思！万事万物都经不起审视，因为世上没有同样的成长环境，也没有同样的认知水平，更「没有适用于所有人的解决方案」；不要急着评判文章列出的观点，只需代入其中，适度审视一番自己即可，能「跳脱出来从外人的角度看看现在的自己处在什么样的阶段」才不为俗人。怎么想、怎么做，全在乎自己「不断实践中寻找适合自己的大道」

你是否曾想过为什么在 Spring Boot 应用中缓存是如此重要？答案在于它通过减少数据检索时间来提高性能。在本文中，我们将深入探讨缓存对微服务模式的影响，并探讨根据操作易用性、速度、可用性和可观测性等因素选择正确缓存的重要性。我们还将探讨如何最大程度地提高缓存性能和可用性。

1 缓存实现 1.1 缓存对微服务模式的影响

考虑这样的情景，其中一个 Edge API 开放给互联网，触发对服务 A 和 B 的额外请求，这两个服务反过来调用服务 C 和 D。通过引入客户端缓存，可以显著提高应用程序性能并打破这种依赖链。

1.2 选择正确的缓存

在选择正确的缓存之前，我们必须了解我们应用的需求，并根据以下因素选择缓存：

操作易用性 — 是否需要向系统添加新组件？
速度 — 从缓存检索或设置值需要多长时间？
可用性 — 它如何提高系统的整体可用性？
可观测性 — 系统的状态推理有多容易？

2 缓存类型

有三种不同类型的缓存：

2.1. 本地缓存

仅限于应用程序/节点运行的本地实例
由于数据存储在本地，所以速度更快
由于数据与其他缓存不共享，缺乏一致性
在需要在多个节点之间共享大量数据的情况下效率低
用例场景：当数据特定于单个实例且不需要在不同实例之间共享数据时

Local Cache：

由于缓存在多个实例之间共享，缓存的数据可由系统中的任何节点访问（用例：多个实例需要共享一个公共缓存）

由于网络延迟，从远程节点访问数据可能需要一些时间，但并非总是如此

由于每个实例将其更改传播到其他节点，因此一致性

可高度扩展

Distributed Cache：

每个客户端副本都保留本地缓存和远程缓存，作为回退

这类似于 CPU 缓存

if local_cache_hit(request):
return get_from_local_cache(request)
else:
if remote_cache_hit(request):
return get_from_remote_cache(request)
else:
response = call_a(request)
set_local_cache_in_background(response)
set_remote_cache_in_background(response)
return response

每种缓存的目标都是最大程度地增加缓存命中，以提高系统的整体性能。那么在实际设置中，当我们有定期更新的动态数据并且还存储缓存内容以获得所需输出时，我们该如何做呢？

可为缓存设置生存时间（TTL）。如果我们为我们的缓存设置长时间的 TTL，比如近 24 小时，我们可能会读取陈旧的数据，另一方面，较短的 TTL 将增加新鲜度，但经常调用服务器可能会导致可用性和延迟问题。

我们将讨论一些策略，如面向事件驱动架构的主动失效和对于服务器不发出事件的情况下的后台刷新。

主动失效→ 用于事件驱动架构的最常见用法。每当服务器发出事件时，客户端都会监听它并更新缓存并清除不必要的缓存数据。我们可以设置较长的 TTL，知道过时的条目将被主动失效。
后台刷新→ 如果服务器不发出事件，我们可以在后台刷新条目，即使是缓存命中。我们的数据可能会变得不那么陈旧，而延迟将大大降低。

3 结论

实质上，在 Spring Boot 中进行缓存是提高性能的关键。从打破依赖关系到优化命中，它是微服务世界中高效和响应性系统的重要工具。