到处是异步,异步滚滚而来Netty和ADBCJ

09-07-27 banq
下一个Big Thing应该是异步

JBoss发布了其NIO非堵塞IO框架Netty,总算追上GlassFish的Grizzly,赶超apache mina,经过测试,Netty性能要超过Mina,Netty是MINA的一个创始人跳到JBoss后开发的项目。

MINA使用系列I/O线程处理读和写,这是很多典型NIO框架的手法。但是Netty要比MINA聪明得多,当发送Queue中是空的,Netty将直接发送数据,不再例行公事放入Queue中,如果发送Queue不是空的,Netty将这个数据放入队列,这时类似MINA做法。所以,Netty要快些。

使用异步数据库驱动ADBCJ,在一个完全异步非堵塞场景下比较, I conducted a simple performance test comparing MINA and Netty. The test runs 100 simple select SQL queries against MySQL that each return a single string. Each test was run 100,000 times.

MINA 618,912,430.60ns 104,509,066.50ns

Netty 563,756,985.70ns 104,440,106.73ns

Netty架构:

异步数据库驱动ADBCJ:

http://code.google.com/p/adbcj/

异步Netty:

http://www.jboss.org/netty/index.html

在设计RESTful系统中,我们一般使用RESTLet结合MINA实现服务器端,但是MINA的产品性不是很强,文档不齐全,而Netty则弥补了这个空白,看来RESTLet + Netty可以获得一个高性能的 可伸缩的分布式式架构

[该贴被banq于2009-07-27 17:22修改过]

11
newthinker
2009-07-28 16:06
比较常见的几种著名的nio框架:grizzly,mina,xsocket和bang介绍的这个netty,从易用性上说,只有xsocket真正做到了高效和简洁。xsocket更新也比较及时,看得出作者的确用心。令人惊奇的是xsocket的简洁!它直接支持原生数据类型的io操作,不像mina和grizzly自作聪明的无耻的干扰用户应用程序逻辑(比如mina和grizzly都提供有关协议解析接口),也就是说mina和grizzly提供的api更加的侵入用户程序。这使得它们难以驾驭。学习过程非常复杂,而且容易出错。xsocket则尽量避免了这些,就像它的作者一直强调的一样,xsocket保持了nio的简洁性。xsocket的官方教程只有短短的经过精心设计的一页!大约40分钟的阅读,你便可以完全掌握它。除了编程模型跟阻塞式不同(nio框架写的好的全都是基于事件的模型,阻塞式io就是不断的轮询),io操作上跟阻塞式io编程很像。xsocket本身并不提供跟用户程序领域模型有关的一切,只是像阻塞式io那样的提供原生数据类型(byte,int ,String,byte[]...)的操作。这会是你最想看到的,因为我猜你也跟我一样不愿意去思考mina、grizzly之流提供的侵入应用逻辑的概念。下载xsocket以后你会发现,它不依赖与任何第三方类库!只有一个300多k的jar包,它的log功能也不是常规使用的log4j或者common log,而是直接使用jdk的logger。这一切都是我欣赏的!自从接触xsocket,mina、grizzly之流就被我彻底抛垃圾桶里了,不是它们不好,是因为它们太复杂难用。

banq
2009-07-29 09:01
Xsocket是不错。

想找个有Restful风格的异步Http服务器,加上推Push机制,这样一个组合应该很新潮,是未来趋势。

bloodrate
2009-07-29 09:27
nio应该还包括jetty6 Continous和tomcat6 comet吧

banq
2009-07-29 10:21
jetty6 Continous和tomcat6 comet属于Push机制,是使用异步实现的PUSH。

这些框架服务器包括xsocket都在服务器端处理客户Session,而Restful是在客户端自己处理自己的session状态,所以,寻找Restful的轻量的异步框架中,目前没有看到。

如果这个轻量框架出现,将会冲击或替代SOA/SCA/ESB这个重量世界。

bloodrate
2009-07-29 13:32
无论是grizzly,mina,xsocket,自己构建服务器在生产环境下实在是不现实,因为除非你有非常专业的IO知识,否则即便是别人封装好的api,自己封装出来的服务器,尤其是应用开发商招很多毕业学生,做这些就是没有把握的事情。所以为了迎合Rest以及异步机制而自己封装服务器一直停留在Demo阶段。

banq
2009-07-29 16:40
bloodrate 谈得有理,不过我们现在是在架构层面来谈这些,而不是从用户角度谈,从架构高度要细分,从用户角度要合,这样交给用户的是一个DSL之类的快速开发运行环境。

架构师应该更关注细分,正像ebay架构师总结伸缩性要旨为:任何地方都要异步,在每个环节都能异步,只有细分,打破串行化,才能异步,所以,异步架构思维是一种新式思维,是一种并发计算的新思维。

bloodrate
2009-07-30 09:23
其实很羡慕互联网应用自己为自己搞技术,那种环境下的架构师才是真正的架构师

alexlee002
2009-12-03 14:10
怎么就没人提到国内的 Cindy 呢? 这个框架也挺不错的啊

不必老外的差, 只是因为是国产的, 就不用?

jamesqiu
2009-12-05 19:44
从文档和例子来说,xsocket和netty最好,grizzly的最烂;

性能应该netty最好,xsocket不知道如何。

基础类型IO倒是xsocket特有的;

yinchonging
2009-12-17 14:43
这位仁兄有点极端。

在我看在技术只有适合不适合使用,而不是这种技术或者框架使用不现实。

也许有一天你会用到netty也说不定,而且是在生产环境。

据我所知有很服务都是基础mina、netty做的,而且是一些在中国来说比较牛的公司。

mina、netty、grizzly都做过测试,的确是mina最慢。

netty和grizzly比较的话,还是grizzly稍微快那么一点点点点......

yinchonging
2009-12-17 14:44
2009年07月29日 13:32 "bloodrate"的内容
无论是grizzly,mina,xsocket,自己构建服务器在生产环境下实在是不现实,因为除非你有非常专业的IO知识,否则即便是别人封装好的api,自己封装出来的服务器,尤其是应用开发商招很多毕业学生,做这些就是没有把握的事情。所以为了迎合REST以及异步机制而自己封装服务器一直停留在Demo阶段。

我上面说的是对这个仁兄说的。

猜你喜欢