再谈Share-Nothing体系结构
之前比较PHP和ASP.NET的时候，提到了Share-Nothing-Architecture，这是PHP创始人Rasmus Lerdorf提出的概念。PHP采用的就是Share Nothing Architecture，各个HTTP请求之间在PHP这个层次是不共享任何状态的，这样的好处是可以使得PHP应用程序具有很高的扩容性(Scalability)。
世上的事情就是有利就有弊，SNA(Share Nothing Architecture)也不是没有缺点。采用SNA来构建传统的Web 1.0或者大部分Web 2.0应用都没问题，但是用来构建Comet应用就成了问题。
什么是Comet?
用例子来说明最容易，试着同时登陆两个GMail账户，从一个账户往另外一个账户发一封信，可以看到，这边刚刚按Send按钮，那边就提示收到新信件了。这种用户体验就是好像这封信是从Server被Push到浏览器一样，但是我们都知道HTTP协议是不支持Push的，只能是Client发一个请求，Server返回一个响应，Client再发一个请求，Server再返回一个响应，那GMail是怎么做到的呢？这就是在HTTP协议基础上的Comet技术。
简单说来，Comet就是让浏览器Client端保持一个到Server的长时间的HTTP请求，浏览器发出这个HTTP请求之后并不指望Server立刻返回点什么，Server愿意什么时候返回就什么时候返回，而且即使返回了写什么也不着急断开这个链接，Server可以通过这个连接返回一些东西到浏览器。总保持一个Client和Server端的HTTP随时待命，这样，Push就实现了。
为什么PHP不适合Comet?
准确来说，并不是PHP不适合Comet，而是PHP的容器不适合Comet。通常PHP都是和Apache配合使用，Apache是世界上使用最多的Web Server，但是它的设计不适合新兴的Comet应用。
对每个HTTP请求，Apache会分配一个线程或者进程来处理，问题是，被分配的线程或进程不处理完这个HTTP请求是不会去做别的事情的，也就是说，这个线程/进程被这个HTTP请求占用了，这也是Share Nothing Architecture的应用。
为了实现Comet，每个浏览器都要建立一个和Server的“长时间的”HTTP信道，对于Apache而言，就是对每个浏览器访问都要有一个线程或者进程伺候着。可以想象，随着用户数的增加，需要的进程和线程数也线性增加，而且大部分时间这些线程和进程并不做实际工作的，这很影响Scalability。
如果Apache被修改成异步方式，那么PHP作为一门语言还是可以实现Comet的，但是我想Apache永远不会这么改。而且，PHP也不是被设计成来处理异步请求的，现在有很多其他语言、平台和服务器支持异步了，如果真的需要实现Comet，就不应该选择Apache + PHP。
