php+mysql+memcache实战型技术测试(答案公布)

出两个变态的题目，题目很变态，但是都是实战中遇到的真实案例，

1：我写一个程序，既要使用mysql也要使用memcache，

第一行是 mysql_connect,第二行是memcache_connect

换过来写，第一行是memcache_connect，第二行是mysql_connect

caoz发现实践中这两种写法有很大的区别，区别在哪里？

2：我写一个程序，使用了mysql，生成了一个页面最后用 echo $html; 输出

一种写法是

mysql_close();

echo $html;

另一种是

echo $html;

mysql_close();

caoz发现实践中这两种区别很大，区别在哪里？

两个全是实践中发现并调整的案例。

---------------------------------------------半夜黑眼圈更新博客的分割线--------------------------------

caoz写程序不是追求BT的人，caoz经常和工程师强调，不追求极端的技术体现或者技术炫耀，所以，如果读者认为这里的题目是为了所谓的诸如某个写法比某个写法资源开销小一点或者其他什么，那么这真不是caoz的本意。

这两道题都是真实运营环境中遇到的典型案例，典型在哪里呢？就是当你遇到一个系统故障的时候，你怎么分析，怎么思考，怎么判断多种关联因素的影响，所以这个题目答出答不出并不重要，重要的是怎么思考系统彼此的关系。

一个典型的系统故障是， mysql 连接过多，或者说too many connections，这个问题困扰了我们很久，如果这是因为索引导致的，或者因为数据并发请求导致的，定位到原因并不复杂，但是当上述问题解决后，诡异的现象发生了，数据库几乎没有压力，没有阻塞进程，没有慢查询，但是mysql连接很多，而且都是sleep连接。此时，webserver的链接也很多，换句话说，因为php执行阻塞，导致mysql链接无法迅速释放，那么，php为什么会阻塞？ 逐个断点分析发现，原来echo耽误了最多时间。

这个事情让caoz涨了点经验，之前从来不会认为echo是一个时间阻塞点（如果你在本机测试，你会认为其时间延迟几乎是0），但是实例跟踪发现，echo实际上在我们的工作环境中，代表的网络传输的过程，换言之，会因为路由，带宽的因素而等待，而此时，mysql的链接还在那里没有释放，是的，看到题目每个人都会想到，mysql_close要放在echo后面，但是为什么echo会耽误时间，很少人会想到。当然，这个也与工作环境有关，caoz只知道我们配置的webserver会有这种情况，是不是存在其他的配置模式，caoz没有实测，不敢乱说，但是这里的经验是，mysql_close放到echo前面，大量的sleep链接会迅速减少。

echo并不耗费太多系统资源，但是会等待网络传输，在高并发的网络环境下，注意这一点对数据库很有好处。

这个问题解决后，mysql健康了很多，但是偶然还会出现链接过多的问题，又困扰了很久，直到有一天，根据用户反馈的一些错误信息，发现memcached服务器有不稳定因素，原来是memcached流量过高产生阻塞，php进程等待链接，导致mysql链接大量等待，这是第一个题目的由来，其实这个题目本身没有标准答案，但是应该有一个意识，当你在一个脚本中同时启动A,B两个链接，那么如果你不能保证这两个链接是必然可靠的（通常是无法保障的），那么后者一旦阻塞，就会导致前者大量链接等待，而前者阻塞，通常不会影响后者。所以，这个答案取决于，哪个链接对你的应用更重要，以及哪个链接有更大的并发支撑性。

两道题说到底就是一个意思，当遇到系统问题和故障的时候，多想想一些关联的因素影响，多思考整个架构响应先后过程的逻辑，数据库连接过多，不一定是数据库造成的，web链接过多，也不一定非要去优化webserver，关联因素可能才是根源，解决了根源，表象才会彻底解决。