为什么facebook较多的使用PHP而不是java ?
[问题点数：100分，结帖人AlphaMind]
为什么facebook较多的使用PHP而不是java ?
[问题点数：100分，结帖人AlphaMind]
不显示删除回复
显示所有回复
显示星级回复
显示得分回复
只显示楼主
2007年6月 总版技术专家分月排行榜第三
2007年6月 VC/MFC大版内专家分月排行榜第一
2011年9月 C/C++大版内专家分月排行榜第二2011年4月 C/C++大版内专家分月排行榜第二2010年11月 C/C++大版内专家分月排行榜第二
2011年6月 C/C++大版内专家分月排行榜第三
2011年8月 C/C++大版内专家分月排行榜第二
2011年9月 C/C++大版内专家分月排行榜第二2011年4月 C/C++大版内专家分月排行榜第二2010年11月 C/C++大版内专家分月排行榜第二
2011年6月 C/C++大版内专家分月排行榜第三
2011年9月 C/C++大版内专家分月排行榜第二2011年4月 C/C++大版内专家分月排行榜第二2010年11月 C/C++大版内专家分月排行榜第二
2011年6月 C/C++大版内专家分月排行榜第三
2012年11月 挨踢职涯大版内专家分月排行榜第二2011年9月 Linux/Unix社区大版内专家分月排行榜第二
2012年1月 Linux/Unix社区大版内专家分月排行榜第三2011年8月 C/C++大版内专家分月排行榜第三2011年8月 Linux/Unix社区大版内专家分月排行榜第三2010年4月 C/C++大版内专家分月排行榜第三
本帖子已过去太久远了，不再提供回复功能。热门关键词：
腾近两年奥林巴斯的新机更新频率比M43同门松下可是慢了不少，不过这家日本相...12月1日发布了swoole-1.7.21版本，修复了很多BUG。这是swoole-1.7最后一个版本了，以后不再更新。我们启动了雄心勃勃的swoole-1.8开发计划。在介绍1.8的计划前，先讲一段小插曲。
性能测试游戏
昨天在1.7.21发布后，正好赶上PHP7也发布，忍不住想要做下性能测试。安装了一下HHVM，准备对比PHP5.6、PHP7、HHVM3.9的性能。对WordPress程序的测试中，PHP7确实已经与HHVM很接近了。不过这不是重点，接下来我又测试了一下新写的PHP版本WebSocket客户端。这一测问题就来了。我发现PHP在这个场景下性能非常差。当时的数据是：
5.6.9 cost 419ms
5.6.99-hhvm cost 905ms
7.0.0RC7 cost 777ms
压测10万次WebSocket协议打包，竟然消耗了23秒，PHP7比PHP5.6提升了1倍性能，但和HHVM还是有较大的差距。这个结果倒是在预料之中，毕竟Zend PHP没有JIT，这样纯密集计算的场景下性能不会太好。我顺手加了一个C版本的websocket_pack。再次压测，结果震惊了。
5.6.9 cost 419ms
5.6.99-hhvm cost 905ms
7.0.0RC7 cost 777ms
C-websocket_pack cost 57.ms
C语言版本只用了57ms就完成了10万次的打包。比PHP版本性能高出300多倍。即使是有JIT的HHVM也无法和C语言版本的websocket_pack相提并论。好了接下来就聊聊swoole-1.8的开发计划。
Swoole-1.8的开发计划
异步模式下reload/max_request的支持
swoole-1.7下如果Server是纯异步非阻塞的模式，使用reload/max_request可能会导致某些事件丢失。所以WIKI中明确写了异步模式不应该设置max_request，reload会出现一些错误。1.8会解决此问题，对异步模式下Worker进程退出逻辑将发生一些修改。底层会确保Worker进程中的事件全部处理完后才会退出。
网络协议部分的调整
swoole-1.8将增加Http异步客户端（同步阻塞模式直接用CURL就可以了）、WebSocket同步/异步客户端。1.8还将增加http2.0、mqtt协议的支持。
另外一个重要调整就是，1.8将支持Server多协议。目前1.7版本一个swoole_server只能使用一种网络协议，比如swoole_http_server就只能处理HTTP协议，无法再支持固定包头+包体、EOF协议。有一些场景下一个Server需要做多件事情。新的版本会支持混合多协议。
正是因为上面的性能测试，让我下定决定在swoole内逐步开始支持绝大部分通用的网络协议。C语言实现的客户端在性能上远远超过其他语言。Swoole要让PHP在网络通信方面超过其他语言，比如Java、Node.js、Golang、Erlang等，只有C语言实现一条路可选。
扩展内RPC的支持
RPC作为服务器端程序中很重要的一项功能，Swoole没有理由不去支持它。1.8版本将会内置RPC的基础模块，包括Server端和Client端，Client端会同时支持异步和同步，并且支持php-fpm下调用。
配套工具的支持
经常有PHPer向我反馈想要有一套命令行工具可以简单地实现Server程序的start、stop、reload、status，以及通过inotify监控实现自动reload，新的swoole-1.8开发计划中将包含这些工具，我们会提供一些通用的、非侵入式的工具。
Swoole-1.8什么时候发布
我们已经启动了开发，新特性会逐个在子版本上线，预计2016年7月份会上齐所有特性。
昨天和一个前同事聊天，各种吐槽PHP，吐槽Swoole，他认为PHP到处是坑，PHP局限很大。PHP+Swoole不适合做高并发服务器，C+Swoole才是最好的方案。C++有各种数据结构，C++可以开线程，C++可以共享对象。看来有必要好好得说明一下了。
PHP比C/C++或Java少了什么？多线程，多线程，多线程……
是的。PHP比C/C++、Java少了多线程。PHP只有多进程的方案，所以PHP里的全局变量和对象不是共享的、数据结构也不能跨进程操作、Socket文件描述符不能共享等等。所以PHP有局限？
多线程看似比多进程要强大很多，实际上我可以负责任的告诉你，多线程带来的坑更多。
数据同步问题会让你崩溃的。要么就牺牲性能到处加锁，要么就用地狱难度的无锁并发编程，据我所知目前国内能掌握此项技能的人凤毛麟角。
不要以为加锁就万事大吉了，你会在死锁问题上栽个大跟头。当你的程序逻辑复杂后，锁越来越难控制了，一旦死锁你的程序基本上就完了。
某个线程挂了那所有线程都会退出
反而在看多进程，其实就简单的多了。
配合进程间通信，基本上你可以实现任意的数据共享。比如利用一个进程专门存数据结构和对象，其他进程的数据操作全部投递到此进程来
多进程不需要锁
多进程可以使用共享内存的数据结构实现一些多线程的功能。如Swoole提供的Table、Atomic可以实现数据共享，但成本很低。未来还会加入共享内存队列
所谓PHP限制了Swoole，这完全是无稽之谈。合理利用Swoole提供的Table、Atomic、SendMessage/PipeMessage、Task完全可以实现异步非阻塞的代码逻辑。
C++写出来的程序性能更好？
这完全是盲目的迷信，密集计算的程序C++确实是有优势的。而并发服务器核心是IO，并非大规模密集运算。C++从语言层面来看并没有什么优势。另外C++中的大部分数据结构在PHP中都有对应的实现，实在不行自己写个专门的扩展也能解决之。
高并发的服务器单机能维持10W连接、每秒可处理3-5W笔消息收发。这种性能水准已经可以应用在BAT的核心系统上了。
开发效率快的意义是什么？
这位同事还说PHP开发Server虽然比C++快了，但是追求性能的极致还是要用C++。我要告诉你效率高了究竟意义何在。开发一套好程序不是一件容易的事情，需要程序员投入大量时间和精力。开发效率提升的意义并不是简单的我可以更少时间完工，而是剩下的时间你可以增加单元测试、修复BUG、提升用户体验、完善细节、提供配套工具、优化性能、增加关键日志、增加监控报警、增加容灾方案。
TCP协议在底层机制上解决了UDP协议的顺序和丢包重传问题。但相比UDP又带来了新的问题，TCP协议是流式的，数据包没有边界。应用程序使用TCP通信就会面临这些难题。一些程序在本机测试是正确的，上线后就出现各种奇怪的BUG。如下面的伪代码，客户端向服务器端发送一个json字符串，服务器端接收此字符串。在慢速网络中Server无法正确接收完整的JSON字符串。
$client-&send(json_encode('a' =& $data_10k, 'b' =& $data_5k));
$pkg = $server-&recv(); //Server收到的数据只有一小部分
$client-&send("hello1");
$client-&send("hello2");
$client-&send("hello3");
$pkg = $server-&recv(); //Server会一次性收到3个数据包
因为TCP通信是流式的，在接收1个大数据包时，可能会被拆分成多个数据包发送。多次Send底层也可能会合并成一次进行发送。这里就需要2个操作来解决：
分包：Server收到了多个数据包，需要拆分数据包
合包：Server收到的数据只是包的一部分，需要缓存数据，合并成完整的包
具体编码实现这里就不讲了，这是一个比较复杂的编程过程，稍有不慎就会出现严重的BUG
Swoole如何解决此问题
swoole提供了通用协议的支持，如Http和WebSocket。自定义协议可以使用Length/EOF 2种协议解析方式来完美解决此问题。从1.7.18版本开始，Swoole的Server/Client都支持了Length/EOF的协议处理方式，应用层代码只需要配置一下参数，就无需关注底层分包合包了。每次onReceive收到的数据包总是完整的。
Server/Client的配置是相同的
Http/WebSocket
swoole内置对http/websocket 2种协议的支持，如果要实现一个http服务或者websocket服务，直接用swoole_http_server和swoole_websocket_server即可。
$server-&set(array('open_eof_split' =& true, 'package_eof' =& "\r\n"));
EOF协议处理的原理是每个数据包结尾加一串特殊字符表示包已结束。如memcache、ftp、stmp都使用\r\n作为结束符。发送数据时只需要在包末尾增加\r\n即可。使用EOF协议处理，一定要确保数据包中间不会出现EOF，否则会造成分包错误。
$server-&set(array(
'open_length_check' =& true,
'package_max_length' =& 81920,
'package_length_type' =& 'n', //see php pack()
'package_length_offset' =& 0,
'package_body_offset' =& 2,
固定包头的协议非常通用，在BAT的服务器程序中经常能看到。这种协议的特点是一个数据包总是由包头+包体2部分组成。包头由一个字段指定了包体或整个包的长度，长度一般是使用2字节/4字节整数来表示。服务器收到包头后，可以根据长度值来精确控制需要再接收多少数据就时完整的数据包。Swoole的配置可以很好的支持这种协议，可以灵活地设置4项参数应对所有情况。
Swoole的Server和异步Client都是在onReceive回调函数中处理数据包，当设置了协议处理后，只有收到一个完整数据包时才会触发onReceive事件。同步客户端在设置了协议处理后，调用 $client-&recv() 不再需要传入长度，recv函数在收到完整数据包或发生错误后返回。
最近PHP官方终于发布了传说中的PHP7，虽然只是alpha版。PHP7号称是新一代的PHP，官方开发组对Zend引擎底层做了大量修改来优化PHP的性能。可以说PHP7这个版本的主题就是性能优化。
在过去PHP一直以开发效率快著称，而语言本身的性能较差（当然比Python，Ruby还是要快一些的）。普通的Web网站都是IO密集型的程序，瓶颈在MySQL上，所以体现不出PHP的性能劣势。但在密集计算方面比C/C++、Java等静态编译语言差几十倍甚至上百倍。另外使用设计非常复杂的开发框架，如Symfony、Laravel等，程序性能也会明显下降。
现在随着PHP越来越流行，像Facebook、新浪微博这样超大型规模的网站都在使用PHP。PHP语言性能问题就越来越严重了。Facebook有几十万台服务器，如果现有的PHP程序可以提升一部分性能，将会节约大量的服务器资源。所以就有了HHVM、Hack。Hack为PHP增加了类型，HHVM是一个重新设计的PHP引擎，实际项目中使用HHVM可以提近70%的性能。实际项目70%性能提升这是一个什么概念？腾讯QQ农场最初使用PHP开发，后因为性能问题使用C语言重构，完成后性能提升了100%。
PHP官方也注意到了这个问题，所以就有了PHP7的开发计划。最新公布的PHP7-alpha在WordPress项目中测试的表现已经超越了HHVM。未来PHP将会同时具备极高的开发效率和极高的性能，再结合Swoole做异步编程，PHP势必会更加流行。
本文简单介绍一下PHP7做了哪些优化，可以提升如此多性能。
zval使用栈内存
在Zend引擎和扩展中，经常要创建一个PHP的变量，底层就是一个zval指针。之前的版本都是通过MAKE_STD_ZVAL动态的从堆上分配一个zval内存。而PHP7可以直接使用栈内存。PHP代码中创建的变量也进行了优化，PHP7直接在栈内存上预分配zval。这样节约了大量内存分配和内存管理的操作。
zval * MAKE_STD_ZVAL(val);
二 zend_string存储hash值，array查询不再需要重复计算hash
PHP7为字符串单独创建了新类型叫做zend_string，除了char *指针和长度之外，增加了一个hash字段，用于保存字符串的hash值。PHP中array是核心数据结构，PHP程序中往往都有大量的$array[$key]操作，虽然hashtable查找的时间复杂度是O(1)，但$key要转为hash值是要经过计算的。不仅仅是array操作，实际上PHP底层对于类属性、类方法、函数，访问时都要先通过hashtable查找到对应的指针，再执行对应的操作。PHP7之前Zend引擎会有大量的CPU时间用于计算hash值。
实际上PHP程序运行起来之后，大部分情况下$key的值都是不变的。PHP7干脆将这个hash值保存起来，下次直接使用，这样就节省了大量的hash计算操作，PHP的hashtable与C数组的性能一致。
从实际项目进行callgrind性能分析，会发现alloc和hash 2项操作就占用了相当大比例的CPU时间。PHP7优化之后这2项操作占用的CPU时间降低了非常多。（注：zend_hash仍然占12%，因为整体CPU降低了，所以总的耗时降低了不少）
三 hashtable桶内直接存数据
PHP5的hashtable每个元素都是一个 Bucket *，而PHP7直接存Bucket，减少了内存申请次数，提升了Cache命中率和内存访问速度。
四 zend_parse_parameters改为宏实现
PHP的C扩展函数与PHP中的变量进行参数输入时，要使用zend_parse_parameters()函数，这个函数根据一个字符串参数找到对应PHP的zval指针，然后进行赋值。 这个函数实际上有一定的性能消耗。PHP7直接使用宏替换了zend_parse_parameters函数，C扩展中不再需要使用zend_parse_parameters进行逐个参数的查找，宏展开后自动会实现参数赋值。仅此一项就提升了5%的性能。
五 新增加4种OPCODE
很多PHP程序中会大量使用call_user_function, is_int/string/array,
strlen , defined 函数。PHP5 都是以扩展函数的方式提供，PHP7中这4类函数改成ZendVM的OPCODE指令，执行更快。
六 其他更多优化
除了上面5个主要优化点之外，PHP7还有其他更多的细节性能优化。如基础类型int、float、bool等改为直接进行值拷贝，排序算法改进，PCRE with JIT，execute_data和opline使用全局寄存器等等。PHP7对性能的优化会继续进行下去。
PHP7-alpha相比PHP5.6性能提升了近3倍。下面是WordPress在PHP7上的表现：
PHP7的新特性
除了性能优化外，PHP7新增加了2项重要的新特性。
1. 变量类型
PHP7版本函数的参数和返回值增加了类型限定。为什么PHP要加入类型，实际上此项特性是为了PHP7.1版本的JIT特性做准备，增加类型后PHP JIT可以准确判断变量类型，生成最佳的机器指令。
function test(int $a, string $b, array $c) : int {
2. 错误异常
PHP程序出错后过去Zend引擎会发生致命错误并终止程序运行，PHP7可以使用try/catch捕获错误。底层使用Exeception代替了Fatal Error。这个特性表示PHP语言正在向一个更加规范的方向发展。应用层与底层在错误抛出的方式全部统一为异常。
non_exists_func();
} catch (EngineException $e) {
echo "Exception: {$e-&getMessage()}\n";
$test = new class("Hello World") {
public function __construct($greeting) {
$this-&greeting = $
最初PHP7性能优化的方向并不是以上所讲的，而是JIT。JIT是just in time的缩写，表示运行时将指令转为二进制机器码。Java语言的JVM引擎底层就是使用JIT将Java字节码编译为二进制机器码执行。PHP7开发过程中有一个中间版本是基于JIT，后来开发组发现使用JIT后，对于实际项目并没有有太大的性能提升，所以PHP7最终放弃了JIT方案，PHP7.0-final版本不会携带JIT特性。
但如果是密集计算类程序就不同了，使用JIT将PHP OpCode编译为机器码，运算的性能会大幅提升。PHP官方开发组在2014年底重启了JIT的开发工作。
PHP的异步网络通信扩展Swoole
PHP在大部分程序员印象中都是用来做Web网站的。PHP没有像Python的Twisted、Tornado，Java的Netty、Mina，JavaScript的Node.js等框架，无法实现异步网络通信程序。PHP的Swoole扩展就是为了弥补此项缺陷而诞生的开源项目。Swoole是一个标准的PHP扩展，为PHP提供了一系列异步IO、事件驱动、并行数据结构功能。
Swoole与Node.js非常相似，不同之处是Swoole在并行提供了底层支持。Node.js是一个单进程单线程的程序，在多核服务器上无法发挥全部CPU核的计算能力。需要程序员自行使用child_process/cluster扩展或者启动多实例，使程序能够利用到多核优势。而Swoole在底层就支持了多线程/多进程，程序启动后就会创建好多个IO线程和多个Worker进程。程序员仅需配置线程/进程数量即可。
使用Swoole开发的TCP服务器程序：
$serv = new swoole_server("127.0.0.1", 9501);
$serv-&on('connect', function ($serv, $fd){
echo "Client:Connect.\n";
$serv-&on('receive', function ($serv, $fd, $from_id, $data) {
$serv-&send($fd, $data);
$serv-&on('close', function ($serv, $fd) {
echo "Client: Close.\n";
$serv-&start();
Swoole同样也内置了http_server和WebSocket服务器的支持。swoole_http_server与传统的php-fpm不同，它是在PHP内进行事件循环的，基于swoole_http_server完全可以开发出类似Java应用服务器一样，可以控制完整对象生命周期的程序。swoole_http_server天然支持异步IO，可以很方便的实现支持大量TCP连接的Comet服务。swoole_websocket_server可以用来实现支持Web实时推送的程序。
使用Swoole的Web服务器程序：
$http = new swoole_http_server("0.0.0.0", 9501);
$http-&on('request', function ($request, $response) {
$response-&header("Content-Type", "text/ charset=utf-8");
$response-&end("
Hello Swoole. #".rand()."
$http-&start();
可以预见PHP语言未来会在性能方面有明显的提升，越来越接近C/C++、Java等静态编译语言。再加上Swoole扩展，PHP的使用范围可以扩展到移动通信、云计算、网络游戏、物联网、车联网、智能家居等领域。
PHP虽然未必是最好的编程语言，但PHP在向着这个方向在发展。
swoole-1.7.14增加了tick定时器，解决了addtimer存在的各种问题。
swoole_timer_tick(1000, function ($timer_id) {
echo "tick-1000ms\n";
swoole_timer_clear($timer_id);
swoole_timer_tick(2000, function () {
echo "tick-2000ms\n";
swoole_timer_tick和swoole_timer_after原理是相同的，区别是after只执行一次就会销毁。tick定时器会持续执行，直到调用了swoole_timer_clear清除定时器。
与PHP代码中的pcntl_alarm不同，swoole的定时器是基于EventLoop实现的，不依赖系统信号和PHP的tick机制，所以效率非常高。即使添加大量定时器，CPU消耗也是很低的。PHP在过去没有像JavaScript这样方便的定时器功能，现在有swoole就可以很好地解决。
在网络游戏程序中经常要用定时器，PHP+swoole将会成为最佳的技术方案。
最近群里很多朋友询问我是如何学习编程的，今天抽个时间大致讲讲。
和所有人一样，上学学的第一门编程语言是C语言。我记得我当时学的很认真，非常认真。和别人最大的不同是我买了一本老外写的C语言编程书，没被谭浩强误导。另外还买了一本《现代操作系统》一书看了很久。学习期间写了不少读书笔记。真正要说学到什么了，这个还真不好说，到最后我对C语言也是似懂非懂的状态。
用学物理、数学的方法学编程语言是行不通的，编程需要的是实践。
学Java的目的很明确，为了找一份好工作。面向对象、J2EE、Java设计模式、SSH的书买了好几本。最后还是没能够入门。原因我后来分析主要是2点，1、Java太复杂了，根本就不适合初学者。2、犯了和学习C语言同样的错误，读书太多，实践太少（主要是不会搭建Java的开发环境）。
偶然的机会了解到了PHP语言，按照网上的教程一搞，写了一个MySQL的网页程序，竟然运行成功了。这实在太神奇了。你们无法理解当时我的心情，可以说到了 高兴地3天不用吃饭的程度。呵呵，当时我就下定决心以后就是它了。PHP让我进入了一个新的境界，我可以大量地实践，写出各种程序。而且也顺利找到了工作，干的风生水起，一个接一个地做了很多项目。后来又进入腾讯，在腾讯有机会去开发维护一个超过2亿用户，日活超过8千万，机器规模超过1000多台的超大系统。我的人生的各种成果都归功于PHP这门伟大的编程语言。
重新回到C语言
当然后面也逐渐认识到PHP的不足，不过很快我就发现可以写C扩展来弥补。重新学起C语言，我发现竟然很顺利。原因应该是我在写PHP程序的过程中，工程实践能力已经磨练到非同一般。其实不只是C语言，只要我愿意，C++，Java，Python，Golang任何语言都可以快速掌握。然后就开始搞Swoole这个项目，边学边做。经过这2年的时间，现在可以说我已经掌握C语言了。
为什么会回到C语言，原因很简单：所有底层软件都是C语言写的，包括操作系统、底层库、驱动、其他编程语言本身。C语言一切现代软件技术的根源。
我的个人感悟
我的编程之路轨迹就是 C语言（起始） -& Java（过客）-& PHP（主）-& C语言（终点）。
编程语言专注于一个就行了，Java、PHP、Python、Ruby 任意一个都行。只要能把一门编程语言学精通，其他语言学起来也很容易。
工作时选择的编程语言，应该是一主多辅。做Web得了解Javascript，做APP需要掌握Android、Object-C，写桌面程序需要学习C++。带着问题去学就好了。
不要选择难或者复杂的编程语言作为入门，易于上手的编程语言更容易成功。公司有一个搞Java 9年的人，技术等级很低。很好的例子。另外一个只工作了5年的PHPer现在已经是T3-2的技术Leader了。
编程最核心的是动手实践
多看一看别的编程语言和技术，开阔一下视野
编程做到最后还是会回到C语言的，当然很多人中途就已经离开编程岗位了
分类: , , ,
最近到处在争论这些话题，发现很多人对一些基础的常识并不了解，在此发表一文做一下解释。此文未必能解答所有问题，各位能有一个大致的了解就好。
C10K的由来
大家都知道互联网的基础就是网络通信，早期的互联网可以说是一个小群体的集合。互联网还不够普及，用户也不多。一台服务器同时在线100个用户估计在当时已经算是大型应用了。所以并不存在什么C10K的难题。互联网的爆发期应该是在www网站，浏览器，雅虎出现后。最早的互联网称之为Web1.0，互联网大部分的使用场景是下载一个Html页面，用户在浏览器中查看网页上的信息。这个时期也不存在C10K问题。
Web2.0时代到来后就不同了，1方面是普及率大大提高了，用户群体几何倍增长。2是互联网不再是单纯的浏览万维网网页，逐渐开始进行交互，而且应用程序的逻辑也变的更复杂，从简单的表单提交，到即时通信和在线实时互动。C10K的问题才体现出来了。每一个用户都必须与服务器保持TCP连接才能进行实时的数据交互。Facebook这样的网站同一时间的并发TCP连接可能会过亿。
腾讯QQ也是有C10K问题的，只不过他们是用了UDP这种原始的包交换协议来实现的，绕开了这个难题。当然过程肯定是痛苦的。如果当时有epoll技术，他们肯定会用TCP。后来的手机QQ，微信都采用TCP协议。
这时候问题就来了，最初的服务器都是基于进程/线程模型的，新到来一个TCP连接，就需要分配1个进程（或者线程）。而进程又是操作系统最昂贵的资源，一台机器无法创建很多进程。如果是C10K就要创建1万个进程，那么操作系统是无法承受的。如果是采用分布式系统，维持1亿用户在线需要10万台服务器，成本巨大，也只有Facebook，Google，雅虎才有财力购买如此多的服务器。这就是C10K问题的本质。
实际上当时也有异步模式，如：select/poll模型，这些技术都有一定的缺点，如selelct最大不能超过1024，poll没有限制，但每次收到数据需要遍历每一个连接查看哪个连接有数据请求。
Epoll异步非阻塞
既然有了C10K问题，程序员们就开始行动去解决它。于是FreeBSD推出了kqueue，Linux推出了epoll，Windows推出了IOCP。这些操作系统提供的功能就是为了解决C10K问题。因为Linux是互联网企业中使用率最高的操作系统，Epoll就成为C10K killer、高并发、高性能、异步非阻塞这些技术的代名词了。
epoll技术的编程模型就是异步非阻塞回调，也可以叫做Reactor，事件驱动，事件轮循（EventLoop）。Epoll就是为了解决C10K问题而生。使用Epoll技术，使得小公司也可以玩高并发。不需要购买很多服务器，有几台服务器就可以服务大量用户。Nginx，libevent，node.js这些就是Epoll时代的产物。
C100K，C1M，C10M，C100M …
C10K问题解决后，程序员又提出了更高的挑战，也就是最近在火热争论的C100K，C1M等。Epoll既然能解决C10K，解决什么C100K，C1M也是可以的。只不过这个已经没有意义了。一个公司有1亿用户难道他买不起1万台服务器嘛。WhatsApp有2亿用户，卖了150亿美元。1万台服务器最多花费5000万美元。
看到阿里技术保障部的人也在谈C10K话题，我要补充一下，搞路由器、交换机、网关、防火墙之类基础网络设备的人，就不要参与C10K话题了。我们说的是应用层程序。
协程，coroutine
当程序员还沉浸在解决C10K问题带来的成就感时，一个新的问题被抛出了。异步嵌套回调太TM难写了。尤其是Node.js层层回调，缩进了几十层，要把程序员逼疯了。于是一个新的技术被提出来了，那就是协程（coroutine）。这个技术本质上也是异步非阻塞技术，它是将事件回调进行了包装，让程序员看不到里面的事件循环。程序员就像写阻塞代码一样简单。比如调用 client-&recv() 等待接收数据时，就像阻塞代码一样写。实际上是底层库在执行recv时悄悄保存了一个状态，比如代码行数，局部变量的值。然后就跳回到EventLoop中了。什么时候真的数据到来时，它再把刚才保存的代码行数，局部变量值取出来，又开始继续执行。
这个就像时间禁止的游戏一样，国王对巫师说“我必须马上得到宝物，不然就砍了你的脑袋”，巫师念了一句时间停止的咒语，直到过了1年后勇士们才把宝物送来。这时候巫师解开咒语，把宝物交给国王。这里国王就可以理解成协程，他根本没感觉到时间停止，在他停止到醒来期间发生了什么他不知道，也不关心。
这就是协程的本质。协程是异步非阻塞的另外一种展现形式。Golang，Erlang，Lua协程都是这个模型。
再回到同步阻塞这个话题，不知道大家看完协程是否感觉得到，实际上协程和同步阻塞是一样的。答案是的。所以协程也叫做用户态进/用户态线程。区别就在于进程/线程是操作系统充当了EventLoop调度，而协程是自己用Epoll进行调度。
协程的优点是它比系统线程开销小，缺点是如果其中一个协程中有密集计算，其他的协程就不运行了。操作系统进程的缺点是开销大，优点是无论代码怎么写，所有进程都可以并发运行。
Erlang解决了协程密集计算的问题，它基于自行开发VM，并不执行机器码。即使存在密集计算的场景，VM发现某个协程执行时间过长，也可以进行中止切换。Golang由于是直接执行机器码的，所以无法解决此问题。所以Golang要求用户必须在密集计算的代码中，自行Yield。
实际上同步阻塞程序的性能并不差，它的效率很高，不会浪费资源。当进程发生阻塞后，操作系统会将它挂起，不会分配CPU。直到数据到达才会分配CPU。多进程只是开多了之后副作用太大，因为进程多了互相切换有开销。所以如果一个服务器程序只有1000左右的并发连接，同步阻塞模式是最好的。
异步回调和协程哪个性能好
协程虽然是用户态调度，实际上还是需要调度的，既然调度就会存在上下文切换。所以协程虽然比操作系统进程性能要好，但总还是有额外消耗的。而异步回调是没有切换开销的，它等同于顺序执行代码。所以异步回调程序的性能是要优于协程模型的。
这里是指Nginx这种多进程异步非阻塞程序。Node.js/Redis此类程序如果不开多个进程，由于无法利用多核计算优势，所以性能并不好。在Node.js中可以使用childprocess/cluster等扩展开启多进程以解决此问题。
最近几年大量的资本投入到移动互联网，这个行业很是被看好。但懂行的人都知道这里泡沫太重，曾经有人以为微信商城一出手就可以压倒淘宝天猫，后来发现这个微信商城订单少的可怜。毫无疑问移动互联网被高估了。目前互联网市场，大家都可以看得到PC，游戏，Web，社交等市场基本上已经饱和了。而阿里巴巴、京东主导的电商确实一片欣欣向荣，市场前景非常好。国内目前电商仅仅在1,2线城市得到普及，3，4线城市以及小城镇电商还是处于一个试探的阶段，市场空间是极大的。所以前不久阿里会投入100亿去开拓地方小城镇市场。
个人认为移动互联网，云计算，以及最近火热的智能家居，车联网实际上都是为了物联网做铺垫，真正的未来科技是物联网。互联网只是颠覆了信息传递，而物联网可以颠覆人的生活。未来每一个电器设备都会有操作系统和无线网络芯片，比如冰箱、电视、空调、电灯、洗衣机等等。设备的传感器获取到环境信息由自带的微型系统计算分析，通过WIFI网络连接路由器，接入互联网，将信息传入云端。云端服务器通过3G/4G/5G/6G/WIFI网络，实时地与每个人的手机通信，发送信息。云端还可以接收来自手机客户端下达的各项指令，再通过网络-&路由器-&WIFI到电器设备，设备接到指令后就可以去执行。比如照明设备可以在用户回家之前自动开启，空调在回家前20分钟自动开启升温或者降温，清洁设备可以自动启动开始除尘，烹饪设备可以开始工作制作食物，饮水设备可以自动加热，配备了自动导航和自动驾驶的智能电动汽车可以在主人下班前自动驾驶到公司楼下等待，等等更多。未来想象空间是无限的，而且这些东西实际上离我们已经很近了。
硬件是科技的载体，软件是科技的灵魂，这些全部离不开编程技术。我们程序员应该考虑用什么技术去实现这些，我的观点是传统的C/C++，Java，Golang都无法满足需求，这些编程语言天生就是为专业的程序而生。未来的编程语言，必须要简单，非计算机专业的人士也可以掌握。个人感觉云端服务器程序，PHP，Python，Ruby都是很好的选择。JavaScript肯定不再其中，目前专业程序用JS都会觉得很饶，这个语言不够严谨。当然传统PHP也是不行的，必须有实时通信支持才可以满足需求，PHP配合Swoole就毫无压力了。移动客户端程序，Swift/Dart是很好的选择。
很多纯PHP开发的后端框架中都使用了pcntl扩展提供的信号处理函数pcntl_signal，实际上这个函数的性能是很差的。首先看一段示例代码：
declare(ticks = 1);
pcntl_signal(SIGINT, 'signalHandler');
这段代码在执行pcntl_signal前，先加入了declare(ticks = 1)。因为PHP的函数无法直接注册到操作系统信号设置中，所以pcntl信号需要依赖tick机制。通过查看pcntl.c的源码实现发现。pcntl_signal的实现原理是，触发信号后先将信号加入一个队列中。然后在PHP的ticks回调函数中不断检查是否有信号，如果有信号就执行PHP中指定的回调函数，如果没有则跳出函数。
PHP_MINIT_FUNCTION(pcntl)
php_register_signal_constants(INIT_FUNC_ARGS_PASSTHRU);
php_pcntl_register_errno_constants(INIT_FUNC_ARGS_PASSTHRU);
php_add_tick_function(pcntl_signal_dispatch TSRMLS_CC);
return SUCCESS;
pcntl_signal_dispatch 函数的实现：
void pcntl_signal_dispatch()
//.... 这里略去一部分代码，queue即是信号队列
while (queue) {
if ((handle = zend_hash_index_find(&PCNTL_G(php_signal_table), queue->signo)) != NULL) {
ZVAL_NULL(&retval);
ZVAL_LONG(&param, queue->signo);
/* Call php signal handler - Note that we do not report errors, and we ignore the return value */
/* FIXME: this is probably broken when multiple signals are handled in this while loop (retval) */
call_user_function(EG(function_table), NULL, handle, &retval, 1, &param TSRMLS_CC);
zval_ptr_dtor(&param);
zval_ptr_dtor(&retval);
next = queue->
queue->next = PCNTL_G(spares);
PCNTL_G(spares) =
这样就存在一个比较严重的性能问题，大家都知道PHP的ticks=1表示每执行1行PHP代码就回调此函数。实际上大部分时间都没有信号产生，但ticks的函数一直会执行。如果一个服务器程序1秒中接收1000次请求，平均每个请求要执行1000行PHP代码。那么PHP的pcntl_signal，就带来了额外的 1000 * 1000，也就是100万次空的函数调用。这样会浪费大量的CPU资源。
比较好的做法是去掉ticks，转而使用pcntl_signal_dispatch，在代码循环中自行处理信号。而swoole中因为底层是C实现的，信号处理不受PHP的影响。swoole使用了目前Linux系统中最先进的signalfd来处理信号，几乎是没有任何额外消耗的。
Linux/Unix系统
深入理解计算机系统
UNIX环境高级编程
深入理解Linux内核
网络通信编程
UNIX网络编程
TCP/IP详解
Linux多线程服务端编程
数据结构与算法
《数据结构》（C语言版）
C程序设计语言
PHP5权威编程}