hibernate - 何时使用缓存/二级缓存？有具体的实际场景吗？

Question

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

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

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

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

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

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

需要专家的帮助。另外，如果有人可以分享真正需要缓存的实际场景，将会有很大的帮助。

Answer 1

My question is, Do i need to go with Second level cache option for storing the values for form field getting displayed from master data?

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

Since these values are getting displayed from a set of Master tables that will change once a week only, I'm thinking caching of master data will help improving performance,

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

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

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

but I'm not too sure as I've yet to move my application to Production to see the real performance and to see, if i really need caching.

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

If I go with caching, I might need to spent a week or two figuring out how to configure that and I don't wanted to spend a week or two without seeing any real benefit?

其实没那么复杂。您需要在 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 更新数据，而是使用存储过程(使用 evict SessionFactory 上的方法)。这将需要一些代码行。如果可能的话，重新启动您的应用程序将是另一种选择。