群聊天系统，高吞吐量，高转发量，后端什么架构？比如一个群1000个人在聊天，共20万个这样的群，正在此系统活动。目前没有这方面的经验，还请v2er多多提看法和意见
This topic created in 4717 days ago, the information mentioned may be changed or developed.
 |
ejinDec 6, 2013
1
yy一个频道几万人在线。还有视频。太牛擦了
|
 |
2
IRC
|
1 |
3
xmpp
|
 |
4
如果只是群聊天可以考虑用发布-订阅的协议来做。比如MQTT，用户进入群就是订阅了topic，然后发言就向这个topic发消息，所有订阅该topic的人都能收到。具体到使用的技术，我们现在用netty实现了类似的应用，大概每台服务器支持了150w个用户这样（应该还能提升）。
|
 |
5
|
 |
binuxDec 7, 2013
6
20w*1000人在线，同时在线2亿人。。。QQ就是个渣渣啊
|
 |
9hillsDec 7, 2013
7
2亿人同时在线的系统。。lz没有经验还是不要做了，这个最少值2亿
|
 |
lvyeDec 7, 2013
8
架构做出来，验证也是个问题。目前估计只有腾讯有这个经验了。
|
 |
NumbcoderDec 7, 2013
9
|
 |
xujialiangDec 7, 2013 via Android
13
消息队列吧。可路由转发不同服务器，貌似公司的报文服务就是这么干的
|
 |
14
目前，消息大小限值在255个字符之内，不限制一个人在多个群。
|
 |
akiraDec 7, 2013
15
估计没几个人有这种经验。
不过大规模的使用内存数据库 和 消息队列 应该跑不掉的了。 |
 |
inyfeeDec 7, 2013
16
之前做聊天室时，用的是redis的 subpub 功能，用户订阅了频道，在同频道中的其它用户发布消息都由redis 来做发布，开发起来也简单。不过20w*1000人在线 ~~~ 这里面要考虑的东西还要更复杂
|
|
18
做过百万级别同时在线的案例。lz 这个可能比我的大。
给 lz 几个建议： 1. 选好协议。从你的应用场景来看，XMPP 或 MQTT 比较合适，群组功能是典型的 PubSub 应用场景。如果有移动端的话，MQTT 稍微好点。 2. 服务端语言选型要慎重。erlang，golang 或许比较合适，java 的话可以试试 netty。 3. 还是要先做好充分的调研，同时在线人数（群组数量真不太重要，在 PubSub 里就是订阅个 topic 而已），每秒钟的消息量，这两个指标比较重要。 |
Select Language