面向流數(shù)據(jù)的分布式時序同步系統(tǒng)的設(shè)計與實現(xiàn)

黃偉健，胡懷湘

面向流數(shù)據(jù)的分布式時序同步系統(tǒng)的設(shè)計與實現(xiàn)

黃偉健，胡懷湘

(華北計算技術(shù)研究所，北京 100083)

針對目前分布式流數(shù)據(jù)管理方案的不足，本文從實際的業(yè)務(wù)需求出發(fā)，結(jié)合雷達流數(shù)據(jù)的單消息體規(guī)模大、消息流壓力大以及流量波動明顯的特征，采用主從式的分布式結(jié)構(gòu)，利用Akka異步通信框架，設(shè)計并實現(xiàn)了一個面向流數(shù)據(jù)的分布式時序同步系統(tǒng)。該系統(tǒng)可擴展性強，容錯性好，同時也是后續(xù)的分布式流數(shù)據(jù)實時計算系統(tǒng)和實時存儲系統(tǒng)能夠正常運行的重要前提。本文首先分析了系統(tǒng)使用的關(guān)鍵技術(shù)，然后結(jié)合實際背景設(shè)計了系統(tǒng)的整體框架，接著從消息類型、數(shù)據(jù)結(jié)構(gòu)和主從節(jié)點的處理流程三個方面詳細剖析了系統(tǒng)的實現(xiàn)細節(jié)，最后通過實驗進一步驗證了系統(tǒng)設(shè)計的可行性。

流數(shù)據(jù)管理；Akka；時序同步；分布式系統(tǒng)

0 引言

近年來，在通信領(lǐng)域、交通領(lǐng)域、金融領(lǐng)域、工業(yè)監(jiān)控領(lǐng)域等領(lǐng)域，出現(xiàn)了一種新的數(shù)據(jù)類型，這類數(shù)據(jù)來自傳感器采集信息、交通監(jiān)控數(shù)據(jù)、實時交通信息等，通常被稱為流數(shù)據(jù)（streaming data）[1]，它們是一組順序、大量、快速、連續(xù)到達的數(shù)據(jù)序列，一般情況下，可被視為一個隨時間延續(xù)而無限增長的動態(tài)數(shù)據(jù)集合。不同類型的流數(shù)據(jù)也具有不同的特征。雷達流數(shù)據(jù)除了具有持續(xù)不斷到達、潛在規(guī)模無限等一般性的流數(shù)據(jù)的特征之外，還具有如下特征：（1）數(shù)據(jù)流有明顯的波峰波谷階段，而且各個階段的界限較為清晰；（2）單個消息體的大小一般為10MB左右，每一批次的數(shù)據(jù)流包含的消息體個數(shù)相對固定；（3）數(shù)據(jù)流分成多路，數(shù)據(jù)到達各個數(shù)據(jù)接入服務(wù)器的時間相差不大。在雷達流數(shù)據(jù)的實際處理場景中，流數(shù)據(jù)經(jīng)過產(chǎn)生、預(yù)處理、時序同步、緩存、實時計算等過程。其中，時序同步的環(huán)節(jié)是順利進行實時計算的重要前提。

本文從實際業(yè)務(wù)需求出發(fā)，針對目前流數(shù)據(jù)管理系統(tǒng)的種種不足[2][3]，結(jié)合雷達流數(shù)據(jù)自身的多個特征，采用主從式分布式架構(gòu)，利用Akka異步通信框架，設(shè)計并實現(xiàn)一個可擴展性強、容錯性好的面向流數(shù)據(jù)的分布式時序同步系統(tǒng)。

1 關(guān)鍵技術(shù)

1.1分布式系統(tǒng)架構(gòu)

目前分布式系統(tǒng)主要有兩種主流的分布式結(jié)構(gòu)：主從結(jié)構(gòu)和P2P對等結(jié)構(gòu)[4]。不同的分布式結(jié)構(gòu)有著不同的特點，在面對不同的場景時設(shè)計的難度和系統(tǒng)的性能有著很大的差距，因此在實際應(yīng)用中需要根據(jù)不同的業(yè)務(wù)需求選擇合適的結(jié)構(gòu)。

主從結(jié)構(gòu)如圖1所示，包含一個主節(jié)點和若干個從節(jié)點。其中主節(jié)點一般扮演著管理者的角色，協(xié)調(diào)管理各個從節(jié)點的信息，并保存系統(tǒng)整體的元數(shù)據(jù)。主從結(jié)構(gòu)的系統(tǒng)設(shè)計較為簡單，有著更強的可控制性，但是主節(jié)點的性能往往會影響整個系統(tǒng)的運行，容易成為系統(tǒng)的瓶頸。采用主從結(jié)構(gòu)的系統(tǒng)有很多，典型例子有：Hadoop[5]，Storm，Spark等。

圖1 分布式系統(tǒng)主從結(jié)構(gòu)圖

P2P對等結(jié)構(gòu)如圖2圖所示，該結(jié)構(gòu)的系統(tǒng)中每個節(jié)點的地位是對等的，所起到的作用也是類似的。這種結(jié)構(gòu)的系統(tǒng)不存在單點故障的問題，但是每個節(jié)點必須向系統(tǒng)中的其他節(jié)點廣播自己的信息，使得每個節(jié)點都知曉系統(tǒng)的整體狀況，這種設(shè)計方案也造成了系統(tǒng)有較大的通信開銷。采用P2P對等結(jié)構(gòu)的系統(tǒng)也很常見，典型例子有：Redis[6]，OceanStore，Past等。

圖2 分布式系統(tǒng)P2P結(jié)構(gòu)圖

1.2并發(fā)處理框架Akka

Akka[7]是一個開發(fā)庫和運行環(huán)境，可以用于構(gòu)建高并發(fā)、分布式、可容錯、事件驅(qū)動的基于JVM的應(yīng)用。

1.2.1 Akka的Actor模型

Actor模型并不是最近才出現(xiàn)的概念，早在上世紀70年代早期，Carl Hewitt就已經(jīng)提出這一模型，目的是為了解決分布式系統(tǒng)中一系列的編程問題[8]。維基百科這樣定義Actor模型——在計算科學(xué)領(lǐng)域，Actor模型是一個并行計算模型，它將Actor作為并行計算的基本元素來對待：為了快速響應(yīng)一個外部發(fā)送來的消息，一個Actor能夠根據(jù)既定的規(guī)則，自己選擇作出某種決策，例如發(fā)送更多的響應(yīng)消息，或創(chuàng)建更多處理邏輯的Actor，或確定以何種方式去響應(yīng)接收到的下一個消息。Actor模型是一種分布式系統(tǒng)中的高級抽象方式，也是Akka系統(tǒng)中最核心的概念，它封裝了狀態(tài)和行為。另外，Actor之間也可以通過交換消息的方式來相互通信。每個Actor都具有自己的Mailbox來接收其他Actor發(fā)送過來的消息。通過Actor的抽象，可以明顯簡化鎖和線程管理的工作，而且可以非常容易地開發(fā)出邏輯復(fù)雜的并發(fā)系統(tǒng)。

1.2.2 Akka Cluster

Akka Cluster提供了一個容錯、去中心化、基于P2P的集群服務(wù)，而且不會出現(xiàn)單點故障問題。Akka基于分布式系統(tǒng)的Gossip協(xié)議[9]，實現(xiàn)集群廣播服務(wù)，而且能夠快速檢測失敗情況。

一個Akka集群由若干個成員節(jié)點組成，其中每個成員節(jié)點的唯一標(biāo)識是hostname:port:uid，同時所有成員節(jié)點之間是完全解耦合的。一個Akka應(yīng)用程序是分布式的，它具有一個Actor的集合S，而且每個節(jié)點可以集合S的一部分Actor，而非全集S。由于Akka集群是基于Gossip協(xié)議實現(xiàn)的，所以如果有一個新的成員節(jié)點準(zhǔn)備加入到原來的Akka集群中，只需要在集群中任意一個成員節(jié)點上執(zhí)行Join命令，集群中其他節(jié)點將會獲知該成員節(jié)點加入的消息。

Akka集群中各個成員節(jié)點之間的狀態(tài)關(guān)系，如圖3所示。

圖3 Akka集群節(jié)點的狀態(tài)關(guān)系圖

基于Gossip協(xié)議收斂過程得到的確定性結(jié)果，Akka集群中任何一個成員節(jié)點都有可能成為集群的Leader，而且這個過程是透明的。Leader僅僅扮演一種臨時的角色。因為在各輪Gossip收斂過程中，Leader是可以變化的，它負責(zé)管理各個成員節(jié)點進入和離開集群。一個成員節(jié)點加入后，開始處在joining狀態(tài)，當(dāng)所有其他節(jié)點因為廣播消息的原因，都看到了該新成員節(jié)點，則Leader會將該節(jié)點的狀態(tài)修改為up。如果一個節(jié)點順利地離開原來的Akka集群，它可以預(yù)先將其自身的狀態(tài)改為leaving。當(dāng)Leader看到該節(jié)點變化為leaving狀態(tài)之后，會將該節(jié)點的狀態(tài)進一步修改為exiting，然后經(jīng)過一段時間，當(dāng)所有其他節(jié)點都已經(jīng)看到該節(jié)點狀態(tài)變?yōu)閑xiting，則Leader將該節(jié)點移出集群，其狀態(tài)被修改為removed。如果一個節(jié)點處在unreachable狀態(tài)，基于Gossip協(xié)議的定義，Leader無論通過任何辦法來執(zhí)行操作，系統(tǒng)都是無法收斂到該節(jié)點的，所以當(dāng)節(jié)點處于unreachable狀態(tài)，它必須被外界執(zhí)行某些操作來進行強制性改變，使其狀態(tài)變成reachable或者down。如果該節(jié)點在離開集群之后，如果想重新加入到原來的Akka集群，必須經(jīng)過重啟并經(jīng)過若干個步驟加入到集群。

2 系統(tǒng)設(shè)計

本文構(gòu)建的面向流數(shù)據(jù)的分布式時序同步系統(tǒng)采用主從結(jié)構(gòu)，不僅能夠很好解決多路流數(shù)據(jù)同步問題，而且具有良好的可擴展性，同時降低了系統(tǒng)的設(shè)計難度。本文設(shè)計的系統(tǒng)整體架構(gòu)如圖4所示。整個系統(tǒng)分為消息控制節(jié)點和數(shù)據(jù)同步節(jié)點，其中消息控制節(jié)點是系統(tǒng)的主節(jié)點，只有一個；數(shù)據(jù)同步節(jié)點是系統(tǒng)的從節(jié)點，也就是系統(tǒng)中的數(shù)據(jù)接入服務(wù)器。其中，主節(jié)點并不處理到來的流數(shù)據(jù)，只負責(zé)保存各個從節(jié)點發(fā)送過來的同步信息，以及根據(jù)數(shù)據(jù)目前的到達情況和是否超時來決定向各個從節(jié)點下達數(shù)據(jù)發(fā)送的命令。各個從節(jié)點負責(zé)接收上游的數(shù)據(jù)，并發(fā)送一批數(shù)據(jù)初次到達服務(wù)器以及一批數(shù)據(jù)完全到達服務(wù)器的消息給系統(tǒng)的主節(jié)點，并根據(jù)主節(jié)點返回的命令做進一步的處理。主節(jié)點與從節(jié)點之間通過消息進行通信交互。同步過后的數(shù)據(jù)經(jīng)過復(fù)制，成為兩份，一份流向?qū)崟r計算系統(tǒng)，另外一份流向持久化存儲系統(tǒng)。

圖4 面向流數(shù)據(jù)的分布式時序同步系統(tǒng)架構(gòu)圖

3 系統(tǒng)實現(xiàn)

3.1消息類型

本系統(tǒng)使用Akka作為分布式組件之間的通信工具。Akka是一個基于Actor模型的異步消息框架，Actor與Actor之間相互獨立，使用隊列的機制收發(fā)消息。本系統(tǒng)可以抽象出4種Actor，這4種Actor分別為：主節(jié)點接消息Actor（MasterMsgActor），主節(jié)點定時Actor（MasterTimerActor），從節(jié)點接數(shù)據(jù)包Actor（SlaveDataActor），從節(jié)點接消息Actor（SlaveMsgActor）。Actor之間的通信是通過Akka封裝的消息來完成，本系統(tǒng)涉及到以下5種消息類型（約定如下：<>中的字段為消息內(nèi)容，ActorA –> ActorB表示消息是從ActorA發(fā)送給ActorB）：

（1）：SlaveDataActor -> MasterMsgActor，從節(jié)點接到新一組數(shù)據(jù)的第一個包，向主節(jié)點發(fā)送消息，記為FIRST。

（2）：SlaveDataActor ->MasterMsg-Actor，從節(jié)點接到新一組數(shù)據(jù)的最后一個包，向主節(jié)點發(fā)送消息，記為LAST。

（3）：MasterMsgActor -> SlaveMsg-Actor，主節(jié)點向所有從節(jié)點下達發(fā)送該組數(shù)據(jù)的SEND命令。

（4）：MasterMsgActor ->MasterTimerActor，主節(jié)點接消息進程決定該組數(shù)據(jù)包休眠指定的SleepTime時間，起到定時效果，記為SLEEP。

（5）：MasterTimerActor -> Master-MsgActor，主節(jié)點定時進程到達休眠時間后，向主節(jié)點的接消息進程發(fā)送該組ID，表示休眠時間已到，記為AWAKE。

3.2數(shù)據(jù)結(jié)構(gòu)

本文構(gòu)建的面向流數(shù)據(jù)的分布式時序同步系統(tǒng)采用典型的主從結(jié)構(gòu)，主節(jié)點和從節(jié)點分別扮演不同的角色。雷達流數(shù)據(jù)只在從節(jié)點進行緩存，而不需要經(jīng)過主節(jié)點。主節(jié)點主要負責(zé)從節(jié)點之間的協(xié)調(diào)與控制。系統(tǒng)中的主節(jié)點與從節(jié)點，分別使用不同的數(shù)據(jù)結(jié)構(gòu)對數(shù)據(jù)和消息進行組織和管理。這種設(shè)計方案達到了“移動計算，不移動數(shù)據(jù)”的目的，大大減少了系統(tǒng)的通信開銷，提高了系統(tǒng)的響應(yīng)速度。

主節(jié)點的數(shù)據(jù)結(jié)構(gòu)為：MasterList（LinkedList< MasterTable>）。MasterList是主節(jié)點維護的鏈表，用于記錄所有從節(jié)點數(shù)據(jù)包到達的情況。其中，每一項是自定義的類MasterTable。MasterTable類中包含以下幾項：

表1 MasterTable詳細定義

從節(jié)點的數(shù)據(jù)結(jié)構(gòu)有兩個：

（1）PackageList（LinkedList）。這是從節(jié)點維護的鏈表，用于記錄到達數(shù)據(jù)的包個數(shù)以及暫時保存流數(shù)據(jù)的部分消息體。其中，每一項元素Package是自定義的類。Package中包含以下幾項：

表2 Package詳細定義

（2）DeletedGroupSet（Set）。這是從節(jié)點維護的集合，集合中的每個元素都是一個GroupID，代表該批次的數(shù)據(jù)已經(jīng)完成同步工作，發(fā)送給下游的實時計算系統(tǒng)或者存儲系統(tǒng)，如果有重復(fù)的數(shù)據(jù)到來，將不作任何處理。

3.3處理流程

本文構(gòu)建的面向流數(shù)據(jù)的分布式時序同步系統(tǒng)分成主節(jié)點和從節(jié)點，兩者有著截然不同的處理邏輯。由于系統(tǒng)的整體框架都是基于Akka的消息驅(qū)動機制建立的，所以當(dāng)主節(jié)點和從節(jié)點接到不同的消息或者數(shù)據(jù)時，將會啟動不同的處理流程。下面分別從主節(jié)點和從節(jié)點兩個角度來闡述系統(tǒng)的處理流程。

3.3.1 主節(jié)點處理流程

第一種情況，主節(jié)點接消息進程接到首次消息FIRST后，處理流程如圖5所示，具體步驟如下：

（1）首先檢查MasterList是否為空。

（2）如果為空，添加GroupID到MasterList，并同時啟動定時進程MasterTimerProc。

（3）否則，遍歷MasterList，如果能找到GroupID，則判斷是否超時。

（4）如果超時，則下達SEND命令給各個從節(jié)點，然后刪除對應(yīng)項。

（5）否則，不執(zhí)行任何動作。

（6）如果遍歷MasterList之后沒有找到相同的GroupID，則添加GroupID進去，并啟動定時進程MasterTimerProc。

圖5 系統(tǒng)主節(jié)點接到FIRST消息

第二種情況，主節(jié)點接消息進程接到完成消息LAST后，處理流程如圖6所示，具體步驟如下：

（1）首先遍歷MasterList，查找傳入的GroupID。

（2）找到以后，判斷是否超時。

（3）如果超時，則下達SEND命令給各個從節(jié)點，然后刪除對應(yīng)項。

（4）否則，更新FinishNum，然后判斷FinishNum是否等于從節(jié)點的個數(shù)。

（5）如果相等，說明各個從節(jié)點的該組數(shù)據(jù)已經(jīng)全部到達，下達SEND命令給各個從節(jié)點，然后刪除對應(yīng)項。

（6）否則，不執(zhí)行任何動作。

圖6 系統(tǒng)主節(jié)點接到LAST消息

第三種情況，主節(jié)點接消息進程接到主節(jié)點定時線程的喚醒消息AWAKE后，處理流程如圖7所示，具體步驟如下：

（1）首先遍歷MasterList，查找傳入的GroupID。

（2）如果能夠找到，則下達SEND命令給各個從節(jié)點，然后刪除對應(yīng)項。

（3）否則，向主節(jié)點定時進程返回MasterList頭部的GroupID以及剩余定時時間。

第四種情況，主節(jié)點定時線程接到主節(jié)點接消息進程的定時消息SLEEP后，處理流程如圖8所示，具體步驟如下：

（1）休眠傳入的定時時間。

（2）立即返回傳入的GroupID。

3.3.2 從節(jié)點處理流程

從節(jié)點不僅接收數(shù)據(jù)，緩存數(shù)據(jù)，還根據(jù)主節(jié)點的反饋信息，執(zhí)行發(fā)放數(shù)據(jù)到實時計算集群和持久化存儲集群的動作。

圖7 系統(tǒng)主節(jié)點接到AWAKE消息

圖8 系統(tǒng)主節(jié)點定時線程接到SLEEP消息

第一種情況，從節(jié)點接到新到達的數(shù)據(jù)newData后，處理流程如圖9所示，具體步驟如下：

（1）首先檢查DeletedGroupSet是否為空或者DeletedGroupSet中是否不含有newData的GroupID，記為條件1。

（2）如果滿足條件1，然后判斷PackageList是否為空，記為條件2。

（3）如果滿足條件2，則添加newData到PackageList，并發(fā)送FIRST消息給主節(jié)點。

（4）然后判斷newData的該組所有個數(shù)totalNum是否為1，記為條件3。

（5）如果滿足條件3，則發(fā)送LAST消息給主節(jié)點。

圖9 系統(tǒng)從節(jié)點接到新數(shù)據(jù)newData

（6）如果不滿足條件2，則遍歷PackageList，查找是否有GroupID等于newData的GroupID，記為條件4。

（7）如果滿足條件4，則在GroupID所在位置插入newData，同時count加一。

（8）然后判斷count是否等于newData的totalNum，記為條件5。

（9）如果滿足條件5，則發(fā)送LAST消息給主節(jié)點。

（10）如果不滿足條件4，則插入newData到PackageList的末尾，并發(fā)送FIRST消息到主節(jié)點。

（11）判斷條件3，如果滿足，轉(zhuǎn)入（5）。

第二種情況，從節(jié)點接到主節(jié)點返回的SEND命令，處理流程如圖10所示，具體步驟如下：

（1）添加GroupID到DeletedGroupSet，標(biāo)記該GroupID已經(jīng)被刪除。

（2）遍歷PackageList，找到GroupID對應(yīng)的該組所有數(shù)據(jù)，發(fā)送到下游的系統(tǒng)。

（3）刪除該組數(shù)據(jù)。

圖10 系統(tǒng)從節(jié)點接到SEND命令

4 實驗驗證

本實驗采用64位的Ubuntu作為服務(wù)器的操作系統(tǒng)，Akka版本為2.4.16。本實驗構(gòu)建了一個面向流數(shù)據(jù)的分布式時序同步系統(tǒng)，共使用11臺服務(wù)器，其中5臺作為數(shù)據(jù)發(fā)射器，5臺作為與數(shù)據(jù)發(fā)射器一對一的數(shù)據(jù)接入服務(wù)器，同時也是時序同步系統(tǒng)的從節(jié)點，另外1臺作為時序同步系統(tǒng)的主節(jié)點。實驗主要針對分布式時序同步系統(tǒng)進行功能測試，驗證在不同的流速下，各個從節(jié)點服務(wù)器之間能否完成同批數(shù)據(jù)的同步操作。測試方式是在流數(shù)據(jù)發(fā)射器分別發(fā)送100 MB/s、200 MB/s、300 MB/s、400 MB/s、500 MB/s的數(shù)據(jù)包，觀察主節(jié)點控制臺顯示的信息。如果每個從節(jié)點服務(wù)器能夠?qū)Φ絹淼拿恳慌鲾?shù)據(jù)成功完成同步操作，主節(jié)點將會及時給各個從節(jié)點發(fā)送命令，將這一批次的數(shù)據(jù)發(fā)送到下游系統(tǒng)，而且該信息將在主節(jié)點的控制臺打印出來。如果同步失敗，主節(jié)點也將打印同步失敗的信息。

圖11顯示的是當(dāng)流數(shù)據(jù)流速為500MB/s時，主節(jié)點控制臺打印出來的信息，從圖中顯示的信息可以看出，時序同步系統(tǒng)的運行結(jié)果正常，達到了預(yù)期的同步效果。其他流速下的結(jié)果也類似，系統(tǒng)同樣運行正常，驗證了系統(tǒng)在時序同步方面的正確性。

圖11 流數(shù)據(jù)流速為500 MB/s時的實驗結(jié)果圖

5 結(jié)論

本文從實際的業(yè)務(wù)背景出發(fā)，結(jié)合雷達流數(shù)據(jù)的具體特征，借鑒當(dāng)前分布式系統(tǒng)的設(shè)計思想，利用Akka作為異步通信工具，設(shè)計并實現(xiàn)了面向流數(shù)據(jù)的時序同步系統(tǒng)。該系統(tǒng)具有可擴展性強、容錯性好的優(yōu)點，不僅可以實現(xiàn)雷達流數(shù)據(jù)的時序同步功能，也可以很好地應(yīng)用到其他流數(shù)據(jù)的管理系統(tǒng)中。

[1] BL Golab, MT ?zsu. Issues in data stream management[J] ACM Sigmod Record, 2003,32(2), 4-14.

[2] 馬凱航, 高永明, 吳止鍰, 李磊. 大數(shù)據(jù)時代數(shù)據(jù)管理技術(shù)研究綜述[J]. 軟件. 2015(10)

[3] 周昭, 林昭文. 基于OpenFlow的數(shù)據(jù)流管控系統(tǒng)的研究與實現(xiàn)[J]. 軟件. 2013(12)

[4] 華镕. 談?wù)劮植际较到y(tǒng)[J]. 軟件. 2007(06)

[5] 陸嘉恒. 分布式系統(tǒng)及云計算概論[M]. 北京: 清華大學(xué)出版社. 2011.

[6] Redis home page: https://redis.io/

[7] Gupta, Munish. Akka essentials. Packt Publishing Ltd, 2012.

[8] Tasharofi S, Dinges P, Johnson R E. Why do scala developers mix the actor model with other concurrency models? [C]. European Conference on Object-Oriented Programming. Springer Berlin Heidelberg, 2013: 302-326.

[9] Fetahi Wuhib, Rolf Stadler, Mike Spreitzer. A gossip protocol for dynamic resource management in large cloud environments. IEEE transactions on network and service management, 2012.

Design and Implementation of the Distributed Timing Synchronization System for Stream Data

HUANG Wei-jian, HU Huai-xiang
(North China Institute of Computing Technology, Beijing 100083, China)

In view of the shortcomings of the current distributed data management scheme, this paper starts from the actual business demand, combines the characteristics of the radar flow: large single message body, large message flow pressure and obvious fluctuation of the traffic flow, takes the master-based distributed structure and Akka, and finally designs and implements a distributed timing synchronization system. The system is highly scalable and fault-tolerant, and it is also an important prerequisite for the subsequent operation of the distributed real-time computing system. This paper first analyzes the key technology used in the system, and then designs the overall framework of the system, and then analyzes the details of the system from three aspects: the message type, the data structure and the processing flow of the master and subordinate nodes. Finally, And the feasibility of the system is verified by the test.

Stream data management; Akka; Timing synchronization; Distributed system

TP391

: A

10.3969/j.issn.1003-6970.2017.02.022

黃偉健，男，碩士研究生，研究方向為大數(shù)據(jù)處理及分布式存儲；胡懷湘，男，研究員級高級工程師，研究方向為計算機網(wǎng)絡(luò)裝備和網(wǎng)絡(luò)存儲技術(shù)。

本文著錄格式：黃偉健，胡懷湘. 面向流數(shù)據(jù)的分布式時序同步系統(tǒng)的設(shè)計與實現(xiàn)[J]. 軟件，2017，38（2）：105-111