开心每一天1111
脱离带宽内存与计算量来讨论并发是没有意义的。因为并发数受带宽及其它很多因素影响,不能单就node.js来说并发多高。如果无限带宽,无限计算力,无限存……你可以认为node.js并发数也是无限的,但这没有意义,在同样的情况下,就算是IIS,并发数也可以认为是无限的。node.js的优势严格来说不是并发而是“非阻塞”。它是通过非阻塞来达到高并发的目标的,我们用node.js也是用它的非阻塞这个特点。在优化线程池,以及端口复用等技术的基础上,对于简单的业务处,使用其它的模型也可以达到高并发的目标,但在面临业务逻辑耗时长的问题时,node.js的优势就比较明显。如果一个事务请求涉及三个业务逻辑,比如登录(login)这个事务,假设我们定义它有三个业务逻辑:verify:验证用户是否合法(用户名,密码什么的);user:获取身份信息(权限什么的);modules:返回他可用的业务接口列表(商品管理,用户管理,订单审核等)我们假设:只有1完成了才可以进行2,2完成了才可以进行3,上述每个业务逻辑都需要1秒去完成(客户的登录请求这个事务需要3秒才能完成)。同时,我们也假设,这三个业务逻辑服务都是在其它的服务器上,它们的并发数无上限。然后,我们在“一瞬间”我向这个服务发出1000个login请求那么,我们来看看node.js与纯java的不同。nodejs调用它们来完成,因为它是非阻塞的,它调了verify后,不再等待它返回结果,就可以处理另一个事务请求了,当verify请求有返回结果时,它再来处理结果,决定是否调用user……,整个过程,只在一个进程中就完成了。它收到这1000个请求后,在这个进程中向verify发出了1000个请求,过了一秒,收到回应又有900个验证成功,它返回了100个登录失败的信息,并向user发出了900个请求,又过了一秒,返回了900个modules的结果。这样的结果,在客户端看来,发出请求后1秒,收到了100个登录失败,又过了两秒,收到了900个可用功能列表(因为异步机制,它还会稍微长一点点,假设是3.003秒吧)现在,在带宽与计算力不受限的情况下,同样的内存,看看纯Java是怎么个情况。如果使用纯java来做这个事,java不使用异步模式的话,一个线程响应一个请求。java同样“一瞬间”收到了1000个请求,java开启了1000个线程去响应它们,然后这1000个线程在第一秒里都在等待verify,第一秒结束时,返回100个登录失败,关闭了100个线程,又过了两秒,900个线程得到了各自的modules结果,并返回给客户端。对于客户端来说,感觉就是3秒,没有那个0.003。好,至此,node.js与纯java的区别已经很明显了。纯java在不使用非阻塞机制的情况下,它需要开启1000个线程(或者进程,这个成本更高)而node.js则需要更多的时间。在内存受限的情况下,node.js就有优势了。假设一个进程需要1M内存,为了能同时开1000进程,你需要额外的1G内存来给它。而对于node.js,它可能只需要20M来完成这个事,代价就是每个客户端都需要多等那么一小会。严格来说,并不提倡在node.js中实现业务逻辑,node.js最好是只用于以非阻塞模式连接多个阻塞模式的业务逻辑。