今天要讨论的话题是多页面数据同步。顾名思义，就是更新A页面的内容，B页面也要及时反映出改变，当然A、B页面至少要是在同域下才有意义。放在WebIM这个应用场景中来，就是如果有多个页面开着webim，其中任何一个页面上发送或接收到新消息，要在其他所有的页面中同步显示出来。

使用短连接的WebIM要轮询服务器来获取最新的消息，如果多个页面一起轮询，那么对服务器的消耗还是很大的，使用页面数据同步能减少消耗：无论同时存在多少个聊天页面，同时仅有一个主页面A负责与服务器轮询；在主页面A轮询到服务器消息后，分发给其他页面B、C、D；如果A被关掉了，检测程序会马上检测到，并从剩下的页面中挑选新的页面充当主页面负责通讯；客户端向服务端提交数据不必通过主页面，直接向服务器提交即可，只是提交的数据也需要分发给其他页面，便于同步UI。

多页面数据同步的实现细化起来，大概就是下面这个流程：

1.有一套本地化存储方案，要求能本域下任何页面都可以读写数据，至少有set和get两个方法；

2.页面加载时实例化sync对象，可以指定页面代号(name)方便进行页面分组，系统自动给每个页面分类一个唯一标识符(clientId)，并将这个页面client的相关信息加入clients列表，放进本地存储；

3.sync提供sendMsg方法，可根据clientID发给单一页面，或根据name发给一组页面，传递的数据(data)是一个JSON，sendMsg方法不关心data的实际结构。将消息的发送者clientID、接收者clientID以及data拼成一个消息JSON，并将多条JSON组成一个消息数组，序列化后放本地存储；

4.sync通过定时检查并解析本地存储获知是否有新消息，在收到发给自己(根据clientID来判断)的消息后，将这条消息置为已读，并调用onNewMsg方法，将data作为参数传递给它；

5.页面unload的时候，需要调用remove方法将自己从clients列表中去除。

另外，每个页面都必须有一个定时器，用来更新clients列表，检查新消息以及删掉已读消息。

新版本的webim应该会采用这种方案来实现多页面聊天，具体代码我也没写完，不过从下面的demo已经可以看到基本思想：打开多个页面，在文本框写些文字，点击同步按钮，其它页面会同步更新文本框。

点这里打开Demo。

该方案的让人头疼的是用什么做本地存储：userData需要页面完全一致才能使用；globalStorage只有firefox和ie8才支持；flash、google gear需要装插件，database storage是html5里的内容也没几家支持。这样看来似乎只有session cookie比较靠谱，但众所周知每次与服务器的交互都会带上cookie，cookie本身的容量也很有限。但是，相比较每个页面都轮询服务器而言，就算用cookie存也还是值得的。

我之前发布了一个webim，那个im设计了前端UI、交互，后端程序和通讯只是随便写了一下。作为一个交互很多的web应用，良好的后端设计可以减少数据库访问、减轻服务器负载；良好的通讯模式更是可以较少服务器连接数、节省流量。这篇文章主要讲web即时通讯中常用的技术。

HTTP是无连接的，HTTP通讯过程基本就是：客户端发送请求给服务器，服务器接收请求给出响应信息，客户端接收响应信息显示在用户的显示器上，客户端断开连接。由此可知，要实现即时聊天中的”即时”，我们有两个办法：服务器抓住连接不断开和客户端不断的向服务器发起请求实现伪即时。当然用Flash XMLSocket可以实现真正的即时通讯，但这样已经不是使用HTTP协议了，HTTP天生的优势（无需另外开端口、自动穿越防火墙）也就无法体现。

1.短轮询(polling)：核心思想是客户端定时去服务器取消息。为了实现即时效果，轮询的间隔必须设计得足够短，另外为了操作的流畅，需要使用Ajax来发送请求。本人的QGYWebIM就是采用的此方案。这种方案的优点是：后端程序编写比较容易，发送完响应信息马上断开连接，不会占用太多服务器资源。缺点是一般情况下，频繁的请求中有大半是无用，这些冗余请求无形中浪费了带宽和服务器资源。我们可以通过判断用户的活跃程度来决策请求服务器的间隔，我在51的一个帖子提到过这种方法，但是间隔一旦长了，消息的传送就有延时，违背了即时聊天的初衷了。

2.长轮询(long-polling)：基本原理是客户端向服务器发送请求，服务器接到请求后hold住连接，直到有新消息才返回响应信息并关闭连接，连接被断开期间用户的新信息会被服务器缓存起来。客户端处理完响应信息后再向服务器发送新的请求。这种做法的优势是如果用户一直没新消息，客户端不会频繁的轮询去服务器取消息，节省了流量，但是服务器维持长连接是很消耗资源的。具体实现起来，前端这边基本不需要什么改动，依然是用Ajax轮询取信息，后端需要在没有新消息时处理一下。

3.长连接(streaming)：其实很早以前就有人使用这种技术来实现聊天室的通讯。以前在页面中嵌入一个iframe，iframe里放一个使用长连接页面，服务器有新消息就会及时的在iframe里反映出来，再依靠客户端的脚本解析出来就OK了。这样做一个比较严重的问题是：使用iframe请求长连接时，无论是IE还是firefox都会认为页面没有加载完而显示进度条，很难看。不过这个问题是可以解决的。firefox支持了Streaming Ajax，在readyState为3的时候就能接受数据，所以问题不大；IE则只能在readyState为4，即连接断开时才能得到返回值。但是伟大的Google工程师使用了一个hack成功的解决了这个问题：使用一个被称为“htmlfile”的ActiveX，把iframe放在这个ActiveX里就OK了。

无疑，使用长连接对于用户来说是最好的方案，用户体验最好（消息能及时的到达）、占用用户带宽最少（不会发送无用的请求），但是会增加服务器的开销；长轮询是折中方案，Facebook IM就是采用这种方案，不过做了一点改动：客户端发起的每个连接服务器都hold10S，这10S中新消息会源源不断的返回给客户端，10s后连接关闭，客户端发起下一个连接。这样做是因为Facebook的用户会不断的打开、关闭新页面，如果每个页面都建立一个永久的长连接，会阻塞浏览器其他请求，服务器也会吃不消的；短轮询因为实现起来简单，适用于小型应用。