本發(fā)明涉及通信領域，尤其涉及一種基于同向流的調(diào)度方法和一種服務器。

背景技術：

不同于傳統(tǒng)的流抽象,coflow(同向流)捕捉在連續(xù)的計算階段中兩組機器之間的網(wǎng)絡流的集合,其中通信階段在所有流都完成后才結束。同向流(coflow)也可以簡單定義為由同一個計算任務產(chǎn)生的網(wǎng)絡流量。越來越多的文獻證明利用使用同向流(coflow)的應用級別需求可以顯著改善并行數(shù)據(jù)集群中應用級別的通信效果。

同向流的注解或者識別不能保證100％的準確度，同向流的注解/識別過程有時會錯誤地將一個網(wǎng)絡流應該屬于的同向流識別為另一個同向流。而現(xiàn)有的同向流調(diào)度算法對這種錯誤又都是極其敏感的。一旦出現(xiàn)錯誤就會造成嚴重的影響。一個被錯誤歸類的網(wǎng)絡流可明顯地影響其父親同向流的CCT(Coflow Completion Time，同向流完成時間)。

為了評估由于識別錯誤而造成的影響，可以根據(jù)調(diào)度時間將所述被錯誤識別的網(wǎng)絡流分為兩類。

第一類稱為先驅(qū)者(pioneers)，指那些由于錯誤識別而造成其調(diào)度時間早于其父親同向流的網(wǎng)絡流。

第二類稱為掉隊者(stragglers)，指那些由于錯誤識別而造成其調(diào)度時間晚于其父親同向流的網(wǎng)絡流。

這兩類網(wǎng)絡流對平均CCT(Coflow Completion Time，同向流完成時間)的影響是不同的。參見圖1，兩個一樣的同向流C₁(顏色較淺)和C₂(顏色較深)，共用同樣的瓶頸鏈路，并且同時到達。每個同向流包含10個相同的網(wǎng)絡流。進一步假設給C₁分配更高級別的優(yōu)先級，每個同向流都需要1個 單位時間才能完成。在沒有識別錯誤的時候，可以得到最優(yōu)CCT為1.5個單位時間。

然而，參見圖1a，一個先驅(qū)者的出現(xiàn)會造成C₁的CCT增加10％，并且平均CCT也會增加3％(平均CCT為1.55個時間單位)。而一個掉隊者的出現(xiàn)造成的影響更大，參見圖1b，幾乎加倍了C₁的CCT，并且導致平均CCT增加33％(平均CCT為2個時間單位)。由此可以得到一個結論：相比于先驅(qū)者，掉隊者對平均CCT的影響更大。

為了更高效地調(diào)度，很多現(xiàn)有的同向流調(diào)度算法都假設預先知道同向流信息。然而，這些算法在出現(xiàn)識別錯誤時都變得非常不高效。

考慮MADD(Minimum-Allocation-for-Desired-Duration,期望持續(xù)時間的最小資源分配)，該最優(yōu)算法用于網(wǎng)絡流大小已知的同向流內(nèi)部的調(diào)度。MADD算法改變一個同向流內(nèi)部各網(wǎng)絡流的速率，令所有網(wǎng)絡流在最長的網(wǎng)絡流完成時完成。由于使用MADD所有網(wǎng)絡流都同時完成，因此一個錯誤識別的網(wǎng)絡流(特別是一個掉隊者)將會嚴重地影響CCT(參見圖1b)。

與上述算法不同，Aalo使用D-CLAS(Discretized Coflow-Aware Least-attained Service,離散化的同向流知曉最少獲得服務)。它將同向流分為具有不同優(yōu)先級的隊列，并按照FIFO(First Input First Output，先入先出)的順序在每個隊列中進行調(diào)度，從而不需要預先知道網(wǎng)絡流的大小就可以減小平均CCT。然而，Aalo在有識別錯誤出現(xiàn)時表現(xiàn)地更加糟糕。這是由于被錯誤識別的網(wǎng)絡流可能會掉入低優(yōu)先級的大同向流中，然后成為一個超級掉隊者，參見圖2。圖2所示并非個例。由于占17％的大同向流產(chǎn)生了99％的網(wǎng)絡流量，于是在占83％的小同向流中的網(wǎng)絡流是很容易被錯誤識別到大同向流中，從而影響性能。

因此我們需要一種具有容錯能力的同向流調(diào)度方法。所述同向流調(diào)度方法要能在有個別識別錯誤時依然保持穩(wěn)健。

技術實現(xiàn)要素：

本發(fā)明實施例所要解決的技術問題在于，提供一種網(wǎng)絡流調(diào)度方法，可以減少掉隊者的數(shù)量。

為了解決上述技術問題，本發(fā)明實施例提供了一種基于同向流的調(diào)度方法，包括:

步驟1：依據(jù)預定條件對各同向流進行擴展獲得相應的擴展同向流，所述擴展同向流中至少有兩個擴展同向流包含相同的網(wǎng)絡流；

步驟3：對所述擴展同向流進行優(yōu)先級排序；

其特征在于，

步驟4：按照排序后的擴展同向流的順序執(zhí)行調(diào)度，其中，包含于多個擴展同向流的網(wǎng)絡流在隨所述多個擴展同向流中優(yōu)先級最高的擴展同向流調(diào)度之后不再隨所述多個擴展同向流中其他的擴展同向流調(diào)度。

進一步地，在步驟1之后還包括：

步驟2：對所述擴展同向流內(nèi)部的各網(wǎng)絡流進行優(yōu)先級排序。

進一步地，所述步驟3進一步包括：按照先入先出算法對所述擴展同向流進行優(yōu)先級排序。

進一步地，所述步驟2進一步包括：按照最小優(yōu)先啟發(fā)法對所述擴展同向流內(nèi)部的各個網(wǎng)絡流進行優(yōu)先級排序。

進一步地，所述最小優(yōu)先啟發(fā)法進一步包括：

在網(wǎng)絡流隊列之間使用多級反饋調(diào)度，對網(wǎng)絡流隊列中的各個網(wǎng)絡流按照最大-最小公平的策略分配帶寬。

相應地，本發(fā)明還提供一種服務器，所述服務器包括:

擴展模塊，用于依據(jù)預定條件對各同向流進行擴展，獲得相應的擴展同向流，所述擴展同向流中至少有兩個擴展同向流包含相同的網(wǎng)絡流；

排序模塊，用于對所述擴展同向流進行優(yōu)先級排序；

執(zhí)行模塊，用于按照排序后的擴展同向流的順序執(zhí)行調(diào)度，其中，包含于多個擴展同向流的網(wǎng)絡流在隨所述多個擴展同向流中優(yōu)先級最高的擴展同向流調(diào)度之后不再隨所述多個擴展同向流中其他的擴展同向流調(diào)度。

進一步地，所述排序模塊還用于在對各擴展同向流進行優(yōu)先級排序之前對所述擴展同向流內(nèi)部的各網(wǎng)絡流進行優(yōu)先級排序。

進一步地，所述排序模塊按照先入先出算法對所述擴展同向流進行排序。

進一步地，所述排序模塊按照最小優(yōu)先啟發(fā)法對所述擴展同向流內(nèi)部的各個網(wǎng)絡流進行優(yōu)先級排序。

進一步地，所述排序模塊在網(wǎng)絡流隊列之間使用多級反饋隊列調(diào)度，對網(wǎng)絡流隊列中的各個網(wǎng)絡流按照最大-最小公平的策略分配帶寬。

實施本發(fā)明實施例，具有如下有益效果：

(1)減少掉隊者的數(shù)量；

(2)不需要先驗知識；

(3)改善CCT。

附圖說明

圖1(a)是由于先驅(qū)者而造成的影響的示意圖；

圖1(b)是由于掉隊者而造成的影響的示意圖；

圖2是現(xiàn)有技術Aalo在發(fā)生識別錯誤時的示意圖；

圖3是本發(fā)明調(diào)度方法的一個實施例的示意圖；

圖4是本發(fā)明調(diào)度方法的另一個實施例的示意圖；

圖5是本發(fā)明服務器的一個實施例的示意圖；

圖6是位于多個同向流之間的網(wǎng)絡流容易被錯誤識別的示意圖；

圖7(a)是本發(fā)明后期綁定策略的示意圖；

圖7(b)是本發(fā)明同向流內(nèi)部優(yōu)先級排序策略的示意圖；

圖8是工作負載的一些與時間相關的特征的示意圖；

圖9是本發(fā)明與每流平均共享、Aalo算法在CCT和JCT方面的比較示意圖；

圖10(a)是有關本發(fā)明伸縮性的仿真結果示意圖；

圖10(b)是有關協(xié)調(diào)周期的影響的仿真結果示意圖；

圖11(a)是有關本發(fā)明在正常工作負載下的標準化CCT的仿真示意圖；

圖11(b)是有關本發(fā)明在正常工作負載下的CCT分布仿真示意圖；

圖12(a)是有關本發(fā)明在成批到達場景下的仿真示意圖(Hadoop)；

圖12(b)是有關本發(fā)明在展開到達場景下的仿真示意圖；

圖13(a)是有關本發(fā)明在成批到達場景下的效果的仿真示意圖；

圖13(b)是有關本發(fā)明在展開到達場景下的效果的仿真示意圖；

圖14是有關本發(fā)明后期綁定策略在展開到達場景下的效果的仿真示意圖；

圖15(a)是有關本發(fā)明同向流內(nèi)部優(yōu)先級排序在成批到達場景下的效果的仿真示意圖(Hadoop)；

圖15(b)是有關本發(fā)明同向流內(nèi)部優(yōu)先級排序在展開到達場景下的效果的仿真示意圖；

圖16是本發(fā)明另一實施例的軟件框架示意圖。

具體實施方式

為使本發(fā)明的目的、技術方案和優(yōu)點更加清楚，下面將結合附圖對本發(fā)明作進一步地詳細描述。

如圖3所示，為本發(fā)明一個實施例。在該實施例中，本發(fā)明一種基于網(wǎng)絡流的調(diào)度方法包括：

S1：依據(jù)預定條件對各同向流進行擴展獲得相應的擴展同向流，所述擴展同向流中至少有兩個擴展同向流包含相同的網(wǎng)絡流；

S3：對所述擴展同向流進行優(yōu)先級排序；

S4：按照排序后的擴展同向流的順序執(zhí)行調(diào)度，其中，包含于多個擴展同向流的網(wǎng)絡流在隨所述多個擴展同向流中優(yōu)先級最高的擴展同向流調(diào)度之后不再隨所述多個擴展同向流中其他的擴展同向流調(diào)度。

正如之前所討論的，一個具有容錯能力的調(diào)度方法的關鍵點在于避免掉隊者。為了減少掉隊者的數(shù)量，本發(fā)明采取后期綁定的策略。舉例來說，假如有一個網(wǎng)絡流它即可以被分為同向流C₁也可以被分為同向流C₂，換句話說，所述網(wǎng)絡流是聚類過程中處于C₁和C₂的邊界處(參考圖6)。此時本發(fā)明不是強制為所述網(wǎng)絡流指定C₁或C₂中的一個，而是暫時先不做出決定，直到真的要調(diào)度時，再將所述網(wǎng)絡流分配給C₁和C₂中優(yōu)先級高的同向流。這樣的話，無論所述網(wǎng)絡流是屬于C₁還是C₂都不會成為一個掉隊者。

這樣做會造成兩點影響。首先，最壞的情況下，也就是說初始的分類是正確的，那么這么做會引進了一個先驅(qū)者。其次，如果初始的分類是錯的，那么這么做可以有效地阻止一個網(wǎng)絡流成為掉隊者。為了不讓所有的網(wǎng)絡流都成為先驅(qū)者，本發(fā)明只處理那些處于兩個同向流之間的網(wǎng)絡流。

參考圖2和圖7a，不是生成C₁的掉隊者，而是引入C₂的先驅(qū)者，從而減小了平均CCT。通過本申請后面段落的介紹可以知道通過后期綁定本發(fā)明可以在有識別錯誤的情況下依舊改善CCT至少10％，降低由于識別錯誤導致的減速至少30％。

總之，本發(fā)明實施例通過將一個網(wǎng)絡流分配給多個擴展同向流，再在調(diào)度過程中使所述分配至多個擴展同向流的網(wǎng)絡流僅隨優(yōu)先級最高的擴展同向流調(diào)度，可以在不需要先驗知識的情況下有效減少掉隊者的數(shù)量，從而減小平均CCT。

如圖4所示，在本發(fā)明的另一個實施例中，步驟S1之后,步驟S3之前,還包括步驟S2：對所述擴展同向流內(nèi)部的各網(wǎng)絡流進行優(yōu)先級排序。

即便是實施了后期綁定，也還是難免有些網(wǎng)絡流被錯誤的識別。一個更棘手的情況發(fā)生在C₁和C₂被聚類成一個同向流時?，F(xiàn)有技術MADD或者每網(wǎng)絡流公平共享，都是將網(wǎng)絡流伸長直至整個同向流的末端。然而，如果將每個同向流中的網(wǎng)絡流按優(yōu)先級排序，那么被錯誤識別的網(wǎng)絡流就更有可能早些完成。這樣可以減小由于錯誤識別而造成的影響。例如，在圖1b中，如果我們對C₁中的網(wǎng)絡流進行優(yōu)先級排序，則期望的平均CCT將從2變?yōu)?.75個時間單位。這里，由于C₁掉隊者被調(diào)度的時刻并不知道，因此C₁的CCT應該是介于1和2個時間單位的一個值，因此我們說期望的平均CCT為1.75個時間單位。

正如我們上面討論過的，同向流內(nèi)部優(yōu)先級排序在有識別錯誤的情況下能夠有效地減少由于識別錯誤而造成的影響。

考慮到這一點，本發(fā)明在不知道任何先驗知識的情況下依據(jù)已經(jīng)發(fā)送的字節(jié)數(shù)對擴展同向流內(nèi)部的每個網(wǎng)絡流進行優(yōu)先級排序。這個對小同向流中的網(wǎng)絡流掉入大的同向流中成為掉隊者的情況很有效。并且大多數(shù)的情況下普遍存在的都是小同向流，因此前述小同向流中的網(wǎng)絡流掉入大的 同向流中成為掉隊者的情況也是經(jīng)常發(fā)生的。參考圖2和圖7b，圖2中C₁(Q1中淺色)的掉隊者(Q3中淺色)需要持續(xù)和C₂(Q3中深色)的網(wǎng)絡流一樣長的時間，而圖7b中卻可以因為其本身的大小比較小而可以提早很多就完成。

這樣的策略在相反的情況下也是有效的。即，當來自大同向流C₂中的一個網(wǎng)絡流加入到一個小同向流C₁成為先驅(qū)者時。由于小的網(wǎng)絡流更受到優(yōu)待，因此C₁的網(wǎng)絡流更可能比來自C₂的先驅(qū)者提早完成。

總之，本發(fā)明實施例通過對所述擴展同向流內(nèi)部的各網(wǎng)絡流進行優(yōu)先級排序可以在有識別錯誤的情況發(fā)生時進一步減少CCT。通過本申請后面段落有關仿真部分的介紹可以知道通過同向流內(nèi)部優(yōu)先級排序可以在低識別準確度時為小同向流帶來高達40％的提速。

下面將用偽代碼的形式對本發(fā)明實施例進行描述。

其中，CoflowExtention(.)為每個識別的同向流生成一個擴展同向流所述擴展同向流是通過將所述同向流的邊界向外擴展直徑d的距離而得到的(參見偽代碼第4行)。這就是說，C*進一步包括距離C小于d的所有網(wǎng)絡流。需要注意的是，經(jīng)過此步驟之后，一個網(wǎng)絡流可能同時屬于兩個或者更多的擴展同向流。之后，所述屬于多個擴展同向流的網(wǎng)絡流會在它首次被調(diào)度時綁定至一個優(yōu)先級最高的擴展同向流。

InterCoflow(.)利用D-CLAS對各個擴展同向流進行優(yōu)先級排序。具體地講，就是自動將擴展同向流安排到不同的隊列Q^C中，對各擴展同向流隊列流進行優(yōu)先級排序(參見偽代碼第9行)。本實施例中使用FIFO對各擴展同向流進行排序(參見偽代碼第10行)，所述擴展同向流將會保持運行直到其任務完成或者隊列滿了。使用FIFO可以減少同一個隊列中擴展同向流之間的交錯，從而減小CCT。

IntraCoflow(.)使用最小優(yōu)先啟發(fā)法(smallest-first heuristic)來對一個擴展同向流內(nèi)部的各個網(wǎng)絡流進行優(yōu)先級排序。具體地，本發(fā)明用具有指數(shù)增長的閾值對網(wǎng)絡流隊列Q^F實施MLFQ(multi-level feedback queue scheduling,多級反饋隊列調(diào)度)。這樣的策略可以在沒有先驗知識的條件下令小的網(wǎng)絡流具有比大的網(wǎng)絡流更高的優(yōu)先級。對于每個網(wǎng)絡流隊列中的各個網(wǎng)絡流采用最大-最小公平(max-min fairness)分配帶寬。(參見偽代碼第18行)。

直徑d反映了掉隊者和先驅(qū)者之間的平衡。能夠獲得最優(yōu)平均CCT的直徑d跟同向流的識別半徑∈密切相關，并且根據(jù)網(wǎng)絡中流量分布的不同而變化。毫無疑問的是，極端的d值(例如，無窮大)肯定會得到一個差的CCT。然而，如前面提到的，掉隊者造成的影響要遠大于先驅(qū)者。因此，一個大的d值將有益于后期綁定。

此外，本發(fā)明實施例還提供一種服務器。如圖5所示，所示服務器包括擴展模塊、排序模塊和執(zhí)行模塊。所述擴展模塊用于依據(jù)預定條件對各同向流進行擴展，獲得相應的擴展同向流，所述擴展同向流中至少有兩個擴展同向流包含相同的網(wǎng)絡流。所述排序模塊用于對所述擴展同向流進行 優(yōu)先級排序。所述執(zhí)行模塊用于按照排序后的擴展同向流的順序執(zhí)行調(diào)度，其中，包含于多個擴展同向流的網(wǎng)絡流在隨所述多個擴展同向流中優(yōu)先級最高的擴展同向流調(diào)度之后不再隨所述多個擴展同向流中其他的擴展同向流調(diào)度。

進一步的，在另一個實施例中，所述排序模塊還用于在對各擴展同向流進行優(yōu)先級排序之前對擴展同向流內(nèi)部的各網(wǎng)絡流進行優(yōu)先級排序。

進一步地，所述排序模塊按照先入先出算法對所述擴展同向流進行排序。

進一步地，所述排序模塊按照最小優(yōu)先啟發(fā)法對所述擴展同向流內(nèi)部的各個網(wǎng)絡流進行優(yōu)先級排序。

進一步地，所述排序模塊在網(wǎng)絡流隊列之間使用多級反饋隊列調(diào)度，對網(wǎng)絡流隊列中的各個網(wǎng)絡流按照最大-最小公平的策略分配帶寬。

前述實施例提供了一種基于同向流信息的調(diào)度方法,要實現(xiàn)所述調(diào)度方法,首先需要實現(xiàn)對所述同向流信息的采集。然而現(xiàn)有的基于同向流的解決方案都需要對應用進行改動才能提取同向流，而這在很多實際的情境下無法使用。為此本發(fā)明對現(xiàn)有軟件框架進行了改造，造后的軟件框架不再需要對應用進行改動就可以采集同向流信息以供使用。

在現(xiàn)有技術中，客戶機和服務機之間通過遠程過程調(diào)用(Remote Procedure Call，RPC)進行數(shù)據(jù)交換。參與遠程過程調(diào)用(RPC)的軟件框架至少包括應用、分布式計算框架和Java虛擬機。所述應用調(diào)用所述分布式計算框架發(fā)送RPC消息，但所述RPC消息中不包含同向流信息。所述應用和所述分布式計算框架都通過所述Java虛擬機進行編譯。所述分布式計算框架可以是Apache Hadoop或者Apache Spark等。所述分布式計算框架進一步可以包括Netty框架等用于RPC發(fā)送的子框架。此時，所述應用通過所述分布式計算框架中的Netty框架發(fā)送RPC消息。一個RPC消息通過一個TCP鏈接進行發(fā)送，一個TCP鏈接對應一個網(wǎng)絡流，一個或多個網(wǎng)絡流構成一個同向流，一個應用對應一個Java虛擬機。

本發(fā)明的一個實施例中對現(xiàn)有技術中的軟件框架做出的改造如下：

步驟A1，修改所述分布式計算框架，修改后的分布式計算框架在發(fā)送 RPC消息時將所述RPC消息所屬同向流的同向流信息加入所述RPC消息中。

步驟A2，通過java字節(jié)碼插裝機制在所述Java虛擬機中增加一個解析模塊，所述解析模塊在所述Java虛擬機啟動時加載，所述解析模塊在RPC消息發(fā)送前解析所述RPC消息并獲取所述同向流信息。

具體的，在Hadoop框架下，我們可以簡單的認為屬于一個job ID的RPC消息屬于同一個同向流。因此，在本發(fā)明的一個實施例中，修改后的分布式計算框架，或者更具體的，修改后的Netty框架在發(fā)送RPC消息時將job ID加入RPC消息的消息格式中。

由于RPC消息通常在進入網(wǎng)絡級之前就被序列化成字節(jié)流，因此需要進一步增加所述模塊來解析所述RPC消息，從而獲取所述同向流信息。

Java字節(jié)碼插裝機制指的是在Java字節(jié)碼生成之后，對其進行修改，增強其功能。這種做法相當于對應用程序的二進制修改。該方法能夠在不修改源代碼的前提下在類中加入新的成員、變量的聲明、初始化；在代碼的特定位置插入新的指令或者修改現(xiàn)有的指令，以及在目標類中插入新的方法。因此，通過使用Java字節(jié)碼插裝機制，就可以在不修改原Java虛擬機源代碼的條件下增加所述解析模塊。

至此，本發(fā)明實施例通過修改分布式計算框架和Java虛擬機對用于進行RPC的軟件框架進行改造,改造后的軟件框架不需要應用做出任何修改便可實現(xiàn)對同向流的采集，以供使用。

此外，現(xiàn)在的同向流實現(xiàn)都是在用戶控件模仿阻塞行為的，這可以有效地促使線程讓沒調(diào)度的流進入睡眠。因此，一個CPU線程在任一時間最多只能發(fā)送一個流，不可伸縮。為了讓每個線程能夠服務多個I/O操作，通常的做法是利用操作系統(tǒng)提供的I/O多路復用主數(shù)據(jù)結構(multiplexing primitives)(例如，POSIX中的select和poll，Windows中的IOCP)。Hadoop和Spark對低等級非阻塞I/O使用java.nio。由于很多流行的框架(包括Hadoop和Spark)在Java虛擬機下編譯，因此本發(fā)明實施例提供一種方法可以在支持java.nio的同時在Java虛擬機上支持很多第三方庫。對此，本發(fā)明實施例采用Java字節(jié)碼插裝改變應用在運行時的行為，采集同向流信 息，基于調(diào)度結果攔截I/O操作。在Java虛擬機引導過程中，所述插裝的代理被預加載。在首次I/O操作時，所述代理檢測原始字節(jié)碼的加載，并對其進行更改使其記錄運行中Hadoop和Spark在Shuffle階段中的job ID。用這樣的方法同向流的信息就被采集到了。

Non-blocking I/O(非阻塞輸入輸出)是現(xiàn)代網(wǎng)絡服務器的基礎技術，可以提升網(wǎng)絡服務器同時處理的請求數(shù)量級。但是由于步驟A1中對計算框架做出了改動，使得所述計算框架不能兼容非阻塞輸入輸出(non-blocking I/O)，本發(fā)明的一個實施例通過Java字節(jié)碼插裝機制對Java虛擬機調(diào)用操作系統(tǒng)Non-blocking I/O接口的方法進行改動，使得改動過后的計算機框架能夠兼容操作系統(tǒng)Non-blocking I/O。

以上實施例是對現(xiàn)有軟件框架進行的改造，改造后的軟件框架實現(xiàn)了在不修改應用的條件下獲取同向流信息。接下來的實施例中將介紹如何對現(xiàn)有軟件框架進行進一步地改造，以實現(xiàn)基于所述同向流信息對網(wǎng)絡流的調(diào)度。

首先，所述改造進一步包括步驟：

步驟A3，生成一個代理，所述代理接收各Java虛擬機中的解析模塊發(fā)送的同向流信息，并將所述同向流信息發(fā)送給調(diào)度器，所述代理還在所述調(diào)度器做出調(diào)度決定后執(zhí)行所述調(diào)度決定；

步驟A4，生成所述調(diào)度器，所述調(diào)度器接收所述代理發(fā)送的同向流信息，并基于所述同向流信息做出調(diào)度決定。

由于執(zhí)行調(diào)度決定實際上是對發(fā)送RPC消息的TCP連接進行流量控制或者是優(yōu)先級控制的過程。因此，實施調(diào)度決定需要知道哪一個TCP鏈接負責發(fā)送哪個RPC消息。為了將所述RPC消息與發(fā)送所述RPC消息的TCP鏈接關聯(lián)起來，本發(fā)明一實施例在前述步驟A2中進一步地令所述解析模塊在獲取所述同向流信息的同時還記錄所述RPC消息對應的TCP鏈接，并將所述TCP鏈接的信息一并發(fā)送給所述代理。所述代理在獲得TCP連接的信息之后，就可以依據(jù)所述調(diào)度器做出的調(diào)度決定對相應的TCP鏈接進行流量控制了。

更具體的，在一個實施例中，所述軟件框架運行在Linux操作系統(tǒng)上， 所述代理使用Linux下的tc模塊，并使用兩層分層令牌桶(HTB,Hierarchical Token Bucket)對所述TCP鏈接進行流量控制。葉節(jié)點執(zhí)行每流速率，根節(jié)點將外出包歸類至對應的葉節(jié)點。

在進行了如上A1-A4步驟改造之后的軟件框架的基礎之上，本發(fā)明實施例提供了一種處理RPC通信中同向流信息的方法。所述方法包括：

步驟B1，所述應用通過所述分布式計算框架發(fā)送RPC消息，所述RPC消息包含所述RPC消息所屬同向流的信息；

步驟B2，所述Java虛擬機在發(fā)送所述RPC消息前通過解析所述RPC消息獲取所述同向流信息；

步驟B3，所述Java虛擬機將所述同向流信息發(fā)送給所述代理；

步驟B4，所述代理接收各Java虛擬機發(fā)送的同向流信息，并將所述同向流信息發(fā)送給所述調(diào)度器；

步驟B5，所述調(diào)度器基于所述同向流信息做出調(diào)度決定，并將所述調(diào)度決定發(fā)送給所述代理；

步驟B6，所述代理執(zhí)行所述調(diào)度決定。

其中，所述分布式計算框架是Apache Hadoop或者Apache Spark，所述分布式計算框架包括經(jīng)過修改的Netty框架，所述經(jīng)過修改的Netty框架發(fā)送的RPC消息的消息格式中包含用于描述所述RPC消息所屬同向流的項。

所述Java虛擬機中包含一個通過Java字節(jié)碼插裝機制增加的解析模塊，所述解析模塊在Java虛擬機啟動時被加載，所述解析模塊用于實現(xiàn)步驟B2中所述在發(fā)送所述RPC消息前通過解析所述RPC消息獲取所述同向流信息。

在一個具體的實施例中，所述解析模塊在獲取所述同向流的同時還記錄所述RPC消息對應的TCP鏈接，并將所述TCP鏈接的信息一并發(fā)送給所述代理；此時所述步驟B6具體包括：所述代理依據(jù)所述調(diào)度器做出的調(diào)度決定對相應的TCP鏈接進行流量控制。

進一步的，所述軟件框架還Linux操作系統(tǒng)，所述代理使用Linux下的tc模塊并使用分層令牌桶進行流量控制。

執(zhí)行上述步驟B1和步驟B2，可以在不需要應用做出任何改動的條件 下獲取同向流信息。進一步執(zhí)行上述步驟B3至步驟B6可以在不需要應用做出任何改動的條件下，基于所述同向流信息對所述同向流所包含的網(wǎng)絡流進行調(diào)度。

相應地，本發(fā)明實施例還提供一種服務器，所述服務器上建有軟件框架，如圖16所示。所述軟件框架包括應用、分布式計算框架，Java虛擬機，所述應用發(fā)送的RPC消息中包含所述RPC消息所屬同向流的信息，所述Java虛擬機在發(fā)送所述RPC消息前通過解析所述RPC消息獲取所述同向流信息。

其中，所述分布式計算框架是Apache Hadoop或者Apache Spark，所述分布式計算框架包括RPC子模塊，通過所述RPC子模塊發(fā)送的RPC消息的消息格式中包含用于描述所述RPC消息所屬同向流的項。所述RPC子模塊可以是經(jīng)過修改的Netty框架。

所述Java虛擬機中包含一個通過Java字節(jié)碼插裝機制增加的解析模塊，所述解析模塊在Java虛擬機啟動時被加載，所述解析模塊用于實現(xiàn)所述在發(fā)送所述RPC消息前通過解析所述RPC消息獲取所述同向流信息。

進一步地，所述軟件框架還包括代理和調(diào)度器。

所述Java虛擬機中的所述解析模塊向所述代理發(fā)送其獲取的同向流信息；所述代理接收各解析模塊發(fā)送的同向流信息，并將所述同向流信息發(fā)送給調(diào)度器；所述調(diào)度器基于所述同向流信息做出調(diào)度決定，并交由所述代理執(zhí)行所述調(diào)度決定。

進一步地，所述解析模塊在獲取所述同向流信息的同時還記錄用于發(fā)送所述RPC消息的TCP鏈接的信息，并將所述TCP鏈接的信息一并發(fā)送給所述代理。所述代理依據(jù)所述調(diào)度決定對相應的TCP鏈接進行流量控制。

在一個具體的實施例中，所述軟件框架進一步包括Linux操作系統(tǒng)，所述代理使用Linux下的tc模塊并使用分層令牌桶進行流量控制。

使用上述實施例中服務器，可以實現(xiàn)在不修改應用的條件下對同向流信息的采集，并基于所述同向流信息進行調(diào)度。接下來通過仿真實驗對本發(fā)明性能進行評估。評估主要針對以下兩個問題。

首先關于所述代理。

為了測量由所述代理引起的CPU開銷，發(fā)明人在具有8GB內(nèi)存4核Intel E5-1410 2.8GHz CPU的Dell PowerEdge R320服務器的NIC(Network Interface Card，網(wǎng)絡接口卡)上運行一百多條網(wǎng)絡流，使其工作在飽和狀態(tài)下。與不使用代理相比，使用代理僅造成1％的CPU負荷增長，而吞吐量保持不變。也就是說，本發(fā)明只需要犧牲很小的性能就可以擴展很多代理。

其次，關于所述調(diào)度?？偟膩碇v，本發(fā)明在正常工作負載下且超過90％的識別準確度時，能夠?qū)崿F(xiàn)和Aalo相當?shù)腃CT(Aalo需要先驗知識)，同時比每流公平共享(per-flow fair sharing)算法CCT小82.9％。此外，本發(fā)明的容錯設計使CCT提速1.16倍。減少40％由于識別錯誤而引起的減速。后期綁定和同向流內(nèi)部優(yōu)先級排序?qū)Ρ景l(fā)明都是非常重要的。前者可減少10％的CCT，后者對小的同向流可減少40％的CCT。

本發(fā)明的平均CCT及95百分位CCT相比于每流公平共享(per-flow fair sharing)算法的CCT分別減少了58.3％和80.4％，而和需要同向流先驗知識的Aalo相比，本發(fā)明幾乎具有相同的表現(xiàn)。

下面將具體介紹所述實驗和仿真是如何進行的。

首先建立試驗床。所述試驗床由40個連接至Pronto 3295 48-port Gigabit Ethernet switch(48端口、千兆比特、以太網(wǎng)服務器)的服務器。每個服務器都是一個Dell PowerEdge R320并搭載4核Intel E5-1410 2.8GHz CPU，8G內(nèi)存，500G硬盤和Broadcom BCM5719NetXtreme Gigabit Ethernet NIC。每個服務器具有Linux 3.16.0.4內(nèi)核運行Debian 8.2-64bit。實驗利用同樣的計算引擎計算Varys和Aalo。設定坐標間隔Δ＝100ms，并設定∈＝100，d＝150為缺省值。

然后設定仿真器。對于大規(guī)模仿真，所述實驗使用軌跡驅(qū)動網(wǎng)絡流級別仿真器。并用此仿真器運行同向流軌跡詳細的任務級別的重播。它保存任務的輸入輸出比，位置條件，以及兩個工作之間的到達間隔時間，并以1s作為決定間隔。

接著設定工作負載。實驗使用真實工作負載，采集來自3000機器，150機架臉譜網(wǎng)(Facebook)生產(chǎn)集群一小時的Hive/MapReduce軌跡。所述軌跡包含超過500條同向流(7*10⁵個網(wǎng)絡流)。所述同向流的大小(1MB-10TB) 以及一個所述同向流內(nèi)部的網(wǎng)絡流的數(shù)量(1-2*10⁴)遵循重尾分布。圖8示出同向流之間的到達時間分布以及并發(fā)同向流的數(shù)量的分布。實驗中相應地按比例縮小作業(yè)以與設定的最大可能為40Gbps的二分帶寬相匹配，同時還保留所述作業(yè)的通信特點。

然而，所述臉譜網(wǎng)的軌跡并不包含具體的網(wǎng)絡流級別的信息，例如網(wǎng)絡流的起始時間以及端口號等。為了能夠在仿真中進行合理的重演，首先在實驗床中的Spark和Hadoop上運行基準程序(例如，WordCount和PageRank)?；谠囼灤矊W習到的同向流內(nèi)部網(wǎng)絡流的到達時間模式，我們將網(wǎng)絡流的起始時間信息加回臉譜網(wǎng)工作負載中以模仿Spark和Hadoop的網(wǎng)絡流量。

Spark網(wǎng)絡流量：每個同向流內(nèi)部的各個網(wǎng)絡流按照100ms內(nèi)的均勻分布進行生成。

Hadoop網(wǎng)絡流量：每個同向流內(nèi)部的各個網(wǎng)絡流按照1000ms內(nèi)的均勻分布進行生成，實驗還增加平均為100ms的額外指數(shù)延遲。

最后設定度量。為了易于將本發(fā)明的CCT與Aalo(當今最先進的需手動注解同向流的同向流調(diào)度方法)以及每網(wǎng)絡流公平共享(per-flow fair sharing)的CCT進行比較，這里將本發(fā)明的CCT進行標準化。即：

值越小說明性能越好。如果標準化后的值大于(小于)1，則說明本發(fā)明更快(更慢)。

下面介紹試驗床實驗的結果。

圖9顯示與基于TCP的每流公平共享相比，本發(fā)明可以將平均CCT減小58.3％，而將95百分位CCT減小80.4％。相應地，平均作業(yè)完成時間和95百分位作業(yè)完成時間(JCT,Job Completion Time)也分別減少28.5％和60％。還可以看到Aalo標準化后的作業(yè)以及同向流完成時間都接近1，說明本發(fā)明幾乎具有和Aalo一樣的表現(xiàn)。

為了評估本發(fā)明的可伸縮性，試驗床實驗模仿運行了高達40,000個代理。圖10a和圖10b展示了由500個協(xié)調(diào)輪回(coordination round)得出的不同數(shù)量的模仿代理(例如40，000模仿代理指每個機器模仿1000代理)平均完成一個協(xié)調(diào)輪回的時間。在每次實驗中，協(xié)調(diào)器將平均100個并發(fā)同向流的調(diào)度信息轉(zhuǎn)移至每個模仿代理。

與預期的一致，本發(fā)明的伸縮性并不像Aalo的那么好，這是因為本發(fā)明有識別過程，而Aalo并沒有此過程。然而，需要說明的是本發(fā)明的識別加速已經(jīng)具有很大的進步—DBSCAN支持400個代理都需要好幾分鐘。

盡管本發(fā)明可以在6954ms協(xié)調(diào)40,000個代理，然而協(xié)調(diào)周期△(coordination period△)肯定是增長的。為了理解△對性能的影響，我們用越來越高的△再次運行之前的實驗(參見圖10b)。可以觀察到，類似于Aalo，本發(fā)明在△增長時表現(xiàn)的更糟，并在△>100s時性能驟然下降。

下面將重點介紹一下關于調(diào)度的部分。

首先介紹本發(fā)明在正常工作負載下調(diào)度的仿真結果。圖11a示出幾種不同的調(diào)度算法在標準化的CCT方面的表現(xiàn)。顯然本發(fā)明可以有效地容許一些識別錯誤，并且明顯地優(yōu)于每網(wǎng)絡流公平共享。舉例來說，對于Spark網(wǎng)絡流量來說，在95％識別準確度時，本發(fā)明幾乎與Aalo的表現(xiàn)一樣好，同時本發(fā)明明顯優(yōu)于每網(wǎng)絡流公平共享(CCT減少62.9％)。對于Hadoop網(wǎng)絡流量來說，在90％的識別準確度時，本發(fā)明稍稍比Aalo差一點點(CCT長10％)，但還是優(yōu)于每網(wǎng)絡流公平共享(CCT減少56.5％)。為了更直觀地表現(xiàn)，圖11b顯示了本發(fā)明在Spark網(wǎng)絡流量下的CCT的CDF(Cumulative Distribution Function，累積分布函數(shù))，可以看到這也幾乎與Aalo一致。

然后介紹本發(fā)明在兩個具有挑戰(zhàn)性的場景中的仿真結果。所述挑戰(zhàn)性場景一個是指成批到達(batch arrival)，一個是指展開到達(stretched arrival)。在這兩個場景下，本發(fā)明的識別精度不如在正常工作負載下的表現(xiàn)。

圖12a對比了幾種不同的調(diào)度算法在使用Hadoop網(wǎng)絡流量并處于成批到達的場景下的表現(xiàn)?？梢灶A料，在這種場景下有更多的錯誤識別發(fā)生。 相應地，本發(fā)明調(diào)度方法的性能逐漸下降。舉例來說，本發(fā)明在成批到達的場景下與具有正確信息的Aalo相比，性能低(CCT長30％-80％)。

圖12b顯示了幾種不同的調(diào)度算法在展開到達場景下的表現(xiàn)。最后再來驗證如圖13中本發(fā)明的容錯設計的有效性?？梢宰⒁獾?，不具有后期綁定和同向流內(nèi)部優(yōu)先級排序時，本發(fā)明調(diào)度方法與直接使用Aalo相比對含有不準確識別信息的輸入數(shù)據(jù)進行調(diào)度的結果是一樣的。圖13a顯示在成批到達的場景下，本發(fā)明容錯設計總體上可以帶來3-5％的CCT改善。特別的是，本發(fā)明容錯設計可以為小同向流來帶10-20％的CCT改善(圖15a中的后者)。進一步的，由圖13b可知，本發(fā)明在展開到達場景下可以帶來更多的性能提升。此時，本發(fā)明容錯設計給Hadoop和Spark網(wǎng)絡流量可以提供總體為1.16倍、1.14倍的提速?？紤]到本發(fā)明大約比Aalo慢1.3倍(圖12b)，1.16倍提速可以減少由于錯誤識別而造成的影響約40％。

接下來介紹所述后期綁定和所述同向流內(nèi)部優(yōu)先級排序各自獨立的好處。首先后期綁定在展開到達的場景下仍可以帶來不可忽視的改善。無論是對Hadoop還是Spark，改善都超過10％。相對而言，同向流內(nèi)部優(yōu)先級排序帶來的改善會稍微少一些，在展開到達的場景下改善Hadoop 7％，在其他場景下改善1-5％。然而，同向流內(nèi)部優(yōu)先級排序能為小同向流CCT帶來高達40％的改善。

為了理解為什么后期綁定可以有效的改善CCT，圖14a展示了以直徑d對所述識別了的同向流進行擴展之前和擴展之后(即前述的擴展同向流C*)的識別準確度?？梢杂^察到，查全率提升4％，代價是查準率下降4％。高查全率意味著一個同向流中的網(wǎng)絡流有更多的網(wǎng)絡流被成功的劃分在一個組中，也就是說同向流擴展有效地識別了一些掉隊者。這些被識別的掉隊者在他們被綁定至具有最高優(yōu)先權的同向流后就不再是掉隊者了。因此，后期綁定可以有效地減少掉隊者的數(shù)量，從而改善CCT。

在展開到達場景下，所述后期綁定可以帶來明顯地改善。而在展開到達的場景下直徑d是如何對所述后期綁定的效果造成影響呢？從圖14b中可以看到，在開始的時候，標準化的CCT隨著d的增加而改善。這說明更多的掉隊者被成功地識別了，因此減小了相應同向流的CCT。然而，當d 繼續(xù)增加，后期綁定會引入過多的先驅(qū)者，導致更長的CCT。

同向流內(nèi)部的優(yōu)先級排序又是如何有益的呢？為說明這一點，首先依據(jù)同向流的長度和寬度對所述同向流進行分類。具體的，最長的網(wǎng)絡流小于5MB的同向流被認為是短的同向流。寬度不超過50個網(wǎng)絡流的同向流被認為是窄的同向流，則認為。我們發(fā)現(xiàn)超過50％的同向流都是又短又窄的(SN)同向流。然而，由于它們占總網(wǎng)絡流量負載還不到0.1％，因此它們的表現(xiàn)并不能清楚地通過總CCT來表現(xiàn)。圖15a顯示了SN同向流在成批到達時標準化的CCT?？梢钥吹酵蛄鲀?nèi)部的優(yōu)先級排序可以帶來16％的改善。一個可能的原因是當許多同向流成批到達時，本發(fā)明有可能將一些同向流錯誤分類為“超級”同向流。同向流內(nèi)部的優(yōu)先級排序可以有效地加速這些被錯誤分類的同向流中的SN同向流。

圖15b所示為展開到達場景下SN同向流的標準化CCT。展開到達模式容易產(chǎn)生許多掉隊者。而同向流內(nèi)部優(yōu)先級排序可以有效地提升SN同向流中掉隊者的速度高達40％。

近來，同向流抽象越來越多地被人們關注。然而，現(xiàn)有的同向流知曉方案都要求開發(fā)者對應用做出很大的改動，并需要手動對同向流進行注解。本發(fā)明首先提出將對應用透明的同向流識別和具有容錯能力的同向流調(diào)度相結合。

盡管已經(jīng)有很多關于ITC(Internet Traffic Classification,網(wǎng)絡流量分類)的文獻，一些本質(zhì)的差別還是讓它們無法被應用到同向流識別中。首先，一旦父親工作結束，由一個特定同向流捕捉的網(wǎng)絡流相互之間的關系便不再重現(xiàn)。因此，同向流無法被標注成預定的類別。與此相反，在傳統(tǒng)的網(wǎng)絡流量分類中，網(wǎng)絡流量通常對應于穩(wěn)定的類別。其次，時效性對同向流識別是非常重要的，這是因為它的結果要作為調(diào)度的輸入。與此相反，在很多傳統(tǒng)的ITC任務中，遲來的識別也仍是有作用的(例如，入侵檢測)。

還有一個相似的主題，魯邦調(diào)度，已經(jīng)在運籌學中被大量研究。然而，魯邦調(diào)度首要的是處理在預計算調(diào)度過程中的突發(fā)事件。而本發(fā)明具有容錯能力的調(diào)度方法是為了調(diào)度可能具有錯誤輸入的任務。

本發(fā)明可以不需要對應用做任何修改就能夠自動地識別并調(diào)度同向 流。本發(fā)明利用增量式聚類算法以快速運行對應用透明的同向流識別，并通過提出具有容錯能力的同向流調(diào)度算法來減小識別錯誤的可能。試驗床實驗以及軌跡追蹤仿真顯示本發(fā)明在超過90％的識別準確度時,本發(fā)明調(diào)度方法有效地處理剩余的識別錯誤。本發(fā)明的總體表現(xiàn)與Aalo相當，同時明顯優(yōu)于每網(wǎng)絡流公平共享。

總而言之，本發(fā)明不需要手動地在應用中進行注解，因此更加實用。同時本發(fā)明還提供了一些可以研究方向，包括在數(shù)據(jù)密集型工作負載前的識別機制的推廣，為實現(xiàn)更佳的可伸縮性而進行的去中心化，在線參數(shù)調(diào)整，處理同向流相關性，以及將具有容錯能力的調(diào)度算法和分配算法應用至其他領域。

以上所述是本發(fā)明的優(yōu)選實施方式，應當指出，對于本技術領域的普通技術人員來說，在不脫離本發(fā)明原理的前提下，還可以做出若干改進和潤飾，這些改進和潤飾也視為本發(fā)明的保護范圍。