求高并发，10w人服务器的思路

求高并发，10w人服务器的思路


求各位高手来解决下。。。


我想用NOI框架来做，但是网上说mina框架比较好。。。

我估计如果直接用线程池可以处理1W人的服务器。。。

但是10万。。。求高手指点

43 个解决方案

#1

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

#2

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

#3

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

#4

#5

嗯

#6

NIO以满足10万人

#7

楼主这个需求写的完全不清晰。

首先要确认你的10w人服务器，是长连接型的，如即时通讯；还是短连接型的，如网站？

如果是短连接型，首推仍然是线程池；因为这种情况下连接会很多、切换很快，所以没必要去维护连接，想想银行大厅的前台窗口排队叫号，窗口忙得很如果还同时照顾几个客户那不疯了？

如果是长连接型，首推是NIO模型；因为这种情况下保持连接很重要，但线程并不忙，想想医院住院部的病人，大部分时间躺在床上就行了，一个护士就可以搞定好多病人了；mina提供了比较好的封装。

#8

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

#9

真的10万人同时在线，不管是什么IO都得挂，考虑服务器集群才是王道！

#10

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

#11

引用 7 楼 ldh911 的回复:

楼主这个需求写的完全不清晰。

首先要确认你的10w人服务器，是长连接型的，如即时通讯；还是短连接型的，如网站？

如果是短连接型，首推仍然是线程池；因为这种情况下连接会很多、切换很快，所以没必要去维护连接，想想银行大厅的前台窗口排队叫号，窗口忙得很如果还同时照顾几个客户那不疯了？

如果是长连接型，首推是NIO模型；因为这种情况下保持连接很重要，但线程并不忙……

---学习了，讲解的很到位..

#12

引用 7 楼 ldh911 的回复:

楼主这个需求写的完全不清晰。

首先要确认你的10w人服务器，是长连接型的，如即时通讯；还是短连接型的，如网站？

如果是短连接型，首推仍然是线程池；因为这种情况下连接会很多、切换很快，所以没必要去维护连接，想想银行大厅的前台窗口排队叫号，窗口忙得很如果还同时照顾几个客户那不疯了？

如果是长连接型，首推是NIO模型；因为这种情况下保持连接很重要，但线程并不忙……

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

#13

引用 7 楼 ldh911 的回复:

楼主这个需求写的完全不清晰。

首先要确认你的10w人服务器，是长连接型的，如即时通讯；还是短连接型的，如网站？

如果是短连接型，首推仍然是线程池；因为这种情况下连接会很多、切换很快，所以没必要去维护连接，想想银行大厅的前台窗口排队叫号，窗口忙得很如果还同时照顾几个客户那不疯了？

如果是长连接型，首推是NIO模型；因为这种情况下保持连接很重要，但线程并不忙……

我是准备先实现1W人在线的聊天系统，用5台服务器，1台服务器装数据库。。。

5台服务器怎么均衡 用什么？


如果这样搭建   以后扩容到10台 20台方便吗？

#14

引用 10 楼 gymak 的回复:

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

我也是这样认为的 集群来部署

用什么系统比较好？ubuntu？   我能告诉我如何让服务器之间来均衡发来的请求吗？就是如何把他们串在一起？求资料。。。

#15

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

所以你要把你的业务流量模型大概说清楚，大伙儿才帮你

#16

引用 15 楼 clariones 的回复:

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

所以你要把你的业务流量模型大概说清楚，……

大概是这样的，是做及时通宵的，类似微信一样，我们现在有10万个手机用户，都在使用我们的手机软件发语音消息。。。

大概就是这个样子，，，我想找一个好的框架来写。。。然后用分布式服务器来弄。。。

#17

手机软件发语音消息的流量模型，应该是长连接，短突发。这个用NIO满合适的。 
手机用户，有延迟，掉线后重连什么的很常见，要在DB侧做数据保存，不能全用实时传输。

反正不是银行类业务，MINA+集群我觉得就可以了。

#18

引用 17 楼 clariones 的回复:

手机软件发语音消息的流量模型，应该是长连接，短突发。这个用NIO满合适的。 
手机用户，有延迟，掉线后重连什么的很常见，要在DB侧做数据保存，不能全用实时传输。

反正不是银行类业务，MINA+集群我觉得就可以了。

网上说的 jboss netty 框架是MINA的优化版。。。

可以吗？

#19

该回复于2012-12-08 10:25:52被管理员删除

#20

引用 16 楼 KPRF2009 的回复:

大概是这样的，是做及时通宵的，类似微信一样，我们现在有10万个手机用户，都在使用我们的手机软件发语音消息。。。

大概就是这个样子，，，我想找一个好的框架来写。。。然后用分布式服务器来弄。。。

要看业务量，也就是你这10万个手机用户，到底发送信息的频度如何。
也就是要计算出 TPS：每秒事务处理量（简单点就是平均每秒你的服务器要处理多少消息传输）。
如果你这10万个手机用户，平均一天只发送1条消息，那也没啥；10万消息平均到每天 10 小时，不过是每小时1W条，每秒才3条不到；一台服务器就够解决问题了。

当然另一个问题是你的服务器是啥能力的，你搞个山寨台式机跟搞个P780是数量级上的差距。


至于15楼所说的64K的问题，那个不是问题。TCP的连接是根据四元组（五元组）来建立的，64K的限制是在两台计算机之间才是这个数；基于互联网的情况下，所能支持TCP的量级绝对远远远远超你服务器处理能力的。



集群环境恐怕没有你想得这么简单，当用户U1连接在你 FA服务器 上，用户U2连接在你 FB服务器上；然后U1向U2发送信息，你的系统准备怎么玩？
建议你考虑基于某开源的消息服务框架（未必非要Java，毕竟你只需要利用服务器）来进行二次开发，比如OpenFire啥的，也许会更靠谱些。

#21

引用 20 楼 ldh911 的回复:

引用 16 楼 KPRF2009 的回复:大概是这样的，是做及时通宵的，类似微信一样，我们现在有10万个手机用户，都在使用我们的手机软件发语音消息。。。

大概就是这个样子，，，我想找一个好的框架来写。。。然后用分布式服务器来弄。。。

要看业务量，也就是你这10万个手机用户，到底发送信息的频度如何。
也就是要计算出 TPS：每秒事务处理量（简单点就是平均每秒你……

我只会用java。。。。

#22

引用 20 楼 ldh911 的回复:

引用 16 楼 KPRF2009 的回复:大概是这样的，是做及时通宵的，类似微信一样，我们现在有10万个手机用户，都在使用我们的手机软件发语音消息。。。

大概就是这个样子，，，我想找一个好的框架来写。。。然后用分布式服务器来弄。。。

要看业务量，也就是你这10万个手机用户，到底发送信息的频度如何。
也就是要计算出 TPS：每秒事务处理量（简单点就是平均每秒你……

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

#23

引用 7 楼 ldh911 的回复:

楼主这个需求写的完全不清晰。

首先要确认你的10w人服务器，是长连接型的，如即时通讯；还是短连接型的，如网站？

如果是短连接型，首推仍然是线程池；因为这种情况下连接会很多、切换很快，所以没必要去维护连接，想想银行大厅的前台窗口排队叫号，窗口忙得很如果还同时照顾几个客户那不疯了？

如果是长连接型，首推是NIO模型；因为这种情况下保持连接很重要，但线程并不忙……

讲得非常好。

#24

该回复于2012-12-08 09:25:36被管理员删除

#25

引用 22 楼 KPRF2009 的回复:

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

那么，注意到 FA 上面有5W 个用户，FB上面有5W个用户。

你的意思是，共计10W个用户不停的去请求服务器查询有木有最新消息来？

那么你需要一个超级强大的数据库服务器，至于应用服务器，随便整个4CPU16核的就差不多了。

#26

引用 25 楼 ldh911 的回复:

引用 22 楼 KPRF2009 的回复:如果我把A发给B的消息存在数据库里面，然后B不停的去请求服务器查询有木有最新的消息来，如果有就获取，然后把这条消息标记成已经获取了。。。可以吗？

那么，注意到 FA 上面有5W 个用户，FB上面有5W个用户。

你的意思是，共计10W个用户不停的去请求服务器查询有木有最新消息来？

那么你需要一个超级强大的数据库服务……

需要一个超级强大的数据库服务器？

貌似我可以优化这个问题

开2个静态的10W的一维数组。。。A数组表示是否有消息。。。（初始化全部是0）B数组表示[如果有消息]数据库储存的最后一条消息的id（初始化全部是-1），【如果有数据，就先扫描一次数据库，预处理下。。。】

我们把十万个用户编号。。。1---10W

当T1发消息给T2的时候，我们先在数组里面查询下（映射表代价 O(1)）。。。如果没有消息就不去数据库里面拿了。。。

如果有消息就先去B数组里面查最后一条消息在数据库的id，然后去获取最后一条消息，【注意：这里需要在数据库里面增加一个字段：上一条消息在数据库的id】，这里采用链表的思想，记录上一条的位置，不用去查了。。。直接获取，然后把状态改变为已获取。。。直到上一条的消息编号是：-1，把消息发送后最后把A[T2]=0;B[T2]=-1;


这样就应该可以优化很多。。。

#27

你提出来的方案，相当于将数据模型部分放入了内存中，那么似乎你需要两个服务都能访问同一个内存模型，才能保证数据一致；或者你需要用另一种手段来保证两个服务器有镜像的内存模型。


不过，实际上在集群环境下，你必然会面临这种多服务器之间数据共享需求，这是逃不掉的。因为单纯依赖于数据库级别的数据共享，基本上都会面临严重的性能瓶颈。那么也许你会起用MemCache这类外置缓存服务等方式，用其来维护所有用户的登录位置状态等，然后服务器智能的将跨服务器的消息准确的发送给目标服务器再转发给最终用户。


总的来说是个挺大的命题，不使用成熟的开源框架，你会比较辛苦啊。。。

#28

引用 27 楼 ldh911 的回复:

你提出来的方案，相当于将数据模型部分放入了内存中，那么似乎你需要两个服务都能访问同一个内存模型，才能保证数据一致；或者你需要用另一种手段来保证两个服务器有镜像的内存模型。


不过，实际上在集群环境下，你必然会面临这种多服务器之间数据共享需求，这是逃不掉的。因为单纯依赖于数据库级别的数据共享，基本上都会面临严重的性能瓶颈。那么也许你会起用MemCache这类外置缓存……

你说的成熟框架是指的：OpenFire 吗？还是MINA？

如果你来写会用那种框架？会怎么来做？求一个大概思路。

我主要是文字，语音（大多数），图片信息  

应该需要存一下数据库，因为可以留言

#29

完全不知道你们在说什么。。。。一种局外人的感觉……

#30

好贴留名。

#31

qq怎么做的？

#32

引用 31 楼 jiangertou 的回复:

qq怎么做的？

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

#33

该回复于2012-12-10 08:55:17被管理员删除

#34

至于15楼所说的64K的问题，那个不是问题。TCP的连接是根据四元组（五元组）来建立的，64K的限制是在两台计算机之间才是这个数；基于互联网的情况下，所能支持TCP的量级绝对远远远远超你服务器处理能力的。

这个不是这么算的哦，虽然是五元组，其实是一元，因为你提供服务的IP是固定的。 没有负载均衡，只有一台server，你能建立两条链接，一个是 1.2.3.4:80,另外一个是1.2.3.5：80来提供服务么？

#35

引用 34 楼 clariones 的回复:

至于15楼所说的64K的问题，那个不是问题。TCP的连接是根据四元组（五元组）来建立的，64K的限制是在两台计算机之间才是这个数；基于互联网的情况下，所能支持TCP的量级绝对远远远远超你服务器处理能力的。

这个不是这么算的哦，虽然是五元组，其实是一元，因为你提供服务的IP是固定的。 没有负载均衡，只有一台server，你能建立两条链接，一个是 1.2.3.4:80,……

10万，肯定做分布式的，肯定会做负载均衡的。。。

不知道大哥，对我说的，如果是您来做，有木有具体的一些实现方法？

#36

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

#37

引用 36 楼 ghchen 的回复:

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

"因为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或者其它).

#38

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

#39

引用 35 楼 KPRF2009 的回复:

不知道大哥，对我说的，如果是您来做，有木有具体的一些实现方法？

最近封闭搞项目，有段时间没上CSDN。

客观地说，我并不是此方面的领域专家，短时间能根据经验给你些建议，但恐怕未必能比开源的框架做得更好。这也是为啥我会建议你用开源框架的原因，Openfire 应该是目前最火热的，它只是一个平台，你可以在此平台基础上做二次增强，支持集群等企业级能力。

偷偷的说，我知道的几家中型企业，就用这个做运营平台中的即时通讯部分，量级约50万。

如果你不是运营级要求，就用这个应该是差不多了的。



如果非要自行开发，那么给你如下建议：
◎ 分离：登录服务器、通讯服务器、消息服务器 和 数据库服务器；
◎ 登录服务器（有状态）：除给Client提供登录和分配通讯服务器外，重点功能是提供关于用户目前连接在哪台服务器上的查询，所以所有查询基本基于缓存完成；考虑到单点故障问题，登录服务器应双机冗余，但不能太多，否则双机之间的缓存同步代价太高；缓存可使用开源组件。
◎ 通讯服务器（有状态）：负责维护消息长连接，以及消息的收发；通讯服务器缓存自身的所有用户连接信息，和部分（这个要时情况动态调整）非自身的热点用户连接信息（即该用户连在哪台通讯服务器上）；消息到达时，将消息转发给消息服务器进行落地；然后根据目标最终用户先查询本地表，查不到就去查询登录服务器；然后直接寻找目标通讯服务器，发送消息到达的通知；通讯服务器的问题是没有Failover，但是也不重要，客户端连接不上就由登录服务器重新分配新的通讯服务器来提供服务即可。
◎ 消息服务器（无状态）：负责接收通讯服务器所发来的消息，批量写入数据库中，以及供其它消息服务器存取；另外也提供历史消息查询这类辅助性功能；因为是无状态，所以集群较为简单，略。
◎ 数据库服务器：略。

#40

太牛了，长见识了。

#41

引用 39 楼 ldh911 的回复:

引用 35 楼 KPRF2009 的回复:不知道大哥，对我说的，如果是您来做，有木有具体的一些实现方法？

最近封闭搞项目，有段时间没上CSDN。

客观地说，我并不是此方面的领域专家，短时间能根据经验给你些建议，但恐怕未必能比开源的框架做得更好。这也是为啥我会建议你用开源框架的原因，Openfire 应该是目前最火热的，它只是一个平台，你可以在此平台基础上做二次……

学习了

#42

学习了

#43

牛人呀牛人，来学习了