淺說網(wǎng)絡泛知識的構建方法
前言：想要寫出一篇引人入勝的文章？我們特意為您整理了淺說網(wǎng)絡泛知識的構建方法范文，希望能給你帶來靈感和參考，敬請閱讀。
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)因此而花費的主機和網(wǎng)絡開銷是不相同。此外，信息資源由于時間、門類等因素，導致一些資源的當前閱讀群體范圍廣大（即成為熱點資源），一些資源則很少人關注（冷門資源）。熱點資源存在于服務器和大量Peer節(jié)點上，冷門資源則存在于服務器和少數(shù)Peer節(jié)點上?？梢?，在基于Cloud-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ī)定范圍內再提供服務。可見本文提出的QoS保障機制不再對所有用戶關于所有資源的請求都簡單遵循傳統(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網(wǎng)絡平臺的泛知識云原型系統(tǒng)，底層的通信機制參考eMule協(xié)議[11-12]，文件實體分布在Cloud-P2P網(wǎng)絡中的所有數(shù)據(jù)節(jié)點輔存上。泛知識云原型系統(tǒng)基于eMule協(xié)議實現(xiàn)了節(jié)點間通信、知識文件傳輸和多線程下載等功能。
3.2性能分析
本文提出的基于Cloud-P2P網(wǎng)絡平臺的泛知識云模型及其服務質量保障機制可以有效提升網(wǎng)絡知識共享系統(tǒng)的性能，具有以下的性能優(yōu)勢：
（1）負載分擔。與傳統(tǒng)的基于Cloud的知識系統(tǒng)相比，基于Cloud-P2P網(wǎng)絡平臺的泛知識云中的知識信息資源分散于服務器節(jié)點和用戶節(jié)點，用戶節(jié)點同時成為信息資源的提供者和消費者，而上述的復合自適應QoS保障策略也進一步減輕了服務器節(jié)點的負擔；
（2）高資源利用率。與傳統(tǒng)的基于Cloud的知識系統(tǒng)相比基于Cloud-P2P網(wǎng)絡平臺的泛知識云不但利用了服務器節(jié)點的穩(wěn)定資源，也利用了眾多閑置的普通用戶終端節(jié)點上蘊含的巨大的計算和存儲資源；
（3）高魯棒性。基于Cloud-P2P網(wǎng)絡平臺的泛知識云采用了備份冗余的機制，重要的信息資源存儲在服務器節(jié)點和普通用戶終端節(jié)點，同時由于終端節(jié)點的數(shù)量巨大，可靈活設置備份規(guī)模，因此系統(tǒng)不會存在單點失效問題，具有較高的魯棒性。
（4）高靈活性?；贑loud-P2P網(wǎng)絡平臺的泛知識云中使用的復合自適應QoS保障策略，充分考慮了不同類型的節(jié)點在不同的情況下獲取不同等級的服務的差異性情況，具體較高的靈活性。
4.結束語
將網(wǎng)絡中的各類文獻、知識信息有序的組織在一起；充分考慮網(wǎng)絡邊緣節(jié)點上可以利用的資源，在保障用戶使用體驗的前提下，將用戶提交的知識索取任務從網(wǎng)絡中心的服務器端遷移到網(wǎng)絡邊緣的客戶端。本文進一步提出一種動態(tài)的復合自適應QoS保障機制，通過綜合區(qū)分用戶與資源類型，并設定服務器負載閾值，解決傳統(tǒng)知識系統(tǒng)中存在的高峰階段服務器性能瓶頸的難題，從而達到提高系統(tǒng)中用戶整體普遍滿意度的目標。
作者：周世杰 秦志光 單位：清華大學