关于系统性能的思考

 在评价一个系统的时候，性能指标是很重要的，那么在当前J2EE的系统开发当中，如何来提高系统的性能呢？我觉得应该从对象管理入手，从对象的生命周期开始。虽然大家可能会说，Java有垃圾收集器，我们的对象的生命周期不需要我们自己管理，但是如果要是真的过分依赖java语言本身的特性，那么我相信，系统的性能肯定好不到哪去。所以，下面就主要从三个方面入手来说一下我的想法。

第一：容器化系统功能性组件

    在每个系统中，我想都会存在功能性的组件，比如当前开发当中的service，这些功能性的服务一般来说都是没有状态的，是可以多用户共享的，这种共享的服务对象，我们也需要将其进行统一的管理，幸运的是目前已经存在很多这样的管理功能性服务的框架或者容器，比如目前比较流行的各种IOC容器，或者是重量级的EJB容器，它们都提供了对系统中各种服务组件的管理。

第二：缓存化业务对象

  在说缓存之前，我不得不说一下面向对象的设计，可能有些人认为，为什么缓存会与面向对象的设计扯上关系，其实这就是缓存的关键。首先设想一下，如果开发系统的过程中，都是采用面向过程，面向数据库的思维编程，每一次业务操作，我们都是调用通过数据库操作来完成，这其实就是POEAA中的事务脚本，只适合一些简单的系统的开发，或者一个项目中，比较简单模块的开发，对于复杂的模块，更好的方式就是采用面向对象的方法来进行开发。

  好了，说到了面向对象的设计问题，至于这个问题已经有很多书籍以及很多人讨论了很多年了，就我个人来说，我觉得采用DDD建模是目前比较适合的一种方式。DDD中涉及到得每种模式或者说是每一种模型元素对于缓存设计来说都是很重要的，下面我说说我的想法：

 首先我说一下关于聚合的问题，为什么说聚合对于缓存非常重要呢？这其实涉及到了一种控制访问的问题，一个聚合根控制了对整个聚合的访问，要想访问聚合里的对象必须要通过聚合的根。

 好了，我们以一个实例来说话，比如一个论坛的设计，论坛中有Forum以及ForumState对象，Forum对象是聚合的根，是一个实体模型，而ForumState是一个值对象，并且是属于Forum这个聚合根的子对象，我们把ForumState对象从Forum对象分离出来，好处主要有两个，从事务的角度来说，当我们更新ForumState对象的时候，不用锁住Forum对象，从缓存设计的角度来说，当我们更新ForumState对象的时候不用刷新Forum对象的缓存，因为Forum不是经常改变的，所以不必要因为经常改变属性的改变而改变。那么具体怎么来设计呢？我们可以这样做，在ForumState对象中设置一个状态位，表示它的状态是否已经改变，当Forum状态发生改变，比如有人创建新的帖子或者回复了帖子后，我们可以设置这个状态位为true，表示状态已经改变，这样当再次从缓存中取得Forum时，查看状态位，如果发现已经变化了，那么就重新从数据库加载ForumState。当然要想达到这种效果，我们一定要设计好聚合，所有对子对象的访问都要通过聚合的根，比如所有对ForumState对象的访问都要经过Forum对象，并且要保证所有的数据库操作，都首先从统一的缓冲入口进行，这样保证了整个系统中用的是同一个缓存，大家操作的所有对象都是同一个缓存中的对象。所以这里也给出了一条对象设计的提示，将经常变化的熟悉和不经常变化的属性分开，并且将经常变化的属性独立出去，作为聚合根的 一个子对象，这样做到变和不变分离，不仅有利于高内聚，而且有利于事务的控制和缓存的更新。

 

 

 

<!--EndFragment-->

   上面是关于Repository在对象建模中的作用，下面我也说说关于工厂的作用，既然是工厂，那么它肯定要生产东西出来，但是它不能随便乱生产，它生产出来的应该是整个聚合的根，并且要保证这个聚合的不变量受到保护，这样通过工厂提供一个集中的模型创建的访问点，也方便了控制访问。要设计一个好的工厂，我们首先需要设计一个好的对象模型，分辨出合理的聚合，这样工厂才会发挥真正的效力。

    最后既然说到了缓存，还有一点需要注意，那就是这个缓存的范围，我这里说的缓存是全局的缓存，是一个application级别的缓存。我个人是比较反对在Httpsession中保存大量数据的，这样当用户增多的情况下，比如会浪费很多的内存，浪费性能。所以我们更应该需要的是全局的缓存，这样底层的缓冲框架我们还可以采用分布式的缓存系统，这样以来我们的系统在集群环境下也免去了一些session failover的开销。这其实也是一种SNA架构的思想。

第三：数据库系统优化

 数据库在我们大多数的系统开发中都会涉及到，这方面的优化，主要是基于一些索引等的优化。

    最后，我想说的就是我们应该尽量采用一种面向对象的方式来开发我们的系统，而不是过分的依赖数据库来编程，在系统开发当中，我们操作具体的模型对象，而我们的模型对象由存储在缓存中，尽量减少对数据库的访问操作，从而提升系统的性能。

 

 

 总结上面所述，要想提高系统的性能，我们面临的难题就是对象建模，只有我们针对自己的具体的业务有了合理的对象模型后，我们才能有针对性的对业务对象进行缓存，从而使得缓存的效果最大化，提高系统的性能。

<!--EndFragment-->

评论

25 楼 凤舞凰扬 2009-05-01  

   给楼主三个建议做个小小的点评吧。
1. 池化服务器组件：其实按照楼主的意思，更加应该是指容器化（EJB有池，但是Spring似乎没池）。而如果是容器化的话，那么它的目的并不是对性能的优化（如果只是减少对象的产生，工厂就够了）。即使是池，也面临另外一个问题，那就是池对象的泄漏处理（比如讲，一个程序在大循环中从池中获取组件，或者获取组件后并不归还）。对于类似于数据库的连接池来说，因为对象是继承实现同一接口的，那么也就是容易有一个池实现。而对于基于POJO的服务组件来说，去实现这样一个池支持的实现（解决上述泄漏问题）并不容易。
2.  缓存：没错，如果一个企业级系统没有使用缓存或者没有使用好缓存，是绝对不可能获取良好性能的。但是在大型企业系统中，使用缓存又得面临几个问题。第一，如果存在分布式的负载均衡或集群，缓存间的同步；缓存失效的设定，对于业务数据，是需要准确的读写分析，否则的话，缓存算法就成了空谈。也许许多人都认为LRU是最合适的，其实并非如此，许多时候，固定时间失效是常用的。
3.  数据库系统优化：也许每个人都认为它影响了系统的性能，这话并没错。但实际上是大家低估了数据库的处理能力。真正最为常见地影响软件系统性能的是对数据库的访问，而非数据库本身的优化。这种访问包括：比如循环中去读取数据库，比如滥用ORM工具，比如采用非索引查询等等。

    楼主看到的只是影响系统性能的表面，这些问题的原因也许所谓的书中或者忽悠的咨询师口中是经常见的。但真正解决系统性能的优化是无定式的，是需要架构师根据实际情况分析的。

24 楼 taelons 2009-05-01  

一个系统通常要考虑的不是性能，而是吞吐量和响应时间的均衡。脱离的实际的生产环境去讨论性能，意义不大。性能高并不一定单位时间内完成的笔数就一定多。

23 楼 shuai45 2009-04-30  

狂放不羁 写道

sdh5724 写道

楼上几位一点都不实在。 从技术角度出发讨论问题比较好。

呵呵，请问一下有几个软件公司是单纯靠技术生存的。做企业级开发的软件公司不一定都是技术很好，人家也许技术一般般，但是人家对某个领域的业务非常熟悉，在业务上的精通再加上人家一般般的技术照样可以做出让客户满意的系统。技术虽然重要，但是请别忽视真正软件的核心：业务，领域模型。也许技术都换了很多代，但是核心的领域模型还是不变的。

同意。
  没有不能实现的技术。你能想到的 技术都可以实现。从当初的web1.0的静态页到现在的动态交互，从当初的struts到现在多框架局面，可以说技术只是一个永不废弃的过度。而技术依赖于项目的整体设计，设计如果存在遗憾或缺点 那么再好的技术也不达到实现目的。
   当然了 项目的设计也是技术 但 单从一点的技术来说 系统的性能优化还远远不够。
包括 设计、软件实现、硬件实现。 不知说的对错哈，不要喷我。

22 楼 狂放不羁 2009-04-29  

sdh5724 写道

楼上几位一点都不实在。 从技术角度出发讨论问题比较好。

呵呵，请问一下有几个软件公司是单纯靠技术生存的。做企业级开发的软件公司不一定都是技术很好，人家也许技术一般般，但是人家对某个领域的业务非常熟悉，在业务上的精通再加上人家一般般的技术照样可以做出让客户满意的系统。技术虽然重要，但是请别忽视真正软件的核心：业务，领域模型。也许技术都换了很多代，但是核心的领域模型还是不变的。

21 楼 fjlyxx 2009-04-29  

sdh5724 写道

楼上几位一点都不实在。 从技术角度出发讨论问题比较好。

呵呵 我相信很多人都有这么一种感觉,就是不愿意维护以前的系统,如果允许的话宁愿重新开放. 其实很多时候重新开放并不是使用新的技术,恰恰相反很多时候重新开放就是在脱衣服,减轻原有系统.其实这是一种业务理解的提升. 因为你接触这个业务的高度不一样了.你是站在前人的基础上进行业务分析.
所以我不同意楼上的说法,如果单从技术角度去解决性能的问题终极还是有瓶颈的,当然我这种想法是不现实的,因为业务的重新挖掘其实就是一个重新开发的过程( 当然你可以说是重构)
总之一句话,最原始的业务模型抽象已经决定了你系统的性能大小.

20 楼 sdh5724 2009-04-29  

楼上几位一点都不实在。 从技术角度出发讨论问题比较好。

19 楼 狂放不羁 2009-04-28  

fjlyxx 写道

人讲究性能,机器也讲究性能.人和机器一样,性能无非就受两点影响1.先天因素 2.后天培养
先天因素我们无法改变,人就长成那样了或者机器就那个配置了,这种情况没啥办法.
后天培养倒是可以提高一点性能,但是提高的有限度.就好比你没有办法让手机跑ORACLE一样,
架构和性能绝对是唱反调的.人为了道德要穿衣服,但是穿上了越好的衣服性能也就受越大的影响(最起码时间上没有不穿的快).

技术可以提高性能,池话,负载均衡,分布式都可以提高性能,但是这些都有瓶颈.这就好比人的药物治疗,不治本.

业务设计才是提高性能的王道.业务是一个系统的灵魂,就好比是人类的DNA.改造DNA 进行业务的深度分析才能从根本上提高性能.

有道理，业务设计才是软件的灵魂，严重同意。

18 楼 vlinux 2009-04-28  

fjlyxx 写道

人讲究性能,机器也讲究性能.人和机器一样,性能无非就受两点影响1.先天因素 2.后天培养
先天因素我们无法改变,人就长成那样了或者机器就那个配置了,这种情况没啥办法.
后天培养倒是可以提高一点性能,但是提高的有限度.就好比你没有办法让手机跑ORACLE一样,
架构和性能绝对是唱反调的.人为了道德要穿衣服,但是穿上了越好的衣服性能也就受越大的影响(最起码时间上没有不穿的快).

技术可以提高性能,池话,负载均衡,分布式都可以提高性能,但是这些都有瓶颈.这就好比人的药物治疗,不治本.

业务设计才是提高性能的王道.业务是一个系统的灵魂,就好比是人类的DNA.改造DNA 进行业务的深度分析才能从根本上提高性能.

说得很对呀

17 楼 whaosoft 2009-04-27  

SNA架构 是什么呀 还真不知道

16 楼 狂放不羁 2009-04-27  

shuai45 写道

有没有成型的设计作品或思路。发表一下，我借鉴一下。

其实设计思路，我觉得采用DDD那本书上说的就不错，可惜呢?国内很少用啊，就包括我现在公司的建行项目组也都是用的传统的开发方式，毕竟大环境没办法改变，下午还要去参加建行项目的培训，就先写到这里。

15 楼 狂放不羁 2009-04-27  

puroc 写道

引用

第一：池化系统的功能性组件
    在每个系统中，我想都会存在功能性的组件，比如当前开发当中的service，这些功能性的服务一般来说都是没有状态的，是可以多用户共享的，这种共享的服务对象，我们也需要将其进行统一的管理，幸运的是目前已经存在很多这样的管理功能性服务的框架或者容器，比如目前比较流行的各种IOC容器，或者是重量级的EJB容器，它们都提供了对系统中各种服务组件的管理。

我的理解是，为了提高对象的重复利用，对于有状态的对象是可以放到池里的。比如线程池中的线程，线程是忙还是空闲，这就是线程的状态，连接池中的连接也一样。你上面提到的service，就像你说的，他是无状态的。那么他就应该做成一个单例。就像你说的，会用到IOC。这里，我只是觉得你的描述与“池化系统的功能性组件”不太符合。

呵呵，谢谢。我这里是普通意义的池，EJB stateless session bean就是池化管理，而对于轻量级容器的单例实例，我可以理解为只有一个实例的池，总之是为了重用。我觉得有状态的对象是不需要放到池里的，有状态的对象是没有办法重用的，没有办法重用的东西放到池里没什么意义。有状态的组件比如ejb的statefull session bean采用钝化和激活的方式来管理。或者也可以采用session来hold。

14 楼 puroc 2009-04-27  

liujunsong 写道

要提高性能,最关键的是客户端和服务器的合理分工.
现在啥事情都扔给App服务器去干,最后不慢才怪.
把界面方面的事情扔给客户端,后台只提供数据服务,自然性能就高了.
光限制在服务器上折腾,是不能从根本上解决问题的..

说的很对。但有的时候，啥功能做在服务端，啥功能做在客户端，是有很多因素在里面的。不是单纯从技术的角度出发可以决定的。更不是我们说了算的。深受其害中

13 楼 puroc 2009-04-27  

引用

第一：池化系统的功能性组件
    在每个系统中，我想都会存在功能性的组件，比如当前开发当中的service，这些功能性的服务一般来说都是没有状态的，是可以多用户共享的，这种共享的服务对象，我们也需要将其进行统一的管理，幸运的是目前已经存在很多这样的管理功能性服务的框架或者容器，比如目前比较流行的各种IOC容器，或者是重量级的EJB容器，它们都提供了对系统中各种服务组件的管理。

我的理解是，为了提高对象的重复利用，对于有状态的对象是可以放到池里的。比如线程池中的线程，线程是忙还是空闲，这就是线程的状态，连接池中的连接也一样。你上面提到的service，就像你说的，他是无状态的。那么他就应该做成一个单例。就像你说的，会用到IOC。这里，我只是觉得你的描述与“池化系统的功能性组件”不太符合。

12 楼 shuai45 2009-04-27  

有没有成型的设计作品或思路。发表一下，我借鉴一下。

11 楼 狂放不羁 2009-04-27  

shuai45 写道

狂放不羁 写道

shuai45 写道

“我觉得全局application缓存会比较好，session中尽量少保存数据。”
目前有很多缓存框架。OSCACHE就非常不错。我没做过大项目，基本都是数据库能解决的就用数据库。
实在解决不了 或者性能存在一些问题 就通过程序 上解决。不过这样做 并不好，完全的被动。所以 一个项目要从设计上就考虑优化，而且可扩展。
这样的经验 实在太少。希望LZ把你的开发经验分享一下。

对于如何设计一个扩展的业务对象模型，我目前也处于探索中，但是我敢肯定的就是设计对象模型是一定要划分出一个边界，然后设计为一个聚合，这样整个对象模型由不同的聚合来构成，并且访问聚合内部的对象都要通过聚合根来控制。这样提供一个全局的访问控制点，便于维护和管理。并且我们设计聚合的时候，一定要区分出根对象中哪些属性是经常变化的，哪些不是经常变化，这样我们可以把经常变化的属性独立出来，作为一个值对象。这样通过对对象的细粒度的设计，我们可以更容易控制我们的缓存。所以我觉得对象生命周期很重要，这就设计到了DDD中的工厂和仓库两个模式，我目前的设计中，我是通过工厂来控制对象生命周期的起始，并且保证对象创建出来的聚合根式满足系统不变量的约束的，那么对象创建以后，其它的生命周期交给仓库管理。仓库(repository)管理对象创建以后的生命周期，我觉得这个时候就要使用缓存来管理了，我们要想得到领域对象，只能从一个地方来获得，那就是仓库，而仓库首先通过一个全局的缓存中去获得对象，如果缓存中没有就从数据库或者其它持久性数据源得到对象，然后放到缓存中，这样系统中的所有对对象的访问，都需要经过统一的地方：仓库。当系统中发生了引起领域对象状态变化的操作以后，我们可以清空缓存中的对象或者只清空领域对象的一部分，比如分离出来的状态。

最后使用全局的缓冲还有一个好处，那就是集群环境下面，因为我们可以把全局缓冲通过一个分布式的缓冲透明的替换，这样减少了不同节点之间同步session，以及session failover的开销，这其实就有点SNA的味道了。呵呵。



不知道您有没有读过：<<领域驱动设计>>这本书，这本书我觉得非常好，如果没看过，推荐您看看。这里面详细简介了如何开发一个针对于自己当前业务状态的对象模型。

听楼主的意思，我感觉是 设计模式+CHCHE的组合呢。就是把缓存的意思设定在设计模式的基础上。如果这样的话，缓存的意思感觉存在性不大。重点的是项目的整个设计。看来还是以设计为主。可扩展、高性能在是主要，至于技术实现 是次要。

我的意思不是您说的“设计模式+cache”，cache缓存什么东西才有意义呢？那其实就是针对不同的系统的业务对象模型，而要想能在并发环境下容易控制业务对象模型，那么业务对象的设计，封装时非常重要的，这个时候聚合的作用性就很重要。所以要想能发挥真正缓存的效力，一个优良的系统业务对象模型是非常重要。

10 楼 shuai45 2009-04-27  

fjlyxx 写道

人讲究性能,机器也讲究性能.人和机器一样,性能无非就受两点影响1.先天因素 2.后天培养
先天因素我们无法改变,人就长成那样了或者机器就那个配置了,这种情况没啥办法.
后天培养倒是可以提高一点性能,但是提高的有限度.就好比你没有办法让手机跑ORACLE一样,
架构和性能绝对是唱反调的.人为了道德要穿衣服,但是穿上了越好的衣服性能也就受越大的影响(最起码时间上没有不穿的快).

技术可以提高性能,池话,负载均衡,分布式都可以提高性能,但是这些都有瓶颈.这就好比人的药物治疗,不治本.

业务设计才是提高性能的王道.业务是一个系统的灵魂,就好比是人类的DNA.改造DNA 进行业务的深度分析才能从根本上提高性能.

严重认同此观点。

9 楼 shuai45 2009-04-27  

狂放不羁 写道

shuai45 写道

“我觉得全局application缓存会比较好，session中尽量少保存数据。”
目前有很多缓存框架。OSCACHE就非常不错。我没做过大项目，基本都是数据库能解决的就用数据库。
实在解决不了 或者性能存在一些问题 就通过程序 上解决。不过这样做 并不好，完全的被动。所以 一个项目要从设计上就考虑优化，而且可扩展。
这样的经验 实在太少。希望LZ把你的开发经验分享一下。

对于如何设计一个扩展的业务对象模型，我目前也处于探索中，但是我敢肯定的就是设计对象模型是一定要划分出一个边界，然后设计为一个聚合，这样整个对象模型由不同的聚合来构成，并且访问聚合内部的对象都要通过聚合根来控制。这样提供一个全局的访问控制点，便于维护和管理。并且我们设计聚合的时候，一定要区分出根对象中哪些属性是经常变化的，哪些不是经常变化，这样我们可以把经常变化的属性独立出来，作为一个值对象。这样通过对对象的细粒度的设计，我们可以更容易控制我们的缓存。所以我觉得对象生命周期很重要，这就设计到了DDD中的工厂和仓库两个模式，我目前的设计中，我是通过工厂来控制对象生命周期的起始，并且保证对象创建出来的聚合根式满足系统不变量的约束的，那么对象创建以后，其它的生命周期交给仓库管理。仓库(repository)管理对象创建以后的生命周期，我觉得这个时候就要使用缓存来管理了，我们要想得到领域对象，只能从一个地方来获得，那就是仓库，而仓库首先通过一个全局的缓存中去获得对象，如果缓存中没有就从数据库或者其它持久性数据源得到对象，然后放到缓存中，这样系统中的所有对对象的访问，都需要经过统一的地方：仓库。当系统中发生了引起领域对象状态变化的操作以后，我们可以清空缓存中的对象或者只清空领域对象的一部分，比如分离出来的状态。

最后使用全局的缓冲还有一个好处，那就是集群环境下面，因为我们可以把全局缓冲通过一个分布式的缓冲透明的替换，这样减少了不同节点之间同步session，以及session failover的开销，这其实就有点SNA的味道了。呵呵。



不知道您有没有读过：<<领域驱动设计>>这本书，这本书我觉得非常好，如果没看过，推荐您看看。这里面详细简介了如何开发一个针对于自己当前业务状态的对象模型。

听楼主的意思，我感觉是 设计模式+CHCHE的组合呢。就是把缓存的意思设定在设计模式的基础上。如果这样的话，缓存的意思感觉存在性不大。重点的是项目的整个设计。看来还是以设计为主。可扩展、高性能在是主要，至于技术实现 是次要。

8 楼 fjlyxx 2009-04-25  

人讲究性能,机器也讲究性能.人和机器一样,性能无非就受两点影响1.先天因素 2.后天培养
先天因素我们无法改变,人就长成那样了或者机器就那个配置了,这种情况没啥办法.
后天培养倒是可以提高一点性能,但是提高的有限度.就好比你没有办法让手机跑ORACLE一样,
架构和性能绝对是唱反调的.人为了道德要穿衣服,但是穿上了越好的衣服性能也就受越大的影响(最起码时间上没有不穿的快).

技术可以提高性能,池话,负载均衡,分布式都可以提高性能,但是这些都有瓶颈.这就好比人的药物治疗,不治本.

业务设计才是提高性能的王道.业务是一个系统的灵魂,就好比是人类的DNA.改造DNA 进行业务的深度分析才能从根本上提高性能.

7 楼 狂放不羁 2009-04-24  

shuai45 写道

“我觉得全局application缓存会比较好，session中尽量少保存数据。”
目前有很多缓存框架。OSCACHE就非常不错。我没做过大项目，基本都是数据库能解决的就用数据库。
实在解决不了 或者性能存在一些问题 就通过程序 上解决。不过这样做 并不好，完全的被动。所以 一个项目要从设计上就考虑优化，而且可扩展。
这样的经验 实在太少。希望LZ把你的开发经验分享一下。

对于如何设计一个扩展的业务对象模型，我目前也处于探索中，但是我敢肯定的就是设计对象模型是一定要划分出一个边界，然后设计为一个聚合，这样整个对象模型由不同的聚合来构成，并且访问聚合内部的对象都要通过聚合根来控制。这样提供一个全局的访问控制点，便于维护和管理。并且我们设计聚合的时候，一定要区分出根对象中哪些属性是经常变化的，哪些不是经常变化，这样我们可以把经常变化的属性独立出来，作为一个值对象。这样通过对对象的细粒度的设计，我们可以更容易控制我们的缓存。所以我觉得对象生命周期很重要，这就设计到了DDD中的工厂和仓库两个模式，我目前的设计中，我是通过工厂来控制对象生命周期的起始，并且保证对象创建出来的聚合根式满足系统不变量的约束的，那么对象创建以后，其它的生命周期交给仓库管理。仓库(repository)管理对象创建以后的生命周期，我觉得这个时候就要使用缓存来管理了，我们要想得到领域对象，只能从一个地方来获得，那就是仓库，而仓库首先通过一个全局的缓存中去获得对象，如果缓存中没有就从数据库或者其它持久性数据源得到对象，然后放到缓存中，这样系统中的所有对对象的访问，都需要经过统一的地方：仓库。当系统中发生了引起领域对象状态变化的操作以后，我们可以清空缓存中的对象或者只清空领域对象的一部分，比如分离出来的状态。

最后使用全局的缓冲还有一个好处，那就是集群环境下面，因为我们可以把全局缓冲通过一个分布式的缓冲透明的替换，这样减少了不同节点之间同步session，以及session failover的开销，这其实就有点SNA的味道了。呵呵。



不知道您有没有读过：<<领域驱动设计>>这本书，这本书我觉得非常好，如果没看过，推荐您看看。这里面详细简介了如何开发一个针对于自己当前业务状态的对象模型。

6 楼 shuai45 2009-04-24  

狂放不羁 写道

恩，上面两位说的都有道理，我这里想说的就是缓存要配合业务对象建模来使用，如果采用面向过程的开发，系统没有一个合理的对象模型，那么缓存的作用就不大。如果要说缓存的位置，那太多了,cpu也有高速缓存的，JVM也有缓存的，DB也有缓存的等等，所以结合自己的业务模型来做适合自己的业务的缓存才是真正适合自己的。并且对于缓存，我觉得全局application缓存会比较好，session中尽量少保存数据。

对于shuai45兄弟说的，很认同，软件的伸缩性可以从两个层面进行，分别是水平伸缩性和垂直伸缩性，水平伸缩从软件设计高度来考虑，而垂直伸缩从硬件的角度来考虑。

对于liujunsong兄弟说的，也有道理，客户端的缓存确实也很重要，比如我们可以通过javascript，json来将客户的状态先保存到客户单浏览器进程中，比如我知道一个公司就采取了这种方式，新建，修改和删除操作首先缓存到客户端，当最后用户真正提交的时候，在通过AJAX异步的将缓存刷新到服务器端。

“我觉得全局application缓存会比较好，session中尽量少保存数据。”
目前有很多缓存框架。OSCACHE就非常不错。我没做过大项目，基本都是数据库能解决的就用数据库。
实在解决不了 或者性能存在一些问题 就通过程序 上解决。不过这样做 并不好，完全的被动。所以 一个项目要从设计上就考虑优化，而且可扩展。
这样的经验 实在太少。希望LZ把你的开发经验分享一下。