那么書歸正傳，講講視頻直播難在哪里？

1.數(shù)據(jù)量大

視頻直播第一個問題就是數(shù)據(jù)量太大，假設(shè)想YY這樣一個房間假設(shè)有5000人同時觀看的話，假設(shè)視頻數(shù)據(jù)每秒50K（實踐數(shù)據(jù)可能比這個要大）那么這個數(shù)據(jù)需要50*5000=250000K.那么這么多數(shù)據(jù)等于多少MB答主默默的掏出了計算器25000/1024=244MB，244*8=1952Mb.對的沒錯單單這一個房間每秒消耗的流量就達到1952Mb這是相當驚人的（答主不經(jīng)回頭看看是不是哪里搞錯了）。而且這只是一個房間，高峰時期假設(shè)有300w人同時在線上吹牛逼我們用同樣的方法來算算沒秒走出去的帶寬達到1144Gbps,這簡直就是兇殘。

2.低延遲 所謂直播要的就是及時性，比較直播世界杯你比電視機慢了幾十秒，那么基本上可以說你這個不可用了。面對變大的流量和很高的并發(fā)又有一個棘手的問題就是延遲還必須要低，這個必須走硬件來扛了？其實差不多。

3.網(wǎng)絡(luò)環(huán)境復(fù)雜 國內(nèi)ISP比較多，有些用戶在電信 有些用戶在網(wǎng)通 移動和聯(lián)通 等等。這些用戶都要同等對待?？鏘SP的問題很多，網(wǎng)速很慢。一般有兩種解決辦法，一種是購買多線機房，也就是大家說的bgp機房，這個比較省心但是有個缺點價格嘛……少年掏銀子吧?。。?！第二種就是自己搭建網(wǎng)關(guān)轉(zhuǎn)發(fā)多ISP數(shù)據(jù)。

4.故障轉(zhuǎn)移不好做 對比web前面有智能DNS，后面有LVS等的高可用，web的故障轉(zhuǎn)移有一整套的解決方案，甚至做到了用戶無感知。視頻直播的故障轉(zhuǎn)移是比較困難的。

那么面多這些棘手的問題如果解決？

1.首先是流量的問題

流量顯然不能只是從服務(wù)器轉(zhuǎn)發(fā)走的︶︿︶這樣白花花的銀子都走了。好在一個房間內(nèi)的視頻對每個人都一樣的，所以用戶之間可以共享收到的數(shù)據(jù)，可以給用戶機器之間P2P。那么誰和誰用戶之間共享這個數(shù)據(jù)？還有P2P前需要做內(nèi)網(wǎng)滲透這個打穿防火墻的操作是需要時間的，如果保證低延遲？如果和我共享數(shù)據(jù)的人下線了那么我的數(shù)據(jù)P2P就斷了，如何處理？這些都是問題哇??！

2.低延遲 這個語言兩點。第一點服務(wù)器的處理數(shù)據(jù)要亂快，必須快。加上這又是IO密集型的所以說白了就是機器夠強帶寬夠大。第二點如果采用P2P需要算法保證數(shù)據(jù)共享的合理性，最后從服務(wù)器出去的數(shù)據(jù)和P2P扛的數(shù)據(jù)可以合理的達到一個平衡。

3.高可用 這個部分我也不清楚。來扯下。首先用戶的狀態(tài)必須單獨分開存放當緩存的服務(wù)器上面，緩存服務(wù)器多實例主從必須做。接入服務(wù)器把用戶的數(shù)據(jù)接入進來，提交給其他服務(wù)器比如跨網(wǎng)關(guān)的服務(wù)器轉(zhuǎn)發(fā)？如果接入或者其他服務(wù)器掛了如何保證數(shù)據(jù)可用？如果用TCP客戶端可能已經(jīng)斷開了，需要掉線重連了。要是我我可能自己實現(xiàn)一套基于UDP的可靠傳輸?。?！做到不需要重連或者重連的TTL更低！

那么有沒有什么更好選擇呢

還沒有租用服務(wù)器的朋友可以看下USA-IDC香港服務(wù)器租用，低延遲，高可用，限量首月半價，三大主流型號自選

而租用了服務(wù)器然而覺得性能不足的朋友也可以使用就USA-IDC高防CDN彌補，限時首月半價

歡迎聯(lián)系24小時在線客服，獲取更多產(chǎn)品