目錄
- 1.問題引入
- 2.問題出現的原因
- 3.問題的解決
- 4.參考資料
1.問題引入
?? 一個客戶端通過一個交換機與資料中心相連，交換機又與多個服務器相連，客戶端向n個服務器請求一個較大的資料塊，如下圖所示：
??每個資料塊都分割到這些服務器上，因此每個服務器都存盤了一個較小的資料塊，接收端為了得到較大的資料塊，向每個服務器發送一個請求，服務器收到請求后，就以一種多對一的模式通過瓶頸鏈路向接收端發送資料，只有在所有請求的服務器資料都被客戶端成功收到，該請求才算完成，客戶端才能請求下一個資料塊，但是，隨著同時參與資料同步傳輸的服務器數目的增加，大量的資料流量會涌向交換機與客戶端之間的瓶頸鏈路，這些流量會導致瓶頸鏈路上交換機的緩沖區的溢位，引起大量丟包事件，以及隨后的資料重傳，最終導致吞吐量的急劇下降，
2.問題出現的原因
??正是由于高帶寬鏈路，低傳播時延，以及有限的交換機緩沖區導致了TCP Incast 問題的出現，首先，由于高帶寬和低時延，在需要資料的客戶端向存盤資料的服務器發送資料請求后，這些服務器幾乎同時向客戶端發送資料，導致大量資料流同時涌向網路，又由于交換機緩沖區空間有限，這種流量很容易就會將其溢位，接著發生丟包，TCP 通過超時重傳進行恢復，超時的時間通常至少要幾百毫秒，需要超時重傳的服務器會進入超時等待，由于同步的傳輸模式，多個服務器可能會同時進入這種等待，因此在等待的這段時間內，鏈路幾乎處于完全空閑狀態，這就導致鏈路的不充分利用，以及吞吐量的急劇下降，
3.問題的解決
??我解決問題的辦法是：出現啥問題？是什么原因導致的？就想辦法去解決這個原因，
???1.因為會發生丟包問題，我們可以從這一點去思考這個問題，由于緩沖區空間小導致的丟包，我們可以稍微擴大緩沖區的空間來解決這個問題，
???2.這些資料基本上都是同時在發送，我們是否可以給它一個先后秩序來發送資料，這樣也能避免大量資料同時涌進一條鏈路，
???3.增大服務器內的資料塊大小，在網上有說明，增大資料塊的大小就使得資料塊平均分割到較小數目的存盤服務器上，這樣客戶端就可以向較少的服務器請求同樣的小的資料塊，
4.參考資料
中國科學院大學碩士論文—《云計算資料中心網路和TCP Incast問題研究》
轉載請註明出處，本文鏈接：https://www.uj5u.com/qita/312055.html
標籤：其他