專利名稱：一種基于數(shù)據(jù)塊比較的數(shù)據(jù)更新方法
技術(shù)領(lǐng)域：
本發(fā)明涉及計算機技術(shù)領(lǐng)域，尤其涉及一種數(shù)據(jù)的更新方法。
背景技術(shù)：
國內(nèi)熱門的網(wǎng)絡(luò)游戲在100款以上，幾乎每天都會有30%以上的網(wǎng)絡(luò)游戲會發(fā)生 內(nèi)容更新，網(wǎng)吧的電腦里面的游戲也需要及時的更新，才能在滿足網(wǎng)吧網(wǎng)民的需求，在解決 這個需求上存在兩個技術(shù)難點，難點之一是所有網(wǎng)吧的機器終端數(shù)非常龐大，約在在1000 萬臺以上，如果都直接從互聯(lián)網(wǎng)服務(wù)器進行游戲更新，服務(wù)器的性能負荷根本不能應(yīng)付，同 時還需要在互聯(lián)網(wǎng)上分配巨大的網(wǎng)絡(luò)帶寬資源才能支持；難點之二是熱門游戲的更新量是 非常巨大的，如果從文件更新的級別來看，目前每天平均在40G左右，巨大的更新量幾乎使 得游戲更新基本不能在網(wǎng)吧里面正常運作，網(wǎng)吧帶寬有限，游戲要更新完需要幾乎不能忍 受的時間長度)。為了解決以上問題，現(xiàn)有技術(shù)也有采用數(shù)據(jù)增量更新的手段，即檢查數(shù)據(jù) 更新與更新后的差異，更新時只針對該差異部分進行更新， 一般以邏輯文件作為原子處理 對象，更新差異比較以文件本身的屬性，例如文件創(chuàng)建時間或文件修改時間做為判斷依據(jù)， 來判斷此文件是否被更新過。如果文件被更新過了，則把整個文件作為差異需求，需要網(wǎng)絡(luò) 傳輸達到數(shù)據(jù)更新的目的。 但現(xiàn)有方法是以邏輯文件作為處理對象，在實際應(yīng)用中，很多數(shù)據(jù)更新只是改變 文件中的一段數(shù)據(jù)。這就導致更新差異比較粒度過大，會重復更新一些原有數(shù)據(jù)。
如果更新差異比較出來的文件需要更新，文件的長度就是需要更新的大小。由于 文件可大可小，導致原子更新長度也是動態(tài)變化的。會導致網(wǎng)絡(luò)傳輸?shù)男阅芟陆怠?br>
發(fā)明內(nèi)容
本發(fā)明提供了一種快速的數(shù)據(jù)更新方法，通過對數(shù)據(jù)的劃分以及特定的更新算法 大大提高了數(shù)據(jù)更新的速度，另外結(jié)合改進的網(wǎng)絡(luò)下載架構(gòu)進一步減輕了服務(wù)器的負荷， 提高網(wǎng)絡(luò)傳輸?shù)男阅堋?本發(fā)明數(shù)據(jù)更新方法通過使用數(shù)據(jù)內(nèi)容的分塊索引和差異對比來實現(xiàn)，把一套完 整的數(shù)據(jù)(例如一款游戲的所有數(shù)據(jù))看作一個連續(xù)完整的二進制數(shù)據(jù)流。 一個文件是一 段二進制數(shù)據(jù)流的邏輯單位。 一個數(shù)據(jù)塊也是二進制數(shù)據(jù)流的邏輯單位。
三者的關(guān)系是數(shù)據(jù)塊是文件的子集，文件是游戲數(shù)據(jù)的子集。當文件整體大小 小于一個數(shù)據(jù)塊定義長度時，一個文件的內(nèi)容就是一個數(shù)據(jù)塊。當然，大多數(shù)情況是一個文 件有若干數(shù)據(jù)塊。數(shù)據(jù)塊的長度可以人工定義，這樣我們可以根據(jù)網(wǎng)絡(luò)傳輸?shù)奶攸c和磁盤 (目前大量使用磁盤列陣)緩存的特點，找到在全局系統(tǒng)中整體性能最優(yōu)的數(shù)據(jù)塊長度。而 不是被動適應(yīng)文件長度。
—種基于數(shù)據(jù)塊比較的數(shù)據(jù)更新方法，包括如下步驟 (1)將所有版本數(shù)據(jù)均劃分為若干數(shù)據(jù)塊，針對每個版本數(shù)據(jù)，分別提取該版本數(shù) 據(jù)中
a)整體版本數(shù)據(jù)的屬性信息和標識映射信息；
b)所有文件的屬性信息和標識映射信息；
C)各個數(shù)據(jù)塊的標識映射信息； (2)針對每個版本數(shù)據(jù)，建立對應(yīng)的索引文件，所述的索引文件包含針對該版本數(shù) 據(jù)的步驟(1)中提取的信息； (3)進行數(shù)據(jù)更新時，對比在先版本數(shù)據(jù)及其在后版本數(shù)據(jù)的索引文件，對比時步 驟如下 a)根據(jù)在后版本索引文件中所有文件的屬性信息和標識映射信息查找出在先版 本數(shù)據(jù)中不包含的文件，以及有改動的文件； 對于在先版本數(shù)據(jù)中不包含的文件，則直接更新，即將在后版本數(shù)據(jù)中的該文件 復制到在先版本數(shù)據(jù)中； 對于有改動的文件，根據(jù)文件中各個數(shù)據(jù)塊的標識映射信息查找出在先版本數(shù)據(jù) 中和在后版本數(shù)據(jù)中有改動的數(shù)據(jù)塊，對有改動的數(shù)據(jù)塊進行更新，即將在后版本數(shù)據(jù)中 的該數(shù)據(jù)塊復制到在先版本數(shù)據(jù)中； b)根據(jù)在先版本索引文件中所有的文件的屬性信息和標識映射信息查找出在后
版本數(shù)據(jù)中不包含的文件，以及有改動的文件； 對于在后版本數(shù)據(jù)中不包含的文件，直接刪除該文件； 對于有改動的文件，根據(jù)文件中各個數(shù)據(jù)塊的標識映射信息查找出在后版本數(shù)據(jù) 中不包含的數(shù)據(jù)塊，直接刪除該數(shù)據(jù)塊。 本發(fā)明步驟(1)中，將某一個版本數(shù)據(jù)劃分為若干數(shù)據(jù)塊時，是以單個文件為對 象，逐個文件來劃分的，不同的文件中的數(shù)據(jù)不會劃分到同一個數(shù)據(jù)塊中，由于數(shù)據(jù)塊的長 度是預先指定的，而一個文件劃分到最后時，末尾塊的長度一般都不會恰好與預先指定的 數(shù)據(jù)塊的長度相等，那么對于一個文件末尾塊的處理方法如下 要說明的是末尾塊的長度一定是小于或等于預先指定的數(shù)據(jù)塊的長度，否則的話 就會繼續(xù)劃分，當末尾塊的長度等于預先指定的數(shù)據(jù)塊的長度時，就按預定的原則劃分，我 們重點考慮的是末尾塊的長度小于預先指定的數(shù)據(jù)塊的長度。 首先設(shè)定一個閾值，計算末尾塊的長度，求出該末尾塊長度與預先指定的數(shù)據(jù)塊 的長度的比值，當比值小于閾值時，則將該末尾塊合并到其前一個數(shù)據(jù)塊中，若比值大于或 等于閾值時，則將該末尾塊單獨劃為一個數(shù)據(jù)塊。作為優(yōu)選，閾值取1/3，這樣可以盡量減少 零星的短長度數(shù)據(jù)塊，有利于提高網(wǎng)絡(luò)傳輸?shù)男?，也盡量避免頻繁的數(shù)據(jù)讀寫。
數(shù)據(jù)塊的長度對數(shù)據(jù)的更新有直接的影響 如果數(shù)據(jù)塊長度過大，在網(wǎng)絡(luò)傳輸時發(fā)生失真，會導致整個數(shù)據(jù)塊重新發(fā)送，期間
去占去大量的網(wǎng)絡(luò)資源和機器性能資源，費事費力。這也是樸素處理方式的弱點。 如果數(shù)據(jù)塊定義適中，由于一塊數(shù)據(jù)塊可以從多個服務(wù)器上獲取。大量數(shù)據(jù)可以
從多個服務(wù)器中分別獲得后再組裝，這樣整個網(wǎng)絡(luò)資源將會被平攤在各個服務(wù)器的帶寬
中。作為優(yōu)選數(shù)據(jù)塊的長度采用16 64K較為合適，最為進一步的優(yōu)選數(shù)據(jù)塊的長度采用
32K，此時可以達到網(wǎng)絡(luò)傳輸質(zhì)量與程序性能的兼顧。 如果數(shù)據(jù)塊定義太小，則增加了程序和操作系統(tǒng)之間的交互次數(shù)，影響程序性能。
現(xiàn)有技術(shù)中有許多方法可以得到數(shù)據(jù)塊(一段二進制流)的標識映射信息。例如
5有MD5碼和CRC32等等。 比較MD5碼和CRC32，MD5碼的沖突率更低，也就是說，2段不同內(nèi)容的二進制數(shù)據(jù) 流，用MD5碼可以區(qū)分出差異，但CRC32可能會認為2段流是一樣的。通過CRC32制作出的 標識信息只有4個字節(jié)，而通過MD5制作標識信息可能操作128個字節(jié)。二者的時間復雜 度相差不大。 不管使用什么方式建立數(shù)據(jù)塊的標識映射信息，其目的都是只要對比數(shù)據(jù)量較小 的標識映射信息替換數(shù)據(jù)塊的內(nèi)容比較。假設(shè)數(shù)據(jù)塊長度是32K字節(jié)，則我們使用4字節(jié) 或128字節(jié)的比較來，替換32K字節(jié)的比較。 本發(fā)明中最終選用CRC32作為標識映射信息，主要是考慮到CRC32的沖突率可接 受，并且標識映射信息所占空間小，有利于減少索引的大小。 步驟(2)所述的索引文件，是記錄一個版本數(shù)據(jù)所有數(shù)據(jù)塊標識映射信息的集 合。不同版本的數(shù)據(jù)一定對應(yīng)一個版本的索引文件。 索引文件的作用待更新程序，通過比較不同版本的索引文件，產(chǎn)生差異需求量， 這樣待更新程序，只要下載差異部分的數(shù)據(jù)，就可以完成版本升級。
本發(fā)明索引文件中的內(nèi)容包括以下幾項 a)整體版本數(shù)據(jù)的屬性信息和標識映射信息，就每個版本數(shù)據(jù)而言包括 Pkgld 版本數(shù)據(jù)的類型標識，不同類型的版本數(shù)據(jù)采用不同的Pkgld，例如不
同游戲的版本數(shù)據(jù)的Pkgld是不同的； BlockSize 文件分塊的單位大小(單位字節(jié))，即數(shù)據(jù)塊的長度； PkgldxVer 索引版本，同一類型但版本不同的版本數(shù)據(jù)的標識；例如同一游戲
有不同的版本，那么不同的版本間Pkgld是相同的，但PkgldxVer不同； SelfCRC索引文件的CRC自校驗，用于在網(wǎng)絡(luò)傳送過程中校驗索引文件自身
是否正確傳輸； FileDescList 文件描述信息的列表(多個文件描述信息的數(shù)組)，表示了該 版本數(shù)據(jù)中所有的文件的屬性信息和標識映射信息。 b)文件描述信息的列表FileDescList中包含了該版本數(shù)據(jù)中所有的文件的屬性
信息和標識映射信息，就每個文件而言，其描述信息如下(FileDescInfo)包括 FileAttr 文件類型，類型分為目錄和文件兩種； FilePathName 文件名稱包含的相對路徑；FileModifyTime 文^牛修改時間； FileCRC 文件整個內(nèi)容的CRC校驗碼； FileLength 文件長度(單位字節(jié))； BeginBlockld文件中第一個數(shù)據(jù)塊的編號；就整個版本數(shù)據(jù)而言，其中所有
的數(shù)據(jù)塊的編號都是唯一的，通過數(shù)據(jù)塊的編號可以快速定位數(shù)據(jù)塊在整個版本數(shù)據(jù)以及 整個文件中的位置； BlockDescList 文件數(shù)據(jù)塊信息的列表(多個數(shù)據(jù)塊信息的數(shù)組)，表示了該 文件中所有的數(shù)據(jù)塊的標識映射信息； c)文件數(shù)據(jù)塊信息的列表BlockDescList中包含了該文件中所有數(shù)據(jù)塊的標識 映射信息，就一個數(shù)據(jù)塊而言，其描述信息如下(BlockDescInfo):
BlockCRC 數(shù)據(jù)塊內(nèi)容的CRC校驗碼。 步驟(3)中，對比在先版本數(shù)據(jù)及其在后版本數(shù)據(jù)時是采用了基于分塊索引的差 異對比算法 可分為二大步驟 —、得到兩個版本的索引文件后，先以新版本(在后版本數(shù)據(jù))的索引文件作為基 準，遍歷新版本的索引文件，取出文件類型的文件描述信息(FileDescInfo)，到舊版本(在 先版本數(shù)據(jù))的索引文件中查找此文件的信息，如果查不到，則說明這個文件是新增的，產(chǎn) 生差異比較結(jié)果(此文件需要全部更新)。如果查到了，判斷2個索引中FileDescInfo的 FileCRC是否相同，如果相同，我們認為這個文件沒有任何變動。如果不相同，則需求查找 變化的數(shù)據(jù)塊有哪些，開始順序遍歷此文件的塊描述信息(BlockDescInfo)，當新舊對應(yīng)的 BlockCRC不同，我們認為這個數(shù)據(jù)塊需要更新。 二、以上操作能處理新增和修改數(shù)據(jù)塊的效果。如果新版本的文件刪除了數(shù)據(jù)塊 時，處理方法如下 以舊版本的索引文件作為基準，遍歷舊版本索引文件，取出文件類型的文件描述
信息，到新版本的索引文件中查找，如果沒有，說明這個文件將被刪除。 對于塊的刪除，和上面的流程相同。 以上兩個步驟，產(chǎn)生的差異有2種類型需要下載更新和需要被替換。這就反映出 要下哪些數(shù)據(jù)，和數(shù)據(jù)組裝時，更新下來的數(shù)據(jù)塊需要放在哪個位置。 而索引文件的文件信息描述中有BeginBlockld(文件第一塊的編號)這個信息， 所以遍歷文件信息描述數(shù)組，就可以通過數(shù)據(jù)塊的長度和偏移量計算精確定位到任一塊數(shù) 據(jù)塊應(yīng)該存放在磁盤中的位置。 本發(fā)明步驟(3)中在進行數(shù)據(jù)塊的更新時，其實是在數(shù)據(jù)塊的提供端和數(shù)據(jù)塊的 請求端之間進行的，也就是說數(shù)據(jù)塊的提供端存放有在后版本數(shù)據(jù)，數(shù)據(jù)塊的請求端存放 有在先版本數(shù)據(jù)，數(shù)據(jù)更新時為了提高數(shù)據(jù)塊的提供端和數(shù)據(jù)塊的請求端之間數(shù)據(jù)量的吞 吐量以及傳輸速度，采用如下方法 (1)在數(shù)據(jù)塊的提供端建立了一個共享緩存(DownCache)，更新數(shù)據(jù)塊時，數(shù)據(jù)塊 的提供端根據(jù)數(shù)據(jù)塊的請求端的請求，向共享緩存中讀入指定的數(shù)據(jù)塊；建立便于共享緩 存對客戶端(數(shù)據(jù)塊的請求端)的所有請求實現(xiàn)統(tǒng)一管理。 (2)數(shù)據(jù)塊的提供端在收到數(shù)據(jù)塊下載申請時，首先讀共享緩存，共享緩存中如果 有該數(shù)據(jù)塊，則立即將請求的數(shù)據(jù)塊向數(shù)據(jù)塊的請求端傳輸； 共享緩存如果沒有該數(shù)據(jù)塊，并不是馬上開始讀文件的，而是把該數(shù)據(jù)塊下載申 請?zhí)峤唤o請求隊列。 (3)當數(shù)據(jù)塊的提供端空閑時按下載申請的提交時間順序處理請求隊列中的下載 申請，將請求的數(shù)據(jù)塊向數(shù)據(jù)塊的請求端傳輸。 作為優(yōu)選，對共享緩存中的數(shù)據(jù)塊按照命中率(命中率是讀到同一個塊的次數(shù))
排序，當共享緩存放滿的時候，將處于末尾的數(shù)據(jù)塊從共享緩存中淘汰出去。 為了避免某一數(shù)據(jù)塊下載申請在請求隊列中的等候時間過長，可是設(shè)定等候時間
閾值，當某一數(shù)據(jù)塊下載申請在請求隊列中的等候時間超過閾值時，即使數(shù)據(jù)塊的提供端
并沒有空閑，也優(yōu)先處理該數(shù)據(jù)塊下載申請。 一般情況，時間閾值可設(shè)為15 30分鐘。
7
為了進一步減少讀寫文件時的尋道時間，對于共享緩存中命中率相同的數(shù)據(jù)塊按 照序號進行升序排序。 本發(fā)明提及的技術(shù)用語如無特殊說明，其含義可作如下理解 1、數(shù)據(jù)塊是一組二進制數(shù)據(jù)流的集合，描述網(wǎng)絡(luò)或邏輯處理的粒度。 2、索引文件用數(shù)據(jù)塊來描述一套完整的游戲數(shù)據(jù)集合，對每個數(shù)據(jù)塊制作標識
映射信息，將這些數(shù)據(jù)塊的標識映射信息及部分游戲?qū)傩孕畔⒂涗浀奈募凶鏊饕募?
3、增量更新是針對一類具有版本升級屬性的操作，依托原有數(shù)據(jù)，只需要更新少
量數(shù)據(jù)，就能達到升級目的過程。 4、 IDC(Intemet Data Center):互聯(lián)網(wǎng)數(shù)據(jù)中心 5、 CRC32 (Cyclic Redundancy Check) :32位循環(huán)冗余校驗碼 6、時間復雜度指算法需要消耗的時間資源。如果一個問題的規(guī)模是n，解這一問
題的某一算法所需要的時間為T(n)，它是n的某一函數(shù)T(n)稱為這一算法的"時間復雜性" 7、空間復雜度是指計算機科學領(lǐng)域完成一個算法所需要占用的存儲空間。8、MD5碼(message-digest algorithm 5):信息-摘要算法。被廣泛用于加密和
解密技術(shù)上，它可以說是文件的〃 數(shù)字指紋〃 。 9、整編將離散分布的數(shù)據(jù)，集中成連續(xù)數(shù)據(jù)的過程。 10、解編是整編的逆操作。 本發(fā)明數(shù)據(jù)更新方法，通過對數(shù)據(jù)的劃分以及特定的更新算法大大提高了數(shù)據(jù)更 新的速度，另外結(jié)合改進的網(wǎng)絡(luò)下載架構(gòu)進一步減輕了服務(wù)器的負荷，提高網(wǎng)絡(luò)傳輸?shù)男?br>

圖1為本發(fā)明索引文件的結(jié)構(gòu)示意圖； 圖2為本發(fā)明差異對比算法的流程示意圖； 圖3為利用本發(fā)明數(shù)據(jù)更新方法的整體系統(tǒng)架構(gòu)圖； 圖4為游戲數(shù)據(jù)更新通道架構(gòu)圖； 圖5為IDC層內(nèi)的新增游戲流程示意圖； 圖6為IDC層和網(wǎng)吧服務(wù)層的數(shù)據(jù)更新流程； 圖7為網(wǎng)吧服務(wù)器層和網(wǎng)吧電腦層的數(shù)據(jù)更新和程序交互； 圖8為優(yōu)化下載緩存流程圖； 圖9為TCPP2P業(yè)務(wù)程序交互示意圖。
具體實施例方式
以下結(jié)合具體的硬件及網(wǎng)絡(luò)資源說明本發(fā)明數(shù)據(jù)更新方法，其中以游戲數(shù)據(jù)的更 新為例。 本發(fā)明通過建立三層更新方式(網(wǎng)吧電腦為終端層、網(wǎng)吧服務(wù)器為網(wǎng)吧層、互聯(lián) 網(wǎng)服務(wù)器為IDC層)，將游戲的更新從IDC層更新到網(wǎng)吧層最終更新到終端層，通過三層更 新的方法，將終端的更新量匯集到網(wǎng)吧層，從而有效降低了更新量，解決了大量終端的并發(fā) 瓶頸和巨大的更新量的問題。該三層整體架構(gòu)可以參見圖3。
8
其中 終端層程序名BarClient，操作對象是網(wǎng)民，具有穿透還原功能和游戲更新功 能，此程序只和網(wǎng)吧服務(wù)器通信。 網(wǎng)吧層程序名BarServer，操作對象是網(wǎng)管或網(wǎng)吧業(yè)主，具有提供BarClient端 更新、從IDC更新游戲數(shù)據(jù)和網(wǎng)管功能。 IDC層提供最新版本的游戲制作并提供BarServer下載游戲。
參見圖4， IDC層中的程序及其架構(gòu)包括 1.游戲制作工具(PMUpdate)，此程序的功能是將游戲數(shù)據(jù)整編并制作對應(yīng)的索
引，即就同一游戲程序而言，生成不同的版本數(shù)據(jù)，并將所有版本數(shù)據(jù)均劃分為若干數(shù)據(jù)塊
(每個數(shù)據(jù)塊預定長度32k大小)。 針對一個文件的末尾塊，作如下處理 nBlockCnt =塊數(shù)； nFileLen =文件長度； nBlockSize =文件分塊的單位大?。籲BlockCnt = nFileLen/nBlockSize+1 if (nFileLen% nBlockSize < nBlockSize/MagicBlockGene) {—nBlockCnt ;}
MagicBlockGene取1/3是一個為了節(jié)約存儲空間而設(shè)立的參數(shù)，它可以有效的 防止末尾塊過小占用完整塊大小的情況出現(xiàn)，當遇到末尾塊過小時(即小于nBlockSize/ MagicBlockGene)末尾塊不單獨成塊，而是合并到前一塊上，那么，倒數(shù)第二塊的塊長 度就會大于BlockSize 了，所以塊大小是不一樣的。除了末尾塊，其他塊的大小都等于 BlockSize 計算出來塊數(shù)nBlockCnt后，EndBlockld = BeginBlockld+nBlockCnt 從上面說明中可以看到，數(shù)據(jù)塊的長度不是一成不變的。有2種類型的長度，一種
是指定長度，另一種是末尾塊的剩余長度。 針對每個版本數(shù)據(jù)，分別提取該版本數(shù)據(jù)中 a)整體版本數(shù)據(jù)的屬性信息和標識映射信息； b)所有文件的屬性信息和標識映射信息； c)各個數(shù)據(jù)塊的標識映射信息； 根據(jù)提的信息制作相應(yīng)的索引文件。索引文件可以參見圖1，內(nèi)容如下
a)整體版本數(shù)據(jù)的屬性信息和標識映射信息，就每個版本數(shù)據(jù)而言包括
Pkgld 版本數(shù)據(jù)的類型標識，不同類型的版本數(shù)據(jù)采用不同的PkgId，例如不 同游戲的版本數(shù)據(jù)的Pkgld是不同的； BlockSize 文件分塊的單位大小(單位字節(jié))，即數(shù)據(jù)塊的長度； PkgldxVer 索引版本，同一類型但版本不同的版本數(shù)據(jù)的標識；例如同一游戲
有不同的版本，那么不同的版本間Pkgld是相同的，但PkgldxVer不同； SelfCRC索引文件的CRC自校驗，用于在網(wǎng)絡(luò)傳送過程中校驗索引文件自身
是否正確傳輸； FileDescList 文件描述信息的列表(多個文件描述信息的數(shù)組)，表示了該 版本數(shù)據(jù)中所有的文件的屬性信息和標識映射信息。
b)文件描述信息的列表FileDescList中包含了該版本數(shù)據(jù)中所有的文件的屬性
信息和標識映射信息，就每個文件而言，其描述信息如下(FileDescInfo)包括 FileAttr 文件類型，類型分為目錄和文件兩種； FilePathName 文件名稱包含的相對路徑； FileModifyTime 文^牛修改時間； FileCRC 文件整個內(nèi)容的CRC校驗碼； FileLength 文件長度(單位字節(jié))； BeginBlockld文件中第一個數(shù)據(jù)塊的編號；就整個版本數(shù)據(jù)而言，其中所有
的數(shù)據(jù)塊的編號都是唯一的，通過數(shù)據(jù)塊的編號可以快速定位數(shù)據(jù)塊在整個版本數(shù)據(jù)以及 整個文件中的位置； BlockDescList 文件數(shù)據(jù)塊信息的列表(多個數(shù)據(jù)塊信息的數(shù)組)，表示了該 文件中所有的數(shù)據(jù)塊的標識映射信息； c)文件數(shù)據(jù)塊信息的列表BlockDescList中包含了該文件中所有數(shù)據(jù)塊的標識 映射信息，就一個數(shù)據(jù)塊而言，其描述信息如下(BlockDescInfo):
BlockCRC 數(shù)據(jù)塊內(nèi)容的CRC校驗碼。 此后將版本數(shù)據(jù)及索引文件上傳到同步源節(jié)點(SyncSrcNode)上，以便 BarServer增量更新游戲數(shù)據(jù)。 2.同步源節(jié)點(SyncSrcNode)，此程序的功能是接受來自PMUpdate程序提交的索 引文件，并通過差異對比，產(chǎn)生需求數(shù)據(jù)塊(需要更新的數(shù)據(jù)塊)，向PMUpdate程序索要對 應(yīng)的數(shù)據(jù)塊，并將這些數(shù)據(jù)塊，根據(jù)索引內(nèi)部的信息，準確地放置在目標位置上。此程序存 放的數(shù)據(jù)都是經(jīng)過整編的數(shù)據(jù)文件。同時SyncSrcNode還提供其他未更新此版本游戲的 SyncSrcNode數(shù)據(jù)同步服務(wù)，和BarServer的同步服務(wù)。
參見圖2，進行差異對比時步驟如下 a)根據(jù)在后版本索引文件中所有文件的屬性信息和標識映射信息查找出在先版 本數(shù)據(jù)中不包含的文件，以及有改動的文件； 對于在先版本數(shù)據(jù)中不包含的文件，則用直接更新，即將在后版本數(shù)據(jù)中的該文 件復制到在先版本數(shù)據(jù)中； 對于有改動的文件，根據(jù)文件中各個數(shù)據(jù)塊的標識映射信息查找出在先版本數(shù)據(jù) 中和在后版本數(shù)據(jù)中有改動的數(shù)據(jù)塊，對有改動的數(shù)據(jù)塊進行更新，即將在后版本數(shù)據(jù)中 的該數(shù)據(jù)塊復制到在先版本數(shù)據(jù)中； b)根據(jù)在先版本索引文件中所有的文件的屬性信息和標識映射信息查找出在后
版本數(shù)據(jù)中不包含的文件，以及有改動的文件； 對于在后版本數(shù)據(jù)中不包含的文件，直接刪除該文件； 對于有改動的文件，根據(jù)文件中各個數(shù)據(jù)塊的標識映射信息查找出在后版本數(shù)據(jù) 中不包含的數(shù)據(jù)塊，直接刪除該數(shù)據(jù)塊。 3.全局同步源服務(wù)器程序(GlobalSSS-GlobalSyncSrcServer)，其作用是分配新 增游戲的游戲資源信息，例如給新增游戲分配游戲ID，給更新的游戲分配版本號，記錄最 新版本游戲的屬性，并提供給網(wǎng)吧服務(wù)端顯示。其另一個重要的任務(wù)是管理SyncSrcNode 的游戲數(shù)據(jù)同步。同步SyncSrcNode有哪些版本的游戲，供SyncSrcNode或BarServer去
10連接下載。由于其負責游戲資源屬性的分配，所以要配套數(shù)據(jù)庫，用于持久化游戲信息。
4.本地同步源服務(wù)器程序(LocalSSS-LocalSyncSrcServer)，本程序本身是一 個代理程序。提供BarServer更新游戲需要的索引文件和IDC端所有游戲最新版本的 SyncSrcServer節(jié)點的信息。 PMUpdate是游戲更新的發(fā)起者，提供索引文件和整編后的游戲數(shù)據(jù)。SyncSrcNode 是游戲數(shù)據(jù)的保持者和提供者，實際上BarServer也是 一 個SyncSrcNode,只不過 BarServer還具有其他功能，在游戲更新方面，可以把BarServer理解為一個級別比較低的 SyncSrcNode。 GlobalSSS具有2大功能，即游戲ID和版本的分配、游戲?qū)傩孕畔⒌某志没?，?SyncSrcNode的游戲信息的同步。 原本只有GlobalSSS，沒有LocalSSS程序，由于BarServer的數(shù)量級和保正 GlobalSSS不受外部攻擊，產(chǎn)生了 LocalSSS， LocalSSS是GlobalSSS的功能切割版，提供最 新的索引文件和持有該版本游戲的SyncSrcNode列表，并實現(xiàn)了負載均衡效果。
參見圖5， IDC層之間的更新流程和程序間的交互 PMUpdate登錄GlobalSSS,在登錄成功后，向GlobalSSS請求游戲列表，當游戲制 作人員發(fā)現(xiàn)IDC端上沒有將要更新的游戲后，決定新增這個游戲。通過界面交互PMUpdate 將游戲制作人員編輯的游戲信息上傳給GlobalSSS,其帶的游戲ID是0，表示未分配游戲 ID。 GlobalSSS收到游戲?qū)傩孕畔⒑螅l(fā)現(xiàn)游戲ID是零，則自動分配一個新的游戲ID 回復給PMUpdate程序，并且向數(shù)據(jù)指定表中插入一條記錄，此記錄表示這個游戲的屬性。
收到GlobalSSS的游戲ID號和初始版本號后，PMUpdate開始將游戲數(shù)據(jù)整編并 開始制作索引文件，并將制作完成的索引文件發(fā)送到程序配置的SyncSrcNode上。當目標 SyncSrcNode收到索引文件后，在指定目錄下創(chuàng)建目標文件(數(shù)據(jù)整編格式的文件)，再查 找本地對應(yīng)游戲ID的索引文件，開始差異對比。在新增游戲的操作中，由于SyncSrcNode 本地沒有先前版本，所以差異對比結(jié)果是需要更新所有數(shù)據(jù)。則SyncSrcNode會根據(jù)比較 出來的需求數(shù)據(jù)塊列表，向PMUpdate程序所要相應(yīng)的數(shù)據(jù)塊。PMUpdate收到塊請求信令 后，從緩存或磁盤中讀出對應(yīng)的數(shù)據(jù)塊，傳輸給SyncSrcNode程序。SyncSrcNode收到數(shù) 據(jù)塊后，寫入指定的位置。直到所有數(shù)據(jù)塊都被放入了合法的位置后，SyncSrcNode通知 PMUpdate更新完畢。PMUpdate則將索引文件提交給GlobalSSS, GlobalSSS本地持久化這 個索引文件，并將索引文件中相關(guān)信息修改到剛才插入的那條記錄中。
GlobalSSS完成上述操作后，通知所有注冊到它這里的LocalSSS和SyncSrcNode 向他請求游戲下載信息(包含最新索引和可供下載的SyncSrcNode列表)。SyncSrcNode 程序發(fā)現(xiàn)索引和本地不同，就會向得到的SyncSrcNode列表中的SyncSrcNode程序，提出 下載此版本游戲的請求，開始下載流程(由于此流程和BarServer請求下載流程類似，將 在下面介紹敘述)。LocalSSS收到下載列表后，會通知所有正在下載此游戲上一版本的 BarServer,去哪個SyncSrcNode節(jié)點下載新版本的游戲。 同時已有最新版本游戲的SyncSrcNode向GlobalSSS上報自己的信息，由 GlobalSSS分發(fā)給所有注冊的LocalSSS。 PMUpdate升級某個已經(jīng)存在的游戲流程和上面相似，區(qū)別在于GlobalSSS不回復
11游戲ID，而是新的版本號。 參見圖6， IDC層和網(wǎng)吧服務(wù)器層的數(shù)據(jù)更新流程及其程序交互如下
BarServer在成功登錄LocalSSS后，會定時獲取游戲列表。當某些游戲被設(shè)置成 自動更新(即IDC有更新時，無需人工干預就會自動同步游戲數(shù)據(jù)的功能)或由網(wǎng)管通過 界面程序手動干預后，BarServer會向LocalSSS請求此版本游戲的下載信息。BarServer 獲得此信息后，會對比新舊索引，進行差異對比，生成需求數(shù)據(jù)塊列表。向下載信息里的 SyncSrcNode所要需求數(shù)據(jù)塊。當下載并組裝完成所有的數(shù)據(jù)塊后，BarServer會通知所連 接的LocalSSS自己的本版本游戲的更新信息。 其實，IDC層的SyncSrcNode之間的同步和此流程極為相似，只不過這里的 BarServer可以看成請求同步的SyncSrcNode, GlobalSSS相當于這里的LocalSSS。
參見圖7，網(wǎng)吧服務(wù)器層和網(wǎng)吧電腦的游戲更新流程和程序間交互如下
BarClient上線會去登錄BarServer,當BarServer認證成功后，BarClient向 BarServer請求游戲列表。得到BarServer持有的游戲列表后，BarClient根據(jù)自己的機制 判斷哪些游戲需要下載。對需要下載的游戲請求索引文件。BarServer得到某個BarClient 的索引請求后，將對應(yīng)的游戲索引發(fā)回給BarCl ient 。 BarCl ient根據(jù)差異對比算法，得出 需求數(shù)據(jù)塊，并向BarServer請求需求塊。BarServer根據(jù)請求回復指定數(shù)據(jù)塊的內(nèi)容。 BarClient獲得需求數(shù)據(jù)塊有，判讀某個文件是否完整了 ，如果完整則把此文件從臨時文件 改名為正式文件。 當所有的游戲數(shù)據(jù)文件都完成更新后，就和PMUpdate制作前的格式和內(nèi)容完全一樣。 由上面的可以看出無論是SyncSrcNode、BarServer還是BarCl ient在增量更新功 能實現(xiàn)上都使用了本發(fā)明的基于分塊索引以及配套的差異對比的數(shù)據(jù)更新方法。本發(fā)明的 數(shù)據(jù)更新方法貫穿于整個三層更新機制中。 另外，對于BarServer或者其他SyncSrcNode同步更新的申請，SyncSrcNode都
會按照他們的遞送的申請去打開對應(yīng)的包文件并回復。當PMUpdate上傳一個游戲到
SyncSrcNode后，就會有許許多多的BarServer或者SyncSrcNode來下載這個游戲，發(fā)送相
同申請，導致相同的數(shù)據(jù)塊的重復讀取，這么一來效率上就變得十分低下了，傳輸速度也很
難上去。于是把讀過的塊緩存起來，當有相同的請求到來時直接回復。 現(xiàn)有技術(shù)中原先的緩存是每一個包開固定大小的緩存，各自緩存自己的塊數(shù)據(jù)，
但并不是每一個游戲都是很熱門的下載申請數(shù)量也不平均，這樣就會造成一定空間上的浪費。 參見圖8，本發(fā)明的三層架構(gòu)中，在進行數(shù)據(jù)交互的兩層中，為了提高數(shù)據(jù)量的吞 吐量以及傳輸速度，在數(shù)據(jù)交互時，特別是在數(shù)據(jù)塊的傳輸時采用了優(yōu)化下載緩存的方法， 如下 (1)在數(shù)據(jù)塊的提供端建立了一個共享緩存(DownCache)，更新數(shù)據(jù)塊時，數(shù)據(jù)塊 的提供端根據(jù)數(shù)據(jù)塊的請求端的請求，向共享緩存中讀入指定的數(shù)據(jù)塊；建立便于共享緩 存對客戶端(數(shù)據(jù)塊的請求端)的所有請求實現(xiàn)統(tǒng)一管理。 對于本發(fā)明采用的三層架而言，數(shù)據(jù)塊的提供端與數(shù)據(jù)塊的請求端時相對而言 的，相鄰兩層中，高級別層可作為數(shù)據(jù)塊的提供端，低級別層則作為數(shù)據(jù)塊的請求端。
(2)數(shù)據(jù)塊的提供端在收到數(shù)據(jù)塊下載申請時，首先讀共享緩存，共享緩存中如果 有該數(shù)據(jù)塊，則立即將請求的數(shù)據(jù)塊向數(shù)據(jù)塊的請求端傳輸； 共享緩存如果沒有該數(shù)據(jù)塊，并不是馬上開始讀文件的，而是把該數(shù)據(jù)塊下載申 請?zhí)峤唤o請求隊列。 (3)當數(shù)據(jù)塊的提供端空閑時按下載申請的提交時間順序處理請求隊列中的下載 申請，將請求的數(shù)據(jù)塊向數(shù)據(jù)塊的請求端傳輸。 作為優(yōu)選，對共享緩存中的數(shù)據(jù)塊按照命中率(命中率是讀到同一個塊的次數(shù))
排序，當共享緩存放滿的時候，將處于末尾的數(shù)據(jù)塊從共享緩存中淘汰出去。 為了避免某一數(shù)據(jù)塊下載申請在請求隊列中的等候時間過長，可是設(shè)定等候時間
閾值，當某一數(shù)據(jù)塊下載申請在請求隊列中的等候時間超過閾值時，即使數(shù)據(jù)塊的提供端
并沒有空閑，也優(yōu)先處理該數(shù)據(jù)塊下載申請。 一般情況，時間閾值可設(shè)為15 30分鐘。 為了進一步減少讀寫文件時的尋道時間，對于共享緩存中命中率相同的數(shù)據(jù)塊按
照序號進行升序排序。 本發(fā)明在數(shù)據(jù)塊更新時，在數(shù)據(jù)塊的傳輸上采用了優(yōu)化下載緩存的方法對于大量 的請求，數(shù)據(jù)塊的提供端遵循了一定的策略，即連接數(shù)多的游戲優(yōu)先下載，并且按照文件與 數(shù)據(jù)塊的序號進行了升序排序，進一步減少寫文件時的尋道時間，也保證了寫文件時是順 序?qū)懙摹?由于IDC層帶寬是稀缺資源，成本較高，目前本發(fā)明的IDC更新量在高峰時刻已經(jīng) 飽和，為了保證網(wǎng)吧服務(wù)器層的更新需求，充分利用網(wǎng)吧的上行帶寬資源，讓網(wǎng)吧服務(wù)器相 互共享數(shù)據(jù)，本發(fā)明進行數(shù)據(jù)更新時還采用P2P技術(shù)。 TCPP2P使用TCP/IP協(xié)議進行數(shù)據(jù)共享的P2P技術(shù)，其優(yōu)點是TCP/IP協(xié)議提供穩(wěn) 定可靠的連接，保證網(wǎng)絡(luò)傳輸?shù)母咚俸蛿?shù)據(jù)正確性。連接的建立受多方面的影響，所以要求 使用TCPP2P的網(wǎng)吧服務(wù)器必須支持UPNP技術(shù)。TCPP2P需要經(jīng)過兩個階段，1.信息共享階 段2.數(shù)據(jù)交互階段
信息共享階段 參見圖9，此階段各個網(wǎng)吧服務(wù)器都要向LocalSSS上報自己存在的游戲信息，以 及支持P2P的IP和端口信息，供其他網(wǎng)吧服務(wù)器來連接。同時在自己需要下載時，向所連 接的LocalSSS索取上報此版本游戲信息網(wǎng)吧服務(wù)端的P2P信息。 為實現(xiàn)P2P信息的共享，在保持游戲更新通道原有架構(gòu)的基礎(chǔ)上新增加了一類程 序，叫做全局P2P信息轉(zhuǎn)發(fā)程序(GlobalP2P)。它的作用就是把注冊的LocalSSS上報的P2P 信息，轉(zhuǎn)發(fā)給除上報者外的其他所有注冊LocalSSS。當BarServer獲取到相關(guān)P2P信息后，
會自動連接有目標資源的網(wǎng)吧服務(wù)端。
數(shù)據(jù)交互階段 前面我們介紹過BarServer具有SyncSrcNode的功能，2個BarServer之間相互交 換數(shù)據(jù)的流程，和前面介紹的游戲更新流程處理方式一致。 本發(fā)明通過建立三層更新方式(網(wǎng)吧電腦為終端層、網(wǎng)吧服務(wù)器為網(wǎng)吧層、互聯(lián) 網(wǎng)服務(wù)器為IDC層)，將游戲的更新從IDC層更新到網(wǎng)吧層最終更新到終端層，通過三層更 新的方法，將終端的更新量匯集到網(wǎng)吧層，從而有效降低了更新量，解決了大量終端的并發(fā) 瓶頸和巨大的更新量的問題。
本發(fā)明通過對游戲內(nèi)容的分塊索引和差異對比以及P2P分發(fā)網(wǎng)絡(luò)的技術(shù)，將游戲 的更新量控制到最小，同時也在互聯(lián)網(wǎng)服務(wù)器帶寬有限的前提下，充分利用了網(wǎng)吧的上行 帶寬資源，縮短了游戲更新的耗時，為網(wǎng)吧和網(wǎng)民提供了更加暢快的娛樂體驗。
權(quán)利要求
一種基于數(shù)據(jù)塊比較的數(shù)據(jù)更新方法，其特征在于，包括如下步驟(1)將所有版本數(shù)據(jù)均劃分為若干數(shù)據(jù)塊，針對每個版本數(shù)據(jù)，分別提取該版本數(shù)據(jù)中a)整體版本數(shù)據(jù)的屬性信息和標識映射信息；b)所有文件的屬性信息和標識映射信息；c)各個數(shù)據(jù)塊的標識映射信息；(2)針對每個版本數(shù)據(jù)，建立對應(yīng)的索引文件，所述的索引文件包含針對該版本數(shù)據(jù)的步驟(1)中提取的信息；(3)進行數(shù)據(jù)更新時a)根據(jù)在后版本索引文件中所有文件的屬性信息和標識映射信息查找出在先版本數(shù)據(jù)中不包含的文件，以及有改動的文件；對于在先版本數(shù)據(jù)中不包含的文件，則直接更新；對于有改動的文件，根據(jù)文件中各個數(shù)據(jù)塊的標識映射信息查找出在先版本數(shù)據(jù)中和在后版本數(shù)據(jù)中有改動的數(shù)據(jù)塊，對有改動的數(shù)據(jù)塊進行更新；b)根據(jù)在先版本索引文件中所有的文件的屬性信息和標識映射信息查找出在后版本數(shù)據(jù)中不包含的文件，以及有改動的文件；對于在后版本數(shù)據(jù)中不包含的文件，直接刪除該文件；對于有改動的文件，根據(jù)文件中各個數(shù)據(jù)塊的標識映射信息查找出在后版本數(shù)據(jù)中不包含的數(shù)據(jù)塊，直接刪除該數(shù)據(jù)塊。
2. 如權(quán)利要求l所述的數(shù)據(jù)更新方法，其特征在于，步驟(1)中，將某一個版本數(shù)據(jù)劃 分為若干數(shù)據(jù)塊時，是以單個文件為對象，按預先指定的數(shù)據(jù)塊的長度逐個文件劃分， 一個 文件劃分到最后時，其末尾塊的處理方法如下a) 設(shè)定閾值；b) 計算末尾塊的長度，求出該末尾塊長度與預先指定的數(shù)據(jù)塊的長度的比值；C)當所述的比值小于閾值時，則將該末尾塊合并到其前一個數(shù)據(jù)塊中，若比值大于或 等于閾值時，則將該末尾塊單獨劃為一個數(shù)據(jù)塊。
3. 如權(quán)利要求l所述的數(shù)據(jù)更新方法，其特征在于，步驟(3)中在進行數(shù)據(jù)塊的更新 時，數(shù)據(jù)塊的提供端存放有在后版本數(shù)據(jù)，數(shù)據(jù)塊的請求端存放有在先版本數(shù)據(jù)(1) 在數(shù)據(jù)塊的提供端建立了一個共享緩存，更新數(shù)據(jù)塊時，數(shù)據(jù)塊的提供端根據(jù)數(shù)據(jù) 塊的請求端的請求，向共享緩存中讀入指定的數(shù)據(jù)塊；(2) 數(shù)據(jù)塊的提供端在收到數(shù)據(jù)塊下載申請時，首先讀共享緩存，共享緩存中如果有該 數(shù)據(jù)塊，則立即將請求的數(shù)據(jù)塊向數(shù)據(jù)塊的請求端傳輸；共享緩存如果沒有該數(shù)據(jù)塊，把該數(shù)據(jù)塊下載申請?zhí)峤唤o請求隊列；(3) 當數(shù)據(jù)塊的提供端空閑時按下載申請的提交時間順序處理請求隊列中的下載申 請，將請求的數(shù)據(jù)塊向數(shù)據(jù)塊的請求端傳輸。
4. 如權(quán)利要求3所述的數(shù)據(jù)更新方法，其特征在于，對共享緩存中的數(shù)據(jù)塊按照命中 率排序，當共享緩存放滿的時候，將處于末尾的數(shù)據(jù)塊從共享緩存中清除。
5. 如權(quán)利要求4所述的數(shù)據(jù)更新方法，其特征在于，對于共享緩存中命中率相同的數(shù) 據(jù)塊按照序號進行升序排序。
6.如權(quán)利要求5所述的數(shù)據(jù)更新方法，其特征在于，設(shè)定等候時間閾值，當某一數(shù)據(jù)塊 下載申請在請求隊列中的等候時間超過閾值時，數(shù)據(jù)塊的提供端優(yōu)先處理該數(shù)據(jù)塊下載申
全文摘要
本發(fā)明提供了一種基于數(shù)據(jù)塊比較的數(shù)據(jù)更新方法，包括(1)將所有版本數(shù)據(jù)均劃分為若干數(shù)據(jù)塊，針對每個版本數(shù)據(jù)，分別提取該版本數(shù)據(jù)中所有文件和各個數(shù)據(jù)塊的標識映射信息；(2)針對每個版本數(shù)據(jù)，建立對應(yīng)的索引文件；(3)進行數(shù)據(jù)更新時根據(jù)在后版本索引文件中所有文件的屬性信息和標識映射信息查找出在先版本數(shù)據(jù)中和在后版本數(shù)據(jù)中不同的數(shù)據(jù)塊，并進行更新。本發(fā)明數(shù)據(jù)更新方法，通過對數(shù)據(jù)的劃分以及特定的更新算法大大提高了數(shù)據(jù)更新的速度，另外結(jié)合改進的網(wǎng)絡(luò)下載架構(gòu)進一步減輕了服務(wù)器的負荷，提高網(wǎng)絡(luò)傳輸?shù)男阅堋?br> 文檔編號G06F17/30GK101770515SQ201010040010
公開日2010年7月7日 申請日期2010年1月18日 優(yōu)先權(quán)日2010年1月18日
發(fā)明者程琛, 許冬 申請人:杭州順網(wǎng)科技股份有限公司