淺說網絡泛知識的構建方法
前言：想要寫出一篇引人入勝的文章？我們特意為您整理了淺說網絡泛知識的構建方法范文，希望能給你帶來靈感和參考，敬請閱讀。
1.復合自適應QoS保障策略
a.按用戶的貢獻程度（如付費或貢獻知識信息和文獻資源）將用戶等級分為實時優(yōu)先級（RealTimePriority，RTP）、高優(yōu)先級（HighPriority，HP）和低優(yōu)先級（LowPriority，LP）。實時優(yōu)先級用戶需要在限定的短時間內獲得信息反饋；在服務器負載沉重情況下，對除實時優(yōu)先級用戶之外的高優(yōu)先級和低優(yōu)先級用戶均實施降低服務質量的服務，但在其它因素相同的情況下，優(yōu)先響應高優(yōu)先級用戶的請求。
b.在泛知識云中包含的信息資源包括知識詞條和文獻資料，這兩種資源所占用的存儲空間是不同的。詞條占用的存儲空間可以小到只有幾KB或幾十KB，若是包含圖片說明性信息會大一些；而文獻資料則一般至少幾百KB（如一篇幾頁的PDF格式的期刊性論文），大的則需幾MB或十幾MB的存儲空間（如一篇幾十頁的碩士學位論文或上百頁的博士學位論文）。用戶在向系統(tǒng)索取這兩種資源時，系統(tǒng)因此而花費的主機和網絡開銷是不相同。此外，信息資源由于時間、門類等因素，導致一些資源的當前閱讀群體范圍廣大（即成為熱點資源），一些資源則很少人關注（冷門資源）。熱點資源存在于服務器和大量Peer節(jié)點上，冷門資源則存在于服務器和少數(shù)Peer節(jié)點上?？梢姡诨贑loud-P2P的泛知識云系統(tǒng)中，節(jié)點獲取熱點資源和冷門資源的選擇余地是不相同的。
c.按照服務器端的當前資源消耗情況，可將服務器的負載分為輕負載（Lightload）、中等負載（Mediumload）、重負載（Heavyload）。為了保障用戶的服務質量（特別是實時優(yōu)先級用戶），需將服務器性能閾值設定為安全點（Safepoint）1和危險點（Dangerouspoint）2：
（1）當服務器端的當前負載程度10x時，服務器端滿足所有優(yōu)先等級的用戶服務請求；
（2）當服務器端的當前負載程度12x時，服務器端滿足實時優(yōu)先級和高優(yōu)先級用戶所有請求，以及低優(yōu)先級用戶針對詞條這樣小文件信息資源的請求，而將低優(yōu)先級用戶針對大文件信息資源的請求調度到存儲該文件的其它Peer節(jié)點上；
（3）當服務器端的當前負載程度2x1時，服務器端滿足實時優(yōu)先級用戶的所有請求，以及高優(yōu)先級和低優(yōu)先級用戶針對詞條這樣小文件信息資源的請求，而將高優(yōu)先級和低優(yōu)先級用戶針對大文件信息資源的請求調度到存儲該文件的其它Peer節(jié)點上。若節(jié)點當前索取的資源是冷門資源，當前存儲該資源的在線節(jié)點很可能只有服務器，而按照上述QoS原則，服務器又不能立即為該節(jié)點提供服務時，則節(jié)點需暫緩該次服務請求，而等待服務器負載降至規(guī)定范圍內再提供服務?？梢姳疚奶岢龅腝oS保障機制不再對所有用戶關于所有資源的請求都簡單遵循傳統(tǒng)的“盡力而為（best-effort）”的服務方式。
2.系統(tǒng)模型與工作流程
提交所需下載的知識的請求，主服務器節(jié)點收到服務請求后，將用戶請求加入服務請求處理隊列中，對隊列中的服務請求依次進行處理。系統(tǒng)主節(jié)點的監(jiān)控模塊負責提供服務器端的當前負載情況：如果服務器端的當前負載程度主節(jié)點服務器普通節(jié)點發(fā)送hello2.分配唯一的ID3.提供共享知識文件列表普通節(jié)點發(fā)送知識文件查詢請求返回查詢結果發(fā)送要下載的知識文件名傳送知識文件保存知識文件，完成下載保存普通節(jié)點共享知識文件列表普通節(jié)點多個普通節(jié)點集群服務器復合自適應Qos服務質量保證策略處于區(qū)間時，直接通過調度模塊將該服務請求加入服務器服務隊列，然后轉；否則，如果服務器端的當前負載程度處于區(qū)間時轉至，如果服務器端的當前負載程度處于區(qū)間時轉至。進一步檢測用戶的等級，若用戶為實時優(yōu)先級和高優(yōu)先級用戶，則通過調度模塊該服務請求加入服務器服務隊列，然后轉；否則需進一步檢測用戶的服務請求類型，若是針對詞條類的小文件信息資源的服務請求，則通過調度模塊將該服務請求加入服務器服務隊列，然后轉；否則通過調度模塊將該服務請求加入終端節(jié)點服務隊列，然后轉。進一步檢測用戶的等級，若用戶為實時優(yōu)先級通過調度模塊將該服務請求加入服務器服務隊列，然后轉；否則進一步檢測用戶的服務請求類型，若是針對詞條類的小文件信息資源的服務請求，則通過調度模塊將該服務請求加入服務器服務隊列，然后轉；否則通過調度模塊將該服務請求加入終端節(jié)點服務隊列，然后轉。服務請求被部署到相應的服務器端節(jié)點，完成后續(xù)服務請求響應工作。服務請求被部署到相應的終端節(jié)點，完成后續(xù)服務請求響應工作。
3.原型系統(tǒng)及性能分析
3.1原型系統(tǒng)
本文提出構建基于Cloud-P2P網絡平臺的泛知識云原型系統(tǒng)，底層的通信機制參考eMule協(xié)議[11-12]，文件實體分布在Cloud-P2P網絡中的所有數(shù)據(jù)節(jié)點輔存上。泛知識云原型系統(tǒng)基于eMule協(xié)議實現(xiàn)了節(jié)點間通信、知識文件傳輸和多線程下載等功能。
3.2性能分析
本文提出的基于Cloud-P2P網絡平臺的泛知識云模型及其服務質量保障機制可以有效提升網絡知識共享系統(tǒng)的性能，具有以下的性能優(yōu)勢：
（1）負載分擔。與傳統(tǒng)的基于Cloud的知識系統(tǒng)相比，基于Cloud-P2P網絡平臺的泛知識云中的知識信息資源分散于服務器節(jié)點和用戶節(jié)點，用戶節(jié)點同時成為信息資源的提供者和消費者，而上述的復合自適應QoS保障策略也進一步減輕了服務器節(jié)點的負擔；
（2）高資源利用率。與傳統(tǒng)的基于Cloud的知識系統(tǒng)相比基于Cloud-P2P網絡平臺的泛知識云不但利用了服務器節(jié)點的穩(wěn)定資源，也利用了眾多閑置的普通用戶終端節(jié)點上蘊含的巨大的計算和存儲資源；
（3）高魯棒性。基于Cloud-P2P網絡平臺的泛知識云采用了備份冗余的機制，重要的信息資源存儲在服務器節(jié)點和普通用戶終端節(jié)點，同時由于終端節(jié)點的數(shù)量巨大，可靈活設置備份規(guī)模，因此系統(tǒng)不會存在單點失效問題，具有較高的魯棒性。
（4）高靈活性。基于Cloud-P2P網絡平臺的泛知識云中使用的復合自適應QoS保障策略，充分考慮了不同類型的節(jié)點在不同的情況下獲取不同等級的服務的差異性情況，具體較高的靈活性。
4.結束語
將網絡中的各類文獻、知識信息有序的組織在一起；充分考慮網絡邊緣節(jié)點上可以利用的資源，在保障用戶使用體驗的前提下，將用戶提交的知識索取任務從網絡中心的服務器端遷移到網絡邊緣的客戶端。本文進一步提出一種動態(tài)的復合自適應QoS保障機制，通過綜合區(qū)分用戶與資源類型，并設定服務器負載閾值，解決傳統(tǒng)知識系統(tǒng)中存在的高峰階段服務器性能瓶頸的難題，從而達到提高系統(tǒng)中用戶整體普遍滿意度的目標。
作者：周世杰 秦志光 單位：清華大學