首页 新闻 赞助 找找看

关于IM即时消息的思路!!!!

0
悬赏园豆:100 [已关闭问题]

例如: 我在网页上给对方发送了一个消息,但是它在IM上能够即时收到。

 请大家都说说,给一个思路!!!

 我现在想的是:

第一种、是有一个程序不停的扫描数据库,然后有数据了然后再分发给对应的用户。但是觉得这种不可取,给数据库的压力太大。

第二种、就是oracle 有一个触发器,当消息到达数据库,然后触发器通知一个外部程序,这样的话就可以通知IM。但是找了半天这样做的好像也不多。。

 

大家多多提,看是否有更好的思路,或者有做过的类似成功方案!谢谢!!

 

crocodile的主页 crocodile | 初学一级 | 园豆:80
提问于:2008-10-06 11:03
< >
分享
其他回答(7)
0

这个问题我也想过!听说有一种叫长连接的东西能做!但我也不知道是什么!
我所能想到的和你的第一种方法一样,使用js写一个程序,不停的请求数据库,但这样确实会给数据库造成压力!
我想过一个方法来解决这个问题,当发送方发送消息的时候,在服务器上生成xml文件,接收方的js文件,一直去找是否有新的文件(可以根据接收方userid+日期)等方式,如果有的话,就呈现消息!
这种方法我没有验证过,你试试吧!

飞阿飞 | 园豆:444 (菜鸟二级) | 2008-10-06 11:21
0

可以看一下观察者模式方面的资料

另个 如果是轮询的方式的话,关键得分析一下你的程序,看取一个多大的轮询时间比较好。

张荣华 | 园豆:2020 (老鸟四级) | 2008-10-06 13:30
0

触发器不要用了,程序轮询(扫描)并没有什么问题

比如3秒钟检测一次,这个时间对于用户来说应该是可以忍受的,3秒钟一次数据库操作没有任何问题,你可以这样算,页面每一次打开多数情况下都需要访问数据库吧,如果有三个人在线(这已经很少了),那么一秒内非常可能超过5次数据库访问,但你的程序和数据库在这种负载下显然不应该出现问题,所以你3秒一次轮询不会有问题,甚至1秒一次的轮询都没有关系

数据库没有想象的那么脆弱,呵呵。想想那些没做缓存上千人在线的网站,一秒钟上百次数据库访问并不会有什么问题

其实网站的站内短消息真正的问题不在这里,而在于如何及时通知用户,因为你无法主动发消息给浏览器,所以只能在页面中通过ajax或者iframe不停的请求服务器,每个打开了页面的用户都需要不停的发送请求,这才是真正的性能问题所在。(C/S类的IM没有此问题)

丁学 | 园豆:18730 (专家六级) | 2008-10-06 20:16
0

公司的商务通产品就是使用的AJAJX刷消息。

Bēniaǒ | 园豆:692 (小虾三级) | 2008-10-06 22:16
0

个人觉得轮询比较好

目前的应用是这么写的,大概情况是用户在页面上提交了信息,后台服务端程序(一个或多个)轮询数据库,发现有新信息,先标记自己拿到了,再采取操作。轮询大概1秒一次,比较温和了,如果是一次询问发现了新纪录,则当此执行完后无条件进行一次询问;若未发现,则延迟1秒轮询。目前没发现什么性能诟病。

如果用多个后台服务端程序,需要控制好并发问题,应该超出本帖讨论范围了吧。

 

@飞阿飞

丁学兄的说法并不矛盾,可能是你理解有点偏差。

丁学的意思应该是说服务端程序轮询不是问题,问题是客户端并发大,不停发送请求。

JimLiu | 园豆:300 (菜鸟二级) | 2008-10-06 22:34
0

你所谓的IM是WEB版的还WINFORM版的

东子 | 园豆:205 (菜鸟二级) | 2008-10-08 11:39
0

ajax处理消息加入到queue中,然后后台处理,返回也是一样

zjy | 园豆:3194 (老鸟四级) | 2008-10-08 11:47
0

SNS这个功能确实很有用.ajax好象在这方面确实是专长...

有所为,有所不为 | 园豆:1200 (小虾三级) | 2008-10-09 10:11
清除回答草稿
   您需要登录以后才能回答,未注册用户请先注册