答案是：的确就是排队。但是并不是一定要处理完请求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线程数相当为佳）。