在传统程编程模里，I/O操作就像一个普通的本地函数调用：在函数执行完之前程序被堵塞，无法继续运行。堵塞I/O起源于早先的时间片模型，这种模型下每个进程就像一个独立的人，目的是将每个人区分开，而且每个人在同一时刻通常只能做一件事，必须等待前面的事做完才能决定下一件事做什么。但是这种在计算机网络和Internet上被广泛使用的“一个用户，一个进程”的模型伸缩性很差。管理多个进程时，会耗费很多内存，上下文切换也会占用大量资源，这些对操作系统是个很大的负担，而且随着进程数的递增，会导致系统性能急剧衰减。
多线程是个替代方案，线程是一个轻量级的进程，它会和同一个进程内的其它线程共享内存，它更像传统模型的扩展，用来并发执行多个线程，当一个线程等待I/O操作时，其它线程可以接管CPU，当I/O操作完成，前面等待的线程会被唤醒。就是说，一个运行中的线程可以被中断，然后稍候再被恢复。此外，在一些系统下线程可以在多核CPU的不同核心下并行运行。
程序员并不知道线程会在什么具体时间运行，他们必须很小心的处理共享内存的并发访问，因此必须使用一些同步原语来同步访问某个数据结构，比如使用锁或信号量，以此来强制线程以特定的行为和计划执行。那些大量依赖线程间的共享状态的应用程序，很容易就会出现一些随机性很强，难以查找的奇怪问题。
还有一种方式是使用多线程协作，由你自己负责显式的释放CPU，并把CPU时间交给其他线程使用，因为由你亲自来控制线程的执行计划，因此减小了对同步的需求，但是也提高了程序的复杂度和出错的机会，而且并没有避免多线程的那些问题。
什么是事件驱动编程
事件驱动编程（Evnet-driven programming）是一种编程风格，由事件来决定程序的执行流程，事件由事件处理器（event handler）或事件回调（event callback）来处理，事件回调是当某个特定事件发生时被调用的函数，比如数据库返回了查询结果或者用户单击了一个按钮。
回想下，在传统的堵塞I/O编程模式里，数据库查询可能像这样：
复制代码 代码如下:
result = query('SELECT * FROM posts WHERE id = 1');
do_something_with(result);
上面的query函数会让当前线程或进程一直处于等待状态，直到底层数据库完成查询操作并返回。
在事件驱动模型里，这个查询会变成这样：
复制代码 代码如下:
query_finished = function(result) {
do_something_with(result);
}
query('SELECT * FROM posts WHERE id = 1', query_finished);
首先你定义了一个叫query_finished的函数，它包含了查询完成后要做的事。然后把这个函数当做参数传递给query函数，当query执行完毕会调用query_finished，而不是仅仅返回查询结果。
当你感兴趣的事件发生时会调用你定义的函数，而不是简单的返回结果值，这种编程模型就叫事件驱动编程或异步编程。这是Node一个最明显的特性，这种编程模型意味着当前进程在执行I/O操作时不会被阻塞，因此，多个I/O操作可以并行执行，当操作完成后相应的回调函数就会被调用。
事件驱动编程底层依赖于事件循环（event loop），事件循环基本上是事件检测和事件处理器触发这两种函数不断循环调用的一个结构。在每次循环里，事件循环机制需要检测发生了哪些事件，当事件发生时，它找到对应的回调函数并调用它。
事件循环只是运行在进程内的一个线程，当事件发生时，事件处理器可以单独运行并且不会被中断，也就是说：
1.在某个特定时刻最多有一个事件回调函数运行
2.任何事件处理器运行时都不会被中断
有了这个，开发人员就可以不再为线程同步和并发修改共享内存这些事头疼了。
一个众所周知的秘密：
很久以前，系统编程社区的人们就知道事件驱动编程是创建高并发服务最佳方式，因为它不用保存很多上下文，因此节省了大量内存，也没有那么多上下文切换，又节省了大量执行时间。
慢慢的，这种理念渗透到了其他的平台和社区，出现了一些有名的事件循环实现，比如Ruby的Event machine,Perl的AnyEvnet,以及Python的Twisted，除了这些还有很多其它的实现和语言。
用这些框架做开发，需要学习框架相关的特定知识以及框架特定的类库，比如，使用Event Machine时，为了享受非阻塞带来的好处，你得避免使用同步类库，只能用Event Machine的异步类库。如果你使用了任何阻塞类库（比如Ruby的大多数标准库），你的服务器就失去了最佳的伸缩性，因为事件循环依然会不断地被阻塞，时不时地阻碍了I/O事件的处理。