mysql长轮询_web端构建实时应用方案及PHP+ajax长轮询阻塞问题的解决

web端构建实时应用方案及PHP+ajax长轮询阻塞问题的解决

构建实时应用一般有以下几个方案

Ajax定时器每间隔一段很短的时间去服务器取数据。

Ajax跟后台语言配合使用长轮询。

使用最新的HTML特性websocket。

方案的优缺点分析

方案1：除了简单之外没什么优点，缺点是没有达到真正的实时，另外会给服务器带来非常大的压力，现在基本摒弃不用了。

方案2：实现比较简单，基本做到了实时，在Ajax定时的基础上大量减轻了服务器的压力，不过并发数高的情况最好深思熟虑下，服务器的压力还是很大的，长时间占用http连接及mysql连接，容易耗尽连接数。

方案3：缺点是浏览器兼容性不是很好，构建服务端相对复杂些，优点就非常明显，可以做到绝对的实时，并且服务压力非常小，另外浏览器兼容性方面可以考虑websoct + flash sockt方案。

方案的选择

最近刚好要做到应用，客户端页面只有一个几乎可以不考虑服务器压力，但是对实时性要求比较高，经过权衡最终选方案二，实现成本低，能满足需求。

遇到的问题

开发的时候遇到问题，刷新页面非常慢，因为是本地电脑做服务器以为是电脑配置低的原因，就没在意了。

直到使用测试服务器的时候，发现问题还是存在，并且根据现象突出来一点是只要长轮询的页面开着打开其他页面也是非常的慢，关闭长轮询的页面其他页面就好了。

问题的分析确定

根据这个现象我首先想到的是会不会是后端php程序占用资源过高(后端php是使用while循环去查数据库，查到数据立即返回，没查到数据就睡眠1秒，然后集训查数据库，如此循环，最大超时时间是15秒。)仔细检查一番代码并没发现问题，再查看长轮询的时候服务器资源占用情况，资源占用基本没什么大的增长。

这个时候基本已经排除后端程序本身BUG引起的资源占用过多问题，那会是什么原因呢，会不会是浏览器的阻塞机制呢，然后就使用两个不同的浏览器，一个打开有长轮询的页面，一个打开该应用下的其他页面，居然发现打开其他页面的时候一点都不慢了，可是刷新长轮询的页面还是很慢。

这个时候基本上已经确定了原因就是阻塞引起的，如果是这样，那基本就要放弃这个方案了，但是想想现在用长轮询的应用很多，应该是有解决方案的，经过查询资料之后才发现并不是浏览器的阻塞机制导致的，而是因为session的阻塞(其实是session锁)机制导致的。

寻找问题的原因

在PHP中执行session_start()后，session会被锁住。直到页面执行完成。因此在页面执行其间，对sesssion进行写操作，只会保存在内存中，并不会写入session文件。而对session进行读取，则需要等待，直到session锁解开才能读取到。

就是因为这个机制，在Ajax长轮询的时候相当于发起了一个http请求，正在执行一个php程序，这个客户端会话session被锁了，这个时候访问该应用的其他页面或者刷新页面相当于再次发起一个http请求，执行一个php程序，由于前一个php一直在执行，后面一个http请求就只能等待，因为php要读取session信息得等session解锁。

解决办法

最后解决办法，在长轮询的程序里面用完session之后立即执行 session_commit() 这个函数能立即把数据写入session文件并结束session进程，这样该客户端的其他会话请求就能进行了。

那如果这个长轮询程序后面还要用到session怎么办呢？很简单重新使用 session_start();用完记得session_commit();。