基于動態均衡技術的海量異構數據高并發可靠接入方法*

趙 勛，周成勝，靳文京，劉曉曼，王桂溫

(中國信息通信研究院 安全研究所，北京 100191)

0 引言

隨著計算機信息技術、互聯網與物聯網技術的快速發展，各類數據資源呈現爆發式增長，海量數據的產生和積累已成為一種不可避免的趨勢。這些數據往往具有多源異構、分布廣泛、動態增長等特點[1]，如傳感器數據、社交網絡數據、視頻數據等，稱其為海量異構數據。在眾多領域，海量異構數據并發接入已成為一個重要且具有挑戰性的問題[2-4]。為了更好地管理和處理這些數據，需要研究和設計高效的數據并發接入技術和策略，以實現數據的快速處理、分析和應用。

在數據接入系統設計方面，已有研究人員在物聯網、車輛交通、電網調度等領域分別對于物聯網設備數據采集[5]、列車網絡設備實時數據采集[6]、電網智能調度數據采集[7]進行了系統設計，用來解決海量數據接入處理問題，但是這些系統設計均是針對特定的業務場景提出，缺少一定的通用性。

在海量異構數據接入過程中，如何在高并發接入的場景下依然能夠確保接入系統穩定可靠運行是數據接入系統設計面臨的主要挑戰。在有限的集群資源前提下，當海量異構高并發數據產生接入任務時，只有將接入任務合理分配并且快速執行，才能保證數據的順利接入。相對于傳統主從任務分配機制[8]，去中心化的任務分配機制具有更好的健壯性；由于集群的計算節點和通信網絡的異構性或共享性，使得難以事先進行計算負載和通信負載的估算，所以動態負載均衡策略更適合用來調整集群節點負載[9]，最終確保集群節點資源能夠得到高效的利用，達到海量數據的高并發可靠接入。

針對以上海量異構數據并發接入的問題，本文提出一種基于動態均衡技術的高并發海量異構數據接入方法。該方法采用去中心化的任務分配機制，并結合動態負載均衡技術，基于三層系統邏輯架構，實現了海量異構數據的高效采集接入。

1 系統架構

基于動態均衡技術的海量異構數據高并發可靠接入系統架構邏輯上分為三層，底部為異構數據源，其與數據采集層對接，數據采集層從數據源采集到相關數據后寫入數據中心層，處理后供應用系統使用。邏輯架構如圖1所示，各部分詳細描述如下。

圖1 系統邏輯架構圖

異構數據源：海量數據的提供者，根據上層應用需求提供各類型數據，包括結構化、半結構化和非結構化等類型的數據，是數據采集層采集海量數據的源頭。

數據采集層：根據所采集的數據特點和上層應用不同的需求場景，提供SFTP、HTTPS、Kafka等采集接口與數據源對接，數據接口方式由相應的采集節點集群完成，將海量數據從異構數據源采集成功后提供到數據中心層。

數據中心層：實現大數據的存儲處理，采集來的各類異構數據根據結構化、半結構化及非結構化特點輸入相應數據集群系統，供上層應用系統使用。

上述系統邏輯架構并非基于某種特定的場景設計，對于一般海量異構數據高并發接入場景具有一定的通用性。

2 接入方法設計

海量異構數據接入方法主要包括節點負載計算方式、去中心化的任務分配機制、節點分配及回收策略、動態負載均衡策略四部分內容。節點負載計算方式明確了每個節點負載程度的量化表達，是實現后續均衡調度的基礎；去中心化的任務分配機制最大限度保障了集群執行任務的高可靠性；節點分配及回收策略使得計算資源得到最大限度的利用，能夠有效應對高并發場景；動態負載均衡策略的設計從整體上對海量異構數據接入進行靈活調整。

數據采集層包括大量的采集節點，所有節點組成采集節點總池，所有節點邏輯上均等，均可執行不同類型采集接口任務，系統根據相關策略動態地將節點分配到SFTP、HTTPS、Kafka等節點集群中，并在運行中根據任務及負載變化對節點進行靈活調度。

2.1 節點負載計算方式

當采集節點投入使用時，要根據節點負載進行任務分配及節點調度。一般選擇CPU資源、內存資源、當前進程數、響應時間等作為評價參數，全面衡量節點負載情況。

為了科學客觀地計算節點負載，必須將以上參數組合成一個綜合負載計算函數。常見的多指標組合方式有加權乘法及加權和法[10]，前者適用于各指標不能互換，指標相互間強關聯且具有同等重要性場景；后者適用于各指標相互獨立，各指標對于整體的影響能夠線性疊加，且指標間具備一定互補性的場景。

根據以上特點，本文采用了加權和法方式進行負載指標計算，將CPU資源、內存資源、磁盤資源、當前進程數、響應時間等重要信息作為計算公式的因子，每個因子對應一個可變系數Ri，其中∑Ri=1。

具體負載計算公式如下：

Loadnode=R1×Loadcpu+R2×Loadmem+R3×LoadI/O+R4×Loadpid+R5×Loadresp

(1)

其中，Load***依次表示為：節點總負載(Loadnode)、CPU使用率(Loadcpu)、內存使用率(Loadmem)、磁盤I/O訪問率(LoadI/O)、進程總數(Loadpid)以及響應時間(Loadresp)。進程總數以及響應時間根據硬件條件百分比化處理，數值在[0，1]區間。Ri系數根據具體節點集群類型進行設置，比如SFTP集群中磁盤I/O訪問率更加重要，故可以將對應的R3系數提高，而Kafka集群中CPU使用率和內存使用率更加重要，故可將R1與R2系數設置較高。

2.2 去中心化的任務分配機制

傳統數據接入任務分配一般采用主從方式的任務分配機制，此機制存在一個專門負責分配任務的主節點，該節點掌控全局資源，負責分配任務并向執行節點下達相關指令[11]。當主節點失效時則啟用備用節點進行任務分配。此種機制最大的缺陷是隨著執行節點數量的增加，任務分配節點的負載會越來越高，在海量任務情況下可能達到自身性能極限，此時會嚴重影響到任務分配機制正常運轉，而去中心化的任務分配方法比中心化方法具有更好的可擴展性。在本文方法中使用如下分布式任務分配框架，如圖2所示。

圖2 分布式任務分配框架

管理者：通過狀態共享機下達節點指令和任務指令，節點指令包括激活和停止節點，任務指令包括添加和刪除任務。

狀態共享機：提供共享機制，讓各節點都掌握任務狀態和集群情況。包括：狀態管理模塊，負責狀態數據共享，維護狀態視圖；集群管理模塊，對各集群進行管理，對節點進行調度；事件管理模塊，負責處理對狀態視圖的監聽請求以及狀態視圖變化時的事件流程；高可用模塊，負責保障維護狀態共享機的可用性；通信模塊，負責底層通信。

節點：任務執行者，分屬于空閑節點池、SFTP集群、HTTPS集群、Kafka集群。包括：任務模塊，負責執行具體任務；狀態檢測模塊，主要負責向狀態共享機進行狀態同步，更新本地任務視圖；任務分配模塊，按照一定算法對新進入任務進行計算，將任務分配到具體節點，同一集群內算法一致，同一任務無論在哪個節點上計算后得出的結果相同；通信模塊，負責底層通信，進行數據同步。

具體任務分配機制描述如下：

(1)注冊：節點有兩種狀態，即空閑(idle)和活動(active)，新節點開始時皆屬于空閑狀態，在空閑節點池中，需要向狀態共享機進行注冊后方可承接任務。

(2)激活：節點注冊后管理者可通過狀態共享機下達激活指令，節點進入活動狀態。狀態共享機中集群管理模塊按節點分配策略通知活動節點進入相關集群。

(3)請求最新狀態視圖：節點進入相關集群后，將向共享狀態機進行狀態視圖同步請求。

(4)同步最新狀態視圖：狀態共享機將最新狀態視圖發送給節點。

(5)狀態視圖監聽：節點進入活動狀態后將向狀態共享機進行申請，對狀態視圖進行持續監聽，狀態共享機通過步驟(4)返回最新狀態視圖。

(6)任務分配計算與狀態更新：節點獲取最新狀態視圖后將任務分配模塊根據統一算法進行任務分配計算(同一集群內分配算法與策略一致)，若本節點為下一任務接收節點則主動進行標識，完成承接任務準備工作并向狀態共享機更新狀態視圖。

2.3 節點分配及回收策略

采集節點總池中節點個數為Ctotal，設置高負載閾值為Loadmax，低負載閾值為Loadmin。

節點分配及回收策略如下：

(2)新增數據源接口采集任務時，根據采集類型將任務分配到相應節點集群，并根據動態負載均衡策略(見2.4節)確定承接任務的運行節點。當一個判斷周期中某個節點集群中出現節點負載超過負載閾值Loadmax并持續超過TimeD時，則分配一個新節點進入相應集群中。

(3)當集群節點數量到達控制值(Sctrl、Hctrl、Kctrl，為相應初始值的200%)后，則只有當集群中50%的節點負載超過負載閾值Loadmax后才分配新節點。

(4)當集群節點數量超過控制值(Sctrl、Hctrl、Kctrl)，且一個判斷周期中集群內所有節點負載都不超過負載閾值Loadmax，同時最小負載節點負載小于80%Loadmax時，則對最小負載節點打上退出標識，不再對其分配任務，等已有的任務執行完畢后退出集群。

(5)當集群節點數量小于等于控制值(Sctrl、Hctrl、Kctrl)，且一個判斷周期中集群內所有節點負載都不超過負載閾值Loadmax，同時最小負載節點負載小于50%Loadmax時，則對最小負載節點打上退出標識，不再分配任務，等已有的任務執行完畢后退出集群。

(6)為避免節點回收速度過快，一個判斷周期內同一集群只會有一個輕載節點退出，集群節點數量不會小于初始值(Smin、Hmin、Kmin)。

2.4 動態負載均衡策略

現有的負載均衡算法主要分為靜態和動態兩類。靜態負載均衡算法以固定的概率分配任務，不考慮服務器的狀態信息。動態負載均衡算法以服務器的實時負載狀態信息來決定任務的分配。

靜態算法實現較為簡單且資源消耗較小，但不能根據系統的實際運行情況進行調整，為了更大程度地保證系統運行的靈活性與平穩性，本文采用了一種動態負載均衡算法，結合權重及負載計算的最小活躍數算法[12]。

最小活躍數算法會根據系統的實際情況進行分發，能夠靈活檢測出集群中各個節點的狀態，自動尋找并調用活躍度最低的節點處理請求。每個服務都有對應的活躍數，初始情況下，所有服務的活躍數均為0。每進來一個請求，都把它分發給活躍數最低的服務，服務每收到一個請求，活躍數加1，完成請求后則將活躍數減1。在服務運行一段時間后，性能好的服務處理請求的速度更快，因此活躍數下降得也越快，此時這樣的服務能夠優先獲取到新的請求，這就是最小活躍數負載均衡算法的基本思想。

但是在典型的最小活躍數算法中，如果一臺節點存在故障，導致它自身處理的請求數比較少，那么它會遭受最大的訪問壓力，這顯然是并不合理的。因此本文對其進行了改進，加入了權重值和負載值兩個參數，能夠更好地選擇合適節點。

設節點i的權重為Wi，當前判斷周期內的負載為Loadi，當前真實活躍數為Ni。則改進后的活躍數N′i如式(2)所示：

N′i=(e[Loadi/K]+Ni)/Wi

(2)

其中K為負載檔位系數，其與具體節點性能和平均任務消耗有關，本文取K=0.1。

具體策略的執行步驟如下：

(1)先從狀態共享機中獲取該集群所有的節點實例狀態，計算改進后的活躍數N′i，然后找出活躍數最小的節點。

(2)如果只有一個，那么則直接選中對應的實例節點處理本次請求。

(3)如果存在多個，則根據當前判斷周期內的負載為Loadi進行比較，選中負載較小的節點。

(4)如果Loadi也相同，那么則選擇i較小的節點提供服務。

3 實驗與分析

3.1 實驗環境

出于方便性考慮，本文采用云環境來進行模擬實驗。共準備130臺云主機，所有節點都是2核8 GB內存，100 GB SSD，2 Gb/s內網帶寬。其中30臺作為采集集群，100臺作為數據源集群。

數據源集群中僅提供單一SFTP、HTTPS、Kafka數據的節點各15臺，同時提供兩類數據的節點各10臺，同時提供三類數據的節點25臺，以模擬復雜的數據采集條件。

采集集群則分兩次分別模擬使用本文方法的正常環境和使用傳統方法的對照環境。由于使用云主機，必要時兩套環境可以使用快照方式進行快速切換部署。

對照環境中SFTP、HTTPS、Kafka采集集群均衡分布，分別為10：10：10，其中任選兩臺同時作為主備任務分配節點。

正常環境中SFTP、HTTPS、Kafka集群的初始節點分別為3臺、4臺、3臺。剩下節點放入空閑節點池。

本實驗正常環境中各集群負載計算的可變系數R1～R5設置如表1所示。

表1 可變系數初始化

負載閾值設置：Loadmax=95%，Loadmin=50%；節點數量設置：Smin=3，Hmin=4，Kmin=3，Sctrl=6，Hctrl=8，Kctrl=6；高負載持續時間TimeD=10 min。

3.2 測試及結果分析

測試時不斷增加采集并發連接數，但三類數據源并發連接數增長速度不同，分析使用本文接入方法的系統運行情況與傳統采用最小連接數算法、加權輪詢算法的系統運行情況，對比平均響應時間及單位時間所接受的有效數據總量。

為了模擬真實采集情況，測試場景中數據并發連接數不是純線性增長，單個連接可能在完成了設定隨機傳輸總數據量后結束，也可能是達到某個傳輸時間后結束。但整體增長比例事先約定，最終達到10 000并發連接總數。每個場景有3輪測試，每輪測試持續時間12 h，SFTP、HTTPS、Kafka數據源并發連接數增長比例分別為1∶1∶1，3∶1∶1，1∶2∶4。為了避免單個數據連接占用大量帶寬，在發送端采用了一些限速手段，使單數據連接速度最大不超過10 Mb/s。

圖3～圖5分別是以上不同增長比例條件下三種場景的平均響應時間。平均響應時間越短說明了負載均衡越有效。

圖3 數據源連接增長比例1：1：1下三種場景平均響應時間

圖4 數據源連接增長比例3：1：1下三種場景平均響應時間

圖5 數據源連接增長比例1：2：4下三種場景平均響應時間

圖6～圖8分別是以上不同增長比例條件下三種場景的單位時間接收的有效數據總量。數據總量為整個采集集群1 min內接收的3類不同數據累加所得。

圖6 數據源連接增長比例1：1：1下三種場景接收有效數據總量

由圖7、圖8可見，在連接數超過4 000之后，本文方法逐漸占優；但超過8 000后，傳統方法有效接收數據總量曲線又向本文方法曲線靠攏，這是因為本測試環境中在大連接數條件下所有采集節點網絡吞吐量基本已趨近物理接口上限。

圖7 數據源連接增長比例3：1：1下三種場景接收有效數據總量

圖8 數據源連接增長比例1：2：4下三種場景接收有效數據總量

從以上結果可以看出，輕載時本文方法與傳統方法性能接近。重載時，若傳統方法中預分配的節點池比例和數據源實際情況比較接近，則本文方法與傳統方法差距很小；若傳統方法中預分配的節點池比例和數據源相差較大，則本文方法具備明顯優勢，平均響應時間較小，而單位時間接收數據量更大。

最終可以得出如下結論：除非能正確預判各類數據源比例并根據此比例來設定采集節點，否則在海量異構數據源采集中本文方法比傳統方法具有更大優勢。

4 方法分析

本文方法根據實際場景設計相關策略、算法及機制，相對于業界常用方法具有較大優勢。

節點負載計算的目的是準確判斷節點負荷，是節點精確調度的基礎。業內常用的方式有直接使用單一指標的做法，比如直接調用CPU負載值，這樣雖然比較簡單直觀，但不能完全反映節點負荷情況，因為很多情況下雖然CPU負載低但可能網絡負載、硬盤負載較高，實際上節點無力承受更多任務。業內也存在使用加權乘法組合多指標的做法，但是這種方式適用于多個指標間互相關聯度高的場景，本文中采用CPU資源、內存資源、當前進程數、響應時間等評價參數，各參數相互獨立，具備互補性，故采用加權和法公式，并根據節點具體用途設置權重，從而精確判斷負載情況。

傳統方法中的任務分配機制一般采用主從分配節點方式，正常情況下由主用節點負責任務分配，主用節點失效后轉由備用節點負責。此方式缺陷，一是主用節點在任務繁重時會比較重載，可能超過設備極限；二是主備節點切換時存在切換失效的可能，從而造成主備雙活情況，這時主備節點中的任務狀態不同步可能導致整個機制崩潰。本文中采用去中心化的任務分配方式，任意節點都可進行任務分配，通過狀態共享機進行同步，整個系統具備良好的擴展性和健壯性。

傳統方法中的節點池很多采用預分配方式，此時節點不能在各池中調度，無法高效率對硬件資源進行利用，可能存在相當大比例的資源浪費情況。本文中根據閾值動態分配及回收節點到不同集群中，運行效率更高也更靈活。

業界方法很多采用靜態負載均衡策略，如輪詢及根據硬件配置采用加權輪詢方式，此種方式雖然實現較為簡單，但由于未考慮節點的狀態信息，可能導致將任務分配給重載或失效節點的情況。業界方法中也有根據單一指標反饋進行動態負載均衡的策略，如最少連接數、最快響應速度、最小活躍數等策略，但單一指標并不能完整反映節點實際情況，存在分配錯誤的可能。本文中采用了結合權重及負載計算的最小活躍數算法，通過多個維度全方面考察節點實時負載，最大程度地保證了負載均衡的準確性。

5 結論

本文針對海量異構數據接入的挑戰和現有解決方法的缺陷，提出了一種基于動態均衡技術的海量異構數據高并發可靠接入方法。文中詳細介紹了該方法的體系結構和實現細節，包括節點負載計算方法、任務分配機制、分配與回收策略和動態負載均衡策略等。該技術具有重要的實際應用價值，特別是在大數據領域中，能夠更好地應對海量異構數據的高并發訪問需求，并提高數據接入的可靠性和效率。