一种基于数据块比较的数据更新方法

专利名称：一种基于数据块比较的数据更新方法
技术领域：
本发明涉及计算机技术领域，尤其涉及一种数据的更新方法。
背景技术：
国内热门的网络游戏在100款以上，几乎每天都会有30%以上的网络游戏会发生 内容更新，网吧的电脑里面的游戏也需要及时的更新，才能在满足网吧网民的需求，在解决 这个需求上存在两个技术难点，难点之一是所有网吧的机器终端数非常庞大，约在在1000 万台以上，如果都直接从互联网服务器进行游戏更新，服务器的性能负荷根本不能应付，同 时还需要在互联网上分配巨大的网络带宽资源才能支持；难点之二是热门游戏的更新量是 非常巨大的，如果从文件更新的级别来看，目前每天平均在40G左右，巨大的更新量几乎使 得游戏更新基本不能在网吧里面正常运作，网吧带宽有限，游戏要更新完需要几乎不能忍 受的时间长度)。为了解决以上问题，现有技术也有采用数据增量更新的手段，即检查数据 更新与更新后的差异，更新时只针对该差异部分进行更新， 一般以逻辑文件作为原子处理 对象，更新差异比较以文件本身的属性，例如文件创建时间或文件修改时间做为判断依据， 来判断此文件是否被更新过。如果文件被更新过了，则把整个文件作为差异需求，需要网络 传输达到数据更新的目的。 但现有方法是以逻辑文件作为处理对象，在实际应用中，很多数据更新只是改变 文件中的一段数据。这就导致更新差异比较粒度过大，会重复更新一些原有数据。
如果更新差异比较出来的文件需要更新，文件的长度就是需要更新的大小。由于 文件可大可小，导致原子更新长度也是动态变化的。会导致网络传输的性能下降。

发明内容
本发明提供了一种快速的数据更新方法，通过对数据的划分以及特定的更新算法 大大提高了数据更新的速度，另外结合改进的网络下载架构进一步减轻了服务器的负荷， 提高网络传输的性能。 本发明数据更新方法通过使用数据内容的分块索引和差异对比来实现，把一套完 整的数据(例如一款游戏的所有数据)看作一个连续完整的二进制数据流。 一个文件是一 段二进制数据流的逻辑单位。 一个数据块也是二进制数据流的逻辑单位。
三者的关系是数据块是文件的子集，文件是游戏数据的子集。当文件整体大小 小于一个数据块定义长度时，一个文件的内容就是一个数据块。当然，大多数情况是一个文 件有若干数据块。数据块的长度可以人工定义，这样我们可以根据网络传输的特点和磁盘 (目前大量使用磁盘列阵)缓存的特点，找到在全局系统中整体性能最优的数据块长度。而 不是被动适应文件长度。
—种基于数据块比较的数据更新方法，包括如下步骤 (1)将所有版本数据均划分为若干数据块，针对每个版本数据，分别提取该版本数 据中
a)整体版本数据的属性信息和标识映射信息；
b)所有文件的属性信息和标识映射信息；
C)各个数据块的标识映射信息； (2)针对每个版本数据，建立对应的索引文件，所述的索引文件包含针对该版本数 据的步骤(1)中提取的信息； (3)进行数据更新时，对比在先版本数据及其在后版本数据的索引文件，对比时步 骤如下 a)根据在后版本索引文件中所有文件的属性信息和标识映射信息查找出在先版 本数据中不包含的文件，以及有改动的文件； 对于在先版本数据中不包含的文件，则直接更新，即将在后版本数据中的该文件 复制到在先版本数据中； 对于有改动的文件，根据文件中各个数据块的标识映射信息查找出在先版本数据 中和在后版本数据中有改动的数据块，对有改动的数据块进行更新，即将在后版本数据中 的该数据块复制到在先版本数据中； b)根据在先版本索引文件中所有的文件的属性信息和标识映射信息查找出在后
版本数据中不包含的文件，以及有改动的文件； 对于在后版本数据中不包含的文件，直接删除该文件； 对于有改动的文件，根据文件中各个数据块的标识映射信息查找出在后版本数据 中不包含的数据块，直接删除该数据块。 本发明步骤(1)中，将某一个版本数据划分为若干数据块时，是以单个文件为对 象，逐个文件来划分的，不同的文件中的数据不会划分到同一个数据块中，由于数据块的长 度是预先指定的，而一个文件划分到最后时，末尾块的长度一般都不会恰好与预先指定的 数据块的长度相等，那么对于一个文件末尾块的处理方法如下 要说明的是末尾块的长度一定是小于或等于预先指定的数据块的长度，否则的话 就会继续划分，当末尾块的长度等于预先指定的数据块的长度时，就按预定的原则划分，我 们重点考虑的是末尾块的长度小于预先指定的数据块的长度。 首先设定一个阈值，计算末尾块的长度，求出该末尾块长度与预先指定的数据块 的长度的比值，当比值小于阈值时，则将该末尾块合并到其前一个数据块中，若比值大于或 等于阈值时，则将该末尾块单独划为一个数据块。作为优选，阈值取1/3，这样可以尽量减少 零星的短长度数据块，有利于提高网络传输的效率，也尽量避免频繁的数据读写。
数据块的长度对数据的更新有直接的影响 如果数据块长度过大，在网络传输时发生失真，会导致整个数据块重新发送，期间
去占去大量的网络资源和机器性能资源，费事费力。这也是朴素处理方式的弱点。 如果数据块定义适中，由于一块数据块可以从多个服务器上获取。大量数据可以
从多个服务器中分别获得后再组装，这样整个网络资源将会被平摊在各个服务器的带宽
中。作为优选数据块的长度采用16 64K较为合适，最为进一步的优选数据块的长度采用
32K，此时可以达到网络传输质量与程序性能的兼顾。 如果数据块定义太小，则增加了程序和操作系统之间的交互次数，影响程序性能。
现有技术中有许多方法可以得到数据块(一段二进制流)的标识映射信息。例如
5有MD5码和CRC32等等。 比较MD5码和CRC32，MD5码的冲突率更低，也就是说，2段不同内容的二进制数据 流，用MD5码可以区分出差异，但CRC32可能会认为2段流是一样的。通过CRC32制作出的 标识信息只有4个字节，而通过MD5制作标识信息可能操作128个字节。二者的时间复杂 度相差不大。 不管使用什么方式建立数据块的标识映射信息，其目的都是只要对比数据量较小 的标识映射信息替换数据块的内容比较。假设数据块长度是32K字节，则我们使用4字节 或128字节的比较来，替换32K字节的比较。 本发明中最终选用CRC32作为标识映射信息，主要是考虑到CRC32的冲突率可接 受，并且标识映射信息所占空间小，有利于减少索引的大小。 步骤(2)所述的索引文件，是记录一个版本数据所有数据块标识映射信息的集 合。不同版本的数据一定对应一个版本的索引文件。 索引文件的作用待更新程序，通过比较不同版本的索引文件，产生差异需求量， 这样待更新程序，只要下载差异部分的数据，就可以完成版本升级。
本发明索引文件中的内容包括以下几项 a)整体版本数据的属性信息和标识映射信息，就每个版本数据而言包括 Pkgld 版本数据的类型标识，不同类型的版本数据采用不同的Pkgld，例如不
同游戏的版本数据的Pkgld是不同的； BlockSize 文件分块的单位大小(单位字节)，即数据块的长度； PkgldxVer 索引版本，同一类型但版本不同的版本数据的标识；例如同一游戏
有不同的版本，那么不同的版本间Pkgld是相同的，但PkgldxVer不同； SelfCRC索引文件的CRC自校验，用于在网络传送过程中校验索引文件自身
是否正确传输； FileDescList 文件描述信息的列表(多个文件描述信息的数组)，表示了该 版本数据中所有的文件的属性信息和标识映射信息。 b)文件描述信息的列表FileDescList中包含了该版本数据中所有的文件的属性
信息和标识映射信息，就每个文件而言，其描述信息如下(FileDescInfo)包括 FileAttr 文件类型，类型分为目录和文件两种； FilePathName 文件名称包含的相对路径；FileModifyTime 文^牛修改时间； FileCRC 文件整个内容的CRC校验码； FileLength 文件长度(单位字节)； BeginBlockld文件中第一个数据块的编号；就整个版本数据而言，其中所有
的数据块的编号都是唯一的，通过数据块的编号可以快速定位数据块在整个版本数据以及 整个文件中的位置； BlockDescList 文件数据块信息的列表(多个数据块信息的数组)，表示了该 文件中所有的数据块的标识映射信息； c)文件数据块信息的列表BlockDescList中包含了该文件中所有数据块的标识 映射信息，就一个数据块而言，其描述信息如下(BlockDescInfo):
BlockCRC 数据块内容的CRC校验码。 步骤(3)中，对比在先版本数据及其在后版本数据时是采用了基于分块索引的差 异对比算法 可分为二大步骤 —、得到两个版本的索引文件后，先以新版本(在后版本数据)的索引文件作为基 准，遍历新版本的索引文件，取出文件类型的文件描述信息(FileDescInfo)，到旧版本(在 先版本数据)的索引文件中查找此文件的信息，如果查不到，则说明这个文件是新增的，产 生差异比较结果(此文件需要全部更新)。如果查到了，判断2个索引中FileDescInfo的 FileCRC是否相同，如果相同，我们认为这个文件没有任何变动。如果不相同，则需求查找 变化的数据块有哪些，开始顺序遍历此文件的块描述信息(BlockDescInfo)，当新旧对应的 BlockCRC不同，我们认为这个数据块需要更新。 二、以上操作能处理新增和修改数据块的效果。如果新版本的文件删除了数据块 时，处理方法如下 以旧版本的索引文件作为基准，遍历旧版本索引文件，取出文件类型的文件描述
信息，到新版本的索引文件中查找，如果没有，说明这个文件将被删除。 对于块的删除，和上面的流程相同。 以上两个步骤，产生的差异有2种类型需要下载更新和需要被替换。这就反映出 要下哪些数据，和数据组装时，更新下来的数据块需要放在哪个位置。 而索引文件的文件信息描述中有BeginBlockld(文件第一块的编号)这个信息， 所以遍历文件信息描述数组，就可以通过数据块的长度和偏移量计算精确定位到任一块数 据块应该存放在磁盘中的位置。 本发明步骤(3)中在进行数据块的更新时，其实是在数据块的提供端和数据块的 请求端之间进行的，也就是说数据块的提供端存放有在后版本数据，数据块的请求端存放 有在先版本数据，数据更新时为了提高数据块的提供端和数据块的请求端之间数据量的吞 吐量以及传输速度，采用如下方法 (1)在数据块的提供端建立了一个共享缓存(DownCache)，更新数据块时，数据块 的提供端根据数据块的请求端的请求，向共享缓存中读入指定的数据块；建立便于共享缓 存对客户端(数据块的请求端)的所有请求实现统一管理。 (2)数据块的提供端在收到数据块下载申请时，首先读共享缓存，共享缓存中如果 有该数据块，则立即将请求的数据块向数据块的请求端传输； 共享缓存如果没有该数据块，并不是马上开始读文件的，而是把该数据块下载申 请提交给请求队列。 (3)当数据块的提供端空闲时按下载申请的提交时间顺序处理请求队列中的下载 申请，将请求的数据块向数据块的请求端传输。 作为优选，对共享缓存中的数据块按照命中率(命中率是读到同一个块的次数)
排序，当共享缓存放满的时候，将处于末尾的数据块从共享缓存中淘汰出去。 为了避免某一数据块下载申请在请求队列中的等候时间过长，可是设定等候时间
阈值，当某一数据块下载申请在请求队列中的等候时间超过阈值时，即使数据块的提供端
并没有空闲，也优先处理该数据块下载申请。 一般情况，时间阈值可设为15 30分钟。
7
为了进一步减少读写文件时的寻道时间，对于共享缓存中命中率相同的数据块按 照序号进行升序排序。 本发明提及的技术用语如无特殊说明，其含义可作如下理解 1、数据块是一组二进制数据流的集合，描述网络或逻辑处理的粒度。 2、索引文件用数据块来描述一套完整的游戏数据集合，对每个数据块制作标识
映射信息，将这些数据块的标识映射信息及部分游戏属性信息记录的文件叫做索引文件。
3、增量更新是针对一类具有版本升级属性的操作，依托原有数据，只需要更新少
量数据，就能达到升级目的过程。 4、 IDC(Intemet Data Center):互联网数据中心 5、 CRC32 (Cyclic Redundancy Check) :32位循环冗余校验码 6、时间复杂度指算法需要消耗的时间资源。如果一个问题的规模是n，解这一问
题的某一算法所需要的时间为T(n)，它是n的某一函数T(n)称为这一算法的"时间复杂性" 7、空间复杂度是指计算机科学领域完成一个算法所需要占用的存储空间。8、MD5码(message-digest algorithm 5):信息-摘要算法。被广泛用于加密和
解密技术上，它可以说是文件的〃 数字指纹〃 。 9、整编将离散分布的数据，集中成连续数据的过程。 10、解编是整编的逆操作。 本发明数据更新方法，通过对数据的划分以及特定的更新算法大大提高了数据更 新的速度，另外结合改进的网络下载架构进一步减轻了服务器的负荷，提高网络传输的性


图1为本发明索引文件的结构示意图； 图2为本发明差异对比算法的流程示意图； 图3为利用本发明数据更新方法的整体系统架构图； 图4为游戏数据更新通道架构图； 图5为IDC层内的新增游戏流程示意图； 图6为IDC层和网吧服务层的数据更新流程； 图7为网吧服务器层和网吧电脑层的数据更新和程序交互； 图8为优化下载缓存流程图； 图9为TCPP2P业务程序交互示意图。
具体实施例方式
以下结合具体的硬件及网络资源说明本发明数据更新方法，其中以游戏数据的更 新为例。 本发明通过建立三层更新方式(网吧电脑为终端层、网吧服务器为网吧层、互联 网服务器为IDC层)，将游戏的更新从IDC层更新到网吧层最终更新到终端层，通过三层更 新的方法，将终端的更新量汇集到网吧层，从而有效降低了更新量，解决了大量终端的并发 瓶颈和巨大的更新量的问题。该三层整体架构可以参见图3。
8
其中 终端层程序名BarClient，操作对象是网民，具有穿透还原功能和游戏更新功 能，此程序只和网吧服务器通信。 网吧层程序名BarServer，操作对象是网管或网吧业主，具有提供BarClient端 更新、从IDC更新游戏数据和网管功能。 IDC层提供最新版本的游戏制作并提供BarServer下载游戏。
参见图4， IDC层中的程序及其架构包括 1.游戏制作工具(PMUpdate)，此程序的功能是将游戏数据整编并制作对应的索
引，即就同一游戏程序而言，生成不同的版本数据，并将所有版本数据均划分为若干数据块
(每个数据块预定长度32k大小)。 针对一个文件的末尾块，作如下处理 nBlockCnt =块数； nFileLen =文件长度； nBlockSize =文件分块的单位大小；nBlockCnt = nFileLen/nBlockSize+1 if (nFileLen% nBlockSize < nBlockSize/MagicBlockGene) {—nBlockCnt ;}
MagicBlockGene取1/3是一个为了节约存储空间而设立的参数，它可以有效的 防止末尾块过小占用完整块大小的情况出现，当遇到末尾块过小时(即小于nBlockSize/ MagicBlockGene)末尾块不单独成块，而是合并到前一块上，那么，倒数第二块的块长 度就会大于BlockSize 了，所以块大小是不一样的。除了末尾块，其他块的大小都等于 BlockSize 计算出来块数nBlockCnt后，EndBlockld = BeginBlockld+nBlockCnt 从上面说明中可以看到，数据块的长度不是一成不变的。有2种类型的长度，一种
是指定长度，另一种是末尾块的剩余长度。 针对每个版本数据，分别提取该版本数据中 a)整体版本数据的属性信息和标识映射信息； b)所有文件的属性信息和标识映射信息； c)各个数据块的标识映射信息； 根据提的信息制作相应的索引文件。索引文件可以参见图1，内容如下
a)整体版本数据的属性信息和标识映射信息，就每个版本数据而言包括
Pkgld 版本数据的类型标识，不同类型的版本数据采用不同的PkgId，例如不 同游戏的版本数据的Pkgld是不同的； BlockSize 文件分块的单位大小(单位字节)，即数据块的长度； PkgldxVer 索引版本，同一类型但版本不同的版本数据的标识；例如同一游戏
有不同的版本，那么不同的版本间Pkgld是相同的，但PkgldxVer不同； SelfCRC索引文件的CRC自校验，用于在网络传送过程中校验索引文件自身
是否正确传输； FileDescList 文件描述信息的列表(多个文件描述信息的数组)，表示了该 版本数据中所有的文件的属性信息和标识映射信息。
b)文件描述信息的列表FileDescList中包含了该版本数据中所有的文件的属性
信息和标识映射信息，就每个文件而言，其描述信息如下(FileDescInfo)包括 FileAttr 文件类型，类型分为目录和文件两种； FilePathName 文件名称包含的相对路径； FileModifyTime 文^牛修改时间； FileCRC 文件整个内容的CRC校验码； FileLength 文件长度(单位字节)； BeginBlockld文件中第一个数据块的编号；就整个版本数据而言，其中所有
的数据块的编号都是唯一的，通过数据块的编号可以快速定位数据块在整个版本数据以及 整个文件中的位置； BlockDescList 文件数据块信息的列表(多个数据块信息的数组)，表示了该 文件中所有的数据块的标识映射信息； c)文件数据块信息的列表BlockDescList中包含了该文件中所有数据块的标识 映射信息，就一个数据块而言，其描述信息如下(BlockDescInfo):
BlockCRC 数据块内容的CRC校验码。 此后将版本数据及索引文件上传到同步源节点(SyncSrcNode)上，以便 BarServer增量更新游戏数据。 2.同步源节点(SyncSrcNode)，此程序的功能是接受来自PMUpdate程序提交的索 引文件，并通过差异对比，产生需求数据块(需要更新的数据块)，向PMUpdate程序索要对 应的数据块，并将这些数据块，根据索引内部的信息，准确地放置在目标位置上。此程序存 放的数据都是经过整编的数据文件。同时SyncSrcNode还提供其他未更新此版本游戏的 SyncSrcNode数据同步服务，和BarServer的同步服务。
参见图2，进行差异对比时步骤如下 a)根据在后版本索引文件中所有文件的属性信息和标识映射信息查找出在先版 本数据中不包含的文件，以及有改动的文件； 对于在先版本数据中不包含的文件，则用直接更新，即将在后版本数据中的该文 件复制到在先版本数据中； 对于有改动的文件，根据文件中各个数据块的标识映射信息查找出在先版本数据 中和在后版本数据中有改动的数据块，对有改动的数据块进行更新，即将在后版本数据中 的该数据块复制到在先版本数据中； b)根据在先版本索引文件中所有的文件的属性信息和标识映射信息查找出在后
版本数据中不包含的文件，以及有改动的文件； 对于在后版本数据中不包含的文件，直接删除该文件； 对于有改动的文件，根据文件中各个数据块的标识映射信息查找出在后版本数据 中不包含的数据块，直接删除该数据块。 3.全局同步源服务器程序(GlobalSSS-GlobalSyncSrcServer)，其作用是分配新 增游戏的游戏资源信息，例如给新增游戏分配游戏ID，给更新的游戏分配版本号，记录最 新版本游戏的属性，并提供给网吧服务端显示。其另一个重要的任务是管理SyncSrcNode 的游戏数据同步。同步SyncSrcNode有哪些版本的游戏，供SyncSrcNode或BarServer去
10连接下载。由于其负责游戏资源属性的分配，所以要配套数据库，用于持久化游戏信息。
4.本地同步源服务器程序(LocalSSS-LocalSyncSrcServer)，本程序本身是一 个代理程序。提供BarServer更新游戏需要的索引文件和IDC端所有游戏最新版本的 SyncSrcServer节点的信息。 PMUpdate是游戏更新的发起者，提供索引文件和整编后的游戏数据。SyncSrcNode 是游戏数据的保持者和提供者，实际上BarServer也是 一 个SyncSrcNode,只不过 BarServer还具有其他功能，在游戏更新方面，可以把BarServer理解为一个级别比较低的 SyncSrcNode。 GlobalSSS具有2大功能，即游戏ID和版本的分配、游戏属性信息的持久化，和 SyncSrcNode的游戏信息的同步。 原本只有GlobalSSS，没有LocalSSS程序，由于BarServer的数量级和保正 GlobalSSS不受外部攻击，产生了 LocalSSS， LocalSSS是GlobalSSS的功能切割版，提供最 新的索引文件和持有该版本游戏的SyncSrcNode列表，并实现了负载均衡效果。
参见图5， IDC层之间的更新流程和程序间的交互 PMUpdate登录GlobalSSS,在登录成功后，向GlobalSSS请求游戏列表，当游戏制 作人员发现IDC端上没有将要更新的游戏后，决定新增这个游戏。通过界面交互PMUpdate 将游戏制作人员编辑的游戏信息上传给GlobalSSS,其带的游戏ID是0，表示未分配游戏 ID。 GlobalSSS收到游戏属性信息后，发现游戏ID是零，则自动分配一个新的游戏ID 回复给PMUpdate程序，并且向数据指定表中插入一条记录，此记录表示这个游戏的属性。
收到GlobalSSS的游戏ID号和初始版本号后，PMUpdate开始将游戏数据整编并 开始制作索引文件，并将制作完成的索引文件发送到程序配置的SyncSrcNode上。当目标 SyncSrcNode收到索引文件后，在指定目录下创建目标文件(数据整编格式的文件)，再查 找本地对应游戏ID的索引文件，开始差异对比。在新增游戏的操作中，由于SyncSrcNode 本地没有先前版本，所以差异对比结果是需要更新所有数据。则SyncSrcNode会根据比较 出来的需求数据块列表，向PMUpdate程序所要相应的数据块。PMUpdate收到块请求信令 后，从缓存或磁盘中读出对应的数据块，传输给SyncSrcNode程序。SyncSrcNode收到数 据块后，写入指定的位置。直到所有数据块都被放入了合法的位置后，SyncSrcNode通知 PMUpdate更新完毕。PMUpdate则将索引文件提交给GlobalSSS, GlobalSSS本地持久化这 个索引文件，并将索引文件中相关信息修改到刚才插入的那条记录中。
GlobalSSS完成上述操作后，通知所有注册到它这里的LocalSSS和SyncSrcNode 向他请求游戏下载信息(包含最新索引和可供下载的SyncSrcNode列表)。SyncSrcNode 程序发现索引和本地不同，就会向得到的SyncSrcNode列表中的SyncSrcNode程序，提出 下载此版本游戏的请求，开始下载流程(由于此流程和BarServer请求下载流程类似，将 在下面介绍叙述)。LocalSSS收到下载列表后，会通知所有正在下载此游戏上一版本的 BarServer,去哪个SyncSrcNode节点下载新版本的游戏。 同时已有最新版本游戏的SyncSrcNode向GlobalSSS上报自己的信息，由 GlobalSSS分发给所有注册的LocalSSS。 PMUpdate升级某个已经存在的游戏流程和上面相似，区别在于GlobalSSS不回复
11游戏ID，而是新的版本号。 参见图6， IDC层和网吧服务器层的数据更新流程及其程序交互如下
BarServer在成功登录LocalSSS后，会定时获取游戏列表。当某些游戏被设置成 自动更新(即IDC有更新时，无需人工干预就会自动同步游戏数据的功能)或由网管通过 界面程序手动干预后，BarServer会向LocalSSS请求此版本游戏的下载信息。BarServer 获得此信息后，会对比新旧索引，进行差异对比，生成需求数据块列表。向下载信息里的 SyncSrcNode所要需求数据块。当下载并组装完成所有的数据块后，BarServer会通知所连 接的LocalSSS自己的本版本游戏的更新信息。 其实，IDC层的SyncSrcNode之间的同步和此流程极为相似，只不过这里的 BarServer可以看成请求同步的SyncSrcNode, GlobalSSS相当于这里的LocalSSS。
参见图7，网吧服务器层和网吧电脑的游戏更新流程和程序间交互如下
BarClient上线会去登录BarServer,当BarServer认证成功后，BarClient向 BarServer请求游戏列表。得到BarServer持有的游戏列表后，BarClient根据自己的机制 判断哪些游戏需要下载。对需要下载的游戏请求索引文件。BarServer得到某个BarClient 的索引请求后，将对应的游戏索引发回给BarCl ient 。 BarCl ient根据差异对比算法，得出 需求数据块，并向BarServer请求需求块。BarServer根据请求回复指定数据块的内容。 BarClient获得需求数据块有，判读某个文件是否完整了 ，如果完整则把此文件从临时文件 改名为正式文件。 当所有的游戏数据文件都完成更新后，就和PMUpdate制作前的格式和内容完全一样。 由上面的可以看出无论是SyncSrcNode、BarServer还是BarCl ient在增量更新功 能实现上都使用了本发明的基于分块索引以及配套的差异对比的数据更新方法。本发明的 数据更新方法贯穿于整个三层更新机制中。 另外，对于BarServer或者其他SyncSrcNode同步更新的申请，SyncSrcNode都
会按照他们的递送的申请去打开对应的包文件并回复。当PMUpdate上传一个游戏到
SyncSrcNode后，就会有许许多多的BarServer或者SyncSrcNode来下载这个游戏，发送相
同申请，导致相同的数据块的重复读取，这么一来效率上就变得十分低下了，传输速度也很
难上去。于是把读过的块缓存起来，当有相同的请求到来时直接回复。 现有技术中原先的缓存是每一个包开固定大小的缓存，各自缓存自己的块数据，
但并不是每一个游戏都是很热门的下载申请数量也不平均，这样就会造成一定空间上的浪费。 参见图8，本发明的三层架构中，在进行数据交互的两层中，为了提高数据量的吞 吐量以及传输速度，在数据交互时，特别是在数据块的传输时采用了优化下载缓存的方法， 如下 (1)在数据块的提供端建立了一个共享缓存(DownCache)，更新数据块时，数据块 的提供端根据数据块的请求端的请求，向共享缓存中读入指定的数据块；建立便于共享缓 存对客户端(数据块的请求端)的所有请求实现统一管理。 对于本发明采用的三层架而言，数据块的提供端与数据块的请求端时相对而言 的，相邻两层中，高级别层可作为数据块的提供端，低级别层则作为数据块的请求端。
(2)数据块的提供端在收到数据块下载申请时，首先读共享缓存，共享缓存中如果 有该数据块，则立即将请求的数据块向数据块的请求端传输； 共享缓存如果没有该数据块，并不是马上开始读文件的，而是把该数据块下载申 请提交给请求队列。 (3)当数据块的提供端空闲时按下载申请的提交时间顺序处理请求队列中的下载 申请，将请求的数据块向数据块的请求端传输。 作为优选，对共享缓存中的数据块按照命中率(命中率是读到同一个块的次数)
排序，当共享缓存放满的时候，将处于末尾的数据块从共享缓存中淘汰出去。 为了避免某一数据块下载申请在请求队列中的等候时间过长，可是设定等候时间
阈值，当某一数据块下载申请在请求队列中的等候时间超过阈值时，即使数据块的提供端
并没有空闲，也优先处理该数据块下载申请。 一般情况，时间阈值可设为15 30分钟。 为了进一步减少读写文件时的寻道时间，对于共享缓存中命中率相同的数据块按
照序号进行升序排序。 本发明在数据块更新时，在数据块的传输上采用了优化下载缓存的方法对于大量 的请求，数据块的提供端遵循了一定的策略，即连接数多的游戏优先下载，并且按照文件与 数据块的序号进行了升序排序，进一步减少写文件时的寻道时间，也保证了写文件时是顺 序写的。 由于IDC层带宽是稀缺资源，成本较高，目前本发明的IDC更新量在高峰时刻已经 饱和，为了保证网吧服务器层的更新需求，充分利用网吧的上行带宽资源，让网吧服务器相 互共享数据，本发明进行数据更新时还采用P2P技术。 TCPP2P使用TCP/IP协议进行数据共享的P2P技术，其优点是TCP/IP协议提供稳 定可靠的连接，保证网络传输的高速和数据正确性。连接的建立受多方面的影响，所以要求 使用TCPP2P的网吧服务器必须支持UPNP技术。TCPP2P需要经过两个阶段，1.信息共享阶 段2.数据交互阶段
信息共享阶段 参见图9，此阶段各个网吧服务器都要向LocalSSS上报自己存在的游戏信息，以 及支持P2P的IP和端口信息，供其他网吧服务器来连接。同时在自己需要下载时，向所连 接的LocalSSS索取上报此版本游戏信息网吧服务端的P2P信息。 为实现P2P信息的共享，在保持游戏更新通道原有架构的基础上新增加了一类程 序，叫做全局P2P信息转发程序(GlobalP2P)。它的作用就是把注册的LocalSSS上报的P2P 信息，转发给除上报者外的其他所有注册LocalSSS。当BarServer获取到相关P2P信息后，
会自动连接有目标资源的网吧服务端。
数据交互阶段 前面我们介绍过BarServer具有SyncSrcNode的功能，2个BarServer之间相互交 换数据的流程，和前面介绍的游戏更新流程处理方式一致。 本发明通过建立三层更新方式(网吧电脑为终端层、网吧服务器为网吧层、互联 网服务器为IDC层)，将游戏的更新从IDC层更新到网吧层最终更新到终端层，通过三层更 新的方法，将终端的更新量汇集到网吧层，从而有效降低了更新量，解决了大量终端的并发 瓶颈和巨大的更新量的问题。
本发明通过对游戏内容的分块索引和差异对比以及P2P分发网络的技术，将游戏 的更新量控制到最小，同时也在互联网服务器带宽有限的前提下，充分利用了网吧的上行 带宽资源，縮短了游戏更新的耗时，为网吧和网民提供了更加畅快的娱乐体验。
权利要求
一种基于数据块比较的数据更新方法，其特征在于，包括如下步骤(1)将所有版本数据均划分为若干数据块，针对每个版本数据，分别提取该版本数据中a)整体版本数据的属性信息和标识映射信息；b)所有文件的属性信息和标识映射信息；c)各个数据块的标识映射信息；(2)针对每个版本数据，建立对应的索引文件，所述的索引文件包含针对该版本数据的步骤(1)中提取的信息；(3)进行数据更新时a)根据在后版本索引文件中所有文件的属性信息和标识映射信息查找出在先版本数据中不包含的文件，以及有改动的文件；对于在先版本数据中不包含的文件，则直接更新；对于有改动的文件，根据文件中各个数据块的标识映射信息查找出在先版本数据中和在后版本数据中有改动的数据块，对有改动的数据块进行更新；b)根据在先版本索引文件中所有的文件的属性信息和标识映射信息查找出在后版本数据中不包含的文件，以及有改动的文件；对于在后版本数据中不包含的文件，直接删除该文件；对于有改动的文件，根据文件中各个数据块的标识映射信息查找出在后版本数据中不包含的数据块，直接删除该数据块。
2. 如权利要求l所述的数据更新方法，其特征在于，步骤(1)中，将某一个版本数据划 分为若干数据块时，是以单个文件为对象，按预先指定的数据块的长度逐个文件划分， 一个 文件划分到最后时，其末尾块的处理方法如下a) 设定阈值；b) 计算末尾块的长度，求出该末尾块长度与预先指定的数据块的长度的比值；C)当所述的比值小于阈值时，则将该末尾块合并到其前一个数据块中，若比值大于或 等于阈值时，则将该末尾块单独划为一个数据块。
3. 如权利要求l所述的数据更新方法，其特征在于，步骤(3)中在进行数据块的更新 时，数据块的提供端存放有在后版本数据，数据块的请求端存放有在先版本数据(1) 在数据块的提供端建立了一个共享缓存，更新数据块时，数据块的提供端根据数据 块的请求端的请求，向共享缓存中读入指定的数据块；(2) 数据块的提供端在收到数据块下载申请时，首先读共享缓存，共享缓存中如果有该 数据块，则立即将请求的数据块向数据块的请求端传输；共享缓存如果没有该数据块，把该数据块下载申请提交给请求队列；(3) 当数据块的提供端空闲时按下载申请的提交时间顺序处理请求队列中的下载申 请，将请求的数据块向数据块的请求端传输。
4. 如权利要求3所述的数据更新方法，其特征在于，对共享缓存中的数据块按照命中 率排序，当共享缓存放满的时候，将处于末尾的数据块从共享缓存中清除。
5. 如权利要求4所述的数据更新方法，其特征在于，对于共享缓存中命中率相同的数 据块按照序号进行升序排序。
6.如权利要求5所述的数据更新方法，其特征在于，设定等候时间阈值，当某一数据块 下载申请在请求队列中的等候时间超过阈值时，数据块的提供端优先处理该数据块下载申
全文摘要
本发明提供了一种基于数据块比较的数据更新方法，包括(1)将所有版本数据均划分为若干数据块，针对每个版本数据，分别提取该版本数据中所有文件和各个数据块的标识映射信息；(2)针对每个版本数据，建立对应的索引文件；(3)进行数据更新时根据在后版本索引文件中所有文件的属性信息和标识映射信息查找出在先版本数据中和在后版本数据中不同的数据块，并进行更新。本发明数据更新方法，通过对数据的划分以及特定的更新算法大大提高了数据更新的速度，另外结合改进的网络下载架构进一步减轻了服务器的负荷，提高网络传输的性能。
文档编号G06F17/30GK101770515SQ201010040010
公开日2010年7月7日 申请日期2010年1月18日 优先权日2010年1月18日
发明者程琛, 许冬 申请人:杭州顺网科技股份有限公司