本帖最后由 KPRF2009 于 2012-12-06 13:26:53 编辑

解决方案 »

  1.   

    可以用基于I/O的多路复用技术,Windows下用IOCP,Linux下用Epoll
      

  2.   

    MINA是对NIO进行了一次封装,方便使用
      

  3.   

    既然用线程池能处理1万人,那说明并不是10万人同时访问,所以用NIO应该能满足需求
      

  4.   

    楼主这个需求写的完全不清晰。首先要确认你的10w人服务器,是长连接型的,如即时通讯;还是短连接型的,如网站?如果是短连接型,首推仍然是线程池;因为这种情况下连接会很多、切换很快,所以没必要去维护连接,想想银行大厅的前台窗口排队叫号,窗口忙得很如果还同时照顾几个客户那不疯了?如果是长连接型,首推是NIO模型;因为这种情况下保持连接很重要,但线程并不忙,想想医院住院部的病人,大部分时间躺在床上就行了,一个护士就可以搞定好多病人了;mina提供了比较好的封装。
      

  5.   

    我个人认为10万的并发 不是一台服务器能搞的定的 nio只能解决客户对服务器的访问,其他业务逻辑呢? 数据库的访问、各种资源的访问等等等
      

  6.   

    个人经验应该在编程模型上用nio,在硬件上用集群来部署,这样比较周全
      

  7.   

    请问 如果是十万人的聊天系统,应该用什么框架?jboss netty框架行不行?应该属于通讯的,短连接?
      

  8.   


    我也是这样认为的 集群来部署用什么系统比较好?ubuntu?   我能告诉我如何让服务器之间来均衡发来的请求吗?就是如何把他们串在一起?求资料
      

  9.   

    无论如何,一个IP只有64K个端口可以用,一个机器同时服务100K人是肯定不行的。
    一定有LB设备才行。
    至于用什么框架,那就是另外一个话题了。 Mina框架不适合工业级应用,一般的网站还是没问题的。 要是实时性高,那就没有什么框架可以用的,NIO只是个粗略的技术术语,不同的业务需要做不同的优化,还有后续的缓冲/排队等等。所以你要把你的业务流量模型大概说清楚,大伙儿才帮你
      

  10.   

    手机软件发语音消息的流量模型,应该是长连接,短突发。这个用NIO满合适的。 
    手机用户,有延迟,掉线后重连什么的很常见,要在DB侧做数据保存,不能全用实时传输。反正不是银行类业务,MINA+集群我觉得就可以了。
      

  11.   


    网上说的 jboss netty 框架是MINA的优化版可以吗?
      

  12.   


    要看业务量,也就是你这10万个手机用户,到底发送信息的频度如何。
    也就是要计算出 TPS:每秒事务处理量(简单点就是平均每秒你的服务器要处理多少消息传输)。
    如果你这10万个手机用户,平均一天只发送1条消息,那也没啥;10万消息平均到每天 10 小时,不过是每小时1W条,每秒才3条不到;一台服务器就够解决问题了。当然另一个问题是你的服务器是啥能力的,你搞个山寨台式机跟搞个P780是数量级上的差距。
    至于15楼所说的64K的问题,那个不是问题。TCP的连接是根据四元组(五元组)来建立的,64K的限制是在两台计算机之间才是这个数;基于互联网的情况下,所能支持TCP的量级绝对远远远远超你服务器处理能力的。集群环境恐怕没有你想得这么简单,当用户U1连接在你 FA服务器 上,用户U2连接在你 FB服务器上;然后U1向U2发送信息,你的系统准备怎么玩?
    建议你考虑基于某开源的消息服务框架(未必非要Java,毕竟你只需要利用服务器)来进行二次开发,比如OpenFire啥的,也许会更靠谱些。
      

  13.   

    如果我把A发给B的消息存在数据库里面,然后B不停的去请求服务器查询有木有最新的消息来,如果有就获取,然后把这条消息标记成已经获取了可以吗?
      

  14.   


    那么,注意到 FA 上面有5W 个用户,FB上面有5W个用户。你的意思是,共计10W个用户不停的去请求服务器查询有木有最新消息来?那么你需要一个超级强大的数据库服务器,至于应用服务器,随便整个4CPU16核的就差不多了。
      

  15.   


    需要一个超级强大的数据库服务器?貌似我可以优化这个问题开2个静态的10W的一维数组A数组表示是否有消息(初始化全部是0)B数组表示[如果有消息]数据库储存的最后一条消息的id(初始化全部是-1),【如果有数据,就先扫描一次数据库,预处理下】我们把十万个用户编号1---10W当T1发消息给T2的时候,我们先在数组里面查询下(映射表代价 O(1))如果没有消息就不去数据库里面拿了如果有消息就先去B数组里面查最后一条消息在数据库的id,然后去获取最后一条消息,【注意:这里需要在数据库里面增加一个字段:上一条消息在数据库的id】,这里采用链表的思想,记录上一条的位置,不用去查了直接获取,然后把状态改变为已获取直到上一条的消息编号是:-1,把消息发送后最后把A[T2]=0;B[T2]=-1;
    这样就应该可以优化很多
      

  16.   

    你提出来的方案,相当于将数据模型部分放入了内存中,那么似乎你需要两个服务都能访问同一个内存模型,才能保证数据一致;或者你需要用另一种手段来保证两个服务器有镜像的内存模型。
    不过,实际上在集群环境下,你必然会面临这种多服务器之间数据共享需求,这是逃不掉的。因为单纯依赖于数据库级别的数据共享,基本上都会面临严重的性能瓶颈。那么也许你会起用MemCache这类外置缓存服务等方式,用其来维护所有用户的登录位置状态等,然后服务器智能的将跨服务器的消息准确的发送给目标服务器再转发给最终用户。
    总的来说是个挺大的命题,不使用成熟的开源框架,你会比较辛苦啊
      

  17.   


    你说的成熟框架是指的:OpenFire 吗?还是MINA?如果你来写会用那种框架?会怎么来做?求一个大概思路。我主要是文字,语音(大多数),图片信息  应该需要存一下数据库,因为可以留言
      

  18.   


    QQ是自己写的协议,UDP直接发送的
      

  19.   

    至于15楼所说的64K的问题,那个不是问题。TCP的连接是根据四元组(五元组)来建立的,64K的限制是在两台计算机之间才是这个数;基于互联网的情况下,所能支持TCP的量级绝对远远远远超你服务器处理能力的。这个不是这么算的哦,虽然是五元组,其实是一元,因为你提供服务的IP是固定的。 没有负载均衡,只有一台server,你能建立两条链接,一个是 1.2.3.4:80,另外一个是1.2.3.5:80来提供服务么?
      

  20.   

    TCP的连接是根据四元组(五元组)来建立的 大哥能不能解释一下
      

  21.   

    "因为TCP端口号是16位无符号整数, 最大65535, 所以一台服务器最多支持65536个TCP socket连接." - 一个非常经典的误解! 即使是有多年网络编程经验的人, 也会持有这个错误结论.理论
    系统通过一个四元组来唯一标识一条TCP连接. 这个四元组的结构是{local ip, local port, remote ip, remote port}, 对于IPv4, 系统理论上最多可以管理2^(32+16+32+16), 2的96次方个连接. 如果不仅仅考虑TCP, 则是一个五元组, 加上协议号(TCP, UDP或者其它).
      

  22.   

    膜拜...最近也在接触 netty和nio啥的...还是比较难的!学习中...
      

  23.   


    最近封闭搞项目,有段时间没上CSDN。客观地说,我并不是此方面的领域专家,短时间能根据经验给你些建议,但恐怕未必能比开源的框架做得更好。这也是为啥我会建议你用开源框架的原因,Openfire 应该是目前最火热的,它只是一个平台,你可以在此平台基础上做二次增强,支持集群等企业级能力。偷偷的说,我知道的几家中型企业,就用这个做运营平台中的即时通讯部分,量级约50万。如果你不是运营级要求,就用这个应该是差不多了的。如果非要自行开发,那么给你如下建议:
    ◎ 分离:登录服务器、通讯服务器、消息服务器 和 数据库服务器;
    ◎ 登录服务器(有状态):除给Client提供登录和分配通讯服务器外,重点功能是提供关于用户目前连接在哪台服务器上的查询,所以所有查询基本基于缓存完成;考虑到单点故障问题,登录服务器应双机冗余,但不能太多,否则双机之间的缓存同步代价太高;缓存可使用开源组件。
    ◎ 通讯服务器(有状态):负责维护消息长连接,以及消息的收发;通讯服务器缓存自身的所有用户连接信息,和部分(这个要时情况动态调整)非自身的热点用户连接信息(即该用户连在哪台通讯服务器上);消息到达时,将消息转发给消息服务器进行落地;然后根据目标最终用户先查询本地表,查不到就去查询登录服务器;然后直接寻找目标通讯服务器,发送消息到达的通知;通讯服务器的问题是没有Failover,但是也不重要,客户端连接不上就由登录服务器重新分配新的通讯服务器来提供服务即可。
    ◎ 消息服务器(无状态):负责接收通讯服务器所发来的消息,批量写入数据库中,以及供其它消息服务器存取;另外也提供历史消息查询这类辅助性功能;因为是无状态,所以集群较为简单,略。
    ◎ 数据库服务器:略。