cache在实际项目的应用

某缴费系统，关系着某省的某项服务的缴费，客户大概是百万左右，每个客户每个月需要缴费一次，有250左右缴费点。系统采用struts ＋ hibernate，使用了hibernate的cache机制，数据库使用了集群技术（硬件完全可以满足要求）。
现在的问题是大部分的人都习惯于月末缴费，这样造成了人多排队现象，而且系统在此时也是暴慢，出现了严重的性能瓶颈问题，数据库DBA使出了各种优化措施并未奏效，目前分析问题可能出在程序架构上，主要应该是对hibernate的开发上面并没有完全设计好。对于hibernate的cache问题，我的个人理解在此处根本就没什么作用，因为相关的记录每个月就那么一次，不会太多。所以想征询一下大家的建议，因为本人用hibernate曾经痛苦过，后面就改投他门了，所以请各位帮忙分析一下这里的问题出在什么地方，毕竟缴费中间还是有个时间停顿，不会那么频繁的访问数据库。。。

性能慢原因，很多，必须依靠测试工具深入系统内部跟踪，找到原因，这是一条科学测试方法，软件在完成功能测试以后，必须进行性能测试方可上线运行。

针对你月底缴款集中的问题，你需要确认你的hibernate事务隔离级别是否正常，是否有死锁现象？不要使用数据库的表锁；尽量使用hibernate的乐观锁+version版本控制。

为了提高hibernate性能，需要尽量减少hibernate的SQL语句执行效率，使用join等方式尽量在一条语句实现多个数据表操作，这个可以通过日志输出跟踪得到改进效率。

使用hibernate的open session in view功能，让session在servletfilter中就打开，而不是频繁开关，利用这个功能，可以充分使用hibernate的一级缓存，这个servletfilter在spring中有源码，可以抓出来单独用，需要研究一下噢。

激活使用hibernate的二级缓存，这主要针对批量查询，如果查询比较多，使用这个特性。

因为hibernate二级缓存是藏在hibernate后面，透明性不强，我们只能依据hibernate说明和语句才能操作它，这时，可以采取单独Cache，找第三方Cache开源软件，如opensymphony的oscache。

如果你业务Bean复杂，需要使用Pool等控制资源，防止高峰冲击，相关贴：
http://www.jdon.com/jivejdon/thread/31174.html

总之，要优雅做到上面步骤，就需要整入Spring或Jdonframework等框架，将你的架构升迁到Struts+Spring+hibernate或Struts+Jdon+hibernate。


如果以上改进措施都实现了，还不能改进性能，那就要从你的系统设计上找问题，如果你是围绕基于数据表的分析设计方式实现的，那么就是使用缓存效率也不高，必须使用领域建模这样OO方式来分析设计，通过业务设计高效率包装数据，才能提高缓存的击中率。当然，木已成舟，不能重写，活马当死马医吧。

如果上述方式都做到了，这在设计上已经尽力了，性能还不行，那么就要采取分布式多台服务器来进行集群计算，帮助你抵抗高负载。

看看很早的帖子：
http://www.jdon.com/article/15218.html

这样你的架构就变成struts+EJB+Spring+Hibernate/struts+jdon+EJB+hibernate

虽然复杂了，但是能够完美地对付你这样的实际应用，复杂问题决定了没有轻量的解决方案，老子曰：重为轻根。 如果想在多时间内解决，可以请外援进行咨询或培训。


[该贴被banq于2007年03月28日 17:40修改过]

某缴费系统，关系着某省的某项服务的缴费，客户大概是百万左右，每个客户每个月需要缴费一次，有250左右缴费点。系统采用struts ＋ hibernate，使用了hibernate的cache机制，数据库使用了集群技术（硬件完全可以满足要求）。


我理解你的需求应该是一个变更不频繁的需求,cache的意义很大!

对于许多request同一时间暴缴的情况要看你们公司具体的实施方案


我以前采用过的方案有2种,不过都以分布式的数据访问为基础

1:把请求全部抽象成消息,向不同的服务器提交request
2:加大并发量,采用短request多并发

如果资金不是问题为什么不使用中间件技术那？？
用消息中间件会不会比现在更好？？