好人系列
這個問題我大概回答一下，由於我不太清楚字節跳動真正的網絡是如何組網的，所以我只能告訴你大概的原理。參考其他大型互聯網企業的組網，應該解決的方案是類似的
抖音並不是全國所有刷視頻用戶都在同一個地方的數據中心接入我們看視頻的流量，如果是這樣的話，那麼這個數據數據中心所需的帶寬就是過於巨大。一般來說，抖音在全國各地會建設幾個比較大的數據中心，我們刷視頻的請求是就近接入的。
比如張三在北京，那麼他接入抖音APP，上傳和瀏覽視頻，就是在北京數據中心完成；李四在上海，那麼他的上傳視頻和瀏覽視頻就是在上海的數據中心完成。如果所有用戶都接入同一個地方數據中心，毫無疑問對於這個數據中心的負載太大，這是不可能的。
各個數據中心的視頻數據，通過專有的高速互聯網絡進行同步。也就是你上傳的視頻雖然是上傳到上海的數據中心，北京的用戶依然可以看到，就是可能要晚一點刷才看到。抖音需要把你在上海上傳的視頻數據通過高速網絡傳遞到北京後，北京的用戶才能看到。
一個數據中心包括多個運營商的出口，一般是會和三大運營商網絡在本地對接，同時會和一些中小型運營商對接，例如廣電。和運營商網絡對接的目的為了接入運營商的用戶，這也就意味著你是北京移動用戶，那麼刷出來抖音的視頻將會從北京移動的網絡接入抖音
如果發現某個區域的數據中心業務負載太重怎麼辦？例如湖南春節大量用戶返鄉，導致位於武漢的數據中心突然接入不了這麼多湖南的用戶了，這個時候抖音內部就會調整用戶的接入路徑，把一部分本來接到武漢的抖音用戶接入到北京去（因為春節北京的人少了很多）
所以，這就是互聯網公司網絡的基本架構。全國存在多個數據中心，不同地方的用戶刷視頻其實是接入不同的數據中心，每個數據中心都會和三大運營商網絡對接。
這種分佈式的網絡保證了抖音的業務不會都積壓在一個數據中心，由全國各地抖音數據中心和運營商互聯的帶寬來保證用戶刷視頻可以正常瀏覽
那麼位於不同位置的抖音的數據中心和三大運營商的互聯帶寬多大？只能講肯定是T級別的，1T等於1000G，現在大型互聯網公司和運營商對接的帶寬普遍是1T、2T起步了，而且一般如果發展互聯帶寬負載超過了30%到50%，就需要擴容
很多人提到了CDN，CDN不能從根本上解決這個帶寬問題，CDN只能從運營商網絡路由層面上解決一定的擁塞問題。不論是騰訊、百度還是抖音、YY，解決遊戲、視頻大帶寬的問題都是從數據中心網絡基礎架構解決，都是採用類似的技術，也就是DCN和DCI相關的技術
IT老菜鳥
從技術的角度來看，這中間其實是有一個海量數據處理的技術問題，筆者在實際工作中，有幸接觸到海量的數據處理問題，對其進行處理是一項艱鉅而複雜的任務。所以小編就簡單給大家說一下，有不正之處歡迎大家留言指正！
使用海量數據處理技術的原因有以下幾個方面：
一、數據量過大，數據中什麼情況都可能存在。如果說有10條數據，那麼大不了每條去逐一檢查，人為處理，如果有上百條數據，也可以考慮，如果數據上到千萬級別，甚至過億，那不是手工能解決的了，必須通過工具或者程序進行處理，尤其海量的數據中，什麼情況都可能存在，例如，數據中某處格式出了問題，尤其在程序處理時，前面還能正常處理，突然到了某個地方問題出現了，程序終止了。
二、軟硬件要求高，系統資源佔用率高。對海量的數據進行處理，除了好的方法，最重要的就是合理使用工具，合理分配系統資源。一般情況，如果處理的數據過TB級，小型機是要考慮的，普通的機子如果有好的方法可以考慮，不過也必須加大CPU和內存，就象面對著千軍萬馬，光有勇氣沒有一兵一卒是很難取勝的。
三、要求很高的處理方法和技巧。這也是本文的寫作目的所在，好的處理方法是一位工程師長期工作經驗的積累，也是個人的經驗的總結。沒有通用的處理方法，但有通用的原理和規則。
海量數據處理概述
所謂海量數據處理，就是數據量太大，無法在較短時間內迅速解決，無法一次性裝入內存。本文在前人的基礎上總結一下解決此類問題的辦法。那麼有什麼解決辦法呢? 時間複雜度方面，我們可以採用巧妙的算法搭配合適的數據結構，如Bloom filter/Hash/bit-map/堆/數據庫或倒排索引/trie樹。空間複雜度方面，分而治之/hash映射。
海量數據處理的基本方法總結起來分為以下幾種：
- 分而治之/hash映射 + hash統計 + 堆/快速/歸併排序；
- 雙層桶劃分；
- Bloom filter/Bitmap；
- Trie樹/數據庫/倒排索引；
- 外排序；
- 分佈式處理之Hadoop/Mapreduce。
前提基礎知識：
1 byte= 8 bit。
int整形一般為4
ytes 共32位bit。
2^32=4G。
1G=2^30=10.7億。
1 分而治之+hash映射+快速/歸併/堆排序
問題1
給定a、b兩個文件，各存放50億個url，每個url各佔64字節，內存限制是4G，讓你找出a、b文件共同的url？
分析：50億*64=320G大小空間。 算法思想1：hash 分解+ 分而治之 + 歸併
- 遍歷文件a，對每個url根據某種hash規則求取hash(url)/1024，然後根據所取得的值將url分別存儲到1024個小文件（a0~a1023）中。這樣每個小文件的大約為300M。如果hash結果很集中使得某個文件ai過大，可以在對ai進行二級hash(ai0~ai1024)。
- 這樣url就被hash到1024個不同級別的目錄中。然後可以分別比較文件，a0VSb0……a1023VSb1023。求每對小文件中相同的url時，可以把其中一個小文件的url存儲到hash_map中。然後遍歷另一個小文件的每個url，看其是否在剛才構建的hash_map中，如果是，那麼就是共同的url，存到文件裡面就可以了。
- 把1024個級別目錄下相同的url合併起來。
問題2
有10個文件，每個文件1G，每個文件的每一行存放的都是用戶的query，每個文件的query都可能重複。要求你按照query的頻度排序。 解決思想1：hash分解+ 分而治之 +歸併
- 順序讀取10個文件a0~a9，按照hash(query)%10的結果將query寫入到另外10個文件（記為 b0~b9）中。這樣新生成的文件每個的大小大約也1G（假設hash函數是隨機的）。
- 找一臺內存2G左右的機器，依次對用hash_map(query, query_count)來統計每個query出現的次數。利用快速/堆/歸併排序按照出現次數進行排序。將排序好的query和對應的query_cout輸出到文件中。這樣得到了10個排好序的文件c0~c9。
- 對這10個文件c0~c9進行歸併排序（內排序與外排序相結合）。每次取c0~c9文件的m個數據放到內存中，進行10m個數據的歸併，即使把歸併好的數據存到d結果文件中。如果ci對應的m個數據全歸併完了，再從ci餘下的數據中取m個數據重新加載到內存中。直到所有ci文件的所有數據全部歸併完成。 解決思想2： Trie樹 如果query的總量是有限的，只是重複的次數比較多而已，可能對於所有的query，一次性就可以加入到內存了。在這種假設前提下，我們就可以採用trie樹/hash_map等直接來統計每個query出現的次數，然後按出現次數做快速/堆/歸併排序就可以了。
問題3：
有一個1G大小的一個文件，裡面每一行是一個詞，詞的大小不超過16字節，內存限制大小是1M。返回頻數最高的100個詞。 類似問題：怎麼在海量數據中找出重複次數最多的一個？
解決思想： hash分解+ 分而治之+歸併
- 順序讀文件中，對於每個詞x，按照hash(x)/(1024*4)存到4096個小文件中。這樣每個文件大概是250k左右。如果其中的有的文件超過了1M大小，還可以按照hash繼續往下分，直到分解得到的小文件的大小都不超過1M。
- 對每個小文件，統計每個文件中出現的詞以及相應的頻率（可以採用trie樹/hash_map等），並取出出現頻率最大的100個詞（可以用含100個結點的最小堆），並把100詞及相應的頻率存入文件。這樣又得到了4096個文件。
- 下一步就是把這4096個文件進行歸併的過程了。（類似與歸併排序）
問題4
海量日誌數據，提取出某日訪問百度次數最多的那個IP 解決思想： hash分解+ 分而治之 + 歸併
- 把這一天訪問百度的日誌中的IP取出來，逐個寫入到一個大文件中。注意到IP是32位的，最多有2^32個IP。同樣可以採用hash映射的方法，比如模1024，把整個大文件映射為1024個小文件。
- 再找出每個小文中出現頻率最大的IP（可以採用hash_map進行頻率統計，然後再找出頻率最大的幾個）及相應的頻率。
- 然後再在這1024組最大的IP中，找出那個頻率最大的IP，即為所求。
問題5
海量數據分佈在100臺電腦中，想個辦法高效統計出這批數據的TOP10。
解決思想： 分而治之 + 歸併。 注意TOP10是取最大值或最小值。如果取頻率TOP10，就應該先hash分解。
- 在每臺電腦上求出TOP10，採用包含10個元素的堆完成（TOP10小，用最大堆，TOP10大，用最小堆）。比如求TOP10大，我們首先取前10個元素調整成最小堆，如果發現，然後掃描後面的數據，並與堆頂元素比較，如果比堆頂元素大，那麼用該元素替換堆頂，然後再調整為最小堆。最後堆中的元素就是TOP10大。
- 求出每臺電腦上的TOP10後，然後把這100臺電腦上的TOP10組合起來，共1000個數據，再利用上面類似的方法求出TOP10就可以了。
問題6
在2.5億個整數中找出不重複的整數，內存不足以容納這2.5億個整數。
解決思路1 ： hash 分解+ 分而治之 + 歸併 2.5億個int數據hash到1024個小文件中a0~a1023，如果某個小文件大小還大於內存，進行多級hash。每個小文件讀進內存，找出只出現一次的數據，輸出到b0~b1023。最後數據合併即可。
解決思路2 ： 2-Bitmap 如果內存夠1GB的話，採用2-Bitmap（每個數分配2bit，00表示不存在，01表示出現一次，10表示多次，11無意義）進行，共需內存2^32*2bit=1GB內存。然後掃描這2.5億個整數，查看Bitmap中相對應位，如果是00變01，01變10，10保持不變。所描完事後，查看bitmap，把對應位是01的整數輸出即可。 注意，如果是找出重複的數據，可以用1-bitmap。第一次bit位由0變1，第二次查詢到相應bit位為1說明是重複數據，輸出即可。
問題7
一共有N個機器，每個機器上有N個數。每個機器最多存O(N)個數並對它們操作。如何找到N^2個數中的中數？
解決思想1 ： hash分解 + 排序
- 按照升序順序把這些數字，hash劃分為N個範圍段。假設數據範圍是2^32 的unsigned int 類型。理論上第一臺機器應該存的範圍為0~(2^32)/N，第i臺機器存的範圍是(2^32)*(i-1)/N~(2^32)*i/N。hash過程可以掃描每個機器上的N個數，把屬於第一個區段的數放到第一個機器上，屬於第二個區段的數放到第二個機器上，…，屬於第N個區段的數放到第N個機器上。注意這個過程每個機器上存儲的數應該是O(N)的。
- 然後我們依次統計每個機器上數的個數，一次累加，直到找到第k個機器，在該機器上累加的數大於或等於（N^2）/2，而在第k-1個機器上的累加數小於（N^2）/2，並把這個數記為x。那麼我們要找的中位數在第k個機器中，排在第（N^2）/2-x位。然後我們對第k個機器的數排序，並找出第（N^2）/2-x個數，即為所求的中位數的複雜度是O（N^2）的。
解決思想2： 分而治之 + 歸併 先對每臺機器上的數進行排序。排好序後，我們採用歸併排序的思想，將這N個機器上的數歸併起來得到最終的排序。找到第（N^2）/2個便是所求。複雜度是O（N^2 * lgN^2）的。
2 Trie樹+紅黑樹+hash_map
這裡Trie樹木、紅黑樹或者hash_map可以認為是第一部分中分而治之算法的具體實現方法之一。
問題1
上千萬或上億數據（有重複），統計其中出現次數最多的錢N個數據。
解決思路： 紅黑樹 + 堆排序
- 如果是上千萬或上億的int數據，現在的機器4G內存可以能存下。所以考慮採用hash_map/搜索二叉樹/紅黑樹等來進行統計重複次數。
- 然後取出前N個出現次數最多的數據，可以用包含N個元素的最小堆找出頻率最大的N個數據。
問題2
1000萬字符串，其中有些是重複的，需要把重複的全部去掉，保留沒有重複的字符串。請怎麼設計和實現？
解決思路：trie樹。 這題用trie樹比較合適，hash_map也應該能行。
問題3
一個文本文件，大約有一萬行，每行一個詞，要求統計出其中最頻繁出現的前10個詞，請給出思想，給出時間複雜度分析。
解決思路： trie樹 + 堆排序 這題是考慮時間效率。 1. 用trie樹統計每個詞出現的次數，時間複雜度是O(n*len)（len表示單詞的平準長度）。 2. 然後找出出現最頻繁的前10個詞，可以用堆來實現，前面的題中已經講到了，時間複雜度是O(n*lg10)。 總的時間複雜度，是O(n*le)與O(n*lg10)中較大的哪一個。
問題4
搜索引擎會通過日誌文件把用戶每次檢索使用的所有檢索串都記錄下來，每個查詢串的長度為1-255字節。假設目前有一千萬個記錄，這些查詢串的重複讀比較高，雖然總數是1千萬，但是如果去除重複和，不超過3百萬個。一個查詢串的重複度越高，說明查詢它的用戶越多，也就越熱門。請你統計最熱門的10個查詢串，要求使用的內存不能超過1G。
解決思想 ： trie樹 + 堆排序 採用trie樹，關鍵字域存該查詢串出現的次數，沒有出現為0。最後用10個元素的最小推來對出現頻率進行排序。
3 BitMap或者Bloom Filter
3.1 BitMap
BitMap說白了很easy，就是通過bit位為1或0來標識某個狀態存不存在。可進行數據的快速查找，判重，刪除，一般來說適合的處理數據範圍小於8*2^32。否則內存超過4G，內存資源消耗有點多。
問題1
已知某個文件內包含一些電話號碼，每個號碼為8位數字，統計不同號碼的個數。
解決思路： bitmap 8位最多99 999 999，需要100M個bit位，不到12M的內存空間。我們把0-99 999 999的每個數字映射到一個Bit位上，所以只需要99M個Bit==12MBytes，這樣，就用了小小的12M左右的內存表示了所有的8位數的電話
問題2
2.5億個整數中找出不重複的整數的個數，內存空間不足以容納這2.5億個整數。
解決思路：2bit map 或者兩個bitmap。 將bit-map擴展一下，用2bit表示一個數即可，00表示未出現，01表示出現一次，10表示出現2次及以上，11可以暫時不用。 在遍歷這些數的時候，如果對應位置的值是00，則將其置為01；如果是01，將其置為10；如果是10，則保持不變。需要內存大小是2^32/8*2=1G內存。 或者我們不用2bit來進行表示，我們用兩個bit-map即可模擬實現這個2bit-map，都是一樣的道理。
那麼處理海量數據有哪些經驗和技巧呢，我把我所知道的羅列一下，以供大家參考：
一、選用優秀的數據庫工具 現在的數據庫工具廠家比較多，對海量數據的處理對所使用的數據庫工具要求比較高，一般使用Oracle或者DB2，微軟公司SQL Server 2005性能也不錯。另外在BI領域：數據庫，數據倉庫，多維數據庫，數據挖掘等相關工具也要進行選擇，像好的ETL工具和好的OLAP工具都十分必要，例如Informatic，Eassbase等。筆者在實際數據分析項目中，對每天6000萬條的日誌數據進行處理，使用SQL Server 2000需要花費6小時，而使用SQL Server 2005則只需要花費3小時。
二、編寫優良的程序代碼 處理數據離不開優秀的程序代碼，尤其在進行復雜數據處理時，必須使用程序。好的程序代碼對數據的處理至關重要，這不僅僅是數據處理準確度的問題，更是數據處理效率的問題。良好的程序代碼應該包含好的算法，包含好的處理流程，包含好的效率，包含好的異常處理機制等。
三、對海量數據進行分區操作 對海量數據進行分區操作十分必要，例如針對按年份存取的數據，我們可以按年進行分區，不同的數據庫有不同的分區方式，不過處理機制大體相同。例如SQL Server的數據庫分區是將不同的數據存於不同的文件組下，而不同的文件組存於不同的磁盤分區下，這樣將數據分散開，減小磁盤I/O，減小了系統負荷，而且還可以將日誌，索引等放於不同的分區下。
四、建立廣泛的索引 對海量的數據處理，對大表建立索引是必行的，建立索引要考慮到具體情況，例如針對大表的分組、排序等字段，都要建立相應索引，一般還可以建立複合索引，對經常插入的表則建立索引時要小心，筆者在處理數據時，曾經在一個ETL流程中，當插入表時，首先刪除索引，然後插入完畢，建立索引，並實施聚合操作，聚合完成後，再次插入前還是刪除索引，所以索引要用到好的時機，索引的填充因子和聚集、非聚集索引都要考慮。
五、建立緩存機制當數據量增加時，一般的處理工具都要考慮到緩存問題。緩存大小設置的好差也關係到數據處理的成敗，例如，筆者在處理2億條數據聚合操作時，緩存設置為100000條/Buffer，這對於這個級別的數據量是可行的。
六、加大虛擬內存 如果系統資源有限，內存提示不足，則可以靠增加虛擬內存來解決。筆者在實際項目中曾經遇到針對18億條的數據進行處理，內存為1GB，1個P4 2.4G的CPU，對這麼大的數據量進行聚合操作是有問題的，提示內存不足，那麼採用了加大虛擬內存的方法來解決，在6塊磁盤分區上分別建立了6個4096M的磁盤分區，用於虛擬內存，這樣虛擬的內存則增加為 4096*6 + 1024 = 25600 M，解決了數據處理中的內存不足問題。
七、分批處理海量數據處理難因為數據量大，那麼解決海量數據處理難的問題其中一個技巧是減少數據量。可以對海量數據分批處理，然後處理後的數據再進行合併操作，這樣逐個擊破，有利於小數據量的處理，不至於面對大數據量帶來的問題，不過這種方法也要因時因勢進行，如果不允許拆分數據，還需要另想辦法。不過一般的數據按天、按月、按年等存儲的，都可以採用先分後合的方法，對數據進行分開處理。
八、使用臨時表和中間表數據量增加時，處理中要考慮提前彙總。這樣做的目的是化整為零，大表變小表，分塊處理完成後，再利用一定的規則進行合併，處理過程中的臨時表的使用和中間結果的保存都非常重要，如果對於超海量的數據，大表處理不了，只能拆分為多個小表。如果處理過程中需要多步彙總操作，可按彙總步驟一步步來，不要一條語句完成，一口氣吃掉一個胖子。
九、優化查詢SQL語句 在對海量數據進行查詢處理過程中，查詢的SQL語句的性能對查詢效率的影響是非常大的，編寫高效優良的SQL腳本和存儲過程是數據庫工作人員的職責，也是檢驗數據庫工作人員水平的一個標準，在對SQL語句的編寫過程中，例如減少關聯，少用或不用遊標，設計好高效的數據庫表結構等都十分必要。筆者在工作中試著對1億行的數據使用遊標，運行3個小時沒有出結果，這是一定要改用程序處理了。
十、使用文本格式進行處理對一般的數據處理可以使用數據庫，如果對複雜的數據處理，必須藉助程序，那麼在程序操作數據庫和程序操作文本之間選擇，是一定要選擇程序操作文本的，原因為：程序操作文本速度快；對文本進行處理不容易出錯；文本的存儲不受限制等。例如一般的海量的網絡日誌都是文本格式或者csv格式（文本格式），對它進行處理牽扯到數據清洗，是要利用程序進行處理的，而不建議導入數據庫再做清洗。
十一、 定製強大的清洗規則和出錯處理機制海量數據中存在著不一致性，極有可能出現某處的瑕疵。例如，同樣的數據中的時間字段，有的可能為非標準的時間，出現的原因可能為應用程序的錯誤，系統的錯誤等，這是在進行數據處理時，必須制定強大的數據清洗規則和出錯處理機制。
十二、 建立視圖或者物化視圖視圖中的數據來源於基表，對海量數據的處理，可以將數據按一定的規則分散到各個基表中，查詢或處理過程中可以基於視圖進行，這樣分散了磁盤I/O，正如10根繩子吊著一根柱子和一根吊著一根柱子的區別。
十三、 避免使用32位機子（極端情況） 目前的計算機很多都是32位的，那麼編寫的程序對內存的需要便受限制，而很多的海量數據處理是必須大量消耗內存的，這便要求更好性能的機子，其中對位數的限制也十分重要。
十四、考慮操作系統問題 海量數據處理過程中，除了對數據庫，處理程序等要求比較高以外，對操作系統的要求也放到了重要的位置，一般是必須使用服務器的，而且對系統的安全性和穩定性等要求也比較高。尤其對操作系統自身的緩存機制，臨時空間的處理等問題都需要綜合考慮。
十五、使用數據倉庫和多維數據庫存儲 數據量加大是一定要考慮OLAP的，傳統的報表可能5、6個小時出來結果，而基於Cube的查詢可能只需要幾分鐘，因此處理海量數據的利器是OLAP多維分析，即建立數據倉庫，建立多維數據集，基於多維數據集進行報表展現和數據挖掘等。
十六、使用採樣數據，進行數據挖掘 基於海量數據的數據挖掘正在逐步興起，面對著超海量的數據，一般的挖掘軟件或算法往往採用數據抽樣的方式進行處理，這樣的誤差不會很高，大大提高了處理效率和處理的成功率。一般採樣時要注意數據的完整性和，防止過大的偏差。筆者曾經對1億2千萬行的表數據進行採樣，抽取出400萬行，經測試軟件測試處理的誤差為千分之五，客戶可以接受。
還有一些方法，需要在不同的情況和場合下運用，例如使用代理鍵等操作，這樣的好處是加快了聚合時間，因為對數值型的聚合比對字符型的聚合快得多。類似的情況需要針對不同的需求進行處理。
海量數據是發展趨勢，對數據分析和挖掘也越來越重要，從海量數據中提取有用信息重要而緊迫，這便要求處理要準確，精度要高，而且處理時間要短，得到有價值信息要快，所以，對海量數據的研究很有前途，也很值得進行廣泛深入的研究。
寫在最後,歡迎大家關注我們的頭條號(搜課)一個可以免費學技術的地方!
搜課 ~ 蒐羅天下好課!
搜課
一 分佈式服務器群
二 負載均衡等技術
三 CDN來做內容分發
四 算法推薦,使得帶寬最大程度利用
總結來說，抖音，頭條抗高併發，高流量的能力，確實讓人佩服！
回答完畢謝謝！！
-------------------------------------------------------------------------
本人專注數據採集，數據處理，數據治理，後端服務，希望多多交流！！
互聯網開發技術宅
抖音不過因CDN的面世受益，加了一些算法優化、抖音主要都是上行固定的視頻數據，每個區域節點都緩存了大量視頻數據，真正最牛的是騰訊，微信， 他們後臺數據的處理能力才是真的牛，視頻處理，實時消息處理，金融數據處理都是極致的。你可能還對微信的功能不太滿足，微信的真正實力就是因為他的後臺數據處理好，經驗豐富、其它新生公司還是望塵莫及！
藝心美思
單純抖音的話，沒那麼複雜。基本上就是cdn堆出來的，視頻都是靜態資源很容易也很適合分發的。
基本的架構就是多數據中心，多數據中心通過租用專線或者光線互聯。每個數據中心負責對應片區的cdn資源分發。
一旦有用戶上傳短視頻，會傳到對應運營商片區的idc，再通過dci將這個短視頻分發到所有idc。然後每個idc再向對應片區的cdn分發到所有加速節點。當然還可以有一些優化，比如某些沒有訪問量的視頻就不會同步到cdn甚至idc。
再然後用戶滑視頻看視頻的時候其實壓根就沒有訪問抖音的服務器，實際訪問的其實是cdn節點。當然，這個僅針對於下載視頻這個大頭流量來說。用戶的點贊評論以及下一次滑動會是哪個視頻，這類的動態信息還是直接訪問的抖音服務器。
糊裡不糊塗a
各個數據中心的視頻數據，通過專有的高速互聯網絡進行同步。也就是你上傳的視頻雖然是上傳到上海的數據中心，北京的用戶依然可以看到，就是可能要晚一點刷才看到。抖音需要把你在上海上傳的視頻數據通過高速網絡傳遞到北京後，北京的用戶才能看到。
一個數據中心包括多個運營商的出口，一般是會和三大運營商網絡在本地對接，同時會和一些中小型運營商對接，例如廣電。和運營商網絡對接的目的為了接入運營商的用戶，這也就意味著你是北京移動用戶，那麼刷出來抖音的視頻將會從北京移動的網絡接入抖音
湖南春節大量用戶返鄉，導致位於武漢的數據中心突然接入不了這麼多湖南的用戶了，這個時候抖音內部就會調整用戶的接入路
李9999
看了其他回答，都太專業化了，頭條用戶可能有一部分看不太懂，我就用通俗的話解釋吧。
確實，現在都是用的分佈式計算，還有CDN之類的，什麼是分佈式計算呢？舉個例子，現在有一個計算任務，比較龐大，一臺計算機可能要運行1個小時，但是我們很急切的要這個結果，那就再來59臺機子，通過分佈式計算技術，這總計60臺機子可以一起做這個任務，這樣做完任務就只要1分鐘了（真實情況比這個要更多）。分佈式計算=多機協同工作，因此，再高的流量衝擊，服務器都可以通過分佈式架構將流量分散到各個機子。
小楓師兄
帶寬多少不清楚，不過有幾處猜測:
一，分佈式系統
二，集群
三，負載均衡
四，肯定是有做微服務，核心模塊單體服務集群
五，CDN加速
六，數據庫拆分不然數據量太過龐大
七，我好奇的是用了多少臺物理服務器一天得燒多少錢，讓創業者死了心[捂臉]
幽幽52299287
自從抖音出現以後，無數的男女老少便成了手機的奴隸，一刷就彷彿中毒一般停不下來，伴隨著帶著節奏感的背景音樂，我們也跟隨著那些悲情，搞怪或賣萌的人們一起又哭又笑又鬧，刷完一個視頻緊接著下一個，完全戒不掉的那種癮，但有人會問抖音有那麼多的用戶，又怎麼保障能同時讓那麼多人刷呢？
其實像抖音這樣的大型視頻網站，它的服務器每天要處理的信息或許能達到百億級別，哪怕是用全球最大的數據中心，也會直接癱瘓不起，因此抖音的數據處理採用的都是分佈式的雲計算，全國各地包括海外都建有大型的數據中心，各個數據中心的視頻數據，通過專有的高速互聯網絡進行同步，比如說你是從上海的數據中心上傳視頻，北京的用戶依然可以看到，就是可能要晚一點刷才看到，抖音需要把你在上海上傳的視頻數據通過高速網絡傳遞到北京後，北京的用戶才能看到。
每個數據中心都會和三大運營商網絡對接，同時會和一些中小型運營商對接，這種分佈式的網絡保證了抖音的業務不會都積壓在一個數據中心，由全國各地抖音數據中心和運營商互聯的帶寬來保證用戶刷視頻可以正常瀏覽。
那麼位於不同位置的抖音的數據中心和三大運營商的互聯帶寬多大？只能講肯定是T級別的，1T等於1000G，現在大型互聯網公司和運營商對接的帶寬普遍是1T、2T起步了，而且一般如果發展互聯帶寬負載超過了30%到50%，就需要擴容。
因此哪怕日活躍用戶3.2億，抖音依然抖得無比帶勁，但是小編在這裡還是想說，不管是玩遊戲還是刷視頻，應該合理的去安排時間，不要沉迷進去，因為短視頻給人的是對生活的不妥協，造成一種我很幸福的假象，而這世界上能讓你覺得幸福的事，是你通過自己實實在在的努力換來的一切，這才是最真實、可靠的。
愛看科技
隨著互聯網業務的快速發展，現在很多大型互聯網企業數據中心的網絡和複雜程度都急速提高了，這意味著對服務器的帶寬要求也急劇上升。像抖音這樣的大型視頻網站，它的服務器每天要處理的信息是百億級別的，這種程度就算用世界上最大的數據中心也很容易癱瘓。
所以為了分攤壓力，目前幾乎所有的大型互聯網企業都是採用多數據中心的的方式。
什麼是多數據中心？
和谷歌的網絡類似，大型互聯網企業的網絡一般可以分為數據中心內部網絡和WAN網，它們的數據中心會分佈在全國各個城市，甚至是海外，各個數據中心又分別和運營商的網絡進行對接，這樣就避免了所有的業務積壓在同一個數據中心。
而按照流量的方向，又可以將WAN網分為內網和外網。內網是各個數據中心之間互聯的網絡，用來連接互聯網企業在地理上分佈的多個數據中心。外網則是面向Internet用戶訪問的網絡，用來提供面向用戶的雲服務，如搜索、視頻、下載等。
題目裡面所說的帶寬指的主要還是外網的帶寬。隨著雲服務的蓬勃發展，Internet用戶數量和流量的急劇增加，現在的網絡容量也從數年前的10G快速增長到1T，10T，甚至更大。
抖音服務器帶寬有多大？
大概估算一下，一個1分鐘的抖音短視頻大約需要70M的流量，那平均就是1.16MB/s，根據7月份的最新數據，抖音的日活用戶數已經達到了3.2億，保守地假設每秒有1千萬用戶同時在線，那就是11.6TB/s，還要考慮到損耗和其他的問題，實際上這個數會更大。
所以就算各個數據中心再分攤一下，每個數據中心和運營商對接的帶寬應該都是是T以上的。
