分布式系統(tǒng)問題之網(wǎng)絡(luò)問題

作者： 程序員阿sir 2021-12-14 08:19:59

網(wǎng)絡(luò)

通信技術(shù)

分布式 在分布式系統(tǒng)上開發(fā)軟件與在單機上開發(fā)軟件完全不同。主要的區(qū)別是分布式系統(tǒng)有更多的地方可能出錯，而且出錯的形式可能與單機系統(tǒng)也不同。這一篇文章將介紹可能出現(xiàn)的兩個問題：網(wǎng)絡(luò)問題、時鐘問題。

創(chuàng)新互聯(lián)專業(yè)為企業(yè)提供臨翔網(wǎng)站建設(shè)、臨翔做網(wǎng)站、臨翔網(wǎng)站設(shè)計、臨翔網(wǎng)站制作等企業(yè)網(wǎng)站建設(shè)、網(wǎng)頁設(shè)計與制作、臨翔企業(yè)網(wǎng)站模板建站服務(wù)，十載臨翔做網(wǎng)站經(jīng)驗，不只是建網(wǎng)站，更提供有價值的思路和整體網(wǎng)絡(luò)服務(wù)。

本文轉(zhuǎn)載自微信公眾號「程序員阿sir」，作者程序員阿sir。轉(zhuǎn)載本文請聯(lián)系程序員阿sir公眾號。

在分布式系統(tǒng)上開發(fā)軟件與在單機上開發(fā)軟件完全不同。主要的區(qū)別是分布式系統(tǒng)有更多的地方可能出錯，而且出錯的形式可能與單機系統(tǒng)也不同。這一篇文章將介紹可能出現(xiàn)的兩個問題：網(wǎng)絡(luò)問題、時鐘問題。

介紹這兩個問題之前，我們先看一下構(gòu)建大規(guī)模的計算服務(wù)的兩種選擇：

• 高性能計算 (High Performance Computing, HPC)：也就是使用超級計算機 (超算, Supercomputers)。這類計算機可能有幾千個CPU，性能很強。這種機器適合于計算密集型的科學(xué)計算任務(wù)，比如實時預(yù)測天氣等等。
• 云計算 (Cloud Computing)：它使用的機器可能都比較一般，但是它可能部署在多個數(shù)據(jù)中心，通過以太網(wǎng)進行相互通信。

當(dāng)然很多企業(yè)使用的是兩者結(jié)合的方式，即每臺機器性能也不錯，也由多臺類似的機器組成集群來提供服務(wù)。高性能計算和云計算的區(qū)別如下：

• 許多云服務(wù)應(yīng)用都是在線的，也就是說任何時候都可能在服務(wù)用戶。所以讓整個云服務(wù)宕機是不可接受的。但是離線的任務(wù)我們可以隨時停止然后重新啟動。
• 超級計算機的方向是構(gòu)建可靠的穩(wěn)定的系統(tǒng)，節(jié)點之間通過共享內(nèi)存和RDMA (Remote Direct Memory Access) 來通信。而云服務(wù)的每個節(jié)點都很便宜，用的硬件也不一定穩(wěn)定，所以失敗率很高。
• 大型數(shù)據(jù)中心網(wǎng)絡(luò)經(jīng)?；贗P和以太網(wǎng)，提供高速網(wǎng)絡(luò)。而超級計算機的方向是使用專用的網(wǎng)絡(luò)結(jié)構(gòu)，專為超算通信而服務(wù)。
• 云服務(wù)系統(tǒng)越大、組件越多，越可能出錯。當(dāng)錯誤處理策略有問題時，大型系統(tǒng)可能需要花費更長的時間從錯誤中恢復(fù)。
• 云服務(wù)通過是全球范圍分布式部署，數(shù)據(jù)通信通過網(wǎng)絡(luò)。而超算通常節(jié)點都十分接近。

因此，如果我們想利用分布式系統(tǒng)創(chuàng)建一個我們自己的服務(wù)，這個服務(wù)必須能容忍錯誤 (Fault-Tolerance)。換句話說，我們需要利用不可靠的組件構(gòu)建可靠的系統(tǒng)。我們需要處理錯誤 (Faults)，并且要在軟件設(shè)計階段就充分考慮錯誤處理，需要知道當(dāng)軟件遇到錯誤的時候我們的軟件會出現(xiàn)什么問題。

在構(gòu)建系統(tǒng)時，我們應(yīng)該多考慮一些可能出現(xiàn)的問題，而不是假設(shè)我們的服務(wù)完美無缺，不會遇到問題。在分布式系統(tǒng)中，任何的懷疑、悲觀、執(zhí)著都會得到回報。(In distributed systems, suspicion, pessimism, and paranoia pay off.)

下面將分別介紹這兩個問題。

1. 網(wǎng)絡(luò)問題

1.1. 網(wǎng)絡(luò)問題概述

分布式的網(wǎng)絡(luò)都是不可靠的網(wǎng)絡(luò) (Unreliable Networks)。數(shù)據(jù)中心之間或者公共網(wǎng)絡(luò)大多數(shù)是異步包交換網(wǎng)絡(luò) (Asynchronous Packet Networks)。在這種網(wǎng)絡(luò)中，一個節(jié)點可以發(fā)送數(shù)據(jù)包到另一個節(jié)點，但是網(wǎng)絡(luò)不保證這個包什么時候能到、是不是能到。所以當(dāng)你向服務(wù)器發(fā)送一個請求時，可能出現(xiàn)幾種錯誤。

• 請求在發(fā)送到對方節(jié)點之前就丟了。比如網(wǎng)線沒插。
• 請求可能在網(wǎng)絡(luò)上排隊，等著被發(fā)出去。比如網(wǎng)絡(luò)過載。
• 服務(wù)器處理請求失敗。比如服務(wù)器crash了或者關(guān)機了。
• 服務(wù)器暫時不能處理請求。比如服務(wù)器開始進行垃圾回收，暫停服務(wù) (Garbage Collection Pause)。
• 服務(wù)器已經(jīng)處理了請求，但是返回的結(jié)果在網(wǎng)絡(luò)上發(fā)丟了。比如交換機配置有問題。
• 服務(wù)器已經(jīng)處理了請求，但是返回的結(jié)果又延遲，等著被發(fā)出去。比如網(wǎng)絡(luò)或機器過載。

網(wǎng)絡(luò)請求失敗示意圖

所以當(dāng)發(fā)送方?jīng)]有收到回復(fù)時，他甚至不能判斷出包是否成功到達了服務(wù)器。唯一判斷的方式就是通過服務(wù)器的response，但是這個response也可能無法到達。如果沒收到回復(fù)，我們幾乎不可能知道哪里出了問題，除非service記了log。

常用的處理該問題的方式是設(shè)置超時時間 (Timeout)，也就是一段時間之后不再繼續(xù)等待結(jié)果。但是要注意的是即使設(shè)置了超時時間，我們也不知道請求是不是已經(jīng)被service處理了。

處理網(wǎng)絡(luò)問題不意味著一定要做處理，可能只是將錯誤的信息返回給用戶。但是我們必須知道這個軟件對于各種網(wǎng)絡(luò)問題時如何相應(yīng)的，并且確保這些處理操作不會造成死鎖之類的系統(tǒng)問題。

1.2. 檢測錯誤

很多系統(tǒng)需要自動檢測錯誤節(jié)點的能力。比如負載均衡器 (Load Balancer)，Single-Leader的分布式數(shù)據(jù)庫等等。但是由于網(wǎng)絡(luò)的不確定性，檢測節(jié)點是否還在工作十分困難。有一些情況下可以幫助獲取到一些關(guān)于網(wǎng)絡(luò)問題的信息：

節(jié)點機器仍然能工作，但是沒有進程在監(jiān)聽對應(yīng)的目標(biāo)端口 (比如進程crash了)，那么系統(tǒng)會拒絕TCP連接，返回 RST 或 FIN包。

如果節(jié)點進程crash了，節(jié)點仍然正常工作，集群可能能夠立刻將請求交給另一個節(jié)點處理。比如 HBase。

如果有權(quán)限訪問數(shù)據(jù)中心的網(wǎng)絡(luò)交換機，可以從硬件層面查看是否存在問題。但是一般情況下我們沒有權(quán)限訪問交換機。

如果IP地址不可達，它可能返回ICMP 目標(biāo)不可達 (ICMP Destination Unreachable) 包。

另外，盡管 TCP 請求會自己進行重試，并對應(yīng)用層透明。但是我們最好還是自己在應(yīng)用層進行重試 (Retry)。 如果直到超時時間如果還是沒有得到結(jié)果，則可以說明節(jié)點出現(xiàn)了問題。

1.3. 超時 (Timeout)時間設(shè)置

超時時間設(shè)置并不是一個簡單的事情。設(shè)置的時間長了的話，服務(wù)器可能會多等很長時間。設(shè)置的短了的話可能有判斷錯誤的風(fēng)險，也許現(xiàn)在只是服務(wù)器網(wǎng)絡(luò)有一點臨時性的堵塞，導(dǎo)致速度慢了一些。一些load balancer是通過timeout來判斷節(jié)點是否存活的，如果誤判了節(jié)點的存活狀態(tài)可能對服務(wù)性能造成影響。

如果一個系統(tǒng)的理想中的網(wǎng)絡(luò)延遲是，服務(wù)器處理時間是 ，則timeout時間最好設(shè)置為 。但是實際中大多數(shù)系統(tǒng)的網(wǎng)絡(luò)延遲是沒有上限的 (Unbounded Delays)，也就是說網(wǎng)絡(luò)盡力最快交付，但是也可能無限慢下去。服務(wù)本身也無法給出準(zhǔn)確的最大處理時間。

1.4. 網(wǎng)絡(luò)擁塞和排隊 (Network Congestion and queueing)

我們開汽車到達目的地的時間不確定主要是由于車在路上排隊的時間是不確定的。同理，網(wǎng)絡(luò)包延遲的不確定性也可能是由于包在網(wǎng)絡(luò)中排隊 (queueing)。有以下幾個可能導(dǎo)致排隊的地方。

• 如果很多人同時往一個目的地發(fā)送包，交換機必須把這些請求排好隊一個一個的發(fā)到目標(biāo)網(wǎng)絡(luò)鏈路。因此包可能需要在目標(biāo)網(wǎng)絡(luò)鏈路中排隊。如果排隊的包太多了，可能后面發(fā)送上來的包都會直接被丟棄，必須重傳。
• 當(dāng)包到達服務(wù)器時，如果所有的CPU都在忙著，當(dāng)前請求就會被操作系統(tǒng)排隊，直到應(yīng)用獲取了時間片可以處理這個請求。這個等待時間根據(jù)當(dāng)前機器的負載來決定，可能很短時間也可能很長。
• 如果是虛擬環(huán)境，可能當(dāng)前獲取CPU時間片的是另一個虛擬環(huán)境，所以當(dāng)前虛擬環(huán)境可能也需要等待，所以網(wǎng)絡(luò)請求也會排隊等待處理。
• TCP擁塞控制 (Flow Control, Congestion Avoidance or backpressure)。可能發(fā)送方限制了發(fā)送速率以保證不會對網(wǎng)絡(luò)或目標(biāo)機器造成過載，所以可能在包進入網(wǎng)絡(luò)之前，包就已經(jīng)在排隊了。

端口1，2，4嘗試發(fā)送包給端口3

除此之外，當(dāng)TCP沒有收到ACK時，會重傳請求。雖然這一過程對應(yīng)用層是透明的，但是應(yīng)用層可以感受到更高的延遲。

當(dāng)服務(wù)有很多空閑的時間時，隊列任務(wù)可以被很快處理完然后清空。但是當(dāng)服務(wù)器快達到它的處理上限時，隊列將很快變得越來越長，排隊將會導(dǎo)致嚴(yán)重的網(wǎng)絡(luò)延遲。

同時，在云環(huán)境下，我們很難控制網(wǎng)絡(luò)延遲，因為可能有很多服務(wù)在共享當(dāng)前的同一個服務(wù)器。所以當(dāng)網(wǎng)絡(luò)擁堵時，也許是別的服務(wù)造成的網(wǎng)絡(luò)擁堵，從而影響了我們的服務(wù)。

1.5. 總結(jié)

在云服務(wù)的場景下，目前的技術(shù)不允許我們對網(wǎng)絡(luò)延遲和可靠性作出保證，也就是說我們需要考慮網(wǎng)絡(luò)擁塞、排隊以及無上限的延遲。超時時間也沒有一個固定的參考值，需要通過實驗來進行設(shè)置。

下一篇文章將繼續(xù)介紹時鐘問題。

(未完待續(xù))

參考文獻

[1] Kleppmann, Martin. Designing data-intensive applications: The big ideas behind reliable, scalable, and maintainable systems. " O'Reilly Media, Inc.", 2017.

當(dāng)前名稱：分布式系統(tǒng)問題之網(wǎng)絡(luò)問題
分享地址：http://www.dlmjj.cn/article/dpsosjg.html