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

Question

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

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

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

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

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

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

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

Answer 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 更新数据，而是使用存储过程（使用 evict 方法） SessionFactory）。这将需要一些代码行。如果可能的话，重新启动您的应用程序将是另一种选择。

Answer 2

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

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