現在比較流行的直播，經常會出現這樣的情況： 使用者打了乙個彈幕上去，主播念出來的時候，彈幕已經飛出去了。二者時間是不匹配的。
這是我們的乙個客戶，兩個主播連線互動，實時互動。試想，如果直播時延時高達幾秒，像這樣的雙主播組合是沒有辦法進行交談的。a說完之後，對方要等幾秒才能聽到，又過了幾秒，a才能聽到對方的回答。
這兩個例子其實要說明實時互動直播和普通直播相比有本質的區別：延時。實時互動直播延時必須低達幾百毫秒。
網際網路是基於電磁波或者通過光纖傳播的。光繞地球一圈，耗時300毫秒，這是無法逾越的物理定律延時。有人號稱可以做到0延時，他們估計用上了量子通訊。在實際網際網路應用中，網路條件並不理想，網際網路訊號繞地球一圈的延時必然大於300毫秒。這就給實時互動直播，帶來了巨大的挑戰。
第一，網際網路的骨幹網上路由器的部署，不是直線點到點，而是中間要經過很多路由器的跳數，實際上是在走「彎路」。所以，網際網路傳輸沒有辦法繞地球一圈正好300毫秒，最好的情況也需要要近400毫秒。
第二，公共網際網路上，路由器其實經常出現故障。比如，在晚高峰的時候，網路會比較慢。這是因為部分路由器可能過載。因為路由器有最大的處理能力上限，一旦超過上限，就不能處理，會造成丟包、擁塞。
第三，無線網路相對有線網路，可靠性較低。無線網路普及度越來越高，，越來越多的手機、筆記本連線無線網。但是無線網路相對有線網路沒有那麼可靠，同時也會引入訊號汙染。訊號覆蓋不到的地方，效果較差。
實時互動直播要保證高可用性，有巨大的難度，原因如下：
實時很難。網際網路基礎設施不是為實時通訊設計的。
覆蓋很難。機房找點，互聯互通。對通訊雲來說，覆蓋不好會影響到可用性。
高併發很難。不能看著看著就不動了，沒聲了。
突發性很難。系統容量要高，還要防止雪崩。
這些挑戰我們在做整個服務的時候，都需要全面考慮。
這個架構很簡單，但有乙個缺點，沒有考慮覆蓋不同地使用者的問題。並且一台伺服器支撐不了大規模使用者。這台伺服器如果宕機，或者伺服器機房出故障，整個傳輸都會受到影響。這必然達不到高可用架構的標準。
可用性可以分為兩個部分：接入可用性和使用可用性。你在使用服務的時候，能夠接得進去，能夠聽得到，這是接入可用性。舉個例子，打**的時候，有時會出現你所呼叫的使用者無法接通，因為使用者的手機沒有接入電信服務，這就是接入可用性問題。在通話的時候，聽不到對方說話了，使用中掉線了，這就是使用可用性。
為了實時監測可用性，我們做了兩方面的監測：
服務可用性不能依靠使用者資料反饋或者使用者主動上報，這樣你永遠是最後乙個知道的。況且初期使用者量小怎麼辦？因此，我們需要自己給出我們的服務有多可靠。為此，我們研發主動監測系統來監測整個服務。端到端監測，接入有沒有問題，在使用的過程中會不會出問題。
使用者在使用我們的服務的時候，我們會收集使用者接入服務的整個過程，多長時間可以接入，接入時經過了幾次請求，使用中有沒有掉線，中間有沒有聲音終端或卡頓。我們會收集這些資料，據此了解服務的可用性。
有了監測資料，那麼就可以據此來不斷改進我們的服務，解決前面所說的挑戰。
在中國做網際網路的人應該都有乙個感受，聯通跨電信，使用者之間是難以互動的。早期的qq傳檔案沒有做中轉，如果聯通和電信的使用者要互相傳檔案，速度非常慢，甚至會中斷。玩網遊的使用者，也會遇到有電信專區、網通專區。下圖是乙個簡單的測試，當跨運營商的時候，發乙個包，可以看到裡面有很多丟包。這個數字是rtt，這個測試結果可以看出，最小是62毫秒，最大是840毫秒。
不但中國有網路互通的問題，國外也有。很多人以為發達國家，比如美國、日本，網際網路的基礎設施較好，所以不會有互聯互通的問題。但是，在我們做實際測試時，美國的網際網路也存在互聯互通的問題，只是狀況比中國好一些。
上圖，展示了乙個乙個阿爾及利亞使用者的網路狀況。他接入的是國家電信的服務商，從骨幹網接入阿爾及利亞電信有很多線路，最下面的線路義大利電信是最直接的。如果不走義大利電信，那麼中間就必須經過很多運營商跳轉。在這種情況下，要保證使用者有做最快的傳輸，就要保證傳輸走義大利電信。這必須依靠覆蓋來解決。
首先，部署大量邊緣伺服器。邊緣伺服器的地理位置越接近使用者越好，二者的線路越接近約好，同乙個sp最好。比如中國國內，我們會有大量電信、聯通、移動伺服器。當我們發現乙個接入的使用者是電信時，我們會找電信線路，如果是聯通的會找聯通線路。再看回上乙個圖，如果遇到阿爾及利亞的使用者要怎麼辦？在現在的服務裡面我們就要找乙個義大利電信接入，而不是隨便找歐洲的機房。必須部署很多邊緣伺服器才能做到這一點。
其次，要有分配服務。有邊緣伺服器之後，使用者還是無法接入邊緣伺服器，因為他不知道接哪個。因此，必須有配套演算法，根據使用者的sp，找到和他最匹配的邊緣伺服器，來進行接入分配。
我們在全中國有好幾十個機房，其中有很多電信的機房，不同的電信使用者來使用我們的服務，應該給他哪個電信機房呢？如果把北京電信使用者接到廣州的電信機房，雖然大多數情況下丟包不會很高，但延時會比較大。為此，我們設計了就近接入演算法，使用我們服務的每個使用者，都會接入到最靠近他，且線路最匹配的伺服器。
當我們就近按sp接入時，遇到了乙個新問題：假如乙個香港使用者，接入的是香港機房，想看北京聯通使用者的表演，那麼這個香港使用者怎麼看到北京使用者的表演呢？我們就需要有乙個分布式傳輸的架構和演算法，來把北京的流量傳到香港。
今天無線網際網路非常普及，使用無線網時，有乙個問題比有線網更嚴重：dns解析。使用者接入時，第一步是通過網域名稱解析，解析到最近的伺服器。但是，做dns解析時，無線網路的訊號會存在汙染，導致dns解析失敗。為此，我們優先使用解析，解析不到再用靜態ip配置。
我們發現在骨幹網上，很多預設的骨幹網路由經常出問題，同時有一些骨幹網部分是不會擁堵的。基於這樣的發現，我們做了自己的路由網路。
在預設路由之外，我們會額外部署路由機房。比如，從上海到洛杉磯，假設預設線路到晚上高峰期會比較擁堵，同時我們發現從上海經過廣州再經過香港再到洛杉磯，這條線路不會擁堵。那麼，我們就會部署這樣一條路由線路，然後做自動的適配。
如果骨幹網上出故障了，我們通過路由的方式構建overlay應對。首先，我們的應用會先連線到分配服務，分配服務會給出一批可接入的機房，當接入的機房壞了，就立即切換到下乙個可用機房，如果發現還是壞了，則再次接入到分配服務，繼續尋找當前可用伺服器。
蜂擁是實時互動直播裡面特別突出的現象，短時間內大量使用者進入頻道或者使用服務。蜂擁對整個後台的衝擊力非常強。大多數的網際網路的後台伺服器每秒接入大概千的量級，但是對於蜂擁而來的使用者，處理量遠遠不夠。這時候就會遇到乙個問題，後台處理響應速度越來越慢，很多使用者的請求會超時。超時之後就會進入更多的請求，請求就會像滾雪球一樣越來越大，導致整個後台系統不能響應，整個系統就會產生雪崩，這叫雪崩效應。
1）要把效能上限提高。通常來說我們的效能上限會達到峰值處理能力10倍以上。效能上限提高要做分配服務效能擴充套件，我們的做法一般是水平擴充套件，因為垂直擴充套件比較困難。
2）應用裡面做自動的重複請求，它會不斷累計請求量，我們要做退避的策略。
3）保證整個接入服務本身的可用性問題，處理方法很簡單，多點備份，然後做併發的請求。我們有很多分配的伺服器，們的應用接入的時候會同時從幾個點請求分配，分配到一批邊緣伺服器之後，會同時連線幾個邊緣伺服器，哪個先響應就處理哪個。
本文整理自聲網agora.io 1號架構師李偉，在archsummit深圳2016 全球架構師峰會 的演講。
【李偉】
海量使用者實時互動直播架構探索
現在比較流行的直播，經常會出現這樣的情況 使用者打了乙個彈幕上去，主播念出來的時候，彈幕已經飛出去了。二者時間是不匹配的。這是我們的乙個客戶，兩個主播連線互動，實時互動。試想，如果直播時延時高達幾秒，像這樣的雙主播組合是沒有辦法進行交談的。a說完之後，對方要等幾秒才能聽到，又過了幾秒，a才能聽到對方...
海量實時使用者行為資料的儲存和分析
在短時間內爆發大量資料，這時資料資源的採集 儲存和分析和應用等，都是大資料行業的難點。行為資料 日誌資料的處理，往往成為企業資料建設首先面對的瓶頸，這些資料不易儲存，實時獲取分析難度較大，但是資料價值卻不可估量。在大資料中，90 以上的資料爆發來自於行為資料，就像現在的網際網路 移動網際網路 甚至在...
基於sersync海量檔案實時同步
基於sersync海量檔案實時同步 專案需求 最近涉及到數百萬張從本地儲存遷移到雲儲存，為了使完成遷移，並保證無缺失，業務不中斷，決定採用實時同步，同步完後再做流量切換。在實時同步方案中進行了幾種嘗試。方案1 rsync inotify同步，最先想到的是此方案，先看下指令碼 此前在多台伺服器間同步 ...