我知道Nginx是事件驱动而不是基于分离进程的。同时Nginx可以通过uWSGI，抗投诉服务器FastCGI等协议来Hold住PHP/Py/RoR构建的Web App。请问当这种情况下，业务逻辑本身怎么能够变成事件驱动呢？还是说只能用C写一个业务逻辑的Module，集成进Nginx里面才行？本人刚刚接触Web Server等概念，对此一直想不通。

你需要先了解Event Loop
see http://en.wikipedia.org/wiki/Event_loop

你的意思是Nginx是一个Dispatcher，Web App是Callback function?

Nginx都已经处理好了，为什么要把后端也事件驱动？要是那样的话要Nginx何用？

nginx作为 前端 能起到 流量整形 的作用

nginx 只负责前台请求的处理和转发，和后台没有关系的。如果后台用 PHP/Py/RoR ，还是按照它们自身的方式来运行，也就是本来是多进程就还是多进程，本来是多线程就还是多线程，不会因为用了 nginx 就改变的。

也就是说有多少个Requests进来，后天的PHP就会开多少个进程来处理Requests？那么Nginx本身的优势是什么？仅仅是转发的话，应该也消耗不了多少资源吧？

后端是单节点时，多进程能够充分利用CPU多核的资源。当后端是多节点时，Nginx可以将request按照配置的负载均衡策略分发到后端多个节点上，当然多节点时，每节点可以运行多个进程。反向代理本身的逻辑很简单，是重度网络IO的应用。基于事件的异步IO，Nginx能够比同步IO多得多的并发。后端的应用可以根据应用的特性以及开发的难度，来决定是否使用事件驱动。我认为如果重点是业务逻辑及计算，没有必要为了事件驱动而增加开发的复杂度，带来更多的不定因素。如果是处理大量并发，IO的应用，事件处理能够提高单进程的处理能力，节省硬件资源

就是做转发。如果后台是多机器了，也可以做负载均衡。还可以限制请求速率，对请求和响应做些修改等等。其实这些都是转发附带的功能了。
nginx 的优势就是解决 C10K 问题，同时接受大量请求。例如做负载均衡的时候，就是一台 nginx 的机器就可以负责给后台几十机器做转发了。

如果是单机Server的话，每个Request，PHP都要开一个进程的话，那么Nginx相对于Apache有什么优势呢？还是差不多？

如果 PHP 的话，看用什么方式吧，可以是 Apache 一起来处理 PHP ，也可以 Apache 转发给 PHP 来处理。如果 Apache 处理的话，如果 PHP 程序有问题 ，就连累到 Apache ；如果是转发的话，除了 PHP 开一个进程来处理之外，Apache 也要开一个进程来处理这个连接，而 nginx 则是一个 worker 进程可以处理多个连接

不存在“它运行的”什么东西。它只是通信转发而已，通信这部分是event loop的

可以理解成一个Worker处理几个连接和它们对应的几个PHP进程呢？

woker 约等于 CPU的个数