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

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

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

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

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

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

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

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

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

1. 網(wǎng)絡問題

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

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

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

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

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

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

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

1.2. 檢測錯誤

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

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

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

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

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

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

1.3. 超時 (Timeout)時間設置

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

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

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

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

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

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

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

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

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

1.5. 總結

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

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

(未完待續(xù))

參考文獻

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