类似"万人聊天群"的需求，目前的技术栈最佳实践会是怎样呢？

[withablink]

考虑这样的需求：

1. 千人聊天群。可以查看完整的信息历史。所有客户端保持同步。同步速度尽量快，对服务器压力尽量小。

2. 万人聊天群。可以查看完整的信息历史。所有客户端保持同步。同步速度尽量快，对服务器压力尽量小。

3. 十万人聊天群。可以查看完整的信息历史。所有客户端保持同步。同步速度尽量快，对服务器压力尽量小。

4. 一百万人聊天群。可以查看完整的信息历史。所有客户端保持同步。同步速度尽量快，对服务器压力尽量小。

5. 以此类推... 目前的技术栈最佳实践会是怎样呢？

[trys1]

telegram 了解一下

[withablink]

@trys1 小规模时就是类似 telegram，但是电报群也没见过十万人及以上的...

（实际需求中，参与的不一定是人，所以不用担心消息太多看不过来）

[jamesxu]

看不出来哪里需要用到这么大的群，这么大的群还叫群吗，有何意义

[vindurriel]

想多了 一个群不会有那么多人同时在线的 telegram 为例 我参加的最大的群 7555 人 5 人在线

[withablink]

@jamesxu 群只是一个比喻。实际需求中，参与的不一定是人。

想了想，如果参与人数特别多，还真的似乎只有靠区块链。

[gy911201]

你这是聊天群啊？我觉得你按照消息中间件去设计吧……
可以参考一下 kafka 之类的实现

[withablink]

@vindurriel 群只是一个比喻。实际需求中，参与的不一定是人。

[vindurriel]

@withablink 不推历史到客户端 谁看谁去服务器拉取 加缓存

[withablink]

@gy911201 消息队列是肯定需要的，不过稍微复杂的是需要保持全部人和全部历史的同步，而且需要支持很多 client，所以可能还是 P2P 的做法更好，那么好像就只有靠区块链了。

[vindurriel]

@vindurriel kafka 就是这么个思路 消息持久化 消费者随用随取

[kernel]

@withablink 你是不是对区块链有什么误解

[withablink]

@vindurriel 好的我研究下，目前还有与 Kafka 类似的方案吗

[wsh1108]

只有我觉得超过 10 万人的聊天群这个需求不存在吗🤐

[innoink]

一开始说“ x 人聊天群”
然后又说不一定是人
那是不是还可以说不一定是聊天
那鬼知道你问的什么

[withablink]

@innoink @wsh1108 标题中说了“类似”。

举聊天群的例子，因为聊天群的信息流速度很大（尤其是发图片和视频时）。

而且不同人数的做法完全不同。百人千人可以随便做。一万人十万人百万人的信息量和同步需求，就不是随随便便可以做得出来了。

[Tumblr]

@withablink #2 “及以上”没见过，因为上限就是 10 万人，前段时间某些东西比较火的时候，前面的几个群都是 10 万人群（是不是这几个名字并不确定，至少前面的当初都是 10 万人群）

[jetbillwin]

说靠区块链的是不是对区块链有什么误解……

[uqin]

哈哈 区块链恰恰是最低效的数据库（就目前水平） tg 本身跟区块链一毛钱关系没有 只是出于某种因素很多区块链项目交流喜欢用他交流而已

[gamexg]

@withablink 区块链？你是认真的？

[MonoLogueChi]

各大直播网站的弹幕不就是最好的示例吗，一个能容纳 60 亿人的“聊天群”