本發明涉及分布式實時計算技術領域,特別是涉及消息流量控制方法、裝置及相關系統。
背景技術:
現有數據處理系統大多采用流水線式處理方式,如圖1所示拓撲圖,消息從數據源s發出后,依照各個處理節點之間的邏輯關系逐步向下游流動;處理節點的總個數及每條流水線上的節點個數根據實際數據處理邏輯而定,圖1僅以a、b和c的三個處理節點為例,箭頭表示消息流動方向。
正常情況下,處于上游的數據源或處理節點的消息發送速率應當與相鄰的下游處理節點的消息處理速率相匹配;如果因上游節點出現消息流量高峰和/或下游處理節點的處理能力不夠,導致上游的消息發送速率大于下游的消息處理速率,則會造成大量的消息積壓、處理器壓力增加,甚至導致部分消息因處理超時而被丟棄,系統實際有效處理能力下降。特別是storm、jstorm、sparkstreaming等實時計算系統,消息流量不斷變化,在流量高峰到來時,要求每個節點都能都能盡快有效的處理接收到的消息,否則將影響其他正常運行的節點或計算任務。
相關技術中采用如下流量控制策略:在數據源配置一個流控值r0,表征系統允許的未完成消息數量,在系統運行過程中,根據流水線中最后一個處理節點的消息處理情況確定實際未完成消息數量r,如果r>r0,說明消息流量過大,則控制數據源減少消息發送數量;反之,如果r<r0,說明消息流量過小,則控制數據源增加消息發送數量。上述流量控制策略在實際應用中存在較嚴重的弊端;例如:如果上述流控值配置的太高,消息丟棄量過高,仍然會造成系統的不穩定,但是流控值配置的太低時,又會造成計算資源的空閑。
技術實現要素:
為了解決上述技術問題,本申請公開了一種消息流量控制方法、裝置及相關系統。
本申請第一方面提供了一種消息流量控制方法,所述方法應用于數據處理系統,所述數據處理系統包括數據源和多個處理節點;所述方法包括:
分別對每個處理節點的消息接收量進行采樣,并根據采樣結果判斷相應處理節點的實際消息接收量是否在其預設流量閾值區間內;
在根據第一處理節點對應的采樣結果判定所述第一處理節點的實際消息接收量不在其預設流量閾值區間內時,生成相應的流量控制請求;
根據所述流量控制請求調整與所述第一處理節點相鄰的上游數據節點的消息發送速率;其中,所述上游數據節點可以為所述數據源或者處理節點。
結合第一方面,在第一方面第一種可行的實施方式中,在根據第一處理節點對應的采樣結果判定所述第一處理節點的實際消息接收量不在預設流量閾值區間內時,生成相應的流量控制請求,包括:
在根據第一處理節點對應的采樣結果判定所述第一處理節點的實際消息接收量大于預設最高流量閾值時,生成流量降低請求;
在根據第一處理節點對應的采樣結果判定所述第一處理節點的實際消息接收量小于預設最低流量閾值時,生成流量升高請求。
結合第一方面第一種可行的實施方式,在第一方面第二種可行的實施方式中,根據所述流量控制請求調整與所述第一處理節點相鄰的上游數據節點的消息發送速率,包括:
在所述流量控制請求為所述流量降低請求時,根據所述第一處理節點的消息處理速率和所述上游數據節點的原始消息發送速率確定消息發送延遲時間;
將所述消息發送延遲時間與所述原始消息發送速率進行疊加,得到所述上游數據節點的目標消息發送速率。
結合第一方面第一種可行的實施方式,在第一方面第三種可行的實施方式中,根據所述流量控制請求調整與所述第一處理節點相鄰的上游數據節點的消息發送速率,包括:
在所述流量控制請求為所述流量升高請求時,根據預設速率調整步長逐步提高所述上游數據節點的消息發送速率至預設正常速率。
結合第一方面,或者第一方面第一種可行的實施方式,或者第一方面第二種可行的實施方式,或者第一方面第三種可行的實施方式,在第一方面第四種可行的實施方式中,在根據所述流量控制請求調整與所述第一處理節點相鄰的上游數據節點的消息發送速率之前,所述方法還包括:
如果在預設時段內所述上游數據節點對應的多個下游處理節點均生成相應的流量控制請求,則確定每個下游處理節點對應的流量控制請求對所述上游數據節點造成的消息發送速率變化量;
確定消息發送速率變化量最大值對應的目標流量控制請求,以根據所述目標流量控制請求調整所述上游數據節點的消息發送速率。
結合第一方面,或者第一方面第一種可行的實施方式,或者第一方面第二種可行的實施方式,或者第一方面第三種可行的實施方式,在第一方面第五種可行的實施方式中,所述方法還包括:
將各個處理節點的流量控制狀態存儲至預設存儲模塊;
根據預設周期將所述預設存儲模塊存儲的所述流量控制狀態同步至相應的處理節點。
結合第一方面,或者第一方面第一種可行的實施方式,或者第一方面第二種可行的實施方式,或者第一方面第三種可行的實施方式,在第一方面第六種可行的實施方式中,根據采樣結果判斷相應處理節點的實際消息接收量是否滿足在其預設流量閾值區間內,包括:
對于任一處理節點,計算預設采樣周期內采集到的不在其預設流量閾值區間內的采樣值個數與所述預設采樣周期內的采樣值總個數之間的比值;
如果所述比值大于預設閾值,則判定相應處理節點的實際消息接收量不在其預設流量閾值區間內。
本申請第二方面提供了一種消息流量控制裝置,所述裝置應用于數據處理系統,所述數據處理系統包括數據源和多個處理節點;所述裝置包括:觸發器和控制器;
所述觸發器設置于每個處理節點中,用于對自身所在處理節點的消息接收量進行采樣,并根據采樣結果判斷自身所在處理節點的實際消息接收量是否在其預設流量閾值區間內,并在自身所在處理節點的實際消息接收量不在其預設流量閾值區間內時,生成相應的流量控制請求;
所述控制器設置于每個具有下游處理節點的數據節點中,用于根據自身所在數據節點對應的下游處理節點的流量控制請求,調整自身所在數據節點的消息發送速率;其中,所述數據節點可以為所述數據源或者處理節點。
結合第二方面,在第二方面第一種可行的實施方式中,為實現在自身所在處理節點的實際消息接收量不在其預設流量閾值區間內時,生成相應的流量控制請求,所述觸發器被配置為:
在自身所在處理節點的實際消息接收量大于預設最高流量閾值時,生成流量降低請求;
在自身所在處理節點的實際消息接收量大于預設最低流量閾值時,生成流量升高請求。
結合第二方面第一種可行的實施方式,在第二方面第二種可行的實施方式中,為實 現根據自身所在數據節點對應的下游處理節點的流量控制請求,調整自身所在數據節點的消息發送速率,所述控制器被配置為:
在所述流量控制請求為所述流量降低請求時,根據所述下游處理節點的消息處理速率,以及自身所在數據節點的原始消息發送速率確定消息發送延遲時間,并將所述消息發送延遲時間與所述原始消息發送速率進行疊加,得到自身所在數據節點的目標消息發送速率。
結合第二方面第一種可行的實施方式,在第二方面第三種可行的實施方式中,為實現根據自身所在數據節點對應的下游處理節點的流量控制請求,調整自身所在數據節點的消息發送速率,所述控制器被配置為:
在所述流量控制請求為所述流量升高請求時,根據預設速率調整步長逐步提高自身所在數據節點的消息發送速率至預設正常速率。
結合第二方面,或者第二方面第一種可行的實施方式,或者第二方面第二種可行的實施方式,或者第二方面第三種可行的實施方式,在第二方面第四種可行的實施方式中,所述裝置還包括:第一協調器;
所述第一協調器與各個處理節點并列設置于所述數據處理系統中,用于獲取所述觸發器發送的流量控制請求,并將所述流量控制請求轉發至相應上游數據節點的控制器;
其中,如果所述第一協調器在預設時段內獲取到多條向同一上游數據節點的控制器發送的流量控制請求,則所述第一協調器確定每條流量控制請求對所述同一上游數據節點造成的消息發送速率變化量,并將消息發送速率變化量最大值對應的流量控制請求發送至所述同一上游數據節點的控制器。
結合第二方面,或者第二方面第一種可行的實施方式,或者第二方面第二種可行的實施方式,或者第二方面第三種可行的實施方式,在第二方面第五種可行的實施方式中,所述裝置還包括:第二協調器;
所述第二協調器與各個處理節點并列設置于所述數據處理系統中,用于將各個處理節點的流量控制狀態存儲至預設存儲模塊,并根據預設周期將所述預設存儲模塊存儲的所述流量控制狀態同步至相應的處理節點。
結合第二方面,或者第二方面第一種可行的實施方式,或者第二方面第二種可行的實施方式,或者第二方面第三種可行的實施方式,在第二方面第六種可行的實施方式中,為實現根據采樣結果判斷自身所在處理節點的實際消息接收量是否滿足在其預設流量閾值區間內,所述觸發器被配置為:
計算預設采樣周期內采集到的不在其預設流量閾值范圍內的采樣值個數與所述預 設采樣周期內的采樣值總個數之間的比值,并在所述比值大于預設閾值時,判定自身所在處理節點的實際消息接收量不在其預設流量閾值區間內。
本申請第三方面提供一種數據處理系統,該系統包括數據源、多個處理節點,以及上述任一種消息流量控制裝置。
由以上技術方案可知,本申請實施例通過對每個處理節點的消息接收量進行采樣,一旦某個處理節點的實際消息接收量不在其對應的預設流量閾值區間內,則生成相應的流量控制請求,并根據該流量控制請求調整該處理節點對應的上游數據節點的消息發送速率,從而可以實現對任意兩個相鄰上下游數據節點之間的消息流量的動態控制,相對于現有技術只根據最后一個處理節點的未處理消息數量來調整數據源的消息發送速率的方式,本申請控制精度更高,任意一個處理節點都不會出現消息積壓或空閑的現象,從而可以減少消息丟棄量,提高整個數據處理系統的穩定性及處理效率。
附圖說明
為了更清楚地說明本發明實施例或現有技術中的技術方案,下面將對實施例或現有技術描述中所需要使用的附圖作簡單地介紹,顯而易見地,對于本領域普通技術人員而言,在不付出創造性勞動性的前提下,還可以根據這些附圖獲得其他的附圖。
圖1為現有數據處理系統的一種拓撲結構圖;
圖2為本申請實施例提供的一種消息流量控制方法的流程圖;
圖3為本申請實施例提供的一種數據處理系統的拓撲結構圖;
圖4為本申請實施例提供的基于圖3所示拓撲結構的消息流量控制方法的信號流圖;
圖5為本申請實施例提供的消息流量控制裝置的工作原理示意圖;
圖6為本申請實施例提供的另一種數據處理系統的拓撲結構圖。
具體實施方式
這里將詳細地對示例性實施例進行說明,其示例表示在附圖中。下面的描述涉及附圖時,除非另有表示,不同附圖中的相同數字表示相同或相似的要素。以下示例性實施例中所描述的實施方式并不代表與本發明相一致的所有實施方式。相反,它們僅是與如所附權利要求書中所詳述的、本發明的一些方面相一致的裝置和方法的例子。
首先對本申請提供的消息流量控制方法的實施例進行說明。該方法可以應用于任一包括數據源和多個處理節點的流水線式數據處理系統,例如storm、jstorm、sparkstreaming等實時計算系統,以調節流水線中各個節點之間的消息流量,實現數據源及 任一處理節點的消息發送速率與相應下游處理節點的消息處理速率相匹配。
圖2為本申請一個實施例提供的消息流量控制方法的流程圖;參照圖2,該方法包括如下步驟。
s11、分別對每個處理節點的消息接收量進行采樣,并根據采樣結果判斷相應處理節點的實際消息接收量是否在其預設流量閾值區間內。
由于數據處理流水線中各個處理節點的處理能力及需要處理的消息數量(即該處理節點的負載)不盡相同,本實施例預先針對每個處理節點分別設置對應的預設流量閾值區間;以圖1所示拓撲圖為例,需要采樣的節點包括所有的三個處理節點,根據節點的處理能力及其負載,設置處理節點a對應的預設流量閾值區間為[a1,b1],處理節點b對應的預設流量閾值區間為[a2,b2],處理節點c對應的預設流量閾值區間為[a3,b3]。
在系統運行過程中,分別采樣每個處理節點的消息接收量,即相應處理節點的負載,并分別根據各個處理節點的采樣結果判斷該處理節點的實際消息接收量是否在其預設流量閾值區間內。仍以圖1為例,根據處理節點a的采樣結果判斷處理節點a的實際消息接收量是否在處理節點a的對應的區間[a1,b1]內,相應的,根據處理節點b的采樣結果判斷處理節點b的實際消息接收量是否在區間[a2,b2]內,依此類推。也即,通過步驟s11檢測每個處理節點的負載和其處理能力是否相匹配。
s12、在根據第一處理節點對應的采樣結果判定所述第一處理節點的實際消息接收量不在其預設流量閾值區間內時,生成相應的流量控制請求。
s13、根據所述流量控制請求調整與所述第一處理節點相鄰的上游數據節點的消息發送速率。
本實施例在檢測到任一處理節點的實際消息接收量不在其對應的預設流量閾值區間內,也即該處理節點的負載與其處理能力不匹配時,生成相應的流量控制請求,并根據該流量控制請求調整該處理節點對應的上游數據節點的消息發送速率。
其中,根據各個處理節點在流水線中所處的位置不同,所述上游數據節點可能為數據源,也可能為處理節點。以圖1為例,對于數據源和處理節點a兩個節點,處理節點a相當于上述第一處理節點,數據源s相當于上述上游數據節點;而對于處理節點a和處理節點b兩個節點,處理節點b相當于上述第一處理節點,處理節點a相當于上述上游數據節點。
由以上技術方案可知,本申請實施例通過對每個處理節點的消息接收量進行采樣,一旦某個處理節點的實際消息接收量不在其對應的預設流量閾值區間內,則生成相應的流量控制請求,并根據該流量控制請求調整該處理節點對應的上游數據節點的消息發送速率,從而可以實現對任意兩個相鄰上下游數據節點之間的消息流量的動態控制,相對 于現有技術只根據最后一個處理節點的未處理消息數量來調整數據源的消息發送速率的方式,本申請控制精度更高,任意一個處理節點都不會出現消息積壓或空閑的現象,減少消息丟棄量,提高整個數據處理系統的穩定性及處理效率。
在本申請一個可行的實施例中,可以在數據處理系統的各個處理節點分別設置觸發器,通過該觸發器執行上述步驟s11和s12,同時,在數據源及各個處理節點中設置控制器,通過該控制器執行上述步驟s13。仍以圖1為例,在本申請實施例中,在數據源s中設置控制器c_s,在處理節點a中設置觸發器t_a和控制器c_a,在處理節點b中設置觸發器t_b,在處理節點c中設置觸發器t_c,如圖3所示。圖3中實線箭頭表示各個節點之間的消息傳輸方向,虛線箭頭表示各個節點之間的流量控制請求傳輸方向。需要說明的是,在圖3所示系統中,由于處理節點b和c的下游無其他處理節點,不需要發送消息,故處理節點b和c中可以不設置相應的控制器,在其他實施例中,如果處理節點b和c的下游還存在其他處理節點,則可以在處理節點b和c中增設相應的控制器。基于圖3所示系統,各節點間消息流量控制過程如圖4所示。
參照圖3和4,對于數據源和處理節點a兩個節點,處理節點a相當于上述第一處理節點,數據源s相當于上述上游數據節點,則:
在步驟s111中,觸發器t_a對處理節點a的消息接收量進行采樣,并根據采樣結果判斷其實際消息接收量是否在對應的預設流量閾值區間[a1,b1]內;
在步驟s121中,觸發器t_a在判定處理節點a的實際消息接收量不在[a1,b1]內(大于b1,或者小于a1)時,也即處理節點a的負載和處理能力不匹配,則生成流量控制請求,并將其發送至數據源s;
在步驟s131中,控制器c_s根據觸發器t_a發送的流量控制請求調整數據源s的消息發送速率。通過上述步驟s111、s121和s131使得單位時間內發送至處理節點a的消息數量,也即單位時間內處理節點a的實際消息接收量,可以與處理節點a的消息處理數量相匹配,既可以避免數據源s的消息發送速率過大時,消息在處理節點a中積壓,也可以避免數據源s的消息發送速率過小時,處理節點a空閑。
相應的,對于處理節點a和處理節點b兩個節點,處理節點b相當于上述第一處理節點,處理節點a相當于上述上游數據節點,則:
在步驟s112中,觸發器t_b對處理節點b的消息接收量進行采樣,并根據采樣結果判斷其實際消息接收量是否在對應的預設流量閾值區間[a2,b2]內;
在步驟s122中,觸發器t_b在判定處理節點b的實際消息接收量不在[a2,b2]內時,則生成流量控制請求,并將其發送至處理節點a;
在步驟s132中,控制器c_a根據觸發器t_b發送的流量控制請求調整處理節點a 向處理節點b發送消息時的消息發送速率。即,通過上述步驟s112、s122和s132使得單位時間內處理節點b的實際消息接收量與消息處理數量相匹配。
對于處理節點a和處理節點c兩個節點,其消息流量控制過程與上述步驟s112、s122和s132類似,本文不再贅述。
在本申請一個可行的實施例中,上述步驟s11所述的根據采樣結果判斷相應處理節點的實際消息接收量是否滿足在其預設流量閾值區間內,具體包括以下步驟:
對于任一處理節點,計算預設采樣周期內采集到的不在其預設流量閾值區間內的采樣值個數與所述預設采樣周期內的采樣值總個數之間的比值;如果所述比值大于預設閾值,則判定相應處理節點的實際消息接收量不在其預設流量閾值區間內。
相對于針對每個不在其預設流量閾值區間內的采樣值生成一條流量控制請求,上述實施例在一個預設采樣周期內超出預設流量閾值區間的采樣值所占的比例大于預設閾值時,才生成流量控制請求,啟動對上游數據節點的消息發送速率的調整,可以避免頻繁調整導致系統抖動、處理能力下降等問題。
在本申請一個可行的實施例中,上述步驟s12所述的根據第一處理節點對應的采樣結果判定所述第一處理節點的實際消息接收量不在預設流量閾值區間內時,生成相應的流量控制請求,具體可以包括以下兩種情況:
在根據第一處理節點對應的采樣結果判定所述第一處理節點的實際消息接收量大于預設最高流量閾值時,生成流量降低請求;
在根據第一處理節點對應的采樣結果判定所述第一處理節點的實際消息接收量小于預設最低流量閾值時,生成流量升高請求。
即,在系統流量高峰時段內,某個處理節點的實際消息接收量大于預設最高流量閾值,則生成流量降低請求,以控制其上游數據節點降低消息發送速率;隨著上游數據節點的消息發送速率的降低,該處理節點的實際消息接收量也降低,當其降低至預設最低流量閾值以下時,生成流量升高請求,以停止對上游數據節點的消息發送速率的降低控制,使其消息發送速率逐步升高,直到恢復至正常值。
在本申請一個可行的實施例中,上述流量控制請求中不僅包括用于指示上游數據節點升高或降低消息發送速率的信息,還包括生成該流量控制請求的處理節點的消息處理速率;相應的,當流量控制請求為上述流量降低請求時,上述步驟s13所述的調整上游 數據節點的消息發送速率的方法為:
在所述流量控制請求為所述流量降低請求時,根據所述第一處理節點的消息處理速率和所述上游數據節點的原始消息發送速率確定消息發送延遲時間;
將所述消息發送延遲時間與所述原始消息發送速率進行疊加,得到所述上游數據節點的目標消息發送速率。
具體的,假設上述流量降低請求中包含第一處理節點的消息處理速率為tps_downstream,相應上游數據節點的原始消息發送速率為tps_upstream,由于流量控制請求為流量降低請求,可以推斷upstream_tps>tps_downstream,故需要在上游節點發送消息時延遲一段時間t_delay(即上述消息發送延遲時間),以降低upstream_tps;可以采用如下公式計算消息發送延遲時間t_delay:
t_delay=1/tps_downstream-1/upstream_tps。
將上述t_delay與upstream_tps疊加可以得到調整后的消息發送速率,也即上述目標消息發送速率upstream_tps’;疊加計算公式可以為:
upstream_tps’=1/[(1/upstream_tps)+t_delay]。
另外,在實際的應用中,由于網絡或者其他中間環節對消息發送速率或者消息處理速率有一定的影響,導致上游數據節點在應用調整后的消息發送速率后,仍然收到下游處理節點的流量控制請求,故在本申請其他實施例中,還可以對在消息發送延遲時間進行微調,即在t_delay的基礎上增加最小延遲單位t_min_adjust(可以為1毫秒)的微調,即:t_delay=1/tps_downstream-1/upstream_tps+t_min_adjust。
在本申請另一個可行的實施例中,當所述流量控制請求為所述流量升高請求時,上述步驟s13所述的調整上游數據節點的消息發送速率的方法為:根據預設速率調整步長逐步提高所述上游數據節點的消息發送速率至預設正常速率。
即在收到流量升高請求時,逐步提高上游數據節點的消息發送速率,而不是一次性恢復至預設正常速率;相對于上述基于消息發送延遲時間t_delay的調整方式,在收到流量升高請求時,逐步減小t_delay的取值直至0,upstream_tps’也隨之逐步提高至upstream_tps。采用這種逐步提高消息發送速率的方式,可以避免消息積壓,保證系統的穩定。
另外,在根據所述流量升高請求將上游數據節點的的消息發送速率恢復至預設正常速率時,可以向相應的下游處理節點反饋響應信息,以通知下游處理節點控制結束;相應的,下游處理節點在接收到該響應信息后,不再發送請求,但仍然通過采樣檢測自身 的實際消息接收量是否在預設流量閾值區間內。
在本申請一個可行的實施例中,步驟s12生成的流量控制請求可以直接由第一處理節點發送至相應的上游數據節點;在本申請另一個可行的實施例中,所述流量控制請求還可以通過一個獨立節點對流量控制請求進行轉發,該獨立節點接收各個處理節點的流量控制請求,確定其對應的上游數據節點,并將該流量控制請求轉發至該上游數據節點。可選的,基于上文實施例所述的在節點中設置觸發器及控制器,本實施例所述的獨立節點可以為設置于系統中的協調器。
實際應用中,某個上游數據節點可能存在多個下游處理節點,則通過上述獨立節點接收并轉發流量控制請求的過程中,在同一檢測時段內,可能多個下游處理節點都檢測到自身的實際消息接收量不在預設流量閾值區間內,從而都相應生成流量控制請求,如果分別依據每個下游處理節點的流量控制請求對該上游數據節點的消息發送速率進行調整,則需要調整多次,不僅工作量大,還可能因頻繁調整導致系統不穩地。
有鑒于此,,在本申請一個可行的實施例中可以對發向同一上游數據節點的多條流量控制請求進行篩選,即,在根據所述流量控制請求調整與所述第一處理節點相鄰的上游數據節點的消息發送速率(步驟s13)之前,上述消息流量控制方法還可以包括如下步驟:
s14、如果在預設時段內所述上游數據節點對應的多個下游處理節點均生成相應的流量控制請求,則確定每個下游處理節點對應的流量控制請求對所述上游數據節點造成的消息發送速率變化量;
s15、確定消息發送速率變化量最大值對應的目標流量控制請求,以根據所述目標流量控制請求調整所述上游數據節點的消息發送速率。
參照圖1或圖3所示系統,處理節點a存在兩個下游處理節點,即處理節點b和處理節點c,則可能出現在同一個檢測時段內,處理節點b和處理節點c都檢測到自身的實際消息接收量不在預設流量閾值區間內,都生成流量控制請求;對于這兩條流量控制請求,通過計算比較,選出對處理節點a造成的消息發送速率變化量最大的一條流量控制請求,并根據選出的流量控制請求來調整處理節點a的消息發送速率。
優選的,可以通過上文所述的消息發送延遲時間t_delay衡量流量控制請求對相應處理節點造成的消息發送速率變化量大小。
上述實施例在同一上游數據節點收到多條流量控制請求,根據各條流量控制請求對 該上游數據節點的消息發送速率造成的變化量大小進行篩選出一條流量控制請求,用于調整上游數據節點的消息發送速率,從而可以減少調整次數,既可以減少流量控制的工作量,又可以避免短時間內頻繁調整導致的系統抖動,提高系統的穩定性。
優選的,可以通過上文實施例所述的協調器執行上述步驟s14和s15,并將步驟s15確定的目標流量控制請求發送至相應上游數據節點的控制器,以避免篩選過程對上游數據節點的內存等資源的占用。
在本申請一個可行的實施例中,上述消息流量控制方法還可以包括如下步驟:
s16、將各個處理節點的流量控制狀態存儲至預設存儲模塊;
s17、根據預設周期將所述預設存儲模塊存儲的所述流量控制狀態同步至相應的處理節點。
以storm、jstorm等實時計算系統為例,上述預設存儲模塊可以為實時計算系統外部的協調服務器,如zookeeper。對應于上文所述的兩種流量控制請求,即流量降低請求和流量升高請求,所述流量控制狀態至少包括兩種:對于任一處理節點,如果其接收到流量降低請求,則其對應的流量控制狀態為降流控制狀態(即該處理節點以低于默認值的消息發送速率向下游處理節點發送消息);如果其接收到流量升高請求或未接收到任何流量控制請求,則其對應的流量控制狀態為無控制狀態(即該處理節點以默認的消息發送速率向下游處理節點發送消息)。
以上技術方案中,通過對各個處理節點的流量控制狀態的實時存儲并定期同步,可以保證處理節點在失效重啟后,仍然可以處于正確的流量控制狀態下,進而保證系統的穩定性。
優選的,上述步驟s16和s17也可以通過上文所述的協調器執行。
與上述消息流量控制方法的實施例相對應,本申請實施例還提供了一種應用于流水線式數據處理系統的消息流量控制裝置,且該流水線式數據處理系統包括數據源和多個處理節點;為便于描述,下文將所述數據源和各個處理節點統稱為數據節點。所述消息流量控制裝置包括:分別設置于所述每個處理節點中的觸發器,和分別設置于每個具有下游處理節點的數據節點中的控制器。設置有上述消息流量控制裝置的數據處理系統的拓撲結構可參照圖3。
其中,所述觸發器用于,對自身所在處理節點的消息接收量進行采樣,并根據采樣 結果判斷自身所在處理節點的實際消息接收量是否在其預設流量閾值區間內,并在自身所在處理節點的實際消息接收量不在其預設流量閾值區間內時,生成相應的流量控制請求。
所述控制器用于,根據自身所在數據節點對應的下游處理節點的流量控制請求,調整自身所在數據節點的消息發送速率。
具體的,如圖5所示的設置有消息流量控制裝置的數據處理系統中任意一個上游數據節點510和與其相鄰的一個下游數據節點520結構框圖;其中,一種具體情況下,該上游數據節點510和下游數據節點520都為處理節點,另一種具體情況下,該上游數據節點510為數據源,下游數據節點520為處理節點。圖5中的虛線框及虛線箭頭表示在一種情況下存在,另一種情況下不存在的結構及信息流向。
基于該上游數據節點510和下游數據節點520,上述消息流量控制裝置的工作過程如下:下游數據節點520的觸發器521對該下游數據節點520的消息接收量進行采樣,并根據采樣結果判斷下游數據節點520的實際消息接收量是否在下游數據節點520的預設流量閾值區間內,如果不在,則生成相應的流量控制請求,并將該流量控制請求發送至上游數據節點510的控制器512;控制器512在接收到觸發器521發送的流量控制請求后,根據該流量控制請求調整上游數據節點510的消息發送速率,從而可以將下游數據節點520的實際消息接收量控制在下游數據節點520的預設流量閾值區間內。
由以上技術方案可知,本申請實施例通過對每個處理節點的消息接收量進行采樣,一旦某個處理節點的實際消息接收量不在其對應的預設流量閾值區間內,則生成相應的流量控制請求,并根據該流量控制請求調整該處理節點對應的上游數據節點的消息發送速率,從而可以實現對任意兩個相鄰上下游數據節點之間的消息流量的動態控制,相對于現有技術只根據最后一個處理節點的未處理消息數量來調整數據源的消息發送速率的方式,本申請控制精度更高,任意一個處理節點都不會出現消息積壓或空閑的現象,減少消息丟棄量,提高整個數據處理系統的穩定性及處理效率。
在本申請一個可行的實施例中,為實現根據采樣結果判斷自身所在處理節點的實際消息接收量是否滿足在其預設流量閾值區間內,上述觸發器可以被配置為:計算預設采樣周期內采集到的不在其預設流量閾值范圍內的采樣值個數與所述預設采樣周期內的采樣值總個數之間的比值,并在所述比值大于預設閾值時,判定自身所在處理節點的實際消息接收量不在其預設流量閾值區間內。
基于以上技術方案,相對于針對每個不在其預設流量閾值區間內的采樣值生成一條流量控制請求,上述實施例在一個預設采樣周期內超出預設流量閾值區間的采樣值所占 的比例大于預設閾值時,才生成流量控制請求,啟動對上游數據節點的消息發送速率的調整,可以避免頻繁調整導致系統抖動、處理能力下降等問題。
在本申請一個可行的實施例中,為實現在自身所在處理節點的實際消息接收量不在其預設流量閾值區間內時,生成相應的流量控制請求,上述觸發器可以被配置為:
在自身所在處理節點的實際消息接收量大于預設最高流量閾值時,生成流量降低請求;
在自身所在處理節點的實際消息接收量大于預設最低流量閾值時,生成流量升高請求。
在本申請一個可行的實施例中,為實現根據自身所在數據節點對應的下游處理節點的流量控制請求,調整自身所在數據節點的消息發送速率,上述控制器可以被配置為:在所述流量控制請求為所述流量降低請求時,根據所述下游處理節點的消息處理速率,以及自身所在數據節點的原始消息發送速率確定消息發送延遲時間,并將所述消息發送延遲時間與所述原始消息發送速率進行疊加,得到自身所在數據節點的目標消息發送速率。
在本申請另一個可行的實施例中,為實現根據自身所在數據節點對應的下游處理節點的流量控制請求,調整自身所在數據節點的消息發送速率,上述控制器可以被配置為:
在所述流量控制請求為所述流量升高請求時,根據預設速率調整步長逐步提高自身所在數據節點的消息發送速率至預設正常速率。
除上述觸發器和控制器外,本申請提供的消息流量控制裝置還可以包括協調器,該協調器與各個處理節點并列設置于所述數據處理系統中,該協調器用于獲取各個觸發器生成的流量控制請求,并將所述流量控制請求轉發至相應的上游數據節點。
圖6為在圖3所示設置有消息流量控制裝置的系統拓撲結構上增設協調器后的拓撲結構圖。參照圖6,協調器k分別獲取觸發器t_a、觸發器t_b和觸發器t_c的流量控制請求,并將觸發器t_a的流量控制請求轉發至數據源s的控制器c_s,將觸發器t_b和觸發器t_c的流量控制請求分別轉發至處理節點a的控制器c_a。
在本申請一個可行的實施例中,上述協調器具體可以被配置為:在預設時段內獲取到多條向同一上游數據節點的控制器發送的流量控制請求,則所述第一協調器確定每條流量控制請求對所述同一上游數據節點造成的消息發送速率變化量,并將消息發送速率變化量最大值對應的流量控制請求發送至所述同一上游數據節點的控制器。
仍參照上圖6,在預設時段內協調器k既獲取到觸發器t_b的流量控制請求q_b,又獲取到觸發器t_c的流量控制請求q_c,為減少對其共同的上游處理節點a的消息發送速率調整次數,保證系統的穩定,協調器k分別確定流量控制請求q_b和q_c對處理節點a造成的消息發送速率變化量,并選出消息發送速率變化量較大的流量控制請求,假設為流量控制請求q_b,則協調器k只將流量控制請求q_b轉發至控制器c_a,將流量控制請求q_c丟棄;相應的,控制器c_a只需根據流量控制請求q_b調整處理節點a的消息發送速率。
在本申請另一個可行的實施例中,上述協調器還被配置為:將各個處理節點的流量控制狀態存儲至預設存儲模塊,并根據預設周期將所述預設存儲模塊存儲的所述流量控制狀態同步至相應的處理節點;從而可以保證處理節點在失效重啟后,仍然可以處于正確的流量控制狀態下,進而保證系統的穩定性。
另外,本申請實施例還提供了一種數據處理系統,該系統包括包括數據源、多個處理節點,以及上文任一實施例所述的消息流量控制裝置。該系統的結構圖可以參照圖3和圖6所示,其流量控制過程可參照上文方法及裝置實施例,本文不再贅述。
本說明書中的各個實施例均采用遞進的方式描述,各個實施例之間相同相似的部分互相參見即可,每個實施例重點說明的都是與其他實施例的不同之處。尤其,對于裝置和系統實施例而言,由于其基本相似于方法實施例,所以描述的比較簡單,相關之處參見方法實施例的部分說明即可。
以上所述的本發明實施方式,并不構成對本發明保護范圍的限定。任何在本發明的精神和原則之內所作的修改、等同替換和改進等,均應包含在本發明的保護范圍之內。