应该保持长连接，然后进行推送把，具体也不太清楚
这里的关键点，是要“服务器主动推送”，而我们使用的普通ajax结构都是客户端问，服务器才会答。新浪微博使用的消息提醒机制，应该是基于，或者类似于Comet的这种HTTP长连接技术。如果单纯基于普通的ajax，由客户端定时发起询问请求，由服务器来答，这种结构时效性不强，而且不断的发HTTP包，一方面增加了流量开支，另一方面也增加了服务器负荷。而Comet这种长轮询，可以以长“心跳包”的形式来跟服务器交互，当有新消息时，再由客户端请求，进而获取具体是什么新消息。IBM的开发社区里有一篇介绍Comet的文章，讲述的很详细，我就不复述了IBM社区《Comet：基于 HTTP 长连接的“服务器推”技术》
如果你的需求是要求服务器推送，而且不用考虑浏览器兼容性，并且客户浏览器支持HTML5中的SSE，Server-sent-event，也就是“服务器发送事件”的话，也可以考虑采用他，制作起来比Comet要简单很多，效果也要好很多MDN上有一篇介绍SSE的文章MDN《使用服务器发送事件》
服务器端：消息表是肯定是要的。消息表包括的基本字段：id，消息类型，来源，接收人，发送时间。然后是用户表，或者从用户表分离分离出来的表。要有一个 last_readtime ，也就最后查看消息的时间。用户每次进入或只要看了个人消息，这个最后阅读时间就更新为当时的时间戳。
客户端：页面利用Ajax长轮询或HTML5的EventSource监听。PHP根据 last_readtime，查询消息表里的大于这个 last_readtime的消息记录。返回到页面，形成消息提示。
用firebug调试一下weibo.com的网络请求可以发现，微博用的是轮询来实现消息提醒的，应该是用set timer隔个30秒或一分钟去服务器进行查询。和即时通信的web应用不同，微博提醒实时性要求不高，所以用轮询方式比较合理，没有必要用长连接。
我想到可能的实现是：1. 轮询，这个最简单，定时查呗。2. 还是推送。服务器有服务总线，定时把除消息外的其它数据（例如加好友通知、新消息条数等）推过来……不太清楚具体的实现，只是个人看法。
一般的消息推送是使用服务推的方式，但是目前的浏览器不支持开着一个端口来监听，做不到客户端那样，所以浏览器一般是使用长轮询，说白就是一个长时间的异步请求，有消息来时就马上关闭连接并发起另一个请求，这个资源的消耗服务器要撑得起才行
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
暂无简介
文章 0 评论 0
接受
发布评论
评论（6）
应该保持长连接，然后进行推送把，具体也不太清楚
这里的关键点，是要“服务器主动推送”，而我们使用的普通ajax结构都是客户端问，服务器才会答。
新浪微博使用的消息提醒机制，应该是基于，或者类似于Comet的这种HTTP长连接技术。
如果单纯基于普通的ajax，由客户端定时发起询问请求，由服务器来答，这种结构时效性不强，而且不断的发HTTP包，一方面增加了流量开支，另一方面也增加了服务器负荷。
而Comet这种长轮询，可以以长“心跳包”的形式来跟服务器交互，当有新消息时，再由客户端请求，进而获取具体是什么新消息。
IBM的开发社区里有一篇介绍Comet的文章，讲述的很详细，我就不复述了
IBM社区《Comet：基于 HTTP 长连接的“服务器推”技术》
如果你的需求是要求服务器推送，而且不用考虑浏览器兼容性，并且客户浏览器支持HTML5中的SSE，Server-sent-event，也就是“服务器发送事件”的话，也可以考虑采用他，制作起来比Comet要简单很多，效果也要好很多
MDN上有一篇介绍SSE的文章
MDN《使用服务器发送事件》
服务器端：
消息表是肯定是要的。
消息表包括的基本字段：id，消息类型，来源，接收人，发送时间。
然后是用户表，或者从用户表分离分离出来的表。
要有一个 last_readtime ，也就最后查看消息的时间。
用户每次进入或只要看了个人消息，这个最后阅读时间就更新为当时的时间戳。
客户端：
页面利用Ajax长轮询或HTML5的EventSource监听。
PHP根据 last_readtime，查询消息表里的大于这个 last_readtime的消息记录。
返回到页面，形成消息提示。
用firebug调试一下weibo.com的网络请求可以发现，微博用的是轮询来实现消息提醒的，应该是用set timer隔个30秒或一分钟去服务器进行查询。和即时通信的web应用不同，微博提醒实时性要求不高，所以用轮询方式比较合理，没有必要用长连接。
我想到可能的实现是：
1. 轮询，这个最简单，定时查呗。
2. 还是推送。服务器有服务总线，定时把除消息外的其它数据（例如加好友通知、新消息条数等）推过来……
不太清楚具体的实现，只是个人看法。
一般的消息推送是使用服务推的方式，但是目前的浏览器不支持开着一个端口来监听，做不到客户端那样，所以浏览器一般是使用长轮询，说白就是一个长时间的异步请求，有消息来时就马上关闭连接并发起另一个请求，这个资源的消耗服务器要撑得起才行