Nodejs区别于传统应用的特点：
1. 异步事件驱动
2. 非堵塞I/O
3. 单线程（这里指主线程）
4. 性能出众
接下来就对以上4点进行简单的阐述：
一、事件驱动
首先，解释下“事件驱动”这个概念。所谓事件驱动，是指在持续事务管理过程中，进行决策的一种策略，即跟随当前时间点上出现的事件，调动可用资源，执行相关任务，使不断出现的问题得以解决，防止事务堆积。
Nodejs设计思想中以事件驱动为核心，事件驱动在于异步回调，他提供的大多数api都是基于事件的、异步的风格。而事件驱动的优势在于充分利用系统资源，执行代码无须阻塞等待某种操作完成，有限的资源用于其他任务。事件驱动机制是通过内部单线程高效率地维护事件循环队列来实现的，没有多线程的资源占用和上下文的切换。
二、异步、非堵塞I/O
Nodejs提供的很多模块中都是异步执行的。比如，文件操作的函数。
一个异步I/O的大致流程：
1. 发起I/O调用
①用户通过js代码调用nodejs的核心模块，将回调函数和参数传入核心模块
②将回调函数和参数封装成
2. 执行回调
①操作完成将结果储存到请求对象的result属性上，并发出完成通知。
②循环事件，如果有未完成的，就在进入对象请求I/O观察者队列，之后当做事件处理；
三、单线程
Nodejs跟Nginx一样都是单线程为基础的，这里的单线程指主线程为单线程，所有的阻塞的全部放入一个线程池中，然后主线程通过队列的方式跟线程池来协作。我们写js部分不需要关心线程的问题，简单了解就可以了，主要由一堆callback回调构成的，然后主线程在循环过在适当场合调用。
四、性能出众
底层选择用c++和v8来实现的，上面第一点讲到过，nodejs的事件驱动机制，这意味着面对大规模的http请求，nodejs是凭借事件驱动来完成的，性能部分是不用担心的，并且很出色。
Nodejs应用场景：
适合I/O密集型的应用，如在线多人聊天，多人在线小游戏，实时新闻，博客，微博之类的。
不适合的场景有：cpu密集型的应用，如计算圆周率，视频解码等业务场景较多的。
那么什么是I/O密集型，CPU密集型呢？下面详细介绍下：
CPU密集型（CPU-bound）
CPU密集型也叫计算密集型，指的是系统的硬盘、内存性能相对CPU要好很多，此时，系统运作大部分的状况是CPU Loading 100%，CPU要读/写I/O(硬盘/内存)，I/O在很短的时间就可以完成，而CPU还有许多运算要处理，CPU Loading很高。
在多重程序系统中，大部份时间用来做计算、逻辑判断等CPU动作的程序称之CPU bound。例如一个计算圆周率至小数点一千位以下的程序，在执行的过程当中绝大部份时间用在三角函数和开根号的计算，便是属于CPU bound的程序。
CPU bound的程序一般而言CPU占用率相当高。这可能是因为任务本身不太需要访问I/O设备，也可能是因为程序是多线程实现因此屏蔽掉了等待I/O的时间。
IO密集型（I/O bound）
IO密集型指的是系统的CPU性能相对硬盘、内存要好很多，此时，系统运作，大部分的状况是CPU在等I/O (硬盘/内存) 的读/写操作，此时CPU Loading并不高。
I/O bound的程序一般在达到性能极限时，CPU占用率仍然较低。这可能是因为任务本身需要大量I/O操作，而pipeline做得不是很好，没有充分利用处理器能力。
CPU密集型 vs IO密集型
我们可以把任务分为计算密集型和IO密集型。
计算密集型任务的特点是要进行大量的计算，消耗CPU资源，比如计算圆周率、对视频进行高清解码等等，全靠CPU的运算能力。这种计算密集型任务虽然也可以用多任务完成，但是任务越多，花在任务切换的时间就越多，CPU执行任务的效率就越低，所以，要最高效地利用CPU，计算密集型任务同时进行的数量应当等于CPU的核心数。
计算密集型任务由于主要消耗CPU资源，因此，代码运行效率至关重要。Python这样的脚本语言运行效率很低，完全不适合计算密集型任务。对于计算密集型任务，最好用C语言编写。
第二种任务的类型是IO密集型，涉及到网络、磁盘IO的任务都是IO密集型任务，这类任务的特点是CPU消耗很少，任务的大部分时间都在等待IO操作完成（因为IO的速度远远低于CPU和内存的速度）。对于IO密集型任务，任务越多，CPU效率越高，但也有一个限度。常见的大部分任务都是IO密集型任务，比如Web应用。
IO密集型任务执行期间，99%的时间都花在IO上，花在CPU上的时间很少，因此，用运行速度极快的C语言替换用Python这样运行速度极低的脚本语言，完全无法提升运行效率。对于IO密集型任务，最合适的语言就是开发效率最高（代码量最少）的语言，脚本语言是首选，C语言最差。
总之，计算密集型程序适合C语言多线程，I/O密集型适合脚本语言开发的多线程。
应用场景穿插2中密集型的原文：http://blog.csdn.net/youanyyou/article/details/78990156