Laxcus大資料管理系統2.0（8）- 第六章 網路通訊

標籤：

第六章 網路通訊

　　Laxcus大資料管理系統網路建立在TCP/IP網路之上，從2.0版本開始，同時支援IPv4和IPv6兩種網路地址。網路通訊是Laxcus體系裡最基礎和重要的一環，為了能夠利用有限的網路資源，獲得最大化的使用效率，我們根據大資料網路環境的特點，設計了一套專屬網路通訊協定，以及在此協議基礎上實現的多套網路通訊方案，它們共同組成了Laxcus叢集的網路通訊基礎。本章將以TCP/IP協議為起點，介紹與網路通訊有關的各個組成部分。

6.1 FIXP協議

　　Laxcus採用FIXP協議通訊。FIXP協議全稱是“自由資訊交換協議(Free Information  eXchange Protocol)”協議。這是一套建立在TCP/IP協議之上的二進位應用程式層通訊協定，二進位字序採用小頭編碼（Little  Endian），協議具有平台獨立、上下文無關、結構簡單、資料尺寸小等特點。

6.1.1 協議結構

　　6.1所示，協議結構布局按排列順序由三部分組成：命令、訊息、資料實體。命令分為兩種：請求和應答，命令的作用是說明本次通訊的基本屬性。每次通訊由發起方發送請求命令，受理方返回應答命令。訊息在命令之後出現，訊息在一次通訊協定中允許出現任意多個，訊息中攜帶本次通訊需要的多類附屬資訊。訊息之間是銜接的，彼此無分隔標記，通過訊息頭中的標記長度加以區別。在最後面是資料實體部分，資料實體包含本次通訊所要傳遞的內容。這些內容可以是任意格式的，如音頻、映像、資料庫資料、各種中繼資料等。資料實體是一個可選部分，是否存在會在訊息中註明。比如通訊發起方通常是不需要傳遞資料實體的。

 

圖6.1 FIXP協議結構

6.1.2 命令結構

　　6.2，命令是一個56位(7位元組)的數字序列。第一個8位的標識的作用是區分當前是請求命令或者應答命令。之後的協議版本號碼佔用16位，協議版本號碼是可變的，不同的協議版本號碼代表不同的協議格式，在應用中分別有不同的解釋。目前協議的最新版本號碼是256(0x100)。 命令的主要區別在第24至40位，請求命令需要提供兩個8位的主命令和從命令，說明本次操作的作用目標，應答命令返回一個16位的應答碼，確認本次請求是接受、還是因為其它原因拒絕。最後是16位的訊息成員數，理論上，一次FIXP通訊最多可以攜帶65535個訊息。

 

 

 

圖6.2 命令(請求/應答)結構

6.1.3 訊息結構

　　6.3，訊息是一個不定長的資料結構，由鍵、類型、參數長度、參數組成。鍵佔用16位，每個鍵都有一個固定的定義，鍵理論上有65536個，目前已經使用了大約100個。類型佔用4位，說明後續的參數屬性，包括布爾、短整數、整型、長整型，單浮點、雙浮點、位元組、字串、壓縮位元組、壓縮字串。參數長度是一個12位的值，參數的實際尺寸由參數長度說明。需要特別指出的是，數值型參數具有字長壓縮能力，例如一個整型數0x20，按照電腦字長標準需要佔用4個位元組，但是實際尺寸只有1個位元組。這時參數長度會說明為1，忽略前面3個0。如本章開篇所述，數值型參數遵循小字頭格式（Little Endian）。

 

圖6.3 訊息結構

6.2 通訊方案

　　我們在FIXP協議基礎上提供了四種通訊方案。這些通訊方案將根據所在環境條件和任務的不同需求，實現有區別的通訊，以達到節約網路流量，降低運行負載，提高計算效率的目的。

6.2.1 TCP通訊

　　TCP通訊建立在TCP/IP協議的TCP堆棧之上，主要用來處理持久性高的、流量大的資料轉送。如資料區塊的分發，以及Diffuse/Converge分布計算行程的資料等。在Laxcus叢集中，它們是主要的通訊流量，佔用了大量的網路頻寬，嚴重的時候會發生網路阻塞，影響到叢集正常運行。為了避免這種現象，TCP通訊會受到流量控制機制的限制，通過採用降低資料轉送流量的辦法，騰出一部分網路頻寬，來保證其它通訊業務的資料轉送和叢集的穩定運行。

6.2.2 UDP通訊

　　UDP通訊建立在TCP/IP協議的UDP堆棧之上，主要針對於非持續、可靠性不高、流量小的資料轉送。在Laxcus叢集中，基於UDP傳輸的FIXP協議包，資料尺寸普遍介於20至300位元組之間，小於一個IP包的傳輸單元最大值(MTU)，其中以網路監控包為主，測試節點狀態的心跳包是最常用一種。目前UDP通訊是Laxcus叢集使用頻率最高的通訊方案。

6.2.3 KEEP UDP通訊

　　UDP的優點在於對電腦的資源佔用率低，缺點是資料通訊不穩定，存在丟包現象。TCP恰恰相反，可以提供穩定的資料通訊通道，但是對TCP/IP堆棧的資源佔用率高。在Laxcus叢集裡，存在著大量即需要保持穩定通訊，又希望採用UDP的網路通訊業務。如何在擁有二者優點的情況下又避免它們的缺點，答案就是“KEEP UDP（可持續的包通訊）”。KEEP UDP是我們在TCP和UDP之間，為Laxcus叢集網路通訊設計的一種過渡方案，通過在UDP基礎上類比TCP通訊過程，為UDP資料提供穩定的通訊保證。這個方案的實質就是將原來在TCP/IP堆棧上進行的包的分組和重組的工作，轉移到Laxcus控制的背景工作執行緒上去執行。在減輕TCP/IP堆棧壓力的同時，還能夠根據當時需求，自由定義一些對包的特殊規則。目前KEEP UDP主要用來執行RPC處理和傳輸部落格，這些都是資料流量不大但是要求可靠傳輸的通訊業務。

6.2.4 RPC通訊

　　RPC(遠程進程調用)的出現由來以久，是一種非常優秀的網路通訊方案，至今仍在被廣泛使用。它通過隱藏網路兩端通訊的方式，使網路上兩台電腦之間進行的網路調用類似本地API調用的過程。這樣就極大地簡化了程式員對網路編程的難度，提高了工作效率，減少了出錯的機會。

　　Laxcus包含了對RPC的實現，它的通訊建立在TCP和KEEP UDP通訊基礎之上，通過在本地嵌入介面和對程式員屏蔽網路流程，實現RPC調用處理。目前Laxcus叢集裡許多複雜的、安全度高的網路通訊都是採用 RPC方案執行。

6.3 通訊檢測

　　叢集運行過程中，發生的很多故障都與網路和網路裝置有關。根據統計，這些故障大致包括：線路損壞、插口鬆動、電磁影響、網路阻塞、網路裝置損壞。其中有些是硬體故障，有些是暫時性的網路故障。判斷故障的有效手段是通過發送ICMP包來檢測網路可達。這項測試可以由單機處理，必要時需要多個節點對一個地址共同測試，然後匯總測試結果得出答案。系統將判斷故障是暫時性的網路問題或是不可恢複的物理故障。如果問題嚴重，將報告給系統管理員，通過人工處理來解決故障問題。通訊檢測在所有節點都會執行，是體現叢集弱中心化和自維持能力的必要手段。

6.4 通訊伺服器

　　如1.3節所述，通訊伺服器是節點管理下的一個工作模組，採用FIXP協議通訊。通訊伺服器在啟動時分別綁定TCP/UDP兩個模式的監聽通訊端(SOCKET)，通訊端參數在設定檔中定義。根據系統的規定，工作節點的通訊端地址在啟動時由系統隨機播放，管理節點的通訊端必須有固定的IP地址和連接埠。因為只有管理節點的地址固定，工作節點才能夠在網路上找到管理節點。通訊伺服器不主動發起通訊工作，只接收外部發來的命令。在收到命令後，指派給下屬的任務線程完成具體的任務處理。通訊伺服器還承擔網路通訊安全的職能，確保通訊過程中，網路兩端傳輸的資料是正確和可信任的。通訊伺服器的安全管理是一個可選項，是否使用由使用者決定，在設定檔中設定。

6.5 全域時間

　　在網路通訊過程中，為了能夠辨別各節點之間資料處理的先後順序，需要一個統一的參數來標識它們當時所處的位置。這個參數被稱為全域時間，也稱為主時鐘或者時間軸。全域時間以叢集中Top Master狀態節點的作業系統時間為標準，其它所有節點必須遵從這個時間定義，與Top Master節點保持一致。全域時間在節點啟動時向所屬上級管理節點申請和擷取，在本地作業系統上設定，誤差要求不超過1秒。全域時間目前已經使用在部落格、網路計算，以及主塊衝突、資料冗災處理中。

6.6 流量控制

　　在造成叢集運行不穩定的因素中，有相當大一部分原因是網路傳輸串流量過大所致，如果可以控制每項資料業務的通訊流量，讓它們以公平和合理的速率傳輸資料，對於改善叢集啟動並執行不穩定狀況，將有很大促進作用。Laxcus採用“等/停傳輸機制”來控制每項工作的網路傳輸速率，這是一項TCP/IP應用程式層的技術，是“Invoke/Produce”任務調度模型的一部分，具有即時判斷網路流量和錯誤重傳的能力。可以根據當時的網路狀況，選擇合適的傳輸速率去傳輸資料，如果丟包率增加，表明當前網路負載過重，就會延遲資料發送間隔。流量控制對上層是透明的，不用對它做任何管理控制措施。目前Laxcus叢集所有資料處理業務中，網路通訊都預設使用“等/停傳輸機制”。根據我們對各種資料流量的檢測顯示，當網路通訊啟用“等/停傳輸機制”後，網路傳輸速率是未啟用前的70% - 84%左右，但是網路在面對重負載的資料通訊時，它的適應能力增強了。所以，總體而言，這對提高系統穩定性是有利的。

Laxcus大資料管理系統2.0（8）- 第六章 網路通訊