关键字:查询,事务,粒度

[size=medium]/**

*作者：张荣华

*日期：2008-08-22

**/

在那遥远的过去,俺曾经写过一篇关于事务的文章,原文地址见: http://ahuaxuan.iteye.com/blog/95124.文章大意是这样的:在spring+hibernate的场景下,readonly的事务会有特别的优化.因为readonly的事务在提交的时候不会flush 一级缓存中的几个队列(包括,更新队列,插入队列等).看了那篇文章的同学会以为:ok,只读的时候我只要readonly就行了. 不过那篇文章中我并没有考虑到所有的场景,所有再写一篇文章,算是对整个概念(查询操作是否需要事务)的一个完善.

还是老路子,我先描述一下我遇到的一个项目的问题:
1 代码逻辑,下面是一段伪代码

/**
	 * 该方法上加事务,传播途径为required
	 * @param params
	 * @return
	 */
	public List<object> getObject(Map<String, String> params)	 {
		//先从memcached中取得数据
		List<object> o1 = memcachedClient.getFromCache(params);
		
		
		if (o1 == null) {
			ol = ObjectDao.getfromDB(params);
			memcachedClient.putToCache(params, o1);
		}
		
		return o1;
	}

这段代码逻辑非常简单,先从memcached中取数据,取不到就从db取,然后再放到memcached中,无可挑剔(不过要注意我的注释,这个方法上加了required的事务)

就是这段代码,放到tomcat中,我的同事william测出来的结果是,单线程请求(tomcat的thread pool中在同一时间只有一个处理请求的线程被调用):ab  -c 1 –n 1000 http://xxxx.xxx.xxx/xxx
结果是每秒中只能处理20个请求,  我的天啊, 20个,改多线程呢,: ab  -c 100 –n 1000 http://xxxx.xxx.xxx/xxx, 一百个线程请求1000次,晕倒,还是每秒只能处理20多个请求.

估计有些人会觉得很奇怪,这么简单的逻辑怎么会这么慢,我但是也很奇怪,不过突然大脑中一个概念闪过”连接池”(难道这就是传说中的灵感),打开配置一看,果然,连接池配置的连接数只有20.

“每秒钟处理20个请求,20个connection,加了事务”
“每秒钟处理20个请求,20个connection,加了事务”
“每秒钟处理20个请求,20个connection,加了事务”

多想了两遍之后(快分裂了),答案出来了:

在getObject方法上加上事务之后,所有的调用都会新建事务对象,然后放到当前线程中,而新建该事务对象的基础是connection,同时这个connection也会被保存在当前线程中,这样造成的结果是只有等到拥有connection的请求退出事务之后,connection才能重新回到线程池,换句话说,getObject方法是依赖于connection的,getObject能够被调用的次数取决于线程池中线程的数量

于是把线程池开到100,同样运行ab,结果果然好了很多,现在每秒能够处理的请求达到了120+,connection的数量变成原来的5倍,每秒处理的请求数也变成了原来的5倍.

看上去为这个get方法配置事务导致了该方法依赖于db connection是真正的原因,
从我们的逻辑上看该方法确实是不需要事务,但是由于我们的习惯,就顺利成章的给配置了一个,但是这个小小的配置确带来了巨大的影响.

不过有时候,我们以为找到了所有的问题,但是往往有更深层次的问题隐藏其中,比如说多次查询不加事务可能产生幻读的情况(不过如果你的应用对幻读的要求不高的话也没有什么问题).

那么也许我们可以这样结论,只要查询的操作在高性能需求的场景下千万不要加事务,即使是readonly的也不行,其他场景加上吧,不加可能会有些问题,比如说前面提到的幻读(这次我的结论好像底气不足,因为我还没有对它有过特别彻底的研究).

结论下来了,我们看看如何优化,其实在我举的这个场景中,是既可以保证事务,又能提高效率的,就是缩小事务的粒度,如果我在ObjectDao.getfromDB(params);加上事务的话,依赖于connection的只有ObjectDao.getfromDB(params);这个方法了,而这个方法只有o1 == null的时候才会被调用,绝大多数情况下它是不会被调用的.这样既一定程度上保证了事务又提高的程序的速度.

那么我们还可以下一个结论,就是某些场景下缩小我们事务的粒度能够很大程度提高程序的性能.



注明：由于ahuaxuan水平有限，文中不妥之处还望不吝指正，谢谢。



[/size]

评论

12 楼 downpour 2008-08-25  

fireflyc 写道

有没有考虑过这样的一种办法：

我们禁用掉Hibernate的二级缓存。
然后我们通过spring的aop，对某些方法的返回结果直接加入缓存，
容过spring的aop，在某些方法执行之后更新缓存里面的结果。

也就是说，这里的缓存是我们自己做的而不是hibernate做的。
原因是因为，我们使用hibernate的时候只使用hql语句，能用hql的就用hql。别的坚决不用。

就我碰见的情况下，我认为多数时候是用不到Hibernate的二级缓存的。所以绝大多数的使用Hibernate做ORM的Entity，我都不开启二级缓存。仅仅对一些只读表，或者修改频率非常非常低的表使用二级缓存。而且针对这些表的读取，我会非常小心，尽量在系统启动的时候就用一次list操作把表中的大部分记录装入二级缓存，接下来就可以随意使用了，而且基本上会全部命中。

Spring的AOP应用缓存的场景非常常见，不过一般Service层会包含非常复杂的逻辑，所以这样的缓存可能也只能使用于业务逻辑相对简单的场景。因为对于复杂的逻辑来说，我们往往需要根据逻辑来判断，业务逻辑到达了某个步骤，才从缓存取数据，而不是简单的先查缓存，查不到再调业务逻辑方法。所以Spring的AOP在缓存的应用上会非常有限。

缓存的使用，越是在层次高的地方使用，使用的效果和程序的效率会越高。但是越是层次高的地方，也越无法包含复杂的逻辑判断，所以是一个权衡。

11 楼 fireflyc 2008-08-25  

有没有考虑过这样的一种办法：

我们禁用掉Hibernate的二级缓存。
然后我们通过spring的aop，对某些方法的返回结果直接加入缓存，
容过spring的aop，在某些方法执行之后更新缓存里面的结果。

也就是说，这里的缓存是我们自己做的而不是hibernate做的。
原因是因为，我们使用hibernate的时候只使用hql语句，能用hql的就用hql。别的坚决不用。

10 楼 ahuaxuan 2008-08-25  

to  NicholasBugs
     

引用

ab 是apache自带的一个工具,你安装apache之后,在它的bin目录可以找到

-----------------------------------------------------------------------
其实很多场景我们都可以看到在view层使用cache的例子,比如ehcache和oscache能够缓存页面,我想我们可以把这种场景叫做 open cache in view, 但是这个东西也不是适合于所有的场景,因为缓存这种东西用起来并不是千篇一律的,得根据项目得实际情况而定.


大多数情况下我们会在我们得业务里用到缓存,如果是大并发情况,就要考虑一下能否缩小事务得范围了

9 楼 xly_971223 2008-08-25  

NicholasBugs 写道

ahuaxuan 写道

/**

*作者：张荣华

*日期：2008-08-22

**/

就是这段代码,放到tomcat中,我的同事william测出来的结果是,单线程请求(tomcat的thread pool中在同一时间只有一个处理请求的线程被调用):ab  -c 1 –n 1000 http://xxxx.xxx.xxx/xxx
结果是每秒中只能处理20个请求,  我的天啊, 20个,改多线程呢,: ab  -c 100 –n 1000 http://xxxx.xxx.xxx/xxx, 一百个线程请求1000次,晕倒,还是每秒只能处理20多个请求.

尽量细化事务粒度，深有同感，想问一下，这个测试是怎么做的，用什么工具？

估计是tomcat的启动参数吧

8 楼 NicholasBugs 2008-08-25  

ahuaxuan 写道

/**

*作者：张荣华

*日期：2008-08-22

**/

就是这段代码,放到tomcat中,我的同事william测出来的结果是,单线程请求(tomcat的thread pool中在同一时间只有一个处理请求的线程被调用):ab  -c 1 –n 1000 http://xxxx.xxx.xxx/xxx
结果是每秒中只能处理20个请求,  我的天啊, 20个,改多线程呢,: ab  -c 100 –n 1000 http://xxxx.xxx.xxx/xxx, 一百个线程请求1000次,晕倒,还是每秒只能处理20多个请求.

尽量细化事务粒度，深有同感，想问一下，这个测试是怎么做的，用什么工具？

7 楼 lzmhehe 2008-08-25  

啊
看到这个 我终于明白为什么之前做的一个项目里面，把cache 层单独提出来了
cache 层调用service层的

6 楼 downpour 2008-08-25  

这篇文章可以给我们更深刻的提示：OpenSessionInView模式的最大的问题在于线程处理能力。因为实际上，OpenSessionInView要求connection在View层就拿过来，直到整个请求结束，才归还连接池。

5 楼 neptune 2008-08-25  

那么用hibernate自身的二级缓存要小心了，其不能分隔那些是cache,那些是事务代码，这个问题很严重.

4 楼 mycybyb 2008-08-25  

嗯，前段时间也遇到了这个问题。明明从cache中读数据，可由于事务的原因，还是要获得一个connection，导致性能下降的厉害。

3 楼 lkjust08 2008-08-25  

阁下真有心呀，以后要向阁下学习呀。

2 楼 laiseeme 2008-08-25  

哪怎么实现呢   吧访问数据库的这一小段代码独立出来给他加事务么?

1 楼 hgq0011 2008-08-24  

"某些场景下缩小我们事务的粒度能够很大程度提高程序的性能."非常有同感，我经常对我的同事们说，尽快的结束事务，减少不必要的数据库的访问。