• / 30
  • 下載費用:30 金幣  

并行用戶態協議棧的管理方法和協議棧系統.pdf

摘要
申請專利號:

CN201410124239.X

申請日:

2014.03.28

公開號:

CN104951357A

公開日:

2015.09.30

當前法律狀態:

授權

有效性:

有權

法律詳情: 授權|||實質審查的生效 IPC(主分類):G06F 9/46申請日:20140328|||公開
IPC分類號: G06F9/46; G06F9/50; H04L29/06 主分類號: G06F9/46
申請人: 華為技術有限公司
發明人: 戴芬
地址: 518129廣東省深圳市龍崗區坂田華為總部辦公樓
優先權:
專利代理機構: 北京龍雙利達知識產權代理有限公司11329 代理人: 王君; 肖鸝
PDF完整版下載: PDF下載
法律狀態
申請(專利)號:

CN201410124239.X

授權公告號:

||||||

法律狀態公告日:

2018.06.26|||2015.11.04|||2015.09.30

法律狀態類型:

授權|||實質審查的生效|||公開

摘要

本發明實施例提供了一種并行用戶態協議棧的管理方法和協議棧系統,該方法包括:監控用戶態協議棧中每個協議棧對應的實例的運行狀態,一個該實例對應于該用戶態協議棧中的一個協議棧;確定第一實例和第二實例,其中第一實例為運行狀態異常的實例,第二實例具備遷入第一實例中至少一個待遷移負載的能力;根據第一實例中至少一個待遷移負載在該共享資源池中所對應的PCB在第二實例中重建該至少一個待遷移負載。本發明實施例中,根據異常實例中待遷移負載在共享資源池對應的PCB在具備遷入負載能力的實例中重建待遷移負載,能夠克服協議棧共用一個分發模塊帶來的系統分發瓶頸,快速進行負載均衡和故障恢復,從而提高協議棧系統的性能。

權利要求書

權利要求書
1.  一種并行用戶態協議棧的管理方法,其特征在于,包括:
監控用戶態協議棧中每個協議棧對應的實例的運行狀態,一個所述實例對應于所述用戶態協議棧中的一個協議棧;
確定第一實例和第二實例,其中所述第一實例為運行狀態異常的實例,所述第二實例具備遷入所述第一實例中至少一個待遷移負載的能力,一個所述待遷移負載在所述第一實例所對應的協議棧內對應于一個協議控制塊PCB,所述PCB在共享資源池中對應于一個存儲著所述待遷移負載連接參數的PCB,所述待遷移負載的連接參數能夠用于重建所述待遷移負載;
根據所述第一實例中至少一個待遷移負載在所述共享資源池中所對應的PCB在所述第二實例中重建所述至少一個待遷移負載。

2.  如權利要求1所述的方法,其特征在于,在所述根據所述第一實例中至少一個待遷移負載在共享資源池中所對應的PCB在所述第二實例中重建所述至少一個待遷移負載之前,所述方法還包括:
確定所述第一實例中的至少一個待遷移負載。

3.  如權利要求2所述的方法,其特征在于,所述實例的運行狀態包括實例的負載狀態和存活狀態,所述監控用戶態協議棧中每個協議棧對應的實例的運行狀態包括:
分別向所述用戶態協議棧中每個協議棧對應的實例發送心跳消息并監控所述心跳消息響應時延,并監控所述用戶態協議棧中每個協議棧對應的實例在第一預定時間內的實例負載均值,以根據所述心跳消息的響應時延和所述實例負載均值確定所述用戶態協議棧中每個協議棧對應的實例的運行狀態,其中,一條心跳消息對應于一個所述實例;或者
分別輪詢所述用戶態協議棧中每個協議棧對應的實例的實例標識,并監控所述用戶態協議棧中每個協議棧對應的實例在第一預定時間內的實例負載均值,以根據所述實例標識和所述實例負載均值確定所述用戶態協議棧中每個協議棧對應的實例的運行狀態,其中,所述實例標識用于表示實例的存活狀態,所述實例標識存儲于共享內存區域或共享文件,一個所述實例標識對應于一個所述實例。

4.  如權利要求3所述的方法,其特征在于,所述確定第一實例包括:
確定距離發送心跳消息時刻達到第二預定時間后仍然未反饋心跳響應的實例為所述第一實例;或者
確定第一預定時間內實例標識表示僵死或失效狀態的實例為所述第一實例。

5.  如權利要求4所述的方法,其特征在于,
所述確定第二實例包括:創建并確定新的實例為所述第二實例;
所述根據所述第一實例中至少一個待遷移負載在共享資源池中所對應的PCB在所述第二實例中重建所述至少一個待遷移負載包括:
根據所述至少一個待遷移負載之第一負載在共享資源池中所對應的第一PCB在所述第二實例中實現所述第一負載與所述用戶態協議棧的上層服務的對接,并將所述第一負載在所述第一實例中綁定的第一接收端擴展RSS隊列重綁定到所述第二實例的所述第一負載中,其中,所述至少一個待遷移負載包括所述第一實例的所有負載。

6.  如權利要求5所述的方法,其特征在于,還包括:終止所述第一實例。

7.  如權利要求3所述的方法,其特征在于,
所述確定第一實例包括:確定第一預定時間內實例總負載均值大于第一預定閾值的實例為所述第一實例。

8.  如權利要求7所述的方法,其特征在于,所述確定第二實例包括:
如果存在第一預定時間內實例總負載均值低于第二預定閾值的實例,則確定所述第一預定時間內實例總負載均值低于第二預定閾值的一個或多個實例作為所述第二實例,其中,遷入所述第二實例的所有負載的負載值與所述第二預定閾值之和小于所述第一預定閾值。

9.  如權利要求8所述的方法,其特征在于,所述根據所述第一實例中至少一個待遷移負載在共享資源池中所對應的PCB在所述第二實例中重建所述至少一個待遷移負載包括:
根據所述第一實例的至少一個待遷移負載之第二負載在所述共享資源池中所對應的第二PCB,將所述第二負載在所述第一實例中綁定的第二RSS隊列的綁定規則修改為綁定到所述第二實例的第二負載中,以使得所述第二實例實現從所述第二RSS隊列進行數據包接收及處理的過程;或者
根據所述第一實例的至少一個待遷移負載之第二負載在所述共享資源 池中所對應的第二PCB,在所述第一實例中解除所述第二負載在所述第一實例中綁定的第二RSS隊列,并在所述第二實例中將所述第二RSS隊列綁定到所述第二負載中,以使得所述第二實例實現從所述第二RSS隊列進行數據包接收及處理的過程。

10.  如權利要求8或9所述的方法,其特征在于,所述確定所述第一實例中的至少一個待遷移負載包括:
確定所述第一實例中的第三負載為所述第一實例的待遷移負載,所述第三負載在所述第一實例中所綁定的第三RSS隊列滿足以下條件:當所述第三RSS隊列綁定到所述第二實例時所述第二實例的連接數、接收字節數、發送字節數3個參數中至少有2個參數不大于所述第一實例的相應參數。

11.  如權利要求7所述的方法,其特征在于,所述確定第二實例包括:如果不存在預定時間內實例總負載均值低于第二預定閾值的實例,則創建并確定新的實例為所述第二實例。

12.  如權利要求11所述的方法,其特征在于,所述根據所述第一實例中至少一個待遷移負載在共享資源池中所對應的PCB在所述第二實例中重建所述至少一個待遷移負載包括:
根據所述第一實例的至少一個待遷移負載之第二負載在所述共享資源池中所對應的第二PCB在所述第二實例中實現所述第二負載與所述用戶態協議棧的上層服務的對接以使得所述第二實例實現與所述第二負載對應的應用app的交互,并在所述第一實例中解除所述第二負載在所述第一實例中綁定的第二RSS隊列,在所述第二實例中將所述第二RSS隊列綁定到所述第二負載中,以使得所述第二實例實現從所述第二RSS隊列進行數據包接收及處理的過程。

13.  如權利要求11或12所述的方法,其特征在于,所述確定所述第一實例中的至少一個待遷移負載包括:
確定所述第一實例中的第三負載為所述第一實例的待遷移負載,所述第三負載在所述第一實例中所綁定的第三RSS隊列滿足以下條件:所述第三RSS隊列的連接數、接收字節數、發送字節數3個參數中都達到所述第一實例的所有負載中對應參數的均值。

14.  一種協議棧系統,其特征在于,包括:
監控單元,用于監控所述協議棧系統的用戶態協議棧中每個協議棧對應 的運行狀態,一個所述實例對應于所述用戶態協議棧中的一個協議棧;
確定單元,用于確定第一實例和第二實例,所述第一實例為運行狀態異常的實例,所述第二實例具備遷入所述第一實例中至少一個待遷移負載的能力,一個所述待遷移負載在所述第一實例所對應的協議棧內對應于一個協議控制塊PCB,所述PCB在所述協議棧系統的共享資源池中對應于一個存儲著所述待遷移負載的連接參數的PCB,所述待遷移負載的連接參數能夠用于重建所述待遷移負載;
負載遷移單元,用于根據所述第一實例中至少一個待遷移負載在所述共享資源池中所對應的PCB在所述第二實例中重建所述至少一個待遷移負載。

15.  如權利要求14所述的系統,其特征在于,所述確定單元還用于確定所述第一實例中的至少一個待遷移負載。

16.  如權利要求15所述的系統,其特征在于,所述實例的運行狀態包括實例的負載狀態和存活狀態,所述監控單元具體用于:
分別向所述用戶態協議棧中每個協議棧對應的實例發送心跳消息并監控所述心跳消息響應時延,并監控所述用戶態協議棧中每個協議棧對應的實例在第一預定時間內的實例負載均值,以根據所述心跳消息的響應時延和所述實例負載均值確定所述用戶態協議棧中每個協議棧對應的實例的運行狀態,其中,一條心跳消息對應于一個所述實例;或者
分別輪詢所述用戶態協議棧中每個協議棧對應的實例的實例標識,并監控所述用戶態協議棧中每個協議棧對應的實例在第一預定時間內的實例負載均值,以根據所述實例標識和所述實例負載均值確定所述用戶態協議棧中每個協議棧對應的實例的運行狀態,其中,所述實例標識用于表示實例的存活狀態,所述實例標識存儲于共享內存區域或共享文件,一個所述實例標識對應于一個所述實例。

17.  如權利要求16所述的系統,其特征在于,在用于確定所述第一實例的過程中,所述確定單元具體用于:
確定距離發送心跳消息時刻達到第二預定時間后仍然未反饋心跳響應的實例為所述第一實例;或者
確定第一預定時間內實例標識都表示僵死或失效狀態的實例為所述第一實例。

18.  如權利要求17所述的系統,其特征在于,
在用于確定所述第二實例的過程中,所述確定單元具體用于創建并確定新的實例為所述第二實例;
所述負載遷移單元具體用于根據所述至少一個待遷移負載之第一負載在所述共享資源池中所對應的第一PCB在所述第二實例中實現所述第一負載與所述用戶態協議棧的上層服務的對接,并將所述第一負載在所述第一實例中綁定的第一接收端擴展RSS隊列重綁定到所述第二實例的所述第一負載中,其中,所述至少一個待遷移負載包括所述第一實例的所有負載。

19.  如權利要求18所述的系統,其特征在于,所述系統還包括:實例停止單元,用于終止所述第一實例。

20.  如權利要求16所述的系統,其特征在于,
在用于確定所述第一實例的過程中,所述確定單元具體用于確定第一預定時間內實例總負載均值大于第一預定閾值的實例為所述第一實例。

21.  如權利要求20所述的系統,其特征在于,
在用于確定所述第二實例的過程中,如果存在第一預定時間內實例總負載均值低于第二預定閾值的實例,則所述確定單元具體用于確定所述第一預定時間內實例總負載均值低于第二預定閾值的一個或多個實例作為所述第二實例,其中,遷入所述第二實例的所有負載的負載值與所述第二預定閾值之和小于所述第一預定閾值。

22.  如權利要求21所述的系統,其特征在于,所述負載遷移單元具體用于:
根據所述第一實例的至少一個待遷移負載之第二負載在所述共享資源池中所對應的第二PCB,將所述第二負載在所述第一實例中綁定的第二RSS隊列的綁定規則修改為綁定到所述第二實例的第二負載中,以使得所述第二實例實現從所述第二RSS隊列進行數據包接收及處理的過程;或者
根據所述第一實例的至少一個待遷移負載之第二負載在所述共享資源池中所對應的第二PCB,在所述第一實例中解除所述第二負載在所述第一實例中綁定的第二RSS隊列,并在所述第二實例中將所述第二RSS隊列綁定到所述第二負載中,以使得所述第二實例實現從所述第二RSS隊列進行數據包接收及處理的過程。

23.  如權利要求21或22所述的系統,其特征在于,在用于確定所述第一實例中的至少一個待遷移負載的過程中,所述確定單元具體用于:確定所 述第一實例中的第三負載為所述第一實例的待遷移負載,所述第三負載在所述第一實例中所綁定的第三RSS隊列滿足以下條件:當所述第三RSS隊列綁定到所述第二實例時所述第二實例的連接數、接收字節數、發送字節數3個參數中至少有2個參數不大于所述第一實例的相應參數。

24.  如權利要求20所述的系統,其特征在于,在用于確定所述第二實例的過程中,如果不存在預定時間內實例總負載均值低于第二預定閾值的實例,則所述確定單元具體用于創建并確定新的實例為所述第二實例。

25.  如權利要求25所述的系統,其特征在于,所述負載遷移單元具體用于:
根據所述第一實例的至少一個待遷移負載之第二負載在所述共享資源池中所對應的第二PCB在所述第二實例中實現所述第二負載與所述用戶態協議棧的上層服務的對接以使得所述第二實例實現與所述第二負載對應的應用app的交互,并在所述第一實例中解除所述第二負載在所述第一實例中綁定的第二RSS隊列,在所述第二實例中將所述第二RSS隊列綁定到所述第二負載中,以使得所述第二實例實現從所述第二RSS隊列進行數據包接收及處理的過程。

26.  如權利要求24或25所述的系統,其特征在于,在用于確定所述第一實例中的至少一個待遷移負載的過程中,所述確定單元具體用于:
確定所述第一實例中的第三負載為所述第一實例的待遷移負載,所述第三負載在所述第一實例中所綁定的第三RSS隊列滿足以下條件:所述第三RSS隊列的連接數、接收字節數、發送字節數3個參數中都達到所述第一實例的所有負載中對應參數的均值。

說明書

說明書并行用戶態協議棧的管理方法和協議棧系統
技術領域
本發明實施例涉及計算機領域,并且更具體地,涉及一種并行用戶態協議棧的管理方法和協議棧系統。
背景技術
隨著以太網技術的發展,10G、40G網卡的出現和普及,傳統基于單核的協議棧已經無法跟上網卡速度的需要。此外,處理器體系結構已從強調高頻單處理器發展到多核多處理器,計算機的并行處理能力越來越強。
現有技術中,數據包在多個協議棧實例之間分發時,采用公用的分發模塊以連接作為粒度進行數據分發,分發模塊可能成為系統的分發瓶頸,在負載均衡和負載故障恢復時需要維護大量的數據,消耗較多的系統時間,不利于負載的連接數據的快速恢復。在并行協議棧中如何快速進行負載均衡和故障恢復,是需要考慮解決的問題。
發明內容
本發明實施例提供一種并行用戶態協議棧的管理方法和協議棧系統,能夠克服協議棧共用一個分發模塊帶來的系統分發瓶頸,快速進行負載均衡和故障恢復,提高協議棧系統的性能。
第一方面,提供了一種并行用戶態協議棧的管理方法,該方法包括:監控用戶態協議棧中每個協議棧對應的實例的運行狀態,一個該實例對應于該用戶態協議棧中的一個協議棧;確定第一實例和第二實例,其中該第一實例為運行狀態異常的實例,該第二實例具備遷入該第一實例中至少一個待遷移負載的能力,一個該待遷移負載在該第一實例所對應的協議棧內對應于一個協議控制塊PCB,該PCB在共享資源池中對應于一個存儲著該待遷移負載連接參數的PCB,該待遷移負載的連接參數能夠用于重建該待遷移負載;根據該第一實例中至少一個待遷移負載在該共享資源池中所對應的PCB在該第二實例中重建該至少一個待遷移負載。
結合第一方面,在第一種可能的實現方式中,在該根據該第一實例中至少一個待遷移負載在共享資源池中所對應的協議控制塊PCB在該第二實例中重建該至少一個待遷移負載之前,該方法還包括:確定該第一實例中的至少一個待遷移負載。
結合第一方面的第一種可能的實現方式,在第二種可能的實現方式中,該實例的運行狀態包括實例的負載狀態和存活狀態,該監控用戶態協議棧中每個協議棧對應的實例的運行狀態包括:分別向該用戶態協議棧中每個協議棧對應的實例發送心跳消息并監控該心跳消息響應時延,并監控該用戶態協議棧中每個協議棧對應的實例在第一預定時間內的實例負載均值,以根據該心跳消息的響應時延和該實例負載均值確定該用戶態協議棧中每個協議棧對應的實例的運行狀態,其中,一條心跳消息對應于一個該實例;或者分別輪詢該用戶態協議棧中每個協議棧對應的實例的實例標識,并監控該用戶態協議棧中每個協議棧對應的實例在第一預定時間內的實例負載均值,以根據該實例標識和該實例負載均值確定該用戶態協議棧中每個協議棧對應的實例的運行狀態,其中,該實例標識用于表示實例的存活狀態,該實例標識存儲于共享內存區域或共享文件,一個該實例標識對應于一個該實例。
結合第一方面的第二種可能的實現方式,在第三種可能的實現方式中,確定第一實例具體實現為:確定距離發送心跳消息時刻達到第二預定時間后仍然未反饋心跳響應的實例為該第一實例;或者,確定第一預定時間內實例標識表示僵死或失效狀態的實例為該第一實例。
結合第一方面的第三種可能的實現方式,在第四種可能的實現方式中,確定第二實例具體實現為創建并確定新的實例為該第二實例;此時,根據該第一實例中至少一個待遷移負載在共享資源池中所對應的協議控制塊PCB在該第二實例中重建該至少一個待遷移負載具體實現為:根據該至少一個待遷移負載之第一負載在共享資源池中所對應的第一PCB在該第二實例中實現該第一負載與該用戶態協議棧的上層服務的對接,并將該第一負載在該第一實例中綁定的第一接收端擴展RSS隊列重綁定到該第二實例的該第一負載中,其中,該至少一個待遷移負載包括該第一實例的所有負載。
結合第一方面的第四種可能的實現方式,在第五種可能的實現方式中,該方法還包括:終止該第一實例。
結合第一方面的第二種可能的實現方式,在第六種可能的實現方式中, 確定第一實例具體實現為:確定第一預定時間內實例總負載均值大于第一預定閾值的實例為該第一實例。
結合第一方面的第六種可能的實現方式,在第七種可能的實現方式中,確定第二實例具體實現為:如果存在第一預定時間內實例總負載均值低于第二預定閾值的實例,則確定該第一預定時間內實例總負載均值低于第二預定閾值的一個或多個實例作為該第二實例,其中,遷入該第二實例的所有負載的負載值與該第二預定閾值之和小于該第一預定閾值。
結合第一方面的第七種可能的實現方式,在第八種可能的實現方式中,根據該第一實例中至少一個待遷移負載在共享資源池中所對應的協議控制塊PCB在該第二實例中重建該至少一個待遷移負載具體實現為:根據該第一實例的至少一個待遷移負載之第二負載在該共享資源池中所對應的第二PCB,將該第二負載在該第一實例中綁定的第二RSS隊列的綁定規則修改為綁定到該第二實例的第二負載中,以使得該第二實例實現從該第二RSS隊列進行數據包接收及處理的過程;或者,根據該第一實例的至少一個待遷移負載之第二負載在該共享資源池中所對應的第二PCB,在該第一實例中解除該第二負載在該第一實例中綁定的第二RSS隊列,并在該第二實例中將該第二RSS隊列綁定到該第二負載中,以使得該第二實例實現從該第二RSS隊列進行數據包接收及處理的過程。
結合第一方面的第七種可能的實現方式或第一方面的第八種可能的實現方式,在第九種可能的實現方式中,確定該第一實例中的至少一個待遷移負載具體實現為:確定該第一實例中的第三負載為該第一實例的待遷移負載,其中該第三負載在該第一實例中所綁定的第三RSS隊列滿足以下條件:當該第三RSS隊列綁定到該第二實例時該第二實例的連接數、接收字節數、發送字節數3個參數中至少有2個參數不大于該第一實例的相應參數。
結合第一方面的第六種可能的實現方式,在第十種可能的實現方式中,確定第二實例具體實現為:如果不存在預定時間內實例總負載均值低于第二預定閾值的實例,則創建并確定新的實例為該第二實例。
結合第一方面的第十種可能的實現方式,在第十一種可能的實現方式中,根據該第一實例中至少一個待遷移負載在共享資源池中所對應的協議控制塊PCB在該第二實例中重建該至少一個待遷移負載具體實現為:根據該第一實例的至少一個待遷移負載之第二負載在該共享資源池中所對應的第 二PCB在該第二實例中實現該第二負載與該用戶態協議棧的上層服務的對接以使得該第二實例實現與該第二負載對應的應用app的交互,并在該第一實例中解除該第二負載在該第一實例中綁定的第二RSS隊列,在該第二實例中將該第二RSS隊列綁定到該第二負載中,以使得該第二實例實現從該第二RSS隊列進行數據包接收及處理的過程。
結合第一方面的第十種可能的實現方式或第一方面的第十一種可能的實現方式,在第十二種可能的實現方式中,確定該第一實例中的至少一個待遷移負載具體實現為:確定該第一實例中的第三負載為該第一實例的待遷移負載,該第三負載在該第一實例中所綁定的第三RSS隊列滿足以下條件:該第三RSS隊列的連接數、接收字節數、發送字節數3個參數中都達到該第一實例的所有負載中對應參數的均值。
第二方面,提供了一種協議棧系統,該系統包括:監控單元,用于監控該協議棧系統的用戶態協議棧中每個協議棧對應的運行狀態,一個該實例對應于該用戶態協議棧中的一個協議棧;確定單元,用于確定第一實例和第二實例,該第一實例為運行狀態異常的實例,該第二實例具備遷入該第一實例中至少一個待遷移負載的能力,一個該待遷移負載在該第一實例所對應的協議棧內對應于一個協議控制塊PCB,該PCB在該協議棧系統的共享資源池中對應于一個存儲著該待遷移負載的連接參數的PCB,該待遷移負載的連接參數能夠用于重建該待遷移負載;負載遷移單元,用于根據該第一實例中至少一個待遷移負載在該共享資源池中所對應的PCB在該第二實例中重建該至少一個待遷移負載。
結合第二方面,在第一種可能的實現方式中,該確定單元還用于確定該第一實例中的至少一個待遷移負載。
結合第二方面的第一種可能的實現方式,在第二種可能的實現方式中,該實例的運行狀態包括實例的負載狀態和存活狀態,該監控單元具體用于:分別向該用戶態協議棧中每個協議棧對應的實例發送心跳消息并監控該心跳消息響應時延,并監控該用戶態協議棧中每個協議棧對應的實例在第一預定時間內的實例負載均值,以根據該心跳消息的響應時延和該實例負載均值確定該用戶態協議棧中每個協議棧對應的實例的運行狀態,其中,一條心跳消息對應于一個該實例;或者,分別輪詢該用戶態協議棧中每個協議棧對應的實例的實例標識,并監控該用戶態協議棧中每個協議棧對應的實例在第一 預定時間內的實例負載均值,以根據該實例標識和該實例負載均值確定該用戶態協議棧中每個協議棧對應的實例的運行狀態,其中,該實例標識用于表示實例的存活狀態,該實例標識存儲于共享內存區域或共享文件,一個該實例標識對應于一個該實例。
結合第二方面的第二種可能的實現方式,在第三種可能的實現方式中,在用于確定第一實例的過程中,該確定單元具體用于:確定距離發送心跳消息時刻達到第二預定時間后仍然未反饋心跳響應的實例為該第一實例;或者,確定第一預定時間內實例標識都表示僵死或失效狀態的實例為該第一實例。
結合第二方面的第三種可能的實現方式,在第四種可能的實現方式中,在用于確定第二實例的過程中,該確定單元具體用于創建并確定新的實例為該第二實例;該負載遷移單元具體用于根據該至少一個待遷移負載之第一負載在共享資源池中所對應的第一PCB在該第二實例中實現該第一負載與該用戶態協議棧的上層服務的對接,并將該第一負載在該第一實例中綁定的第一接收端擴展RSS隊列重綁定到該第二實例的該第一負載中,其中,該至少一個待遷移負載包括該第一實例的所有負載。
結合第二方面的第四種可能的實現方式,在第五種可能的實現方式中,該系統還包括:實例停止單元,用于終止該第一實例。
結合第二方面的第二種可能的實現方式,在第六種可能的實現方式中,在用于確定第一實例的過程中,該確定單元具體用于:確定第一預定時間內實例總負載均值大于第一預定閾值的實例為該第一實例。
結合第二方面的第六種可能的實現方式,在第七種可能的實現方式中,在用于確定該第二實例的過程中,該確定單元具體用于:如果存在第一預定時間內實例總負載均值低于第二預定閾值的實例,則確定預定時間內實例總負載均值低于第二預定閾值的一個或多個實例作為該第二實例,其中,遷入該第二實例的所有負載的負載值與該第二預定閾值之和小于該第一預定閾值。
結合第二方面的第七種可能的實現方式,在第八種可能的實現方式中,該負載遷移單元具體用于:根據該第一實例的至少一個待遷移負載之第二負載在該共享資源池中所對應的第二PCB,將該第二負載在該第一實例中綁定的第二RSS隊列的綁定規則修改為綁定到該第二實例的第二負載中,以使得 該第二實例實現從該第二RSS隊列進行數據包接收及處理的過程;或者,根據該第一實例的至少一個待遷移負載之第二負載在該共享資源池中所對應的第二PCB,在該第一實例中解除該第二負載在該第一實例中綁定的第二RSS隊列,并在該第二實例中將該第二RSS隊列綁定到該第二負載中,以使得該第二實例實現從該第二RSS隊列進行數據包接收及處理的過程。
結合第二方面的第七種可能的實現方式或第二方面的第八種可能的實現方式,在第九種可能的實現方式中,在用于確定該第一實例中的至少一個待遷移負載的過程中,該確定單元具體用于:確定該第一實例中的第三負載為該第一實例的待遷移負載,該第三負載在該第一實例中所綁定的第三RSS隊列滿足以下條件:當該第三RSS隊列綁定到該第二實例時該第二實例的連接數、接收字節數、發送字節數3個參數中至少有2個參數不大于該第一實例的相應參數。確定該第一實例中的至少一個待遷移負載具體實現為:確定該第一實例中的第三負載為該第一實例的待遷移負載,其中該第三負載在該第一實例中所綁定的第三RSS隊列滿足以下條件:當該第三RSS隊列綁定到該第二實例時該第二實例的連接數、接收字節數、發送字節數3個參數中至少有2個參數不大于該第一實例的相應參數。
結合第二方面的第六種可能的實現方式,在第十種可能的實現方式中,在用于確定第二實例的過程中,該確定單元具體用于:如果不存在預定時間內實例總負載均值低于第二預定閾值的實例,則創建并確定新的實例為該第二實例。
結合第二方面的第十種可能的實現方式,在第十一種可能的實現方式中,該負載遷移單元具體用于:根據該第一實例的至少一個待遷移負載之第二負載在該共享資源池中所對應的第二PCB在該第二實例中實現該第二負載與該用戶態協議棧的上層服務的對接以使得該第二實例實現與該第二負載對應的應用app的交互,并在該第一實例中解除該第二負載在該第一實例中綁定的第二RSS隊列,在該第二實例中將該第二RSS隊列綁定到該第二負載中,以使得該第二實例實現從該第二RSS隊列進行數據包接收及處理的過程。根據該第一實例中至少一個待遷移負載在共享資源池中所對應的協議控制塊PCB在該第二實例中重建該至少一個待遷移負載具體實現為:根據該第一實例的至少一個待遷移負載之第二負載在該共享資源池中所對應的第二PCB在該第二實例中實現該第二負載與該用戶態協議棧的上層服務的 對接以使得該第二實例實現與該第二負載對應的應用app的交互,并在該第一實例中解除該第二負載在該第一實例中綁定的第二RSS隊列,在該第二實例中將該第二RSS隊列綁定到該第二負載中,以使得該第二實例實現從該第二RSS隊列進行數據包接收及處理的過程。
結合第二方面的第十種可能的實現方式或第二方面的第十一種可能的實現方式,在第十二種可能的實現方式中,在用于確定該第一實例中的至少一個待遷移負載的過程中,該確定單元具體用于:
確定該第一實例中的第三負載為該第一實例的待遷移負載,該第三負載在該第一實例中所綁定的第三RSS隊列滿足以下條件:該第三RSS隊列的連接數、接收字節數、發送字節數3個參數中都達到該第一實例的所有負載中對應參數的均值。確定該第一實例中的至少一個待遷移負載具體實現為:確定該第一實例中的第三負載為該第一實例的待遷移負載,該第三負載在該第一實例中所綁定的第三RSS隊列滿足以下條件:該第三RSS隊列的連接數、接收字節數、發送字節數3個參數中都達到該第一實例的所有負載中對應參數的均值。
基于以上技術方案,本發明實施例的并行用戶態協議棧的管理方法和協議棧系統,通過根據異常實例中待遷移負載在共享資源池對應的PCB在具備遷入負載能力的實例中重建待遷移負載,能夠克服協議棧共用一個分發模塊帶來的系統分發瓶頸,快速進行負載均衡和故障恢復,從而提高協議棧系統的性能。
附圖說明
為了更清楚地說明本發明實施例的技術方案,下面將對實施例或現有技術描述中所需要使用的附圖作簡單地介紹,顯而易見地,下面描述中的附圖僅僅是本發明的一些實施例,對于本領域普通技術人員來講,在不付出創造性勞動的前提下,還可以根據這些附圖獲得其他的附圖。
圖1是本發明實施例并行用戶態協議棧的管理方法流程圖。
圖2是本發明實施例并行用戶態協議棧的另一管理方法流程圖。
圖3是本發明實施例故障線程恢復的流程示意圖。
圖4是本發明實施例線程負載均衡的流程示意圖。
圖5是本發明實施例線程負載均衡的另一流程示意圖。
圖6是本發明實施例協議棧系統的結構示意圖。
圖7是本發明實施例協議棧系統的另一結構示意圖。
圖8是本發明實施例協議棧系統的再一結構示意圖。
具體實施方式
下面將結合本發明實施例中的附圖,對本發明實施例中的技術方案進行清楚、完整地描述,顯然,所描述的實施例是本發明一部分實施例,而不是全部的實施例。基于本發明中的實施例,本領域普通技術人員在沒有作出創造性勞動前提下所獲得的所有其他實施例,都屬于本發明保護的范圍。
為了方便理解本發明實施例,首先在此介紹本發明實施例描述中會引入的幾個要素。
用戶棧與內核棧:內核在創建進程/線程的時候,會為進程/線程創建相應的堆棧。每個進程/線程會有兩個棧,一個用戶棧,存在于用戶空間,一個內核棧,存在于內核空間。當進程/線程在用戶空間運行時,cpu堆棧指針寄存器里面的內容是用戶堆棧地址,使用用戶棧;當進程/線程在內核空間時,cpu堆棧指針寄存器里面的內容是內核棧空間地址,使用內核棧。
用戶態協議棧:協議棧是操作系統的網絡處理部分通常都會包含的模塊。當與網絡處理部分相關的進程/線程在用戶空間運行時,cpu堆棧指針寄存器指向的協議棧即為用戶態協議棧,本發明實施例中,用戶態協議棧指在用戶空間運行的所有協議棧的集合。
連接數:連接的數量。連接作為CPU負載的最終載體,具有直觀意義。而且,接收端(Recv)接收到數據時需要進行連接查找,進而轉入連接狀態處理,因此考慮平衡各協議棧線程連接數量,對優化查找速度也很有意義。
接收字節數(Recv Bytes):接收端擴展(Receive Side Scaling,RSS)本身主要是針對Recv端的分組發送(Packets dispatch),因此接收包的數據量很能反映對協議棧線程負載的影響。
發送字節數(Send Bytes):發送分組(Send Packets)由于受到Recv數據與連接親和性關系的影響,也影響協議棧處理相關連接的Send負載。
圖1是本發明實施例并行協議棧的處理方法流程圖,圖1的方法由協議棧系統執行。
101,監控用戶態協議棧中每個協議棧對應的實例的運行狀態。
其中,一個該實例對應于該用戶態協議棧中的一個協議棧。
應理解,本發明實施例中,實例可以是協議棧系統內的一個進程或一個線程。內核在創建進程/線程的時候,會為進程/線程創建相應的堆棧。每個進程/線程會有兩個棧,一個用戶棧,存在于用戶空間,一個內核棧,存在于內核空間。
應理解,本發明實施例中,用戶態協議棧用于表示存在于用戶空間的所有協議棧。在用戶態協議棧中,可包含一個或多個協議棧,每個協議棧與協議棧系統的一個實例形成一一對應的關系。
應理解,本發明實施例中,實例的運行狀態包括實例的負載狀態和存活狀態。
應理解,實例的負載狀態是指當前實例對系統資源的占用情況,通常情況下指該實例對CPU的資源利用率。
102,確定第一實例和第二實例。
其中,第一實例為運行狀態異常的實例,第二實例該第二實例具備遷入該第一實例中至少一個待遷移負載的能力。
另外,一個該待遷移負載在該第一實例所對應的協議棧內對應于一個協議控制塊PCB,該PCB在共享資源池中對應于一個存儲著該待遷移負載的連接參數的PCB,該待遷移負載的連接參數能夠用于重建該待遷移負載。
應理解,本發明實施例中,一個負載對應于一個PCB,一個負載在數據處理上等于一個PCB所對應的連接的數據處理量。
當一個實例被創建并初始化后,相應地會生成一個協議棧。如果實例內還不存在任何負載,則協議棧中也不會有PCB的信息。實例中有幾個負載,其對應的協議棧中就會有相同個數的PCB。
另外,本發明實施例中,協議棧只是存儲著PCB的一些基本信息,例如PCB標識等。共享資源池中存儲著PCB的關鍵數據結構,主要包括連接結構體信息,該連接結構體信息對快速響應恢復連接具有關鍵作用。
應理解,運行狀態異常的實例,一般可包括存活狀態異常的實例或負載狀態異常的實例。
存活狀態異常的實例可包括僵死或失效的實例。
負載狀態異常的實例,可包括負載高位運行的實例。在判斷實例是否是負載高位運行時,可通過比較一段時間內實例總負載均值與預定閾值的關系 來確定實例是否處于負載高位運行狀態。
103,根據該第一實例中至少一個待遷移負載在該共享資源池中所對應的協議控制塊PCB在該第二實例中重建該至少一個待遷移負載。
本發明實施例中,根據異常實例中待遷移負載在共享資源池對應的PCB在具備遷入負載能力的實例中重建待遷移負載,能夠克服協議棧共用一個分發模塊帶來的系統分發瓶頸,快速進行負載均衡和故障恢復,從而提高協議棧系統的性能。
圖2是本發明實施例并行用戶態協議棧的另一管理方法流程圖。可選地,如圖2所示,在步驟103之前,該方法還可包括步驟104:確定該第一實例中的至少一個待遷移負載。
可選地,步驟101具體可實現為:分別向該用戶態協議棧中每個協議棧對應的實例發送心跳消息并監控該心跳消息響應時延,并監控該用戶態協議棧中每個協議棧對應的實例在第一預定時間內的實例負載均值,以根據該心跳消息的響應時延和該實例負載均值確定該用戶態協議棧中每個協議棧對應的實例的運行狀態,其中,一條心跳消息對應于一個該實例;或者,分別輪詢該用戶態協議棧中每個協議棧對應的實例的實例標識,并監控該用戶態協議棧中每個協議棧對應的實例在第一預定時間內的實例負載均值,以根據該實例標識和該實例負載均值確定該用戶態協議棧中每個協議棧對應的實例的運行狀態,其中,該實例標識用于表示實例的存活狀態,該實例標識存儲于共享內存區域或共享文件,一個該實例標識對應于一個該實例。
可選地,作為一個實施例,步驟102中確定第一實例具體實現為:確定距離發送心跳消息時刻達到第二預定時間后仍然未反饋心跳響應的實例為該第一實例;或者,確定第一預定時間內實例標識表示僵死或失效狀態的實例為該第一實例。
在本實施例中,步驟102確定第二實例的過程具體可實現為:創建并確定新的實例為該第二實例。此時,步驟103具體實現為:根據該至少一個待遷移負載之第一負載在共享資源池中所對應的第一PCB在該第二實例中實現該第一負載與該用戶態協議棧的上層服務的對接,并將該第一負載在該第一實例中綁定的第一接收端擴展RSS隊列重綁定到該第二實例的該第一負載中,其中,該至少一個待遷移負載包括該第一實例的所有負載。
可選地,作為另一實施例,步驟102中確定第一實例的過程具體實現為: 確定第一預定時間內實例總負載均值大于第一預定閾值的實例為該第一實例。
可選地,在本實施例的一種具體實現方式中,步驟102中確定第二實例具體可實現為:如果存在第一預定時間內實例總負載均值低于第二預定閾值的實例,則確定預定時間內實例總負載均值低于第二預定閾值的一個或多個實例作為該第二實例,其中,遷入該第二實例的所有負載的負載值與該第二預定閾值之和小于該第一預定閾值。
進一步地,在當前的具體實現方式中,步驟103具體可實現為:根據該第一實例的至少一個待遷移負載之第二負載在該共享資源池中所對應的第二PCB,將該第二負載在該第一實例中綁定的第二RSS隊列的綁定規則修改為綁定到該第二實例的第二負載中,以使得該第二實例實現從該第二RSS隊列進行數據包接收及處理的過程;或者,根據該第一實例的至少一個待遷移負載之第二負載在該共享資源池中所對應的第二PCB,在該第一實例中解除該第二負載在該第一實例中綁定的第二RSS隊列,并在該第二實例中將該第二RSS隊列綁定到該第二負載中,以使得該第二實例實現從該第二RSS隊列進行數據包接收及處理的過程。
另外,在當前的具體實現方式中,步驟104具體可實現為:確定該第一實例中的第三負載為該第一實例的待遷移負載,該第三負載在該第一實例中所綁定的第三RSS隊列滿足以下條件:當該第三RSS隊列綁定到該第二實例時該第二實例的連接數、接收字節數、發送字節數3個參數中至少有2個參數不大于該第一實例的相應參數。
可選地,在本實施例的一種具體實現方式中,步驟102中確定第二實例具體可實現為:如果不存在預定時間內實例總負載均值低于第二預定閾值的實例,則創建并確定新的實例為該第二實例。
進一步地,在當前的具體實現方式中,步驟103具體可實現為:根據該第一實例的至少一個待遷移負載之第二負載在該共享資源池中所對應的第二PCB在該第二實例中實現該第二負載與該用戶態協議棧的上層服務的對接以使得該第二實例實現與該第二負載對應的應用app的交互,并在該第一實例中解除該第二負載在該第一實例中綁定的第二RSS隊列,在該第二實例中將該第二RSS隊列綁定到該第二負載中,以使得該第二實例實現從該第二RSS隊列進行數據包接收及處理的過程。
另外,在當前的具體實現方式下,步驟104具體可實現為:確定該第一實例中的第三負載為該第一實例的待遷移負載,該第三負載在該第一實例中所綁定的第三RSS隊列滿足以下條件:該第三RSS隊列的連接數、接收字節數、發送字節數3個參數中都達到該第一實例的所有負載中對應參數的均值。
下面,將結合具體的實施例,對本發明實施例的方法作進一步的描述。下述具體實施例中,以協議棧線程作為用戶態協議棧的實例進行描述。
圖3是本發明實施例故障線程恢復的流程示意圖。
在圖3所示的場景中,用戶態協議棧包含正在運行的應用所對應的多個協議棧。協議棧內協議控制塊(Protocol Control Block,PCB)的關鍵數據結構存儲于系統內存的共享資源池中。共享資源池在圖3表現為協議控制塊分配池(PCB Alloc),存儲著PCB的關鍵數據結構,主要包括連接結構體信息,可用于快速響應恢復連接。協議棧中,PCB作為表示連接的主要數據結構,因此可以將其作為協議棧工作負載的主要衡量指標。如圖3所示,用戶態協議棧可包括協議棧stack1、stack2和stack3。其中,stack1所對應的線程包括2個負載,其對應的PCB分別為PCB1和PCB4;stack2所對應的線程包括1個負載,其對應的PCB為PCB3;stack3所對應的線程包括1個負載,其對應的PCB為PCB2。
S301,協議棧系統監控用戶態協議棧中每個協議棧對應的實例的運行狀態。
協議棧系統可通過多種方式監控用戶態協議棧中每個協議棧對應的實例的運行狀態。其中,實例的運行狀態可包括實例的負載狀態和存活狀態。
實例的存活狀態包括實例是否僵死(或失效)。對于僵死(或失效)的實例,協議棧系統應啟動實例恢復流程。
實例的負載狀態包括實例是處于高位運行、低位運行還是其它。其中,低位運行的實例,具備遷入負載的能力。對于高位運行的實例,應啟動負載均衡流程,將實例內的部分負載遷出。
本發明實施例中,協議棧系統通過向每個協議棧對應的實例發送心跳消息并監控每個協議棧對應的實例對各自的心跳消息的響應時延以及監控第一預定時間內的實例負載均值來監控實例的運行狀態。其中,一條心跳消息對應于一個該實例。
如圖3所示,協議棧系統通過一個公共線程(Common Thread)對線程進行監控。本發明實施例中,Common Thread可包括一個看門狗(Watch Dog)模塊,用于實現對線程的計時監控。Common Thread可通過Watch Dog可分別向用戶態協議棧的每個協議棧對應的線程發送心跳(keep alive)消息。用戶態協議棧的每個協議棧對應的線程接收到心跳消息后,可反饋心跳響應。此外,Common Thread還可監控線程的負載情況,可通過Watch Dog進行監控,或者通過訪問線程的負載參數獲取,其具體實現可參考現有技術,本發明實施例在此不再贅述。
Common Thread可監控線程的存活狀態。Common Thread可向用戶態協議棧的每個協議棧對應的線程發送心跳消息并監控每個協議棧對應的對各自的心跳消息的響應時延。如果Common Thread在向線程發送心跳消息后的第二預定時間內接收到線程反饋的心跳響應,則Common Thread可認為該線程的存活狀態為有效狀態(或活動狀態);反之,如果Common Thread在向線程發送心跳消息后的第二預定時間內沒有接收到線程反饋的心跳響應,則Common Thread可認為該線程的存活狀態為僵死或失效狀態。其中,該第二預定時間由協議棧系統確定。
另外,Common Thread還可監控線程的負載狀態。應理解,為避免瞬時峰值及瞬時低值導致對負載狀態的誤判,可取一段時間內的線程負載均值作為線程負載狀態的判斷標準。Common Thread可確定第一預定時間內線程的總負載均值大于第一預定閾值的實例為高位運行的線程,Common Thread還可確定第一預定時間內線程總負載均值低于第二預定閾值的線程為低位運行線程。其中,第一預定時間、第一預定閾值、第二預定閾值均可由協議棧系統確定。
S302,協議棧系統指示創建新的實例作為第二實例。
當協議棧系統監控到僵死(或失效)的實例后,可創建一個新的實例,并確定該新建實例為第二實例,用于恢復僵死(或失效)的實例。
不妨假設圖3中stack1所對應的線程在第二預定時間內沒有反饋心跳響應,則此時Common Thread可確認stack1所對應的線程為僵死(或失效)的線程。
此時,Common Thread可新建一個線程,并在用戶態協議棧中建立相應的棧元素stack4,完成線程的初始化工作。線程初始化的具體流程可參考現 有技術,本發明實施例在此不再贅述。
S303,第二實例綁定RSS隊列。
第二實例可獲取第一實例中的所有負載對應的PCB的標識信息,從共享資源池中獲取對應的PCB信息,并基于共享資源池中對應的PCB信息,將原先第一實例所綁定的RSS隊列綁定到第二實例中。
在圖3中,共享資源池為協議控制塊分配池(PCB Alloc),存儲著協議棧的實例中所有負載的PCB。PCB中包括連接的主要數據結構。
根據第一實例中的負載對應的PCB
第二實例可根據第一實例中的負載對應的PCB,獲取第一實例中的負載所綁定的RSS隊列,并將第一實例中的負載所綁定的RSS隊列綁定到第二實例中。
如圖3所示,stack4所對應的線程從stack1或stack1所對應的線程中獲取負載所對應的協議控制塊PCB1和PCB4,并從PCB1和PCB4中獲取綁定到stack1所對應的線程的的RSS隊列信息,并將該RSS隊列重綁定到stack4所對應的線程中。
S304,第二實例與用戶態協議棧的上層服務對接。
第二實例還可根據第一實例中的負載對應的PCB建立與用戶態協議棧的上層服務的對接。
具體地,如圖3所示,stack4所對應的線程可根據PCB Alloc中的PCB1和PCB4,重新綁定stack4所對應的線程與上層套接字應用接口層(SocketAPI)中的消息盒子(msg box),完成線程與協議棧上層服務的重新對接,從而恢復線程與應用(app)的交互。
另外,應理解,步驟S303和步驟S304之間不存在先后的關系,新建實例在完成初始化之后,可先綁定RSS隊列,也可先完成與協議棧上層服務的重新對接,本發明實施例在此不作限制。
S305,協議棧系統銷毀第一實例。
在第二實例完成對第一實例的恢復過程后,可銷毀第一實例。
基于系統的穩定性考慮,在恢復過程完成后,原有僵死(或失效)的實例需要被銷毀。
如圖3所示,當stack1所對應的線程的負載在stack4所對應的線程中重建以后,stack1所對應的線程應被銷毀,其對應的棧stack1也會被釋放。
本發明實施例中,協議棧系統基于僵死(或失效)的實例的負載在共享資源池的PCB在新建立的實例中重建負載,可以對失效協議棧負責的連接信息快速接管,快速恢復,下至網卡信息,上至與應用(app)交互的信息,都能快速恢復,損失很小。
另外,本發明實施例中,協議控制塊信息,保持一種全局共享的存儲機制,對于恢復處理中的連接非常有用,尤其對傳輸控制協議(Transmission Control Protocol TCP)監聽(Listen)、UDP連接、超文本傳輸協議(HypertextTransfer Protocol,HTTP)1.1協議中的長連接等對短暫中斷不敏感的連接,可以達到無損恢復的目的;而對于其他類的TCP連接等,可能由于中斷導致超時斷開或者TCP窗口進入慢速啟動的模式,但這些都是協議棧本身可以正確處理恢復到正確的狀態,對系統整體狀態無影響。
另外,在圖3的實施例中,也可從現有低位運行的線程中選擇一個或多個作為第二實例,并在第二實例中重建第一實例的負載,然后再執行銷毀第一實例的操作。
圖4是本發明實施例線程負載均衡的流程示意圖。
在圖4所示的場景中,用戶態協議棧包含正在運行的應用所對應的多個協議棧。協議棧內協議控制塊(Protocol Control Block,PCB)的關鍵數據結構存儲于系統內存的共享資源池中。共享資源池在圖4表現為協議控制塊分配池(PCB Alloc),存儲著PCB的關鍵數據結構,主要包括連接結構體信息,可用于快速響應恢復連接。協議棧中,PCB作為表示連接的主要數據結構,因此可以將其作為協議棧工作負載的主要衡量指標。如圖4所示,用戶態協議棧可包括協議棧stack1、stack2、stack3、stack4。其中,stack1所對應的線程內存在2個負載,其對應的PCB分別為PCB1和PCB4;stack2所對應的線程內存在1個負載,其對應的PCB為PCB3;stack3所對應的線程內存在1個負載,其對應的PCB為PCB2;stack4所對應的線程內存在1個負載,其對應的PCB為PCB5。
S401,協議棧系統監控用戶態協議棧中每個協議棧對應的實例的運行狀態。
步驟S401與圖3的步驟S301類似,本發明實施例在此不再贅述。
S402,協議棧系統分別向第一實例和第二實例發送指示消息。
協議棧系統根據監控的結果,可確定需要遷出負載的實例和能夠遷入負 載的實例。
如果用戶態協議棧的多個實例中存在至少一個高位運行的實例,則可確定該至少一個高位運行的實例為第一實例。
同時,如果用戶態協議棧的多個實例中存在至少一個低位運行的實例,則可確定該至少一個低位運行的實例中的一個或多個實例為第二實例。
如圖4所示,不妨假設步驟S401中,協議棧系統通過公共線程(Common Thread)監控到stack1所對應的線程高位運行,stack4和stack2所對應的線程低位運行,也就是說stack1所對應的線程的負載需要遷出,stack4和stack2所對應的線程具備遷入負載的能力。
此時,Common Thread可確定stack1所對應的線程為第一實例,并確定stack4或stack2所對應的線程為第二實例,或者確定stack4和stack2所對應的線程都為第二實例。由于stack1所對應的線程只有PCB1和PCB4對應的兩個負載,顯然只要遷出一個負載即可,只需要一個第二實例。本發明實施例中,選中stack4所對應的線程為第二實例。
首先,Common Thread可向stack1所對應的線程發送第一指示(notify)消息,指示stack1所對應的線程確定遷出負載并解除對遷出負載所對應的RSS隊列的綁定。
stack1所對應的線程接收到第一指示消息后,首先要確定待遷出負載。
要達到負載均衡,必然要慎重選擇重新綁定的問題:對遷出負載的線程達到了有效減負的目的;對遷入的線程,不能過分導致單方面負載很高,因此需要在遷入和遷出線程間達到1個平衡。
上層,可以進行各隊列對RSS隊列負載的影響進行排序,進而更好的進行負載均攤。并綜合考慮發送和接收等各方面影響。
TCP/UDP連接,以及要處理的其他類型協議,有各自的特點,每個連接的雙向負載是變化的,生存時間也是不確定的,非常精細的劃分和配比對系統的開銷很大。
因此,綜合考慮,希望利用最小的開銷,達到最好的負載均衡效果,采用以下幾個維度來衡量重新綁定的選取過程:連接數,接收字節數(Recv Bytes)和發送字節數(Send Bytes)。
連接數:連接的數量,連接作為CPU負載的最終載體,具有直觀意義;而且,Recv到數據時需要進行連接查找,進而轉入連接狀態處理,因此考 慮平衡各協議棧線程連接數量,對優化查找速度也很有意義。
Recv Bytes:rss本身主要是針對Recv端的數據包調度(Packets Dispatch),因此接收包的數據量很能反映對協議棧線程負載的影響。
Send Bytes:發送數據包(Send Packets)由于受到Recv端數據與連接親和性關系的影響,也會影響協議棧處理相關連接的Send負載。
本發明實施例中,負載均衡在原有線程間進行。因此,遷出的負載應滿足:遷移前負載輕的線程(第二實例),遷移后的負載總值不應高于遷出線程(第一實例)未遷移前的負載總值;遷移前負載輕的線程(第二實例),遷移后綁定的所有RSS隊列的連接數,Recv Bytes和Send Bytes3個參數中至少有2個參數的值不應超出遷出線程(第一實例)未遷移前的對應參數值。
不妨假設stack1所對應的線程中PCB4所對應的負載滿足遷出負載的判定條件,則第一實例可將確定PCB4所對應的負載為待遷出負載。
stack1所對應的線程可將PCB4的標識或PCB4所對應的負載的標識反饋給Common Thread,并執行步驟S403。
另外,Common Thread在接收到stack1所對應的線程的反饋后,可向stack4所對應的線程發送第二指示消息,指示stack4所對應的線程準備遷入負載。該第二指示消息中可攜帶待遷入負載的信息。
S403,第一實例對待遷移負載的隊列解除綁定。
如圖4所示,stack1所對應的線程在確定PCB4對應的負載為待遷出負載后,可解綁定PCB4所對應的負載在stack1所對應的線程所綁定的RSS隊列。
S404,第二實例綁定待遷移負載的隊列。
第二實例在收到第二指示消息后,可根據待遷移負載在共享資源池中的PCB,將待遷移負載在第一實例所綁定的RSS隊列綁定到第二實例中,并將接收從該RSS隊列進行接收數據包的過程,以及由此產生的數據包處理過程。
本發明實施例中,stack4所對應的線程可根據第二指示消息中PCB4的標識信息或PCB4所對應的負載的標識信息,從協議控制塊分配池PCB Alloc中獲取PCB4的信息并基于PCB4的信息在stack4所對應的線程重建負載,并將PCB4所對應的負載在stack1所對應的線程中綁定的RSS隊列重綁定到 stack4所對應的線程PCB4對應的負載上。
本發明實施例中,通過待遷移負載在共享資源池的PCB在原有實例間進行負載均衡,避免了負載均衡時不必要的數據傳輸,提高了負載均衡的效率。
另外,本發明實施例中,還可以直接修改待遷移負載所綁定的RSS隊列的綁定規則,直接將遷移負載所綁定的RSS隊列的綁定規則修改為綁定到第二實例對應的負載上,避免第一實例解綁定和第二實例綁定的操作。監控實例狀態和確定高位運行實例的待遷移負載的步驟可參考本發明實施例的相關過程,本發明實施例在此不再贅述。
圖5是本發明實施例線程負載均衡的另一流程示意圖。
在圖5所示的場景中,用戶態協議棧包含正在運行的應用所對應的多個協議棧。協議棧內協議控制塊(Protocol Control Block,PCB)的關鍵數據結構存儲于系統內存的共享資源池中。共享資源池在圖5表現為協議控制塊分配池(PCB Alloc),存儲著PCB的關鍵數據結構,主要包括連接結構體信息,可用于快速響應恢復連接。協議棧中,PCB作為表示連接的主要數據結構,因此可以將其作為協議棧工作負載的主要衡量指標。如圖5所示,用戶態協議棧可包括協議棧stack1、stack2和stack3。其中,stack1所對應的線程包括2個負載,其對應的PCB分別為PCB1和PCB4;stack2所對應的線程包括1個負載,其對應的PCB為PCB3;stack3所對應的線程包括1個負載,其對應的PCB為PCB2。
S501,協議棧系統監控用戶態協議棧中每個協議棧對應的實例的運行狀態。
步驟S501與圖3的步驟S301類似,本發明實施例在此不再贅述。
S502,協議棧系統向第一實例發送指示消息。
協議棧系統根據監控的結果,可確定需要遷出負載的實例和能夠遷入負載的實例。
如果用戶態協議棧中每個協議棧對應的實例中存在至少一個高位運行的實例,則可確定該至少一個高位運行的實例為第一實例。
如圖5所示,不妨假設步驟S501中,協議棧系統通過公共線程(Common Thread)監控到stack1所對應的線程高位運行,stack2和stack3所對應的線程不具備遷入負載的能力。
首先,Common Thread可向stack1所對應的線程發送第一指示(notify)消息,指示stack1所對應的線程確定遷出負載并解除對遷出負載所綁定的RSS隊列的綁定。
stack1所對應的線程接收到第一指示消息后,首先要確定待遷出負載。
類似的,為了利用最小的開銷,達到最好的負載均衡效果,可采用以下幾個維度來衡量重新綁定的選取過程:連接數,Recv Bytes和Send Bytes三個參數。
本發明實施例中,負載均衡在從原有線程遷入新建線程。在挑選遷出負載時,應選擇連接數,Recv Bytes和Send Bytes三個參數整體上達到均值的RSS隊列所對應的負載進行遷移。或者,可以分別對連接數,Recv Bytes和Send Bytes三個參數設定三個預定參數閾值,選擇三個參數整體上達到對應的預定參數閾值的負載作為待遷出負載。
不妨假設PCB4對應的負載所綁定的RSS滿足遷出負載的判定條件,則stack1所對應的線程可將PCB4的標識或PCB4所對應的負載的標識反饋給Common Thread,并解綁定PCB4所對應的負載在stack1所對應的線程所綁定的RSS隊列。
stack1所對應的線程確定待遷移負載后,可向Common Thread反饋待遷移負載的信息,例如待遷移負載的標識,或者待遷移負載對應的PCB的標識,等等,并執行步驟S504。
同時,如果用戶態協議棧的多個實例中不存在至少一個低位運行的實例,則協議棧系統可指示創建新的實例作為第二實例,即執行步驟S503。
S503,協議棧系統指示創建新的實例作為第二實例。
當協議棧系統監控到高位運行的實例且現有實例中不存在低位運行的實例,協議棧系統可創建一個新的實例,并確定該新建實例為第二實例,用于遷入負載以實現負載均衡。
如圖5所示,協議棧系統通過Common Thread發送一條新建線程(new stack)的指令,創建新的線程,即stack4所對應的線程,并確定stack4所對應的線程為第二實例,同時完成對新建線程的初始化操作。線程初始化的具體流程可參考現有技術,本發明實施例在此不再贅述。
S504,第一實例對待遷移負載的隊列解除綁定。
如圖5所示,stack1所對應的線程在確定PCB4對應的負載為待遷出負 載后,可解綁定PCB4所對應的負載在stack1所對應的線程所綁定的RSS隊列。
S505,第二實例綁定待遷移負載的隊列。
stack4所對應的線程可根據協議控制塊分配池(PCB Alloc)中的PCB4的信息,將PCB4所對應的負載在stack1所對應的線程中所綁定的RSS隊列綁定到第二實例中。此時,stack4所對應的線程將接收從這個隊列進行接收數據包的過程,以及由此產生的數據包處理過程。
S506,第二實例與協議棧上層服務實現對接。
第二實例為新建實例,還需完成與用戶態協議棧的上層服務的對接,才能實現與負載對應的應用的交互。
本發明實施例中,stack4所對應的線程可根據協議控制塊分配池中的PCB4的信息,重新綁定stack4所對應的線程與上層套接字應用接口層(Socket API)中的消息盒子(msg box),完成線程與協議棧上層服務的重新對接,從而恢復線程與應用(app)的交互。
應理解,步驟S505和步驟S506之間不存在時間上的先后關系。
本發明實施例中,通過待遷移負載在共享資源池的PCB在新建實例遷入高負載實例的負載,從而實現負載均衡,避免了負載均衡時不必要的數據傳輸,提高了負載均衡的效率。
除了上述圖3-圖5所示實施例的監控實例運行狀態的方法外,協議棧系統還可通過其它方式來監控實例的運行狀態。本發明的另一種監控方式,協議棧系統可用實例標識來表征實例的存活狀態,并通過監控實例的實例標識監控實例的存活狀態,通過預定時間內實例的總負載均值來監控實例的負載狀態,從而實現對實例的運行狀態的監控。其中,每個實例標識對應于協議棧的一個實例,該實例標識可存儲于內存共享空間,或者是共享文件,協議棧系統可通過輪詢計時器輪詢實例的實例標識。協議棧系統可用輪詢計時器代替圖3-圖5中的Watch Dog,通過輪詢計時器輪詢線程的存活標識以實現對線程的存活狀態的監控。其中,線程的存活標識可存儲于內存共享空間,或者是共享文件,并與線程一一對應。另外,對實例的負載監控及實例負載遷移、負載重建的具體實現可參考圖3-圖5所示的實施例,本發明實施例在此不再贅述。當然,還可能存在其它監控實例運行狀態的方式,本發明實施例對此不作限制。
圖6是本發明實施例協議棧系統600的結構示意圖。協議棧系統600可包括監控單元601、確定單元602和負載遷移單元603。
監控單元601,用于監控用戶態協議棧中每個協議棧對應的實例的運行狀態。
其中,一個該實例對應于該用戶態協議棧中的一個協議棧。
應理解,本發明實施例中,實例可以是協議棧系統內的一個進程或一個線程。內核在創建進程/線程的時候,會為進程/線程創建相應的堆棧。每個進程/線程會有兩個棧,一個用戶棧,存在于用戶空間,一個內核棧,存在于內核空間。
應理解,本發明實施例中,用戶態協議棧用于表示存在于用戶空間的所有協議棧。在用戶態協議棧中,可包含一個或多個協議棧,每個協議棧與協議棧系統的一個實例形成一一對應的關系。
應理解,本發明實施例中,實例的運行狀態包括實例的負載狀態和存活狀態。
確定單元602,用于確定第一實例和第二實例。
其中,第一實例為運行狀態異常的實例,第二實例該第二實例具備遷入該第一實例中至少一個待遷移負載的能力。
另外,一個該待遷移負載在該第一實例所對應的協議棧內對應于一個協議控制塊PCB,該PCB在共享資源池中對應于一個存儲著該待遷移負載的連接參數的PCB,該待遷移負載的連接參數能夠用于重建該待遷移負載。
應理解,本發明實施例中,一個負載對應于一個PCB,一個負載在數據處理上等于一個PCB所對應的連接的數據處理量。
當一個實例被創建并初始化后,相應地會生成一個協議棧。如果實例內還不存在任何負載,則協議棧中也不會有PCB的信息。實例中有幾個負載,其對應的協議棧中就會有相同個數的PCB。
另外,本發明實施例中,協議棧只是存儲著PCB的一些基本信息,例如PCB標識等。共享資源池中存儲著PCB的關鍵數據結構,主要包括連接結構體信息,該連接結構體信息對快速響應恢復連接具有關鍵作用。
應理解,運行狀態異常的實例,一般可包括存活狀態異常的實例或負載狀態異常的實例。
存活狀態異常的實例可包括僵死或失效的實例。
負載狀態異常的實例,可包括負載高位運行的實例。在判斷實例是否是負載高位運行時,可通過比較一段時間內實例總負載均值與預定閾值的關系來確定實例是否處于負載高位運行狀態。
負載遷移單元603,用于根據該第一實例中至少一個待遷移負載在共享資源池中所對應的協議控制塊PCB在該第二實例中重建該至少一個待遷移負載。
本發明實施例中,協議棧系統600根據異常實例中待遷移負載在共享資源池對應的PCB在具備遷入負載能力的實例中重建待遷移負載,能夠克服協議棧共用一個分發模塊帶來的系統分發瓶頸,快速進行負載均衡和故障恢復,從而提高協議棧系統的性能。
可選地,確定單元602還可用于確定該第一實例中的至少一個待遷移負載。
可選地,監控單元601具體用于:分別向該用戶態協議棧中每個協議棧對應的實例發送心跳消息并監控該心跳消息響應時延,并監控該用戶態協議棧中每個協議棧對應的實例在第一預定時間內的實例負載均值,以根據該心跳消息的響應時延和該實例負載均值確定該用戶態協議棧中每個協議棧對應的實例的運行狀態,其中,一條心跳消息對應于一個該實例;或者,分別輪詢該用戶態協議棧中每個協議棧對應的實例的實例標識,并監控該用戶態協議棧中每個協議棧對應的實例在第一預定時間內的實例負載均值,以根據該實例標識和該實例負載均值確定該用戶態協議棧中每個協議棧對應的實例的運行狀態,其中,該實例標識用于表示實例的存活狀態,該實例標識存儲于共享內存區域或共享文件,一個該實例標識對應于一個該實例。
可選地,作為一個實施例,在用于確定第一實例的過程中,確定單元602具體用于:確定距離發送心跳消息時刻達到第二預定時間后仍然未反饋心跳響應的實例為該第一實例;或者,確定第一預定時間內實例標識都表示僵死或失效狀態的實例為該第一實例。
本實施例中,在用于確定第二實例的過程中,確定單元602具體用于創建并確定新的實例為該第二實例;負載遷移單元603具體用于根據該至少一個待遷移負載之第一負載在共享資源池中所對應的第一PCB在該第二實例中實現該第一負載與該用戶態協議棧的上層服務的對接,并將該第一負載在該第一實例中綁定的第一接收端擴展RSS隊列重綁定到該第二實例的該第 一負載中,其中,該至少一個待遷移負載包括該第一實例的所有負載。
圖7是本發明實施例協議棧系統600的另一結構示意圖。如圖7所示,協議棧系統600還可包括:實例停止單元604,用于終止該第一實例。
可選地,作為另一實施例,在用于確定第一實例的過程中,確定單元602具體用于:確定第一預定時間內實例總負載均值大于第一預定閾值的實例為該第一實例。
可選地,在本具體實現方式的一種場景中,在用于確定第二實例的過程中,確定單元602具體用于:如果存在第一預定時間內實例總負載均值低于第二預定閾值的實例,則確定預定時間內實例總負載均值低于第二預定閾值的一個或多個實例作為該第二實例,其中,遷入該第二實例的所有負載的負載值與該第二預定閾值之和小于該第一預定閾值。
進一步地,在當前的具體實現方式中,負載遷移單元603具體用于:根據該第一實例的至少一個待遷移負載之第二負載在該共享資源池中所對應的第二PCB,將該第二負載在該第一實例中綁定的第二RSS隊列的綁定規則修改為綁定到該第二實例的第二負載中,以使得該第二實例實現從該第二RSS隊列進行數據包接收及處理的過程;或者,根據該第一實例的至少一個待遷移負載之第二負載在該共享資源池中所對應的第二PCB,在該第一實例中解除該第二負載在該第一實例中綁定的第二RSS隊列,并在該第二實例中將該第二RSS隊列綁定到該第二負載中,以使得該第二實例實現從該第二RSS隊列進行數據包接收及處理的過程。
另外,在當前的具體實現方式中,在用于確定該第一實例中的至少一個待遷移負載的過程中,確定單元602具體用于:確定該第一實例中的第三負載為該第一實例的待遷移負載,該第三負載在該第一實例中所綁定的第三RSS隊列滿足以下條件:當該第三RSS隊列綁定到該第二實例時該第二實例的連接數、接收字節數、發送字節數3個參數中至少有2個參數不大于該第一實例的相應參數。
可選地,在本實施例的一種具體實現方式中,在用于確定第二實例的過程中,確定單元602具體用于:如果不存在預定時間內實例總負載均值低于第二預定閾值的實例,則創建并確定新的實例為該第二實例。
進一步地,在當前的具體實現方式中,負載遷移單元603具體用于:根據該第一實例的至少一個待遷移負載之第二負載在該共享資源池中所對應 的第二PCB在該第二實例中實現該第二負載與該用戶態協議棧的上層服務的對接以使得該第二實例實現與該第二負載對應的應用app的交互,并在該第一實例中解除該第二負載在該第一實例中綁定的第二RSS隊列,在該第二實例中將該第二RSS隊列綁定到該第二負載中,以使得該第二實例實現從該第二RSS隊列進行數據包接收及處理的過程。
另外,在當前的具體實現方式中,在用于確定該第一實例中的至少一個待遷移負載的過程中,確定單元602具體用于:確定該第一實例中的第三負載為該第一實例的待遷移負載,該第三負載在該第一實例中所綁定的第三RSS隊列滿足以下條件:該第三RSS隊列的連接數、接收字節數、發送字節數3個參數中都達到該第一實例的所有負載中對應參數的均值。
協議棧系統600還可執行圖1、圖2的方法,并能實現協議棧系統在上述如圖1至圖5所示的實施例的功能,具體實現可參考圖1至圖5所示實施例,本發明實施例在此不再贅述。
圖8是本發明實施例協議棧系統800的結構示意圖。協議棧系統可包括IO通道801、處理器802和存儲器803。
IO通道801、處理器802和存儲器803通過總線804系統相互連接;總線804可以是ISA總線、PCI總線或EISA總線等。所述總線可以分為地址總線、數據總線、控制總線等。為便于表示,圖8中僅用一條粗線表示,但并不表示僅有一根總線或一種類型的總線。
存儲器803,用于存放程序。具體地,程序可以包括程序代碼,所述程序代碼包括計算機操作指令。存儲器803可能包含高速RAM存儲器,也可能還包括非易失性存儲器(non-volatile memory),例如至少一個磁盤存儲器。
處理器802執行存儲器803所存放的程序,用于監控用戶態協議棧中每個協議棧對應的實例的運行狀態,確定第一實例和第二實例,并根據該第一實例中至少一個待遷移負載在存儲器803的共享資源池中所對應的協議控制塊PCB在該第二實例中重建該至少一個待遷移負載。其中,一個該實例對應于該用戶態協議棧中的一個協議棧,該第一實例為運行狀態異常的實例,該第二實例具備遷入該第一實例中至少一個待遷移負載的能力,一個該待遷移負載在該第一實例所對應的協議棧內對應于一個協議控制塊PCB,該PCB在共享資源池中對應于一個存儲著該待遷移負載的連接參數的PCB,該待遷移負載的連接參數能夠用于重建該待遷移負載。
應理解,本發明實施例中,用戶態協議棧用于表示存在于用戶空間的所有協議棧。在用戶態協議棧中,可包含一個或多個協議棧,每個協議棧與協議棧系統的一個實例形成一一對應的關系。
應理解,本發明實施例中,一個負載對應于一個PCB,一個負載在數據處理上等于一個PCB所對應的連接的數據處理量。
存儲器803可以包括只讀存儲器和隨機存取存儲器,并向處理器802提供指令和數據。存儲器803的一部分還可以包括非易失性隨機存取存儲器(NVRAM)。
上述如本發明圖1至圖5任一實施例揭示的方法可以應用于處理器802中,或者由處理器802實現。處理器802可能是一種集成電路芯片,具有信號的處理能力。在實現過程中,上述方法的各步驟可以通過處理器802中的硬件的集成邏輯電路或者軟件形式的指令完成。上述的處理器802可以是通用處理器,包括中央處理器(Central Processing Unit,簡稱CPU)、網絡處理器(Network Processor,簡稱NP)等;還可以是數字信號處理器(DSP)、專用集成電路(ASIC)、現成可編程門陣列(FPGA)或者其他可編程邏輯器件、分立門或者晶體管邏輯器件、分立硬件組件。可以實現或者執行本發明實施例中的公開的各方法、步驟及邏輯框圖。通用處理器可以是微處理器或者該處理器也可以是任何常規的處理器等。結合本發明實施例所公開的方法的步驟可以直接體現為硬件譯碼處理器執行完成,或者用譯碼處理器中的硬件及軟件模塊組合執行完成。軟件模塊可以位于隨機存儲器,閃存、只讀存儲器,可編程只讀存儲器或者電可擦寫可編程存儲器、寄存器等本領域成熟的存儲介質中。該存儲介質位于存儲器803,處理器802讀取存儲器803中的信息,結合其硬件完成上述方法的步驟。
可選地,處理器802還用于確定該第一實例中的至少一個待遷移負載。
可選地,在用于監控用戶態協議棧中多個實例的運行狀態的過程中,處理器802具體用于:分別向該用戶態協議棧中每個協議棧對應的實例發送心跳消息并監控該心跳消息響應時延,并監控該用戶態協議棧中每個協議棧對應的實例在第一預定時間內的實例負載均值,以根據該心跳消息的響應時延和該實例負載均值確定該用戶態協議棧中每個協議棧對應的實例的運行狀態,其中,一條心跳消息對應于一個該實例;或者,分別輪詢該用戶態協議棧中每個協議棧對應的實例的實例標識,并監控該用戶態協議棧中每個協議 棧對應的實例在第一預定時間內的實例負載均值,以根據該實例標識和該實例負載均值確定該用戶態協議棧中每個協議棧對應的實例的運行狀態,其中,該實例標識用于表示實例的存活狀態,該實例標識存儲于共享內存區域或共享文件,一個該實例標識對應于一個該實例。
可選地,作為一個實施例,在用于確定第一實例的過程中,處理器802具體用于:確定距離發送心跳消息時刻達到第二預定時間后仍然未反饋心跳響應的實例為該第一實例;或者,確定第一預定時間內實例標識都表示僵死或失效狀態的實例為該第一實例。
本實施例中,在用于確定第二實例的過程中,處理器802具體用于創建并確定新的實例為該第二實例;在用于根據該第一實例中至少一個待遷移負載在存儲器803的共享資源池中所對應的協議控制塊PCB在該第二實例中重建該至少一個待遷移負載的過程中,處理器802具體用于根據該至少一個待遷移負載之第一負載在共享資源池中所對應的第一PCB在該第二實例中實現該第一負載與該用戶態協議棧的上層服務的對接,并將該第一負載在該第一實例中綁定的第一接收端擴展RSS隊列重綁定到該第二實例的該第一負載中,其中,該至少一個待遷移負載包括該第一實例的所有負載。此時,處理器802還可用于終止該第一實例。
可選地,作為另一實施例,在用于確定第一實例的過程中,處理器802具體用于:確定第一預定時間內實例總負載均值大于第一預定閾值的實例為該第一實例。
可選地,在本具體實現方式的一種場景中,在用于確定第二實例的過程中,處理器802具體用于:如果存在第一預定時間內實例總負載均值低于第二預定閾值的實例,則確定預定時間內實例總負載均值低于第二預定閾值的一個或多個實例作為該第二實例,其中,遷入該第二實例的所有負載的負載值與該第二預定閾值之和小于該第一預定閾值。
進一步地,在當前的具體實現方式下,在用于根據該第一實例中至少一個待遷移負載在存儲器803的共享資源池中所對應的協議控制塊PCB在該第二實例中重建該至少一個待遷移負載的過程中,處理器802具體用于:根據該第一實例的至少一個待遷移負載之第二負載在該共享資源池中所對應的第二PCB,將該第二負載在該第一實例中綁定的第二RSS隊列的綁定規則修改為綁定到該第二實例的第二負載中,以使得該第二實例實現從該第二 RSS隊列進行數據包接收及處理的過程;或者,根據該第一實例的至少一個待遷移負載之第二負載在該共享資源池中所對應的第二PCB,在該第一實例中解除該第二負載在該第一實例中綁定的第二RSS隊列,并在該第二實例中將該第二RSS隊列綁定到該第二負載中,以使得該第二實例實現從該第二RSS隊列進行數據包接收及處理的過程。
另外,在當前的具體實現方式下,在用于確定該第一實例中的至少一個待遷移負載的過程中,處理器802具體用于:確定該第一實例中的第三負載為該第一實例的待遷移負載,該第三負載在該第一實例中所綁定的第三RSS隊列滿足以下條件:當該第三RSS隊列綁定到該第二實例時該第二實例的連接數、接收字節數、發送字節數3個參數中至少有2個參數不大于該第一實例的相應參數。
可選地,在本實施例的一種具體實現方式中,在用于確定第二實例的過程中,處理器802具體用于:如果不存在預定時間內實例總負載均值低于第二預定閾值的實例,則創建并確定新的實例為該第二實例。
進一步地,在當前的具體實現方式下,在用于根據該第一實例中至少一個待遷移負載在存儲器803的共享資源池中所對應的協議控制塊PCB在該第二實例中重建該至少一個待遷移負載的過程中,處理器802具體用于:根據該第一實例的至少一個待遷移負載之第二負載在該共享資源池中所對應的第二PCB在該第二實例中實現該第二負載與該用戶態協議棧的上層服務的對接以使得該第二實例實現與該第二負載對應的應用app的交互,并在該第一實例中解除該第二負載在該第一實例中綁定的第二RSS隊列,在該第二實例中將該第二RSS隊列綁定到該第二負載中,以使得該第二實例實現從該第二RSS隊列進行數據包接收及處理的過程。
另外,在當前的具體實現方式下,在用于確定該第一實例中的至少一個待遷移負載的過程中,處理器802具體用于:確定該第一實例中的第三負載為該第一實例的待遷移負載,該第三負載在該第一實例中所綁定的第三RSS隊列滿足以下條件:該第三RSS隊列的連接數、接收字節數、發送字節數3個參數中都達到該第一實例的所有負載中對應參數的均值。
協議棧系統800還可執行圖1、圖2的方法,并能實現協議棧系統在上述如圖1至圖5所示的實施例的功能,具體實現可參考圖1至圖5所示實施例,本發明實施例在此不再贅述。
本領域普通技術人員可以意識到,結合本文中所公開的實施例描述的各示例的單元及算法步驟,能夠以電子硬件、或者計算機軟件和電子硬件的結合來實現。這些功能究竟以硬件還是軟件方式來執行,取決于技術方案的特定應用和設計約束條件。專業技術人員可以對每個特定的應用來使用不同方法來實現所描述的功能,但是這種實現不應認為超出本發明的范圍。
所屬領域的技術人員可以清楚地了解到,為描述的方便和簡潔,上述描述的系統、裝置和單元的具體工作過程,可以參考前述方法實施例中的對應過程,在此不再贅述。
在本申請所提供的幾個實施例中,應該理解到,所揭露的系統、裝置和方法,可以通過其它的方式實現。例如,以上所描述的裝置實施例僅僅是示意性的,例如,所述單元的劃分,僅僅為一種邏輯功能劃分,實際實現時可以有另外的劃分方式,例如多個單元或組件可以結合或者可以集成到另一個系統,或一些特征可以忽略,或不執行。另一點,所顯示或討論的相互之間的耦合或直接耦合或通信連接可以是通過一些接口,裝置或單元的間接耦合或通信連接,可以是電性,機械或其它的形式。
所述作為分離部件說明的單元可以是或者也可以不是物理上分開的,作為單元顯示的部件可以是或者也可以不是物理單元,即可以位于一個地方,或者也可以分布到多個網絡單元上。可以根據實際的需要選擇其中的部分或者全部單元來實現本實施例方案的目的。
另外,在本發明各個實施例中的各功能單元可以集成在一個處理單元中,也可以是各個單元單獨物理存在,也可以兩個或兩個以上單元集成在一個單元中。
所述功能如果以軟件功能單元的形式實現并作為獨立的產品銷售或使用時,可以存儲在一個計算機可讀取存儲介質中。基于這樣的理解,本發明的技術方案本質上或者說對現有技術做出貢獻的部分或者該技術方案的部分可以以軟件產品的形式體現出來,該計算機軟件產品存儲在一個存儲介質中,包括若干指令用以使得一臺計算機設備(可以是個人計算機,服務器,或者網絡設備等)執行本發明各個實施例所述方法的全部或部分步驟。而前述的存儲介質包括:U盤、移動硬盤、只讀存儲器(ROM,Read-Only Memory)、隨機存取存儲器(RAM,Random Access Memory)、磁碟或者光盤等各種可以存儲程序代碼的介質。
以上所述,僅為本發明的具體實施方式,但本發明的保護范圍并不局限于此,任何熟悉本技術領域的技術人員在本發明揭露的技術范圍內,可輕易想到變化或替換,都應涵蓋在本發明的保護范圍之內。因此,本發明的保護范圍應所述以權利要求的保護范圍為準。

關 鍵 詞:
并行 用戶 協議 管理 方法 系統
  專利查詢網所有資源均是用戶自行上傳分享,僅供網友學習交流,未經上傳用戶書面授權,請勿作他用。
關于本文
本文標題:并行用戶態協議棧的管理方法和協議棧系統.pdf
鏈接地址:http://www.rgyfuv.icu/p-6381438.html
關于我們 - 網站聲明 - 網站地圖 - 資源地圖 - 友情鏈接 - 網站客服客服 - 聯系我們

[email protected] 2017-2018 zhuanlichaxun.net網站版權所有
經營許可證編號:粵ICP備17046363號-1 
 


收起
展開
山东11选5中奖结果走势图