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

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

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

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

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

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

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

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

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

1. 網絡問題

1.1. 網絡問題概述

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

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

網絡請求失敗示意圖

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

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

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

1.2. 檢測錯誤

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

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

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

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

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

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

1.3. 超時 (Timeout)時間設置

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

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

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

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

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

端口1，2，4嘗試發送包給端口3

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

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

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

1.5. 總結

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

下一篇文章將繼續介紹時鐘問題。

(未完待續)

參考文獻

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