> 原文出處：http://www.infoq.com/cn/articles/laxcus-introduction-part2 > 作者：梁祖邦 本文是系列文章的第二部分，閱讀前兩部分見這里《[大數據管理系統LAXCUS(一)：基礎與數據](http://www.infoq.com/cn/articles/laxcus-introduction-part1)》 [TOC=2,3] ## 網絡通信 LAXCUS集群網絡建立在TCP/IP協議網絡之上，支持IPv4和IPv6網絡地址。為了適應不同的網絡通信需求和節約網絡通信資源，LAXCUS采用了專屬的網絡通信協議，和在此協議上建立的多套網絡通信方案，它們共同組成了LAXCUS網絡通信運行的基礎。本章將闡述與網絡通信有關的各個組成部分。 ### 3.1 FIXP協議 LAXCUS使用FIXP協議進行網絡通信，FIXP是一套全新的二進制格式的應用層通信協議，名字全稱是自由消息交換協議(Free Information eXchange Protocol)。二進制數據采用小頭碼位序(Little Endian)。FIXP協議具有平臺獨立、上下文無關、結構簡單、數據尺寸小等特點。 #### 3.1.1 協議結構 如圖3.1所示，協議結構布局按排列順序由三部分組成：命令、消息、數據實體。命令分為兩種：請求和應答，命令的作用是說明本次通信的基本屬性。每次通信由發起方發送請求命令，受理方返回應答命令。消息在命令之后出現，消息在一次通信協議中允許出現任意多個，消息中攜帶本次通信需要的多類附屬信息。消息之間是銜接的，彼此無分隔標記，通過消息頭中的標記長度加以區別。在最后是數據實體部分，數據實體包含本次通信需要的主要內容，如音頻、檔案資料等。數據實體是一個可選部分，是否存在會在消息中注明。比如通信發起方通常是不需要傳遞數據實體的。  圖3.1 FIXP協議結構 #### 3.1.2 命令結構 如圖3.2，命令是一個56位(7字節)的數字序列。第一個8位的標識的作用是區分當前是請求命令或者應答命令。之后的協議版本號占用16位，協議版本號是可變的，不同的協議版本號代表不同的協議格式，在應用中分別有不同的解釋。目前協議的最新版本號是256(0x100)。 命令的主要區別在第24至40位，請求命令需要提供兩個8位的主命令和從命令，說明本次操作的作用目標，應答命令返回一個16位的應答碼，確認本次請求是接受、還是因為其它原因拒絕。最后是16位的消息成員數，理論上，一次FIXP通信最多可以攜帶65535個消息。  圖3.2 命令(請求/應答)結構 #### 3.1.3 消息結構 如圖3.3，消息是一個不定長的數據結構，由鍵、類型、參數長度、參數組成。鍵占用16位，每個鍵都有一個固定的定義，鍵理論上有65536個，目前已經使用了大約100個。類型占用4位，說明后續的參數屬性，包括布爾、短整數、整型、長整型，單浮點、雙浮點、二進制數組、字符串、壓縮二進制數組、壓縮字符串。參數長度是一個12位的值，參數的實際尺寸由參數長度說明。需要特別指出的是，數值型參數具有字長壓縮能力，例如一個整型數0x20，按照計算機字長標準需要占用4個字節，但是實際尺寸只有1個字節。這時參數長度會說明為1，忽略前面3個0。如本章開篇所述，數值型參數遵循Little Endian格式。  圖3.3 消息結構 ### 3.2 通信方案 LAXCUS在FIXP協議基礎上提供了四種通信方案。這些通信方案將根據所屬環境和任務的不同需求，實現有區別的通信，達到節約網絡流量，降低運行負載，提高計算效率的目的。 #### 3.2.1 TCP通信 TCP通信建立在TCP/IP網絡的TCP模式基礎上，主要針對持序的、大流量的數據傳輸。比如數據塊的分發。在有上千臺計算機運行的集群環境中，這種流量規模的數據通信會占用大量的網絡帶寬，造成網絡阻塞，嚴重影響集群其它通信業務的正常進行，更嚴重的甚至會造成網絡的癱瘓。所以，大流量的數據傳輸是受到限制的，已經規定必須在HOME節點監管下進行。 #### 3.2.2 UDP通信 UDP通信建立在TCP/IP網絡的UDP模式基礎上，主要針對于非持序、可靠性要求不高的小流量數據傳輸。在系統的網絡通信中，基于UDP傳輸的FIXP協議包，數據尺寸普遍介于20至300字節之間，小于一個IP包的最大傳輸單元(MTU)，并且以網絡監控包為主，測試節點是否正常運行的心跳包是最常用一種。UDP通信是LAXCUS使用頻率最高的通信方案。 #### 3.2.3 KEEP UDP通信 UDP的優點在于對計算機的資源占用率低，缺點是數據通信不穩定，存在丟包現象。TCP恰恰相反，可以提供穩定的數據通信，但是對TCP/IP堆棧的資源占用率高。在系統的網絡通信過程中，存在大量需要保持穩定通信，但是又希望采用UDP的通信業務。如何擁有二者的優點而且避免其缺點，答案就是“KEEP UDP（可持續的包通信）”。KEEP UDP是TCP和UDP之間的一種過渡方案，通過在UDP基礎上模擬TCP通信過程，為UDP數據提供穩定的通信保證。這個方案的實質就是將原來在TCP/IP堆棧上進行的包的分組和重組的工作，轉移到LAXCUS控制的工作線程上去執行。在減輕TCP/IP堆棧壓力的同時，還能夠根據當時需求，自由定義一些對包的特殊規則。目前KEEP UDP主要是發送網絡日志和RPC處理，這些都是數據流量不大但是需要可靠傳輸的業務。 #### 3.2.4 RPC通信 RPC(遠程進程調用)的出現由來以久，是一種非常優秀的網絡通信方案，至今仍在被廣泛使用。它通過隱藏網絡兩端通信的方式，使網絡上兩臺計算機之間進行的網絡調用類似本地API調用的過程。這樣就極大地簡化了程序員對網絡編程的難度，提高了工作效率，減少了出錯的機會。 LAXCUS包含了對RPC的實現，它的通信建立在TCP和KEEP UDP通信基礎之上，通過在本地嵌入接口和對程序員屏蔽網絡流程，實現RPC調用處理。目前節點間許多復雜的、安全度高的網絡通信都被要求采用 RPC方案執行。 ### 3.3 通信檢測 集群運行過程中，發生的很多故障都與網絡和網絡設備有關。根據統計，這些故障大致包括：線路損壞、插口松動、電磁影響、網絡阻塞、網絡設備損壞。其中有些是硬件故障，有些是暫時性的網絡故障。判斷故障的有效手段是通過發送ICMP包來檢測網絡可達。這項測試可以由單機處理，必要時需要多個節點對一個地址共同測試，然后匯總測試結果得出答案。系統將判斷故障是暫時性的網絡問題或是不可恢復的物理故障。如果問題嚴重，將報告給系統管理員，通過人工處理來解決故障問題。通信檢測在所有節點都會執行，是體現集群弱中心化和自維持能力的必要手段。 ### 3.4 通信服務器 如1.3節所述，通信服務器是節點管理下的一個工作線程，采用FIXP協議通信。通信服務器在啟動時分別綁定TCP/UDP兩個模式的監聽套接字(SOCKET)，套接字參數在配置文件中定義。根據系統的規定，工作節點的套接字地址在啟動時由系統隨機選擇，管理節點的套接字必須有固定的IP地址和端口。因為只有管理節點的地址固定，工作節點才能夠在網絡上找到管理節點。通信服務器不主動發起通信工作，只接收外部發來的命令。在收到命令后，分派給下屬的任務線程完成具體的任務處理。通信服務器還承擔網絡通信安全的職能，確保通信過程中，網絡兩端傳輸的數據是正確和可信任的。通信服務器的安全管理是一個可選項，是否使用由用戶決定，在配置文件中設置。 ### 3.5 全局時間 在網絡通信過程中，為了能夠辨別各節點之間數據處理的先后順序，需要一個參數來標識它們當時所處的位置。這個參數被稱為全局時間，也稱為主時鐘或者時間軸。全局時間以集群中唯一的TOP運行節點的操作系統時間為標準，其它所有節點必須遵從這個時間定義，與TOP運行節點保持一致。全局時間在節點啟動時向所屬上級管理節點申請和獲取，在本地操作系統上設置，誤差要求不超過1秒。全局時間目前已經使用在網絡日志、網絡計算，以及主塊沖突、數據冗災處理中。 ## 網絡計算 網絡計算是在網絡通信基礎上實施的數據計算工作，相較于集中計算，網絡計算更適合處理那些復雜的、數據量大、耗時長的計算任務。進行網絡計算的前提是數據可以被分片。分片的辦法有很多種，最常用的是按照數據范圍和散列分片。需要強調的是，分片后的數據區域之間不應該存在數據重疊的現象。 LAXCUS網絡計算模型的設計基于網絡節點物理分散邏輯統一這個現狀，其宗旨將系統職能和用戶職能分開。系統負責網絡通信、計算任務的分配和調度、故障管理等工作，為用戶的計算業務提供一個穩定的運行環境。用戶的職能由程序員通過網絡計算可編程接口實現派生編程，把各種業務規則轉化為計算機可執行的程序代碼，然后發布放到集群上運行，與系統功能結合，共同完成網絡計算工作。 另外聲明：很多資料介紹中，網絡計算又被稱為分布計算。為減少歧意，在這里統一稱為網絡計算。 ### 4.1 DIFFUSE/CONVERGE算法 對于傳統的集中計算的工作模式，其數據處理過程可以理解為：產生/計算，擴大到網絡環境，可以進一步解釋為：分散/匯合。這也是算法名稱的由來。LAXCUS網絡計算模型即源于這一思路。 以下結合集群網絡和圖4.1，闡述DIFFUSE/CONVERGE算法的處理流程。 如圖所示，DIFFUSE是網絡計算的開始，同時會有多個DIFFUSE請求分別作用到不同的節點上，根據內部攜帶的命令產生供后續的CONVERGE計算用的原始數據。在實際應用中，這些命令可以是SQL語句，或者是用戶自定義和自解釋的數據和參數。 CONVERGE是第二步，它分別從多個DIFFUSE結果中提取需要的數據，然后執行計算。當計算完成時，如果還有繼續計算的需要，就將本次計算結果交給下個CONVERGE處理；如果沒有，向任務請求方返回計算結果。這個計算結果也是DIFFUSE/CONVERGE計算的最終答案。 可以看到，DIFFUSE只執行一次，CONVERGE會執行多次迭代計算。這正是本節需要說明的：DIFFUSE/CONVERGE算法的本質是步驟間串行、步驟內并行的工作方式。當前步驟結束后進入下一個步驟，當前步驟內同時有一批線程對上次的數據進行再計算，線程之間無聯系。計算過程中，每一個步驟執行同一程序的副本，當前步驟的數據輸出是下次步驟的數據輸入，直到最后輸出結果數據，完成計算任務。 在DIFFUSE/CONVERGE計算中，出現最多的數據處理是：排序、分解、重組、篩選。 按習慣，LAXCUS把實現DIFFUSE/CONVERGE算法的中間件程序稱為“任務”。任務編寫完成后需要發布到節點上以供調用。  圖4.1 DIFFUSE/CONVERGE 處理流程 ### 4.2 任務命名 任務發布后，需要向集群傳播一個標識說明它的存在。這個標識被稱為任務命名。任務命名是一個任意長度的字符串描述，由ASCII碼集中的英文字符、數字、下劃線的組成，英文字符不區分大小寫。系統要求每個任務命名在集群中都是唯一的，這樣才能夠保證區別不同的發布任務。節點把任務發布成功后，會向HOME節點注冊任務命名。通過任務命名，關聯節點可以快速檢索到成功發布的任務，保證后續啟動和調用的需要。 生成任務命名的權限沒有具體規定，但是重名會導致調用和計算過程的混亂，所以命名最好由系統管理員或者擁有系統管理員權限的用戶分配。因為他們擁有管理整個集群的權限，通過檢查全網的任務命名，防止出現重名現象。 ### 任務實現 系統為DIFFUSE/CONVERGE算法任務提供了一套編程接口，這個編程工作由程序員來完成。一個完整的任務由五個階段組成，每個階段的工作內容和范圍，系統都由做了明確的設定。程序員編碼完成后，需要打包發布到相應的節點上。CALL節點處于任務協調中心的位置，負責任務各階段的管理和分配工作。 #### 4.3.1 INIT階段 這個階段是對網絡計算任務進行初始化處理，設置后續階段運行需要的配置數據。配置數據根據用戶輸入的自定義參數，和結合系統當前可提供的資源產生。INIT階段任務指定發布到CALL節點。 #### 4.3.2 FROM階段 這個階段對應DIFFUSE算法，產生網絡計算任務最初的原始數據。數據的來源目前有兩種：使用SQL SELECT語句產生，或者自定義的數據和規則產生。數據產生后會被保存到磁盤上，同時生成數據位圖信息返回給CALL節點。數據位圖是對數據計算結果的抽象化描述，系統提供了一個基礎框架，由系統或者用戶生成。FROM階段任務指定發布到DATA節點。 #### 4.3.3 TO階段 這個階段對應CONVERGE算法。如4.1節所述，CONVERGE是迭代化的處理過程。為匹配任務迭代，TO階段在其之下，定義了一個子階段：NEXTO，以加以區別。NEXTO理論上可以無限迭代。TO和NEXTO階段的數據源自上個階段的計算結果。本次計算結果，如果當前處理不是迭代過程的最后一次，數據就在本地保存，向CALL節點返回的是數據位圖信息，否則向CALL節點返回這次計算結果。TO階段任務指定發布到WORK節點。 #### 4.3.4 BALANCE階段 這個階段存在于FROM和TO/NEXTO階段之后。它的工作是根據數據位圖信息，為后面的TO/NEXTO任務平均分配當前散布在各節點上的數據資源，希望每一個TO/NEXTO任務以基本相同的時間完成數據計算，達到節省總計算時間、提高計算效率的目的。當前的數據位圖信息，如果是由用戶生成，那么解釋工作也由用戶完成，否則由系統默認的接口執行。BALANCE階段任務指定發布到CALL節點。 #### 4.3.5 COLLECT階段 這個階段承接最后一次的TO/NEXTO任務，是對實際計算結果進行的最后處理。最后處理包括：對來自可能不同CALL節點的計算結果的整合，某些個性化處理，以及數據輸出。數據的輸出地址，系統提供了磁盤和計算機屏幕做為輸出目標。COLLECT階段任務的發布位置由用戶選擇，可以是CALL節點或者終端。 ### 4.4 計算過程中的數據平均分配問題 判斷網絡計算效率的重要指標之一是計算的運行時間。計算時間的長短，取決于所有線程中最慢的那個線程的計算時間。所以，為了實現高效的數據計算，需要保證每個線程的計算時間基本一致。而每個線程的計算時間能否保持一致，忽略掉計算機性能這個指標不談，分散到每個線程上計算的數據量是否平均，基本上能夠決定每個線程的計算時間能否保持一致。 LAXCUS采用“模”為平均數據提供指導依據。 按照LAXCUS的定義，模是數據分布數量的參考標準，是一個64位無符號整數，具有兩種含義：1.相同的模，它代表的數據范圍是一致的；2.在以升序排序后的模數組里，相鄰的模，它們所代表的數據范圍是銜接的。 在4.3節所提的數據位圖信息，它的實質就是數據映射模為后，散列化的元信息集合，同時還包括節點地址、數據的磁盤地址等。 BALANCE的位圖計算，是在收集了來自各個TO/NEXTO任務的數據位圖信息后，按照模值進行的重新分配，盡可能的為后面的每個TO/NEXTO任務分配相同量的數據。這樣，在不考慮計算機性能的情況下，理論上，每個節點的數據計算時間能夠大體保持一致。 模概念的引入，解決了網絡計算過程中各個線程處理時間不一致的問題，有助于提高計算效率。 ## 安全管理 安全對于當前計算機網絡的重要性，已是一個不可回避的話題。數據處理過程中的任何一點疏漏都可能造成無法挽回的損失，所以提供一個全面的安全管理方案成為必然選擇。基于對這種現狀的考量，LAXCUS在數據處理的每一個環節都實施了安全管理。安全管理主要圍繞著兩個方面進行：防竊取和防篡改。同時，出于對計算機性能、計算效率、運行壓力的考慮，而安全管理通常又是非常消耗計算資源和時間的計算，所以，某些環節的安全管理設為可選項，決定權交由用戶選擇。比如內網通信過程中的安全，由于內網的安全保障程度比較高，而且內網的數據傳輸量非常大，網絡計算工作幾乎都在內網中進行。這種情況下，為了給網絡計算騰出基礎資源，提高數據計算效率，可以酌情選擇不采用。 本意將闡述在哪些環節實施安全措施，以及實施的辦法。 ### 5.1 通信安全 在一次網絡通信開始時，為了確保任務請求方是可以信任的，任務受理方會要求對方出示通信安全憑證。這個憑證將保證雙方在安全的狀態下通信。 通信安全憑證需要在FIXP服務器上配置，里面存儲著請求方必須出示的信息。安全通信類型分為三種：地址驗證、賬號驗證、地址/賬號復合驗證。當受理方要求出示安全憑證時，請求方必須遵守這個協定，向受理方出示自己的安全憑證，否則通信將被受理方中止。請求方也可以主動向受理方要求安全校驗，受理方都是會接受的。 在通過安全憑證檢測后，可以確定網絡兩端間傳輸的數據是正確和可信任的，這樣就為后續的數據處理提供了一個基本的安全保障。 但是使用中也有例外，比如本節上面提及的內網通信。因為內網相對公共網絡安全度頗高，而通信安全項除了地址驗證外，其他兩種都需要進行大量計算，這會造成任務處理的延遲，對大規模、高密度的網絡計算來說顯得得不償失。所以，一般的建議是，在穿越VPN或者互聯網的通信雙方，應該啟用安全通信；在信任度高的內網，這項工作可以忽略。 ### 5.2 賬號安全 用戶無論是以終端或者應用接口接入LAXCUS集群，系統都要求使用者提供一個登錄賬號。按照LAXCUS規定，賬號由用戶名稱和密碼組成，系統管理員擁有管理整個集群的權力，每一個賬號必須經由系統管理員建立。用戶賬號由系統管理員在終端輸入，賬號的用戶名稱和密碼的明文不會出現在網絡的任何位置，而是首先在本地散列為SHA1碼，再通過網絡上傳，保存到TOP節點的數據字典里，供以后查證和調用。這樣就保證了賬號產生過程中的安全。 賬號持有人擁有修改賬號密碼的權利，當系統管理員建立該賬號后，可以修改由系統管理員設置的密碼。這樣做的目的是，除了賬號持有人外，任何人包括系統管理員，都不能再通過該賬號，操作其屬下的數據資源，從而保證了賬號持有人和賬號屬下的數據資源的絕對安全。 賬號中還包括了賬號持有人的命令操作許可，這些許可也是系統管理員賦予的。操作許通過SQL命令設置。系統管理員的權限可以延伸和再分配，被賦予了系統管理員權限的用戶也可以擁有與系統管理員平等的權力。 ### 5.3 登錄安全 用戶登錄進入LAXCUS集群，除了需要提供登錄賬號外，還必須持有一個系統管理員頒發的安全許可證書。這是一個經過RSA算法簽名的文件，由系統管理員建立和保管。用戶登錄時首先出示這個證書，TOP節點檢查證書的有效性，確定證書有效和登錄者可信后，再執行賬號檢查。與5.2節所述一樣，網絡上傳的賬號是散列后的SHA1碼，此時又經過了證書加密，TOP節點會與本地保存的賬號記錄逐一比對，判斷賬號的有效性和操作范圍，決定是接受還是拒絕。 登錄成功后，雙方進入正式的通信狀態，此時的數據同樣被要求經過加密或者簽名處理。目前可供選擇的加密和簽名算法有:AES、DES、3DES、MD5、SHA1等。這些算法保證通信雙方每一次交換的數據都是安全和可以依賴的。 ### 5.4 數據塊安全 數據塊的安全依賴于對數據的簽名。當數據塊從CACHE狀態轉向CHUNK狀態過程中，系統會計算這個數據塊的數據內容，生成一個16字節數組序列，做為校驗碼保存到數據塊里。數據塊的簽名過程很快，一個64M的數據塊簽名生成時間，在PENTIUM4 2.0G的計算機上，通常在10毫秒以下。 當DATA節點重新啟動，或者數據塊被加載到內存，或者通過網絡傳輸到另一個DATA節點，系統會重新根據數據內容再次生成一個校驗碼，與已經存在的校驗碼進行比較，確認數據的完整性，從而保證后續數據處理的數據本身是正確的。 ### 5.5 行和列集安全 數據塊在從CACHE狀態轉入CHUNK狀態過程中，除了生成針對數據塊的簽名，還會根據數據塊的存儲模型，針對每一行或者每一列集合，生成它們的CRC32校驗碼，并且保存在它們記錄的開始位置。 設置行/列集校驗碼的原因是，因為整塊的數據不會被經常調用，而行/列集的數據卻總是在網絡上大量、頻繁傳遞，這就使得行/列集的數據校驗更有實際意義。 然而相較于少量的數據塊簽名計算，被傳輸的行/列集因為粒度細、數據量大、校驗次數頻繁，計算持續時間也會更長，這將消耗大量計算資源，影響到網絡計算的處理效率。所以，通常任務請求方在收到計算結果后，會根據數據的來源來選擇是否檢測。如果是內網數據，由于網絡安全度高，這個校驗可以被忽略。 ### 5.6 數組列安全 LAXCUS中的數組列，包括二進制的字節數組和字符串數組，這些列中的內容，偶爾會保存一些很關鍵的信息，比如密碼、電話、家庭地址等私密信息。這些信息，通常是不希望被別人知道的，包括系統管理員和運行的集群本身。還有一些內容，比如像網頁或者文檔這樣的文本數據，可能會很長，如果用明文的方式保存會占用較多的存儲空間，將其壓縮后再保存可以有效減少空間占用，而且文本數據的壓縮比率都是很高的。 LAXCUS提供了這樣一個選項，可以對這類信息進行壓縮和加密。數據的壓縮和解壓、加密和解密的控制權由用戶掌握，在終端或者應用接口上完成。系統在其中只是被動接受和傳遞，不做任何處理。具體使用，見6.3.4節介紹。