什么时候去缓存/二级缓存？有具体的实际场景吗？答案

【问题标题】：When to go for Caching/Second level cache? Any practical scenario with specifics?什么时候去缓存/二级缓存？有具体的实际场景吗？
【发布时间】：2010-09-05 16:47:58
【问题描述】：

我正在开发一个属于汽车制造商的基于 Web 的应用程序，该应用程序是在 Spring-Hibernate 中使用 MS SQL Server 2005 数据库开发的。

通过此应用程序，最终用户可以通过基于 Web 的界面请求创建汽车、公共汽车、卡车等。当用户登录时，会显示一个 HTML 表单，用于捕获车辆的技术规格，例如，如果有人想请求汽车，他可以指定发动机品牌/型号、轮胎、底盘详细信息等。总共有 100 个表单元素在创建车辆请求屏幕上，其中 30% 是用于显示选项的下拉菜单（选择框）（即允许用户选择其中之一）。这些 SELECT 框从存储在数据库中的值（主数据）中填充。通过在后端运行存储过程，此主数据每周至少更改一次。

此应用程序在全球约有 10,000 名用户，我们预计每天最多有 5000 次新车请求点击，即将显示 5000 次“创建车辆”表单。

我的问题是，我是否需要使用 二级缓存 选项来存储从主数据显示的表单字段的值？

由于这些值是从一组每周仅更改一次的主表中显示的，我认为缓存主数据将有助于提高性能，但我不太确定，因为我还没有移动我的生产应用程序以查看真实性能并查看我是否真的需要缓存。

如果我使用缓存，我可能需要花一两个星期来弄清楚如何配置它，我不想花一两个星期看不到任何真正的好处？

在这方面需要专家帮助。另外，如果有人可以分享实际需要缓存的实际场景，那将有很大帮助。

【问题讨论】：

标签： hibernate caching ehcache second-level-cache oscache

【解决方案1】：

我的问题是，我是否需要使用二级缓存选项来存储从主数据显示的表单字段的值？

您不需要，但可以。并且只读数据（或大部分读取），例如不可变的参考数据（国家、州、税码，或者，在您的情况下，发动机、轮胎、底盘等）是第二级的完美候选者缓存（如果需要，还有查询缓存）。

由于这些值是从一组每周仅更改一次的主表中显示的，因此我认为缓存主数据将有助于提高性能，

嗯，根据硬件数量、集群大小等，您的应用可能只能处理负载。但正如我所写，缓存只读数据是很常见的：

每次都访问数据库并没有什么实际意义
- 从长远来看，避免这些命中并没有什么坏处，即使现在不是问题
它们不会经常更改，缓存它们很容易处理并且效果很好

请记住，缓存事物意味着它们的对象表示不会被垃圾收集，因此它可能会增加内存需求。

但我不太确定，因为我尚未将我的应用程序移至生产环境以查看真实性能并查看是否真的需要缓存。

老实说，您不应该等到生产时才查看是否存在性能问题。您应该先在专用环境中加载或压力测试您的应用程序，并调整您的应用程序、JVM、应用服务器、数据库等。不要忘记，您无法改进无法衡量的内容.

如果我使用缓存，我可能需要花一两周时间弄清楚如何配置它，我不想花一两周时间看不到任何真正的好处？

没那么复杂。您需要在 Hibernate 配置中激活二级缓存和查询缓存并选择缓存提供程序。我的建议是使用 EhCache，相关属性是：

hibernate.cache.use_second_level_cache=true
hibernate.cache.use_query_cache=true
hibernate.cache.provider_class=org.hibernate.cache.EhCacheProvider

然后，将相关实体标记为可缓存（如果您不按 id 加载用于检索数据的查询，则缓存它们）。

如果您决定使用二级缓存，则必须手动清除缓存，因为您不是通过 Hibernate API 更新数据，而是使用存储过程（使用 @987654323 上的 evict 方法） @)。这将需要一些代码行。如果可能的话，重新启动您的应用程序将是另一种选择。

【讨论】：

非常感谢。这回答了我的问题。

【解决方案2】：

每天 5000 次点击听起来流量很大，但请记住，这只是每分钟 3 次半的点击。假设您的数据库可以在不到几百毫秒的时间内执行呈现页面所需的所有查询，那么您可能没问题。

也就是说，缓存是一个很好的下一步。听起来查询缓存可能对您有用，因为您的数据很少更改。

【讨论】：