作者：Max 
鏈接：https://www.zhihu.com/question/293021546/answer/487157602
部分來自微信公衆號算法愛好者整理

把 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/視覺暫留