最佳缓存解决方案

在基于Web的应用程序中实现缓存的最佳位置在哪里？

在表示层(希望不是)？

在业务逻辑层？

在数据层？

我将使用像memcached或MS Velocity这样的东西.

我只是发现自己编写了如此多的代码来更新业务逻辑层中的缓存,那么在数据库服务器的数据访问层之间创建一个结构来缓存数据会更好吗？

我认为这些复杂性是事实,我们缓存的大部分数据都是用户特定的,我们正在复制缓存中的数据.我们努力寻找最佳解决方案.

缓存是一个重要的部分或Web应用程序,但没有适合每个项目的神奇解决方案.在应用程序运行之前进行优化通常是个坏主意.在问自己应该在哪里实现缓存层之前,第一步是确保您的应用程序在没有任何缓存优化的情况下运行良好(即使很慢).

当第一步实现时,您可以开始分析应用程序,列出似乎使用大量资源的功能(可能是CPU,内存,I/O,数据库访问)或花费大量时间来完成(通常是因为相同的症状).

一旦你有一个你认为可以用缓存系统优化的功能列表,你需要问自己两个问题:

"我怎样才能同时改进所有这些功能"(宏观焦点):这个问题的一个明显答案通常是数据访问缓存.如果您获得的数据始终相同,您通常不希望一遍又一遍地向数据库服务器发送相同的查询.因此,将这种类型的数据存储在缓存中,具有巧妙的使用寿命,总是一个好主意.

"我如何改进每个功能"(微焦点):这很棘手,你需要很好地理解你的应用程序来解决这个问题.有些数据可以缓存,有些则不应该,有些则不能.调试器和分析器通常是此步骤的绝佳工具,因为它们可帮助您确定功能缓慢的原因,并为您提供有关如何优化功能的提示.

您要弄清楚的优化可能与您的应用程序的任何层(表示,业务逻辑,数据)有关,但这并不意味着您应该全部实现它们.您应该考虑以下几个重要事项:

这个功能真的需要优化吗？(这对客户来说是一个显着的收益吗？对于硬件？对于整个应用程序？对于其他应用程序？)

我可以获得什么样的性能提升？(1%,200%,...)

我需要多长时间来优化它？(1小时,12天,...)

优化它有多大的风险？(它可能会破坏应用程序的内容吗？对于客户？)

一旦您获得了这些问题的答案,就可以与您的项目经理,您的同事,甚至那些不与您一起处理该应用程序的人员讨论这个问题.持中立意见是好的,并且有非技术性(或技术性较低)的意见.与这些人交谈应该可以帮助你弄清楚应该做什么和不应该做什么.

此时,您应该有一个非常清楚的优化列表,您已经多次考虑过,并且编码和测试它们应该没有问题.

缓存是一种性能优化,因此在瓶颈所在的地方也是如此.通过测量三次然后再次测量瓶颈,你知道瓶颈在哪里.

缓存时要注意数据的宽松一致性,例如,您不想缓存所有股票交易应用程序.

您应该考虑在每一层进行缓存。

缓存的最佳位置是尽可能接近客户端请求（因此，您要做的工作尽可能少以响应）。在Web应用程序中，在表示层，业务层和数据层是。

（附带说明：如果您基本上是在各处使用缓存逻辑来添加业务逻辑代码，则应该真正考虑将关注点分离，以免您的代码陷入困境：-)）