把 14 亿中国人民都拉到一个微信群里在技术上能实现吗？

先说结论：也许可以实现，但你会什么都看不见。

根据 2017 年《微信数据报告》的公开数据 [参考 1] ：2017 年 9 月，微信日均登陆 9.02 亿人，日均发送消息 380 亿次。

这意味着平均每人每天发送信息 42 条，如果全国人民（对了，现在全国人口已经接近 14 亿）在同一个群里说话，这个群每天出现的信息就高达：

这么多信息仅仅是匀速发送的话，考虑到大家的睡眠，睡觉的 8 小时不算，那么手机里每秒要接收的信息就是：

哇塞，每秒超过 100 万条啊！目前主频最高的手机 CPU 之一，高通骁龙 845有 2.8GHz 的处理能力[参考 2] ，一共是 8 核。

如不计算安卓系统、显示刷新、网络 IO 等 CPU 操作的话，每条信息能分配到的计算能力是：

这是什么概念？全球第一款微处理器是 1971 年英特尔推出的 Intel 4004[参考 3]，这个老古董的主频也有 108KHz 啊。所以 21.9KHz 就是啥也干不了。

幸好 IT 界有个摩尔定律：每 18 个月 CPU 性能就能翻倍（或者价钱是一半）。虽然现有科技已经很难让主频提升（某牙膏厂拼命挤也只有 5 Ghz）。

但假设我们使用了黑科技提升主频。等到了 2025 摩尔定律失效时[参考 4]，我们的手机 CPU 主频应该达到：

看起来不错嘛，不过每条消息能得到的计算能力将达到：

呵呵，依然没有达到 Intel 4004 的水平，所以结果就是你等了 7 年，还是进不了这个全国群抢一个红包。

好吧，咱们让手机接入一个给力点的电脑, 比如说全球超算第一名的太湖之光，1 千万个 CPU 核心 [参考 5] 来帮忙处理这个宇宙第一大微信群。算力的问题总算有了着落。

我们假设平均每条消息有 10 个汉字，这大概相当于 30 byte，算上应用层会加上一定的控制字符，再加上 TCP／IP 网络层的数据消耗大概是 74 byte，取个整，平均每条消息有 100 byte，每个 byte 相当于 8 个 bit。

这时每秒需要的网络带宽大约是：

如果有人发红包，需要的带宽就更大了。

理论上，4G 网络能支持 1000 Mbps[参考 6]，但别忘了，是全国人民在同一个群里，而你周围的人也需要同样的带宽，这使得你附近的基站不堪重负，陷入瘫痪。

为了避免网络瘫痪导致你抢不到红包或者看群消息，你需要搬到一个周围没有人的基站，比如放暑假了全校只有你还没回家的时候。

不过运营商的日子就不好过了，因为这一秒全国上下的流量就达到了惊人的：

这相当于 2017 年 4 月份的全国移动数据总流量的 65.7%[参考 7]，意味着每 18 秒就能用完全国一年的流量。运营商瑟瑟发抖.gif

如果把 1.146 Ebit 数据用 2TByte 3.5 英寸硬盘（20 mm 高）装起来，然后叠起来，有 1433.25 m，相比之下，全球最高楼——迪拜的哈里发塔只有区区 828m。

当然，如果确实有需要，我相信电信运营商们肯定砸下重金为你建设全世界最大的宽带网络。

不过，接下来该花钱的就不是运营商——而是腾讯了。

为了处理这 1.146 Ebps 的流量， 腾讯需要准备 11466 万套交换机和服务器。

目前一台大厂 4 口万兆交换机售价大约是 4000 元，一台便宜带万兆口的服务器则大概需要 10000 元，这两项加起来的费用是：

呃，仅仅这两项就相当于 深圳 2014 年全年的 GDP[参考 8]。

这里还不包括网线、电线、服务器机架、机房托管、电费、运行支出……

这么多设备的存放也是个问题。一台带万兆（10Gbps）口的 2U 服务器有 88.9 mm 高，这样叠起来就有：

这差不多是中国到美国的飞机航线距离啊，用来修铁路也是够够的了。

好了，有了这么多设备加持，这下你终于可以愉快地进了群。

但你惊讶地发现，屏幕上除了白色，什么都没有——这是因为你的眼睛没办法接收这么快的数据！

人眼的视觉暂留时间是 100-400 毫秒[参考 9] ，而我们这个群每秒钟就要显示 102 万条信息，每条消息停留的时间只有大概 0.001 毫秒。相比之下，电影、电视都有 41 毫秒。

因此你还没来得及看清消息，它就已经消失了，最后只留下一团白色的色块在屏幕的正中央。

小编精选了一些网友留言：

@大哥有柔情：

14 亿在一个群并不可怕。可怕的是，每逢节日群里都会让群主发红包！

@后知后觉：

已经做到了，14 亿人拉到一个微信群，大家看到的都是新闻联播。

@bluecat：

简单的说，你的手机会马上崩溃，因为它承载不了一秒钟的信息量。

@三毛鱼

可以实现，不过要加几条限制：

①所有微信账号强制加入到这个微信群。

②微信群只能有限的几个人发言，其他人不能发言。

③微信群里只能在每天固定时间段发消息。

④其他微信群在固定时间不能发消息，或者只能转发这个微信群的消息。

这样就可以实现了，技术上没有难度。

@程墨Morgan

“拉”到一个群里没啥不难实现的，反正用户信息都在服务器上，建一个包含所有用户微信号的群也就是添加一个记录而已。

但是，这个群千万不要让任何人都能发言，就以我国人民的多样性，各种话唠、贴图狂人、广告狂人......海量信息瞬间就可以把服务器、运营商网络和你手机的电池击溃。

@世安先生

讲真，单从理论上来说目前的技术还是可行的，咳咳，我要装逼了。

看了别的答主的回答，说人、终端、传输、处理、存储、分析等等各方面均有缺陷或者短板，跟不上大批量的数据，其实个人觉得实施起来也还是有得搞的，只是成本和利润之间的关系罢了。

首先，得考虑人的因素，多少多少亿的信息量对于某个特定个体来说价值无限接近于 0，我个人根本不关注这些信息，因为获取信息的效率太低了。

这就导致了百分之九十九的人直接忽略了这个群的存在，剩下的每天这个群里的消息无非就是置顶公告，置顶新闻，红包和闲聊斗图，浏览公告和新闻。

考虑到并发的问题，一般现在的服务器都可以做到，毕竟有大把的新闻 App 都可以做到；红包，做个算法随机分配吧，也别抢了，抢会严重影响体验，给十亿用户随机分配一段数据应该难度也不太大。

剩下的就是斗图闲聊，数据直接云存储在服务器端，分析处理总结出来个中心思想每多少秒多少秒推送给个人用户一次，就差不多了，需要详细信息的上服务器检索，个人觉得对个人终端的压力也不会太大。

其次，传输，这是我觉得问题最小的一个环节，为什么呢？解决了个人终端的问题之后，个人的数据传输量并不大，现有的传输网络完全可以满足。

服务器端的传输，要看这服务器怎么个建法，如果集中式处理和存储，就只能用百 G 专线，建个三五条完全够了。

只不过相应的配套交换机路由器要建一套庞大的系统出来。如果是分布式存储和处理，10G 的甚至 GE 的专线都够。这是传输。

第三，处理，如果非得把大批量的数据集中处理，就得建设一套国内最大甚至世界最大最复杂的数据中心才能够承载这套系统。

但是如果分布式处理的话，我相信现在的系统也够用，毕竟现有的运算量已经这么大了，而有这个群之后数据量也绝对不会爆炸式增长。

第四，存储，处理的工作能够完成存储肯定也不是问题，甚至可以将数据破碎后存储在个人终端上，将投资设备的矛盾转嫁到数据安全和管理上。

第五，数据分析，这一点才是重中之重，难点中的难点，如何有效的分析提取如此大量数据中的有用信息并推送给特定的个人才是核心关键。

虽然现在技术还没有大面积商业化，但我相信这种技术是肯定已经有试用的甚至是已经商用的存在了，只不过公众不太清楚而已，毕竟这种东西仔细想想还是有点恐怖的。

总之，如何实现这个系统或者说建好这个群，无非就是做好需求与资源之间矛盾的转嫁，把存储需求量大与投资大之间的矛盾转嫁到数据安全与运营管理上，把大数据量传输分散化，把大量的数据进行分析提取后定向推送，最核心的投资也就是整套智能有效的大数据分析系统。

(ಥ_ಥ)不过……话说这么搞的话不就是搞了个有 14 亿关注量的公众号嘛…d(ŐдŐ๑)好了，我装逼装完了，你们打的时候下手轻点，别拿砖头，别提 40 米青龙偃月大关刀......

参考链接

• [1]: 2017微信数据报告：日登录用户超9亿 日发送消息380亿次

• [2]: 高通骁龙 845 平台 | Qualcomm

  https://www.qualcomm.cn/snapdragon/processors/845

• [3]: Intel 4004 维基百科

• https://zh.wikipedia.org/wiki/Intel_4004

• [4]:Moore's law - Wikipedia

  https://en.wikipedia.org/wiki/Moore%27s_law#Driving_the_future_via_an_application_focus

• [5]: The 48th edition of the TOP500 list

  https://www.top500.org/lists/2016/11/

• [6]: 4G 维基百科

  https://zh.wikipedia.org/zh-cn/4G

• [7]: 2017年4月通信业主要指标完成情况（一）

  http://www.miit.gov.cn/n1146312/n1146904/n1648372/c5652964/content.html

• [8]: 深圳统计年鉴2017

  http://www.sztj.gov.cn/xxgk/zfxxgkml/tjsj/tjnj/201712/P020180822606533537093.pdf

• [9]: 视觉暂留 维基百科

  https://zh.wikipedia.org/zh-cn/視覺暫留

推荐阅读

GitHub秒变GayHub

有一种痛，叫 “今年没有年终奖”！！！

年度Java技术盘点，懂这些技术的程序员2019年薪资翻倍！

十个GitHub上15W+的后台管理系统

某小公司RESTful、共用接口、前后端分离、接口约定的实践

漫谈何时从单体架构迁移到微服务？

EFK(Elasticsearch + Fluentd + Kibana)方式进行Docker日志收集、检索展示

请问：如何写出没有BUG的代码？

12306 脱库疑云：410 万用户数据仅售 20 美元！

动态图展示Java常用数据结构的特点和基本操作

容器在 2019 年必将碾压 VMware！

Eureka常见问题汇总及注意事项

进阶Java架构师必看的15本书

微服务之间的通信的方式

图解菜鸟、普通、大牛、大神程序员，最后一张我笑了。。

写文不易，你的转发、点赞、赞赏就是对我最大的支持

我们一起愉快的玩耍吧

目前40000+人已关注加入我们

       

       

“程序猿技术大咖”，您值得拥有！
公众号ID：cxyjsdk长按左侧二维码关注