站内信/消息功能的小型推送应用,用轮询还是长轮询?该如何处理
程序员文章站
2022-05-22 20:34:16
...
站内信/消息功能的小型推送应用,用轮询还是长轮询?
最近要做一个这个小应用,也查了不少资料。现在比较纠结该用哪个,主要是考虑服务器负载问题,望了解的大哥指点一二。
1)ajax做个3秒轮询的话,一是会有很多无效请求,另如果上一个请求服务器没响应下一个请求就到了的话,服务器肯定也鸭梨山大。
2)做长轮询的话,一个用户就一个连接,服务器要同时hold住这么多连接,鸭梨也很山大啊。
小弟对具体的架构不懂,反正这2个方法放在这很纠结,因为我也不会分析具体的服务器负载什么的。
另:服务器为盛大中等云主机and这个小应用对即时性要求不高。
------解决方案--------------------
站内信还要做推送比较少见,用户停在一个页面时间不会太长。如果真有这需求,那是真应该加个memcache了,每当对某个用户有更新操作,同时也更新memchache。
另外站内信是要考虑群发功能的,这时只需要插入一条记录,在用户登录时补全。还要把内容分成另外一个表。
------解决方案--------------------
关系编号 发送者 接受者 消息编号 状态
1 ID1 ID2 3 读/未读
这就是一张关系表,另外还有消息表,用户表。
站内信一般就是一个未读信件的计数,select count就得到所有该用户未读信件的条数了,在可容忍限度内减少AJAX给数据库带来的查询压力,可以做个120秒的缓存存储未读条数,然后20秒一拉,就完事了。
最近要做一个这个小应用,也查了不少资料。现在比较纠结该用哪个,主要是考虑服务器负载问题,望了解的大哥指点一二。
1)ajax做个3秒轮询的话,一是会有很多无效请求,另如果上一个请求服务器没响应下一个请求就到了的话,服务器肯定也鸭梨山大。
2)做长轮询的话,一个用户就一个连接,服务器要同时hold住这么多连接,鸭梨也很山大啊。
小弟对具体的架构不懂,反正这2个方法放在这很纠结,因为我也不会分析具体的服务器负载什么的。
另:服务器为盛大中等云主机and这个小应用对即时性要求不高。
------解决方案--------------------
站内信还要做推送比较少见,用户停在一个页面时间不会太长。如果真有这需求,那是真应该加个memcache了,每当对某个用户有更新操作,同时也更新memchache。
另外站内信是要考虑群发功能的,这时只需要插入一条记录,在用户登录时补全。还要把内容分成另外一个表。
------解决方案--------------------
关系编号 发送者 接受者 消息编号 状态
1 ID1 ID2 3 读/未读
这就是一张关系表,另外还有消息表,用户表。
站内信一般就是一个未读信件的计数,select count就得到所有该用户未读信件的条数了,在可容忍限度内减少AJAX给数据库带来的查询压力,可以做个120秒的缓存存储未读条数,然后20秒一拉,就完事了。
相关文章
相关视频