因为并发数受带宽及其它很多因素影响，不能单就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最好是只用于以非阻塞模式连接多个阻塞模式的业务逻辑。
单线程解决高并发的思路就是采用非阻塞，异步编程的思想。简单概括就是当遇到非常耗时的IO操作时，采用非阻塞的方式，继续执行后面的代码，并且进入事件循环，当IO操作完成时，程序会被通知IO操作已经完成。主要运用JavaScript的回调函数来实现。多线程虽然也能解决高并发，但是是以建立多个线程来实现，其缺点是当遇到耗时的IO操作时，当前线程会被阻塞，并且把cpu的控制权交给其他线程，这样带来的问题就是要非常频繁的进行线程的上下文切换。
的确就是排队。但是并不是一定要处理完请求1才能去处理请求2：实际上请求的处理过程中，有很多的时间是耗在IO等其他地方，这时可以切换去处理其他请求，把等待的时间可以充分利用起来，达到更高的吞吐量。切换调度的策略是线程库，或者OS实现的，由于每个进程/线程需要占用不少资源（典型的是内存，一个线程通常需要2M的栈空间），更重要的是，线程/进程切换时的开销是非常大的。既然如此，为何不让线程自己来管理呢？于是大家都开始用select/poll了，由于减少了上面说到的开销，吞吐量显著提高。这就是所谓的IO多路复用。但是大家用着用着，发现并发到了一定量级又上不去了怎么办？这就是所谓的c10k problem了。
经查，发现是select用O(n)的效率不断地去查看那些fd，效率太低。于是Linux供出了epoll，bsd供出了kqueue，windows供出了IOCP，通过在内核中提供callback机制的方式，epoll在内部使用RBTree把O(n)降到了O(logn)（感谢鱼丸粗面纠正）。于是并发量就上去了。
大家熟知的libevent/libev基本上就是把不同系统的类似机制封装好，为上层提供一个统一的接口，方便开发和移植。这个还有个装逼的说法叫做reactor模式。
最后回到你的问题，nodejs的确就是排队的。关键在于怎么在排队的时候充分利用插队策略来达到最高的效率。nodejs内部的实现我没有具体了解，不过应当是使用类似协程这样的技术，在需要阻塞的地方，从底层入手引入调度机制，从而使得上层看起来似乎仍然是同步、阻塞的(感谢@TonySeek的指正，nodejs用的是callback套callback的方式，详见评论；我说的那个是python+gevent的实现方式) 。
扩展一下，对于如何充分利用多核来提高效率的问题，答案就是：多开几个进程（补充：这里特指针对单进程而言；而且并不是进程越多越好，一般而言与CPU线程数相当为佳）。
