- 在呈现层(希望不是)?
- 在业务逻辑层?
- 在数据层?
我发现自己在业务逻辑层的这里写了很多更新缓存的代码,所以是否更好地在数据库服务器的数据访问层之间创建一个织物来缓存数据?
我认为这些复杂性是由于我们大多数缓存的数据都是用户特定的,并且我们在缓存中重复使用数据。 我们正在努力找到最佳解决方案。
缓存是Web应用程序中的重要部分,但没有一种神奇的解决方案适用于每个项目。在应用程序正常运行之前进行优化通常不是一个好主意。在问自己应该在哪里实现缓存层之前,第一步是确保您的应用程序可以正常运行(即使速度很慢)而不需要任何缓存优化。
当完成第一步后,可以开始对应用程序进行分析,列出似乎使用了大量资源(可能是CPU、内存、I/O、数据库访问)或需要很长时间才能完成的功能列表(通常是由于相同的症状)。
一旦您有了认为可以使用缓存系统进行优化的功能列表,就需要问自己两个问题:
“如何同时改善所有这些功能”(宏观视角):对于这个问题,一个明显的答案通常是数据访问缓存。如果您总是获得相同的返回数据,那么通常不希望反复向数据库服务器发送相同的查询。因此,在缓存中存储这种类型的数据,并赋予聪明的生命周期,永远都是一个好主意。
“如何改善每个功能”(微观视角):这很棘手,您需要非常了解自己的应用程序才能找到答案。有些数据可以缓存,有些不应该缓存,有些必须不能缓存。调试器和分析器通常是此步骤的绝佳工具,因为它们可以帮助您确定为什么功能很慢,并为您提供如何进行优化的提示。
您将要找出的优化可能与应用程序的任何层(表示、业务逻辑、数据)相关,但这并不意味着您应该全部实现它们。有几个重要的事情您应该考虑:
一旦你得到了这些问题的答案,就可以与项目经理、同事甚至不与你共事的人谈论这个问题。拥有中立的意见以及非技术性(或少技术性)的意见是好的。与这些人交谈应该可以帮助你弄清楚哪些应该做和哪些不应该做。
此时,你应该已经有一个相当明确的优化清单,你已经反复思考过了,并且在编码和测试它们方面也没有任何问题。
缓存是一种性能优化方式,应该在瓶颈处使用。通过三次测量来确定瓶颈位置,然后再确认一次。
当你缓存数据时,要注意数据的松散一致性,例如,您不希望缓存您的所有股票交易应用程序。
数据层 - 在此层以上的所有层都不需要知道数据的来源。我也只会缓存那些不太容易变化的数据,或者包括一些过期策略。
缓存:在数据访问层实现,由业务逻辑层访问。
这意味着您必须仔细注意缓存过期的情况。
这是我首选的解决方案,如果需要,您可以添加超时、清除等功能。或者使用memcached或Microsoft Enterprise Library Caching Block,但它们通常过于复杂。
我不能代表ASP.NET具体的事情说话,但我通常发现你可以在每个级别上进行缓存。您的数据层将缓存数据响应,您的表示层可能会发现需要缓存生成的表示元素(例如用户特定的样式表),等等。在大多数情况下,数据层是最重的缓存用户,如果需要,其他层将包括对象缓存。
最困难的部分是正确地使缓存失效。在部署期间,陈旧的缓存是一个主要的头痛。确保弄清楚如何管理每个缓存对象的生命周期。基于需求的LRU缓存可用于缓存静态元素。然而,大多数数据缓存将需要明确的生命周期,无论是基于过期计时器还是与某种用户会话相关联。