群聊天系统，高吞吐量，高转发量，后端什么架构？

yy一个频道几万人在线。还有视频。太牛擦了

IRC

xmpp

如果只是群聊天可以考虑用发布-订阅的协议来做。比如MQTT，用户进入群就是订阅了topic，然后发言就向这个topic发消息，所有订阅该topic的人都能收到。具体到使用的技术，我们现在用netty实现了类似的应用，大概每台服务器支持了150w个用户这样（应该还能提升）。

20w*1000人在线，同时在线2亿人。。。QQ就是个渣渣啊

2亿人同时在线的系统。。lz没有经验还是不要做了，这个最少值2亿

架构做出来，验证也是个问题。目前估计只有腾讯有这个经验了。

@binux
一个群1000个人在聊天，共20万个这样的群, 一个人有没有可能在多个群，那么这样的话就不能简单 20w*1000 这么算了

其实最重要的是要估算同时在线人数和消息量吧

@Numbcoder 一个人在多个群，那也是多个链接啊，对于服务器来说是一样的啊

@binux 怎么会是多个链接，必须是一条链接！

@Numbcoder 感觉“信道”这个说法比较合适……我就随口一说

消息队列吧。可路由转发不同服务器，貌似公司的报文服务就是这么干的

目前，消息大小限值在255个字符之内，不限制一个人在多个群。

估计没几个人有这种经验。

不过大规模的使用内存数据库 和 消息队列 应该跑不掉的了。

之前做聊天室时，用的是redis的 subpub 功能，用户订阅了频道，在同频道中的其它用户发布消息都由redis 来做发布，开发起来也简单。不过20w*1000人在线 ~~~ 这里面要考虑的东西还要更复杂

@Numbcoder 需要处理和转发的事件量是一样的啊

做过百万级别同时在线的案例。lz 这个可能比我的大。
给 lz 几个建议：
1. 选好协议。从你的应用场景来看，XMPP 或 MQTT 比较合适，群组功能是典型的 PubSub 应用场景。如果有移动端的话，MQTT 稍微好点。
2. 服务端语言选型要慎重。erlang，golang 或许比较合适，java 的话可以试试 netty。
3. 还是要先做好充分的调研，同时在线人数（群组数量真不太重要，在 PubSub 里就是订阅个 topic 而已），每秒钟的消息量，这两个指标比较重要。