分布式备份数据的方法、装置和***
技术领域
本发明涉及计算机互联网领域,具体而言,涉及一种分布式备份数据的方法、装置和***。
背景技术
现有技术提供了一种KV(key-value)存储模式,该KV存储模式非常适合存储不涉及过多数据关系的业务数据。这种KV存储模式拥有高并发的读写性能,高效率存储和访问,高可扩展性和高可用性等特点。现有的应用架构平台提供一种用于存储业务文件的业务服务器,该业务服务器可以使用KV存储技术来存储用户和业务文件的索引数据,从而提供高质量的海量服务。
基于上述KV(key-value)存储模式,随着应用架构平台的业务规模不断扩大,业务服务器可以以互联网数据中心IDC的形式来存储客户端用户所要访问的资源,通常情况下,会将所有资源集中存储在单个IDC中。随着用户对业务可用性的要求越来越高。原来将所有存储资源集中在单个IDC的架构有一定缺陷。比如:单个IDC网络出口发生硬件故障,单个IDC发生掉电等极端情况时,或者某个省份运营商的网络出口出现不可用,会导致整个业务中断较长时间。
针对上述问题,可以采用备份该单个IDC中的资源的方法来实现一种容灾方案。目前业界常用的容灾方案较为复杂,对原有架构和数据结构冲击较大。
由此可知,现有技术可以提供一种基于KV存储的容灾方案,这种容灾方案可以根据分布式***CAP原则来实现,这种容灾方案的基本原则是为当前的主服务器IDC提供至少三个从服务器IDC,即将KV形式的操作数据利用DHT算法分布到多个设备节点上,每一份操作数据都至少保存在三个节点上。从而使得在主服务器IDC上实现的写操作可以基于时间向量算法在三个副本上进行同步。
具体的,上述方案提供的整个容灾***基于NWR原则(W+R>N),该NWR原则的具体描述如下:
N表示主服务器IDC上产生的一个操作数据拥有的副本数量,即该主服务器IDC的从服务器IDC的数量;W表示***在写入或者更新主服务器IDC上产生的一个操作数据时,需要同步等待写入成功的副本数;R表示***在读取主服务器IDC上产生的一个操作数据时,需要读取的副本数。例如:在一个分布式***中,主服务器IDC上产生的每个操作数据有3个副本(N=3),如果写一个副本(W=1)成功就算成功的话,那么读操作时要读取该数据三个副本(R=3),才能通过比较得到最新的数据。该原则为了保持一致性在读或写性能上有所取舍,W或者R取值越大,则性能越低。
由此可知,基于上述NWR原则的分布式容灾***,在客户端请求主服务器的操作数据之后,操作数据需要在至少三个从服务器中备份成功,并主服务器在接收到所有从服务器返回的备份成功消息的情况下,才可以接收客户端的新的业务请求,即只有在操作数据在所有从服务器都同步成功之后,客户端才可以开始下一个业务请求。
针对上述现有技术的分布式***提供的容灾方案需要保持***的一致性,导致***性能差的问题,目前尚未提出有效的解决方案。
发明内容
本发明实施例提供了一种分布式备份数据的方法、装置和***,以至少解决现有技术的分布式***提供的容灾方案需要保持***的一致性,导致***性能差的技术问题。
根据本发明实施例的一个方面,提供了一种分布式备份数据的方法,该方法包括:主服务器接收调用客户端的操作请求,并基于操作请求生成操作数据;主服务器将操作数据保存至本地的主存储器,并生成同步指令;主服务器根据同步指令将操作数据同步至从服务器的从存储器中,其中,主服务器在将操作数据同步至从服务器之后,默认同步操作成功,无需等待从服务器返回同步成功的反馈信息。
根据本发明实施例的另一方面,还提供了一种分布式备份数据的装置,该装置包括:生成模块,用于主服务器接收调用客户端的操作请求,并基于操作请求生成操作数据;处理模块,用于主服务器将操作数据保存至本地的主存储器,并生成同步指令;同步处理模块,用于主服务器根据同步指令将操作数据同步至从服务器的从存储器中,其中,主服务器在将操作数据同步至从服务器之后,默认同步操作成功,无需等待从服务器返回同步成功的反馈信息。
根据本发明实施例的另一方面,还提供了一种分布式备份数据的***,该***包括:调用客户端,发送操作请求;从服务器;主服务器,分别与调用客户端和从服务器建立通信关系,用于接收调用客户端的操作请求,并基于操作请求生成操作数据,在将操作数据保存至本地的主存储器,并生成同步指令之后,根据同步指令将操作数据同步至从服务器的从存储器中;其中,主服务器在将操作数据同步至从服务器之后,默认同步操作成功,无需等待从服务器返回同步成功的反馈信息。
在本发明实施例中,采用主服务器接收调用客户端的操作请求,并基于操作请求生成操作数据;主服务器将操作数据保存至本地的主存储器,并生成同步指令;主服务器根据同步指令将操作数据同步至从服务器的从存储器中,其中,主服务器在将操作数据同步至从服务器之后,默认同步操作成功,无需等待从服务器返回同步成功的反馈信息的方式,通过为主服务器提供一个从服务器来实现主服务器上发生的操作数据都可以进行备份,实现整个***的容灾处理。在上述操作数据的同步过程中,由于仅执行一次同步操作,而且无需等待从服务器反馈同步成功的信息即可接收调用客户端的新操作任务,这种方式弱化了现有的容灾方案的一致性要求,进而解决了现有技术的分布式***提供的容灾方案需要保持***的一致性,导致***性能差的技术问题。
附图说明
此处所说明的附图用来提供对本发明的进一步理解,构成本申请的一部分,本发明的示意性实施例及其说明用于解释本发明,并不构成对本发明的不当限定。在附图中:
图1是根据本发明实施例一分布式备份数据的***的结构示意图;
图2是根据本发明实施例的分布式备份数据的***框架的流程示意图;
图3是根据本发明实施例一的一种可选的分布式备份数据的***的详细结构示意图;
图4是本发明实施例二的一种运行分布式备份数据方法的主服务器的硬件结构框图;
图5是根据本发明实施例二的分布式备份数据的方法流程图;
图6是根据本发明实施例二的一种分布式备份数据的方法的业务交互流程示意图;
图7是根据本发明实施例三的分布式备份数据的装置的结构示意图;
图8是根据本发明实施例三的一种可选的分布式备份数据的装置的结构示意图;
图9是根据本发明实施例三的一种可选的分布式备份数据的装置的结构示意图。
具体实施方式
为了使本技术领域的人员更好地理解本发明方案,下面将结合本发明实施例中的附图,对本发明实施例中的技术方案进行清楚、完整地描述,显然,所描述的实施例仅仅是本发明一部分的实施例,而不是全部的实施例。基于本发明中的实施例,本领域普通技术人员在没有做出创造性劳动前提下所获得的所有其他实施例,都应当属于本发明保护的范围。
需要说明的是,本发明的说明书和权利要求书及上述附图中的术语“第一”、“第二”等是用于区别类似的对象,而不必用于描述特定的顺序或先后次序。应该理解这样使用的数据在适当情况下可以互换,以便这里描述的本发明的实施例能够以除了在这里图示或描述的那些以外的顺序实施。此外,术语“包括”和“具有”以及他们的任何变形,意图在于覆盖不排他的包含,例如,包含了一系列步骤或单元的过程、方法、***、产品或设备不必限于清楚地列出的那些步骤或单元,而是可包括没有清楚地列出的或对于这些过程、方法、产品或设备固有的其它步骤或单元。
下面就本申请涉及到的部分名词解释如下:
KV存储:NoSQL存储的一种方式,数据按照键值对的形式进行组织,索引和存储。
IDC:InternetDataCenter互联网数据中心(简称机房)。
实施例1
在描述本申请的各实施例的进一步细节之前,将参考图1来描述可用于实现本申请的原理的一个合适的计算体系结构。在以下描述中,除非另外指明,否则将参考由一个或多个计算机执行的动作和操作的符号表示来描述本申请的各实施例。由此,可以理解,有时被称为计算机执行的这类动作和操作包括计算机的处理单元对以结构化形式表示数据的电信号的操纵。这一操纵转换了数据或在计算机的存储器***中的位置上维护它,这以本领域的技术人员都理解的方式重配置或改变了计算机的操作。维护数据的数据结构是具有数据的格式所定义的特定属性的存储器的物理位置。然而,尽管在上述上下文中描述本申请,但它并不意味着限制性的,如本领域的技术人员所理解的,后文所描述的动作和操作的各方面也可用硬件来实现。
在其最基本的配置中,图1是根据本发明实施例一分布式备份数据的***的结构示意图。出于描述的目的,所绘的体系结构仅为合适环境的一个示例,并非对本申请的使用范围或功能提出任何局限。也不应将该计算***解释为对图1所示的任一组件或其组合具有任何依赖或需求。
如图1所示,该***可以包括:调用客户端10、主服务器12和从服务器14。
其中,调用客户端10用于发送操作请求;主服务器12,分别与调用客户端10和从服务器14建立通信关系,用于接收调用客户端10的操作请求,并基于操作请求生成操作数据,在将操作数据保存至本地的主存储器,并生成同步指令之后,根据同步指令将操作数据同步至从服务器的从存储器中;其中,主服务器在将操作数据同步至从服务器之后,默认同步操作成功,无需等待从服务器返回同步成功的反馈信息。
本申请上述方案中的调用客户端10发出的操作请求可以包括如下任意一种或多种类型的操作:写操作、读操作、更新操作等,同时操作请求中携带了使用该调用客户端的用户的账户信息。
结合图2可知,主服务器12会通过接入层来接收调用客户端的操作请求(例如写操作请求),并在逻辑层实现基于操作请求类型生成对应的操作数据,例如,针对写操作,主服务器会对写操作来对当前账户信息对应的写操作写入新的业务数据。
结合图2可知,本申请上述方案中的主服务器12在获取到操作请求对应的操作数据之后,可以先通过存储层将操作数据保存至主存储器中,然后再触发同步层生成相应的同步指令,进而使用该同步指令来实现操作数据的同步功能。
优选地,上述方案在执行同步操作的过程中,可以使用同步通信接口来将操作数据同步至从服务器,区别于现有技术的是,本申请提供的同步方案中,***仅部署一台从服务器,而且主服务器无需等待从服务器反馈同步成功的消息,默认同步操作成功,使得前端的调用客户端无需等待同步成功就可以开始进行下一步的业务操作。
由此可知,本申请上述方法实施例提供的方案,通过为主服务器提供一个从服务器来实现主服务器上发生的操作数据都可以进行备份,实现整个***的容灾处理。在上述操作数据的同步过程中,由于仅执行一次同步操作,而且无需等待从服务器反馈同步成功的信息即可接收调用客户端的新操作任务,这种方式弱化了现有的容灾方案的一致性要求,进而解决了现有技术的分布式***提供的容灾方案需要保持***的一致性,导致***性能差的技术问题。从而提高了***同步操作数据的效率和性能。
此处需要说明的是,弱化一致性是指牺牲主服务器与从服务器同步数据过程中的部分一致性,即同步的操作数据的副本不是实时一致,而是在某个时间窗口内可能不一致,但是最终能达到一致。而且在同步过程中,对应KV的写操作,必须通过主服务器IDC来完成,再由主服务器IDC同步到从服务器IDC,主从服务器IDC都可以提供读操作,读到的内容是否为最新由进行读操作的客户端来进行判断。
此处需要还需要说明的是,本申请上述实施例中的主服务器和从服务器从物理地址上来划分,可以是异地同步的服务器,例如,主服务器可以是部署在北京的服务器,北京及周边范围内的客户端用户可以使用主服务器进行各种操作请求,从服务器可以是部署在上海的服务器,上海及周边范围内的客户端用户可以使用从服务器进行各种操作请求,但上海及周边的客户端用户的操作请求流转过程是需要先去访问主服务器,从主服务器获知从服务器的地址,进而再访问从服务器进行各项操作请求。
下面以前端的调用客户端为腾讯公司提供的即时聊天工具QQ为例,对本申请提供的一种基于弱化一致性的解决方案进行详细描述,该解决方案基于主从服务器的同步模式。
结合即时聊天工具QQ实现的离线传输文件的业务特性,由于通过QQ实现的离线传输文件的业务架构对一致性要求较低,因此,在QQ执行离线上传文件的过程中,如果登陆该调用客户端的用户启动离线上传文件的操作请求,此时主服务器在接收到QQ离线上传文件的操作请求之后,可以将当前操作请求的操作数据进行本地存储,并启动将操作数据同步至远端的从服务器,同步过程中,由于主服务器无需等待从服务器反馈同步成功的信息就默认同步成功,使得调用客户端无需等待主服务器和从服务器之间同步结束就可以开始进行下一个离线文件的传输,实现了将离线上传的文件通过采用牺牲一定的一致性,来提高离线传输文件的性能。
例如,当一个用户A给另外一个用户B发送了一个离线文件的时候,需要用户A的QQ客户端给用户B的QQ客户端发送一个QQ消息进行通知。在前台之间进行上述消息流转的过程有一定时间差,所以对于后台来说,完全可以利用这个时间差来完成同步。因此,本申请提供的上述容灾方案,不需要让前端客户端的登录用户等待后台的主从服务器之间的同步操作成功之后,再返回离线上传数据成功,对于前端客户端,用户只要上传一个文件之后就可以继续上传下一个文件,不需要等待第一个文件上传成功或者收到同步成功的信息之后在进行下一个文件的上传,而对于主从服务器,主服务器在将上传的文件保存至本地存储器之后,将上传的文件同步给从服务器,该过程中主服务器无需等待从服务器返回同步成功的信息就可以继续保存新上传的文件。
此处需要说明的是,本申请上述方案是一种基于KV存储的弱化一致性模型,通过解决异地KV同步,实现数据容灾的方法。结合图3可知,本方案的关键点在于在原有的***架构下,在逻辑层和存储层之间***一层同步层,从而就可以实现异地容灾,原有架构下的布局保持不变。从而在降低一致性要求的***中,可以实现W=1,R=1,N=2。
优选地,本申请上述实施例中的操作数据可以以key-value的格式进行存储,key表征发出操作请求的调用客户端的账户信息,value表征与key关联的目录和文件索引信息。
仍旧以前端的调用客户端为即时聊天工具QQ为例,在使用QQ执行离线上传文件的业务中,NoSql数据库存储的内容以key-value(KV存储)的格式进行存储,其中,key可以是当前QQ登录用户的QQ号,value是该登录用户的目录树,可以包括目录和文件索引信息。当用户上传一个文件,或者删除一个文件的时候,value值会发生变化。
此处需要说明的是。本申请建立KV存储模式的前提是:***内的每一对KV对应一个用户,value值为该用户的目录和所属文件索引信息。在同一时间内,用户只会执行一种写操作(上传、下载、删除文件等),所以对同一KV的操作是没有并发的。
基于上述KV存储模式,上述实施例可以实现在图2所示的同步层中,同步层是一个抽象的概念,按照实现的功能可以将同步层划分为多个功能模块,每个功能模块表征一个同步逻辑中的功能,同步层的实现逻辑如图3所示。
由于本发明是基于KV的同步,所以不关心原有的业务逻辑。只需要在原有架构上增加一个同步层便可实现跨IDC的分布容灾。
结合图3可知,上述主服务器10可以包括:
主存储器104,用于保存以key-value格式记录的操作数据。
处理器102,与主存储器104连接,用于在操作数据保存至主存储器104成功的情况下,如果检测到保存至主存储器104中的操作数据中的value值发生变化,则记录与发生变化的value值关联的key,并生成与发生变化的value值关联的key所对应的同步指令,其中,同步指令用于表征需要将主存储器中成功保存的操作数据进行同步处理。
具体的,如图3所示,主服务器(主IDC)的处理器102可以包括接入模块IdxSyncAccess、至少一个同步逻辑模块IdxSync和跨IDC通信模块SyncGateWay,其中,接入模块IdxSyncAccess提供了一个操作接口,该操作接口用于接收操作请求,该操作接口完全兼容原有***对KV存储器的操作接口;每个同步逻辑模块IdxSync用于实现的同步逻辑,每一对KV(key-value)都可以根据哈希hash规则,由同一个同步逻辑模块IdxSync来进行操作;跨IDC通信模块SyncGateWay可以是一个同步网关,可以用来屏蔽内外网容灾的细节。
本申请上述方案中的操作数据可以是主服务器在接入模块接收到的操作请求对应的操作数据。具体的,以操作请求为写(删)操作为例,结合图3可知,上述方案实现了同步层的接入模块提供了操作接口,该操作接口接收到调用者(即上述调用客户端的登录用户)的写(删)操作请求之后,得到该写(删)操作请求对应的写(删)操作数据,先将该操作数据以key-value格式保存至用于进行KV存储的主存储器中,然后返回操作结果给调用者。
仍旧以操作请求为写(删)操作为例,本申请上述方案还可以实现如果检测到主存储器中保存的写(删)操作数据成功,则该写(删)操作数据中的Value值会发生变化。优选地,可以将主存储器中Value值发生变化的key根据hash规则发送到任意一个IdxSync模块。IdxSync模块此时需要记录binlog来记录当前需要进行同步的操作数据的key,目的是为了防止因为主服务器死机或者网络故障,造成key信息的丢失。
此时在记录操作数据的key时,同时生成用于执行同步处理的同步指令,该同步指令可以实现从主存储器中的KV存储中读取该key的Value值,并将该Value写到从服务器IDC的从存储器中来完成KV存储,从而实现了主服务器和从服务器之间的同步操作。
此处需要说明的是,如果从主服务器IDC中读取key时,该key不存在,则删除从服务器IDC的从存储器中KV存储对应的key。
由此可知,上述方案可以在同步层实现将接收到的操作请求对应的操作数据在主服务器端进行本地存储,并在存储之后,启动同步逻辑模块检测发生更新的Value值,并将该发生更新的Value值及其对应的key同步至从服务器。
优选地,上述主服务器10的处理器102还用于将与发生变化的value值关联的key存储至主服务器中的同步模块,并将与发生变化的value值关联的key所对应的同步指令发送至同步模块,其中,同步模块使用同步指令访问主存储器,并从主存储器中读取需要进行同步处理的操作数据的key所对应的value值;处理器还用于通过同步通信模块将需要进行同步处理的操作数据的key及其对应的value值同步至从服务器。
结合图3可知,上述同步模块可以是图3中的同步逻辑模块IdxSync,由此,具体的,上述方案实现了,将Value值发生变化的key可以根据hash规则发送到任意一个IdxSync模块。同时,该IdxSync模块通过记录binlog来记录当前需要进行内外网同步的key。并在IdxSync模块收到同步指令之后,从主存储器中的KV存储中读取该key的Value值,并将该Value写到从服务器IDC的KV存储,完成操作数据的同步。
此处需要说明的是,在主服务器接收到调用客户端的至少两个操作请求之后,主服务器生成至少两个同步指令,且每个同步指令依次进入等待队列。
仍旧结合图3可知,上述可选方案实现了主服务器对接收到的多个操作请求进行排队处理。具体的,上述方案中,同步模块接收Value值发生变化的key和同步请求的步骤对于整个***来说都是异步的,用户感知不到,但是对于IdxSync这个模块来说是同步的。比如IdxSync模块正在同步一个key的时候,模块会有一个状态机在等待回复。如果此时这个key又接收到一个同步指令时(例如,key对应的用户上传了一个新的文件),新接收到的同步指令就会等待,即如果此时这个key过来多个同步请求时就会排队等候,***会按照等待队列中存储的同步指令的顺序依次完成每个同步指令所要同步的value。
优选地,由于同步模块IdxSync在同步一个key的状态时,可能会收到多次该key的同步请求,由于对于一个key,多次同步的结果可以是同步该key最后一次的状态,因此,这些同步请求对应的同步指令可以在下次同步时合并成一个同步请求。
在本申请提供的一种可选实施例中,上述实施例中的调用客户端10还可以用于发送业务请求至从服务器;上述从服务器12还可以用于将业务请求转发至主服务器,获取与业务请求对应的操作数据,并将与业务请求对应的操作数据返回给调用客户端。
本申请上述方案实现了,在用户通过访问从服务器读取操作数据时,仍旧需要先访问主服务器,再回到与主服务器关联的从服务器中来获取朝族数据。
具体的,在主服务器和从服务器是异地同步的服务器的情况下,仍旧以主服务器可以是部署在北京的服务器,从服务器可以是部署在上海的服务器为例,处于上海及周边范围内的客户端用户可以使用从服务器进行各种操作请求,但上海及周边的客户端用户的操作请求流转过程是需要先去访问主服务器,从主服务器获知从服务器的地址,进而再访问从服务器进行各项操作请求。
此处需要说明的是,本申请上述方法实施例还可以提供如下可选的方案:在主服务器中止工作的情况下,变更服务器配置信息,将主服务器变更为从服务器的工作状态,将从服务器变更为主服务器的工作状态;在从服务器中止工作的情况下,将访问从服务器的调用客户端所发出的业务请求切换至主服务器。
本申请为主服务器提供一个备份的从服务器的目的在于,当主服务器出现了很极端的灾难,比如失火或者机房主光纤被挖断等无法正常工作的状态,则所有客户端的操作请求就会被切换到从服务器IDC进行工作。
下面就以两种主服务器无法工作的应用场景对本申请的提供的功能进行详细说明:
情况一:主服务器IDC不可服务。此时,主服务器IDC会采取如下对应措施:
第一步:接入层停掉向主服务器IDC提供的写请求,将等待队列中剩余部分的KV操作数据同步完毕,如果内外网完全不可用时需要对等待队列中的操作数据进行评估,丢掉部分操作数据。
第二步:变更配置,将从服务器IDC变更为主服务器IDC,并将主服务器IDC变更为从服务器IDC。
第三步:将所有业务请求切向原来的从服务器IDC,即更新后的主服务器IDC。
情况二:从服务器IDC不可服务。此时,从服务器IDC会采取如下对应措施:将业务请求切换至主服务器IDC。
此时需要注意,主服务器IDC的IdxSync模块会积累大量未同步成功的key。但是由于只需要记录key,因此,所有对临时存储(binlog)的存储消耗较小,可以忽略不计。
实施例2
根据本发明实施例,还提供了一种分布式备份数据的方法实施例,需要说明的是,在附图的流程图示出的步骤可以在诸如一组计算机可执行指令的计算机***中执行,并且,虽然在流程图中示出了逻辑顺序,但是在某些情况下,可以以不同于此处的顺序执行所示出或描述的步骤。
本申请实施例一所提供的方法实施例可以在移动终端、计算机终端或者类似的运算装置中执行。以运行在计算机终端上为例,图4是本发明实施例二的一种运行分布式备份数据方法的主服务器的硬件结构框图,该主服务器可以是用于接收前端的调用客户端的操作请求的主服务器。如图1所示,主服务器10可以包括一个或多个(图中仅示出一个)处理器102(处理器102可以包括但不限于微处理器MCU或可编程逻辑器件FPGA等的处理装置)、用于存储数据的主存储器104、以及用于通信功能的传输模块106。本领域普通技术人员可以理解,图4所示的结构仅为示意,其并不对上述电子装置的结构造成限定。例如,主服务器10还可包括比图4中所示更多或者更少的组件,或者具有与图4所示不同的配置。
主存储器104可用于存储应用软件的软件程序以及模块,如本发明实施例中的分布式备份数据的方法对应的程序指令/模块,处理器102通过运行存储在主存储器104内的软件程序以及模块,从而执行各种功能应用以及数据处理,即实现上述的分布式备份数据的方法。主存储器104可包括高速随机存储器,还可包括非易失性存储器,如一个或者多个磁性存储装置、闪存、或者其他非易失性固态存储器。在一些实例中,主存储器104可进一步包括相对于处理器102远程设置的存储器,这些远程存储器可以通过网络连接至主服务器10。上述网络的实例包括但不限于互联网、企业内部网、局域网、移动通信网及其组合。
传输装置106用于经由一个网络接收或者发送数据。上述的网络具体实例可包括主服务器10的通信供应商提供的无线网络。在一个实例中,传输装置106包括一个网络适配器(NetworkInterfaceController,NIC),其可通过基站与其他网络设备相连从而可与互联网进行通讯。在一个实例中,传输装置106可以为射频(RadioFrequency,RF)模块,其用于通过无线方式与互联网进行通讯。
上述在上述运行环境下,本申请提供了如图5所示的分布式备份数据的方法。图5是根据本发明实施例二的分布式备份数据的方法流程图。
如图5所示,该分布式备份数据的方法可以包括如下步骤:
步骤S20,主服务器接收调用客户端的操作请求,并基于操作请求生成操作数据。
本申请上述步骤S20中的调用客户端发出的操作请求可以包括如下任意一种或多种类型的操作:写操作、读操作、更新操作等,同时操作请求中携带了使用该调用客户端的用户的账户信息。
结合图2可知,主服务器会通过接入层来接收调用客户端的操作请求,并在逻辑层实现基于操作请求类型生成对应的操作数据,例如,针对写操作,主会对写操作来对当前账户信息对应的写操作写入新的业务数据。
步骤S22,主服务器将操作数据保存至本地的主存储器,并生成同步指令。
结合图2可知,本申请上述步骤S22中的主服务器在获取到操作请求对应的操作数据之后,先通过存储层将操作数据保存至主存储器中,然后再触发同步层生成相应的同步指令,进而使用该同步指令来实现操作数据的同步功能。
步骤S24,主服务器根据同步指令将操作数据同步至从服务器的从存储器中,其中,主服务器在将操作数据同步至从服务器之后,默认同步操作成功,无需等待上述从服务器返回同步成功的反馈信息。
本申请上述步骤S24在执行同步操作的过程中,可以使用图1中的同步通信接口来将操作数据同步至从服务器,区别于现有技术的是,本申请提供的同步方案中,***仅部署一台从服务器,而且主服务器无需等待从服务器反馈同步成功的消息,默认同步操作成功,使得前端的调用客户端无需等待同步成功就可以开始进行下一步的业务操作。
由此可知,本申请上述方法实施例提供的方案,通过为主服务器提供一个从服务器来实现主服务器上发生的操作数据都可以进行备份,实现整个***的容灾处理。在上述操作数据的同步过程中,由于仅执行一次同步操作,而且无需等待从服务器反馈同步成功的信息即可接收调用客户端的新操作任务,这种方式弱化了现有的容灾方案的一致性要求,进而解决了现有技术的分布式***提供的容灾方案需要保持***的一致性,导致***性能差的技术问题。
此处需要说明的是,弱化一致性是指牺牲主服务器与从服务器同步数据过程中的部分一致性,即同步的操作数据的副本不是实时一致,而是在某个时间窗口内可能不一致,但是最终能达到一致。而且在同步过程中,对应KV的写操作,必须通过主服务器IDC来完成,再由主服务器IDC同步到从服务器IDC,主从服务器IDC都可以提供读操作,读到的内容是否为最新由进行读操作的客户端来进行判断。
此处需要还需要说明的是,本申请上述实施例中的主服务器和从服务器从物理地址上来划分,可以是异地同步的服务器,例如,主服务器可以是部署在北京的服务器,北京及周边范围内的客户端用户可以使用主服务器进行各种操作请求,从服务器可以是部署在上海的服务器,上海及周边范围内的客户端用户可以使用从服务器进行各种操作请求,但上海及周边的客户端用户的操作请求流转过程是需要先去访问主服务器,从主服务器获知从服务器的地址,进而再访问从服务器进行各项操作请求。
下面以前端的调用客户端为腾讯公司提供的即时聊天工具QQ为例,对本申请提供的一种基于弱化一致性的解决方案进行详细描述,该解决方案基于主从服务器的同步模式。
结合即时聊天工具QQ实现的离线传输文件的业务特性,由于通过QQ实现的离线传输文件的业务架构对一致性要求较低,因此,在QQ执行离线上传文件的过程中,如果登陆该调用客户端的用户启动离线上传文件的操作请求,此时主服务器在接收到QQ离线上传文件的操作请求之后,可以将当前操作请求的操作数据进行本地存储,并启动将操作数据同步至远端的从服务器,同步过程中,由于主服务器无需等待从服务器反馈同步成功的信息就默认同步成功,使得调用客户端无需等待主服务器和从服务器之间同步结束就可以开始进行下一个离线文件的传输,实现了将离线上传的文件通过采用牺牲一定的一致性,来提高离线传输文件的性能。
例如,当一个用户A给另外一个用户B发送了一个离线文件的时候,需要用户A的QQ客户端给用户B的QQ客户端发送一个QQ消息进行通知。在前台之间进行上述消息流转的过程有一定时间差,所以对于后台来说,完全可以利用这个时间差来完成同步。因此,本申请提供的上述容灾方案,不需要让前端客户端的登录用户等待后台的主从服务器之间的同步操作成功之后,再返回离线上传数据成功,对于前端客户端,用户只要上传一个文件之后就可以继续上传下一个文件,不需要等待第一个文件上传成功或者收到同步成功的信息之后在进行下一个文件的上传,而对于主从服务器,主服务器在将上传的文件保存至本地存储器之后,将上传的文件同步给从服务器,该过程中主服务器无需等待从服务器返回同步成功的信息就可以继续保存新上传的文件。
此处需要说明的是,本申请上述方案是一种基于KV存储的弱化一致性模型,通过解决异地KV同步,实现数据容灾的方法。结合图3可知,本方案的关键点在于在原有的***架构下,在逻辑层和存储层之间***一层同步层,从而就可以实现异地容灾,原有架构下的布局保持不变。从而在降低一致性要求的***中,可以实现W=1,R=1,N=2。
优选地,本申请提供的一种可选实施例中,操作数据可以以key-value(KV存储)的格式进行存储,key表征发出操作请求的调用客户端的账户信息,value表征与key关联的目录和文件索引信息。
仍旧以前端的调用客户端为即时聊天工具QQ为例,在使用QQ执行离线上传文件的业务中,NoSql数据库存储的内容以key-value(KV存储)的格式进行存储,其中,key可以是当前QQ登录用户的QQ号,value是该登录用户的目录树,可以包括目录和文件索引信息。当用户上传一个文件,或者删除一个文件的时候,value值会发生变化。
此处需要说明的是。本申请建立KV存储模式的前提是:***内的每一对KV对应一个用户,value值为该用户的目录和所属文件索引信息。在同一时间内,用户只会执行一种写操作(上传、下载、删除文件等),所以对同一KV的操作是没有并发的。
基于上述KV存储模式,上述实施例中的步骤S22可以实现在图2所示的同步层中,同步层是一个抽象的概念,按照实现的功能可以将同步层划分为多个功能模块,每个功能模块表征一个同步逻辑中的功能,同步层的实现逻辑如图3所示。
如图3所示,主服务器(主IDC)可以包括接入模块IdxSyncAccess、至少一个同步逻辑模块IdxSync和跨IDC通信模块SyncGateWay,其中,接入模块IdxSyncAccess提供了一个操作接口,该操作接口用于接收操作请求,该操作接口完全兼容原有***对KV存储器的操作接口;每个同步逻辑模块IdxSync用于实现的同步逻辑,每一对KV(key-value)都可以根据哈希hash规则,由同一个同步逻辑模块IdxSync来进行操作;跨IDC通信模块SyncGateWay可以是一个同步网关,可以用来屏蔽内外网容灾的细节。
由于本发明是基于KV的同步,所以不关心原有的业务逻辑。只需要在原有架构上增加一个同步层便可实现跨IDC的分布容灾。
由此可知,该步骤S22执行的主服务器将操作数据保存至本地的主存储器,并生成同步指令的方案可以通过如下步骤实现:
步骤S221,将以key-value格式记录的操作数据保存至主服务器本地的主存储器中。
本申请上述步骤S221中的操作数据可以是主服务器在接入模块接收到的操作请求对应的操作数据。具体的,以操作请求为写(删)操作为例,结合图3可知,上述方案实现了同步层的接入模块提供了操作接口,该操作接口接收到调用者(即上述调用客户端的登录用户)的写(删)操作请求之后,得到该写(删)操作请求对应的写(删)操作数据,先将该操作数据以key-value格式保存至用于进行KV存储的主存储器中,然后返回操作结果给调用者。
步骤S223,在操作数据保存至主存储器成功的情况下,检测到保存至主存储器中的操作数据中的value值发生变化。
仍旧以操作请求为写(删)操作为例,本申请上述步骤S223实现了如果检测到主存储器中保存的写(删)操作数据成功,则该写(删)操作数据中的Value值会发生变化。
步骤S225,如果操作数据中的value值发生变化,则记录与发生变化的value值关联的key,并生成与发生变化的value值关联的key所对应的同步指令,同步指令用于表征需要将主存储器中成功保存的操作数据进行同步处理。
优选地,在上述步骤S225的执行过程中,可以将主存储器中Value值发生变化的key根据hash规则发送到任意一个IdxSync模块。IdxSync模块此时需要记录binlog来记录当前需要进行同步的操作数据的key,目的是为了防止因为主服务器死机或者网络故障,造成key信息的丢失。
此时在记录操作数据的key时,同时生成用于执行同步处理的同步指令,该同步指令可以实现从主存储器中的KV存储中读取该key的Value值,并将该Value写到从服务器IDC的从存储器中来完成KV存储,从而实现了主服务器和从服务器之间的同步操作。
此处需要说明的是,如果从主服务器IDC中读取key时,该key不存在,则删除从服务器IDC的从存储器中KV存储对应的key。
由此可知,上述步骤S221至步骤S225提供的方案,可以在同步层实现将接收到的操作请求对应的操作数据在主服务器端进行本地存储,并在存储之后,启动同步逻辑模块检测发生更新的Value值,并将该发生更新的Value值及其对应的key同步至从服务器。
优选地,本申请上述步骤S24实现的主服务器根据同步指令将操作数据同步至从服务器的从存储器中的方案可以包括如下步骤:
步骤S241,将与发生变化的value值关联的key存储至主服务器中的同步模块,并将与发生变化的value值关联的key所对应的同步指令发送至同步模块。
结合图3可知,上述同步模块可以是图3中的同步逻辑模块IdxSync,由此,具体的,上述步骤S241实现了,将Value值发生变化的key可以根据hash规则发送到任意一个IdxSync模块。同时,该IdxSync模块通过记录binlog来记录当前需要进行内外网同步的key。
步骤S243,同步模块使用同步指令访问主存储器,并从主存储器中读取需要进行同步处理的操作数据的key所对应的value值。
步骤S245,通过主服务器中的同步通信模块将需要进行同步处理的操作数据的key及其对应的value值同步至从服务器。
结合图3可知,上述步骤S243和步骤S245可以实现,在IdxSync模块收到同步指令之后,从主存储器中的KV存储中读取该key的Value值,并将该Value写到从服务器IDC的KV存储,完成操作数据的同步。
优选地,在本申请提供的一种优选实施例总,在主服务器接收到调用客户端的至少两个操作请求之后,主服务器可以生成至少两个同步指令,且每个同步指令依次进入等待队列。
仍旧结合图3可知,上述优选方案实现了主服务器对接收到的多个操作请求进行排队处理。具体的,上述方案中,同步模块接收Value值发生变化的key和同步请求的步骤对于整个***来说都是异步的,用户感知不到,但是对于IdxSync这个模块来说是同步的。比如IdxSync模块正在同步一个key的时候,模块会有一个状态机在等待回复。如果此时这个key又接收到一个同步指令时(例如,key对应的用户上传了一个新的文件),新接收到的同步指令就会等待,即如果此时这个key过来多个同步请求时就会排队等候,***会按照等待队列中存储的同步指令的顺序依次完成每个同步指令所要同步的value。
优选地,由于同步模块IdxSync在同步一个key的状态时,可能会收到多次该key的同步请求,由于对于一个key,多次同步的结果可以是同步该key最后一次的状态,因此,这些同步请求对应的同步指令可以在下次同步时合并成一个同步请求。
在本申请提供的一种可选实施例中,在步骤S24实现主服务器根据同步指令将操作数据同步至从服务器的从存储器之后,还可以执行如下步骤:
步骤S261,调用客户端发送业务请求至从服务器。
步骤S263,从服务器将业务请求转发至主服务器,获取与业务请求对应的操作数据。
步骤S265,从服务器将与业务请求对应的操作数据返回给调用客户端。
本申请上述步骤S261至步骤S265实现了,在用户通过访问从服务器读取操作数据时,仍旧需要先访问主服务器,再回到与主服务器关联的从服务器中来获取朝族数据。
在主服务器和从服务器是异地同步的服务器的情况下,仍旧以主服务器可以是部署在北京的服务器,从服务器可以是部署在上海的服务器为例,处于上海及周边范围内的客户端用户可以使用从服务器进行各种操作请求,但上海及周边的客户端用户的操作请求流转过程是需要先去访问主服务器,从主服务器获知从服务器的地址,进而再访问从服务器进行各项操作请求。
此处需要说明的是,本申请上述方法实施例还可以提供如下可选的方案:在主服务器中止工作的情况下,变更服务器配置信息,将主服务器变更为从服务器的工作状态,将从服务器变更为主服务器的工作状态;在从服务器中止工作的情况下,将访问从服务器的调用客户端所发出的业务请求切换至主服务器。
本申请为主服务器提供一个备份的从服务器的目的在于,当主服务器出现了很极端的灾难,比如失火或者机房主光纤被挖断等无法正常工作的状态,则所有客户端的操作请求就会被切换到从服务器IDC进行工作。
下面就以两种主服务器无法工作的应用场景对本申请的提供的功能进行详细说明:
情况一:主服务器IDC不可服务。此时,主服务器IDC会采取如下对应措施:
第一步:接入层停掉向主服务器IDC提供的写请求,将等待队列中剩余部分的KV操作数据同步完毕,如果内外网完全不可用时需要对等待队列中的操作数据进行评估,丢掉部分操作数据。
第二步:变更配置,将从服务器IDC变更为主服务器IDC,并将主服务器IDC变更为从服务器IDC。
第三步:将所有业务请求切向原来的从服务器IDC,即更新后的主服务器IDC。
情况二:从服务器IDC不可服务。此时,从服务器IDC会采取如下对应措施:将业务请求切换至主服务器IDC。
此时需要注意,主服务器IDC的IdxSync模块会积累大量未同步成功的key。但是由于只需要记录key,因此,所有对临时存储(binlog)的存储消耗较小,可以忽略不计。
综上可知,本申请提供了一种对弱化同步***一致性的情况下,提高用户操作效率的方案,其中,调用客户端可以是QQ客户端。下面就结合图1至图6,对本申请在QQ客户端进行离线上传文件的操作为例进行示例说明:
步骤A,用户登录QQ客户端之后,启动离线上传文件,发送离线上传文件的离线上传请求。
步骤B,主服务器的接收模块接收到该离线上传请求之后,获取到该离线上传请求对应的上传文件的数据,该上传数据以key-Value的模式保存至本地的主存储器,上传成功的情况下,Value值会发生变化。其中,key为登录该QQ客户端的账户信息,value是该登录用户的目录和离线文件的索引信息。
步骤C,主服务器检测到value值发生变化的情况下,将Value值发生变化的key根据hash规则发送到一台同步模块IdxSync。IdxSync模块此时需要记录binlog来记录当前同步的key。
步骤D,此时,主服务器根据同步请求将主存储器中发生变化的value值对应的key同步至从服务器,即同步模块同时收到同步请求时,则从主存储器中读取该key的value值,并将该key-Value通过同步通信接口同步至从服务器。
步骤E,从服务器将接收到的操作数据保存在本地的从存储器中。
步骤F,从服务器向主服务器反馈同步成功的反馈信息。
此处需要说明的是,上述步骤的实现过程中,主服务器不需要等待从服务器成功返回同步成功的反馈信息,就可以向QQ客户端返回响应信息,使得QQ客户端的登录用户可以不考虑后台同步工作是否成功完成的情况下,执行下一步离线上传操作,如果主服务器同时接收到多个操作指令,则对操作指令进行排队处理,或者合并为一个操作指令进行同步请求,这种方案提高了用户端的操作效率,适用于一致性要求不高的应用。
需要说明的是,对于前述的各方法实施例,为了简单描述,故将其都表述为一系列的动作组合,但是本领域技术人员应该知悉,本发明并不受所描述的动作顺序的限制,因为依据本发明,某些步骤可以采用其他顺序或者同时进行。其次,本领域技术人员也应该知悉,说明书中所描述的实施例均属于优选实施例,所涉及的动作和模块并不一定是本发明所必须的。
通过以上的实施方式的描述,本领域的技术人员可以清楚地了解到根据上述实施例的方法可借助软件加必需的通用硬件平台的方式来实现,当然也可以通过硬件,但很多情况下前者是更佳的实施方式。基于这样的理解,本发明的技术方案本质上或者说对现有技术做出贡献的部分可以以软件产品的形式体现出来,该计算机软件产品存储在一个存储介质(如ROM/RAM、磁碟、光盘)中,包括若干指令用以使得一台终端设备(可以是手机,计算机,服务器,或者网络设备等)执行本发明各个实施例所述的方法。
实施例3
根据本发明实施例,还提供了一种用于实施上述方法实施例的装置实施例。图7是根据本发明实施例三的分布式备份数据的装置的结构示意图。
如图7所示,该分布式备份数据的装置可以包括:生成模块70、处理模块72、同步处理模块74。
其中,生成模块70,用于主服务器接收调用客户端的操作请求,并基于操作请求生成操作数据;处理模块72,用于主服务器将操作数据保存至本地的主存储器,并生成同步指令;同步处理模块74,用于主服务器根据同步指令将操作数据同步至从服务器的从存储器中,其中,主服务器在将操作数据同步至从服务器之后,默认同步操作成功,无需等待从服务器返回同步成功的反馈信息。
由此可知,本申请上述方法实施例提供的方案,通过为主服务器提供一个从服务器来实现主服务器上发生的操作数据都可以进行备份,实现整个***的容灾处理。在上述操作数据的同步过程中,由于仅执行一次同步操作,而且无需等待从服务器反馈同步成功的信息即可接收调用客户端的新操作任务,这种方式弱化了现有的容灾方案的一致性要求,进而解决了现有技术的分布式***提供的容灾方案需要保持***的一致性,导致***性能差的技术问题。
此处需要说明的是,上述生成模块70、处理模块72、同步处理模块74对应于实施例二中的步骤S20至步骤S24,三个模块与对应的步骤所实现的示例和应用场景相同,但不限于上述实施例二所公开的内容。需要说明的是,上述模块作为装置的一部分可以运行在实施例一提供的主服务器10中。
优选地,如图8所示,在本申请提供一种优选方案中,操作数据以key-value的格式进行存储,key表征发出操作请求的调用客户端的账户信息,value表征与key关联的目录和文件索引信息,其中,上述处理模块72可以包括:保存模块721、检测模块723和子处理模块725。
其中,保存模块721,用于将以key-value格式记录的操作数据保存至主服务器本地的主存储器中;检测模块723,用于在操作数据保存至主存储器成功的情况下,检测到保存至主存储器中的操作数据中的value值发生变化;子处理模块725,用于如果操作数据中的value值发生变化,则记录与发生变化的value值关联的key,并生成与发生变化的value值关联的key所对应的同步指令,其中,同步指令用于表征需要将主存储器中成功保存的操作数据进行同步处理。
此处需要说明的是,上述保存模块721、检测模块723和子处理模块725对应于实施例二中的步骤S221至步骤S225,三个模块与对应的步骤所实现的示例和应用场景相同,但不限于上述实施例二所公开的内容。需要说明的是,上述模块作为装置的一部分可以运行在实施例一提供的主服务器10中。
优选地,如图9所示,上述实施例中的同步处理模块74可以包括:存储模块741、发送模块743、同步模块745和同步通信模块747。
其中,存储模块741,用于将与发生变化的value值关联的key存储至主服务器中的同步模块;发送模块743,用于将与发生变化的value值关联的key所对应的同步指令发送至同步模块;同步模块745,用于使用同步指令访问主存储器,并从主存储器中读取需要进行同步处理的操作数据的key所对应的value值;同步通信模块747,用于将需要进行同步处理的操作数据的key及其对应的value值同步至从服务器。
此处需要说明的是,上述存储模块741、发送模块743、同步模块745和同步通信模块747对应于实施例二中的步骤S241至步骤S245,四个模块与对应的步骤所实现的示例和应用场景相同,但不限于上述实施例二所公开的内容。需要说明的是,上述模块作为装置的一部分可以运行在实施例一提供的主服务器10中。
此处需要说明的是,在主服务器接收到调用客户端的至少两个操作请求之后,主服务器生成至少两个同步指令,且每个同步指令依次进入等待队列。
在本申请提供的一种可选方案中,在执行完成主服务器根据同步指令将操作数据同步至从服务器的从存储器之后,还可以执行如下功能:调用客户端发送业务请求至从服务器;从服务器将业务请求转发至主服务器,获取与业务请求对应的操作数据;从服务器将与业务请求对应的操作数据返回给调用客户端。
优选的,本申请提供的装置方案中,在主服务器中止工作的情况下,变更服务器配置信息,将主服务器变更为从服务器的工作状态,将从服务器变更为主服务器的工作状态;在从服务器中止工作的情况下,将访问从服务器的调用客户端所发出的业务请求切换至主服务器。
由此可知,本申请提供的方案,主服务器不需要等待从服务器成功返回同步成功的反馈信息,就可以向调用客户端返回响应信息,使得调用客户端的登录用户可以不考虑后台同步工作是否成功完成的情况下,执行下一步离线上传操作,如果主服务器同时接收到多个操作指令,则对操作指令进行排队处理,或者合并为一个操作指令进行同步请求,这种方案提高了用户端的操作效率,适用于一致性要求不高的应用。
实施例4
本发明的实施例还提供了一种存储介质。可选地,在本实施例中,上述存储介质可以用于保存上述实施例二所提供的应用程序的分布式备份数据的方法所执行的程序代码。
可选地,在本实施例中,上述存储介质可以位于计算机网络中计算机终端群中的任意一个主服务器中。
可选地,在本实施例中,存储介质被设置为存储用于执行以下步骤的程序代码:主服务器接收调用客户端的操作请求,并基于操作请求生成操作数据;主服务器将操作数据保存至本地的主存储器,并生成同步指令;主服务器根据同步指令将操作数据同步至从服务器的从存储器中,其中,主服务器在将操作数据同步至从服务器之后,默认同步操作成功,无需等待从服务器返回同步成功的反馈信息。
可选地,存储介质还被设置为存储用于执行以下步骤的程序代码:将以key-value格式记录的操作数据保存至主服务器本地的主存储器中;在操作数据保存至主存储器成功的情况下,检测到保存至主存储器中的操作数据中的value值发生变化;如果操作数据中的value值发生变化,则记录与发生变化的value值关联的key,并生成与发生变化的value值关联的key所对应的同步指令,同步指令用于表征需要将主存储器中成功保存的操作数据进行同步处理。
可选的,存储介质还被设置为存储用于执行以下步骤的程序代码:将与发生变化的value值关联的key存储至主服务器中的同步模块,并将与发生变化的value值关联的key所对应的同步指令发送至同步模块;同步模块使用同步指令访问主存储器,并从主存储器中读取需要进行同步处理的操作数据的key所对应的value值;通过主服务器中的同步通信模块将需要进行同步处理的操作数据的key及其对应的value值同步至从服务器。
可选的,存储介质还被设置为存储用于执行以下步骤的程序代码:在主服务器接收到调用客户端的至少两个操作请求之后,主服务器生成至少两个同步指令,且每个同步指令依次进入等待队列。
可选的,存储介质还被设置为存储用于执行以下步骤的程序代码:调用客户端发送业务请求至从服务器;从服务器将业务请求转发至主服务器,获取与业务请求对应的操作数据;从服务器将与业务请求对应的操作数据返回给调用客户端。
可选的,存储介质还被设置为存储用于执行以下步骤的程序代码:在主服务器中止工作的情况下,变更服务器配置信息,将主服务器变更为从服务器的工作状态,将从服务器变更为主服务器的工作状态;在从服务器中止工作的情况下,将访问从服务器的调用客户端所发出的业务请求切换至主服务器。
可选地,在本实施例中,上述存储介质可以包括但不限于:U盘、只读存储器(ROM,Read-OnlyMemory)、随机存取存储器(RAM,RandomAccessMemory)、移动硬盘、磁碟或者光盘等各种可以存储程序代码的介质。
可选地,本实施例中的具体示例可以参考上述实施例1和实施例2中所描述的示例,本实施例在此不再赘述。
上述本发明实施例序号仅仅为了描述,不代表实施例的优劣。
上述实施例中的集成的单元如果以软件功能单元的形式实现并作为独立的产品销售或使用时,可以存储在上述计算机可读取的存储介质中。基于这样的理解,本发明的技术方案本质上或者说对现有技术做出贡献的部分或者该技术方案的全部或部分可以以软件产品的形式体现出来,该计算机软件产品存储在存储介质中,包括若干指令用以使得一台或多台计算机设备(可为个人计算机、服务器或者网络设备等)执行本发明各个实施例所述方法的全部或部分步骤。
在本发明的上述实施例中,对各个实施例的描述都各有侧重,某个实施例中没有详述的部分,可以参见其他实施例的相关描述。
在本申请所提供的几个实施例中,应该理解到,所揭露的客户端,可通过其它的方式实现。其中,以上所描述的装置实施例仅仅是示意性的,例如所述单元的划分,仅仅为一种逻辑功能划分,实际实现时可以有另外的划分方式,例如多个单元或组件可以结合或者可以集成到另一个***,或一些特征可以忽略,或不执行。另一点,所显示或讨论的相互之间的耦合或直接耦合或通信连接可以是通过一些接口,单元或模块的间接耦合或通信连接,可以是电性或其它的形式。
所述作为分离部件说明的单元可以是或者也可以不是物理上分开的,作为单元显示的部件可以是或者也可以不是物理单元,即可以位于一个地方,或者也可以分布到多个网络单元上。可以根据实际的需要选择其中的部分或者全部单元来实现本实施例方案的目的。
另外,在本发明各个实施例中的各功能单元可以集成在一个处理单元中,也可以是各个单元单独物理存在,也可以两个或两个以上单元集成在一个单元中。上述集成的单元既可以采用硬件的形式实现,也可以采用软件功能单元的形式实现。
以上所述仅是本发明的优选实施方式,应当指出,对于本技术领域的普通技术人员来说,在不脱离本发明原理的前提下,还可以做出若干改进和润饰,这些改进和润饰也应视为本发明的保护范围。