一种数据备份方法及装置与流程

本申请涉及数据库技术领域，尤其涉及一种数据备份方法及装置。

背景技术：

在大数据时代，出于灾备的目的，数据拥有方一般都会建设两个以上的数据中心。每个数据中心分别配置有应用系统及数据库，并且形成备份关系，当其中一个数据中心出现故障时，其他数据中心可以迅速接管业务。

数据中心之间进行数据备份时，由于数据库本身并不理解数据的业务含义，因此在数据备份时需要采用数据库的原生数据复制方案，无法实现实时备份，难以满足数据备份的时效性需求。针对该问题，目前一种常见的解决方案是应用层数据强同步，参见图1所示：在应用层面，本地业务系统完成业务处理逻辑后，需要先向异地的fo(failover，故障切换)库同步本次处理的数据变动情况，同步完成后才会向业务请求方返回业务成功消息；另外在数据库层面，本地数据库采用异步方式向异地数据库复制数据。上述方案中，由于业务系统可以针对性地选择业务数据，因此能够相对快速地完成数据同步，使得异地的fo库中的数据时效性远高于底层数据库。进而，当本地数据中心发生故障后，异地数据中心通过合并备库和故障切换库的数据，就可以实现数据恢复。

但是，上述方案的存在一个问题在于：由于本地业务系统需要等待同步完成后才会向业务请求方返回业务成功消息，因此，对于业务请求方而言，办理一次业务需要等待的时间＝业务系统实际处理耗时+数据异地同步耗时。这种情况下，如果两个数据中心部署距离较远，那么数据异地同步的耗时将会对用户体验产生较为明显的影响。

技术实现要素：

针对上述技术问题，本申请提供一种数据备份方法及装置，技术方案如下：

根据本申请的第一方面，提供一种数据备份方法，该方法包括：

数据备份源侧接收业务请求方发送的业务处理请求后，判断当前业务的业务类型，所述业务类型包括：流入类业务和流出类业务；

在当前业务为流出类业务的情况下，以并行方式执行第一操作及第二操作：

第一操作：在本地执行所述当前业务的处理逻辑；

第二操作：将所述当前业务对应的额度变化量数据同步到数据备份目标侧的故障切换库；

第一操作和第二操作均执行完成后，向业务请求方发送业务处理响应。

根据本申请的第二方面，提供一种容灾切换业务处理方法，该方法包括：

在容灾切换状态下，数据备份目标侧接收到业务处理请求后，判断当前业务所对应的额度变化量是否小于安全可用余额的相反数，如果是则停止处理该业务，否则正常处理该业务；

其中，数据备份目标侧根据本地的备库数据及故障切换库数据确定安全可用余额，对于任意账户，其安全可用余额＝备库记录的该账户最新可用余额+故障切换库记录的该账户额度变化量。

根据本申请的第三方面，提供一种数据备份装置，应用于数据备份源侧，该装置包括：

业务类型判断模块，用于接收业务请求方发送的业务处理请求后，判断当前业务的业务类型，所述业务类型包括：流入类业务和流出类业务；

控制模块，用于在当前业务为流出类业务的情况下，控制业务处理模块及数据同步模块以并行方式执行各自功能；

所述业务处理模块用于：在本地执行所述当前业务的处理逻辑；

所述数据同步模块用于：将所述当前业务对应的额度变化量数据同步到数据备份目标侧的故障切换库；

业务处理响应模块，用于在控制业务处理模块及数据同步模块的操作均执行完成后，向业务请求方发送业务处理响应。

根据本申请的第四方面，提供一种容灾切换业务处理装置，应用于数据备份目标侧，该装置包括业务处理模块及安全可用余额确定模块；

所述业务处理模块，用于在容灾切换状态下，接收到业务处理请求后，判断当前业务所对应的额度变化量是否小于安全可用余额的相反数，如果是则停止处理该业务，否则正常处理该业务；

所述可用余额确定模块，用于根据数据备份目标侧本地的备库数据及故障切换库数据确定安全可用余额，对于任意账户，其安全可用余额＝备库记录的该账户最新可用余额+故障切换库记录的该账户额度变化量。

本申请所提供的技术方案，基于“避免发生资损”这一前提需求，在数据备份时对流入类业务和流出类业务进行区别处理，其中，对于流出类业务，允许本地业务系统对“执行业务处理逻辑”及“将数据变动情况同步到异地”进行并行处理，与现有技术相比，可以将办理一次业务需要的时间由“业务系统实际处理耗时+数据异地同步耗时”优化至两者的最大值，从而降低对用户体验的影响。

应当理解的是，以上的一般描述和后文的细节描述仅是示例性和解释性的，并不能限制本申请。

附图说明

为了更清楚地说明本申请实施例或现有技术中的技术方案，下面将对实施例或现有技术描述中所需要使用的附图作简单地介绍，显而易见地，下面描述中的附图仅仅是本申请中记载的一些实施例，对于本领域普通技术人员来讲，还可以根据这些附图获得其他的附图。

图1是应用层数据强同步容灾系统结构示意图；

图2是现有的数据备份方法的流程示意图；

图3是本申请的数据备份方法的第一种流程示意图；

图4是本申请的数据备份方法的第二种流程示意图；

图5是本申请的数据备份方法的第三种流程示意图；

图6是本申请的数据备份装置的结构示意图；

图7是本申请的容灾切换业务处理装置的结构示意图。

具体实施方式

为了使本领域技术人员更好地理解本申请中的技术方案，下面将结合本申请实施例中的附图，对本申请实施例中的技术方案进行详细地描述，显然，所描述的实施例仅仅是本申请一部分实施例，而不是全部的实施例。基于本申请中的实施例，本领域普通技术人员所获得的所有其他实施例，都应当属于本申请保护的范围。

对于资金、卡券、积分等涉及用户资产(可以包括实际资产或虚拟资产)的业务，在容灾备份体系下，首先需要考虑的问题就是保证余额数据、额度变化数据等关键数据在备份源端与备份目标侧的一致性。目前，对这些关键数据的进行异地备份的最可靠的一种方式就是应用层数据强同步。

以财务系统为例进行说明，图2示出了一种财务系统在业务处理时进行应用层数据强同步的流程示意图。

假设用户账户的初始余额为100元，用户侧向业务系统发送业务处理请求，请求向第三方支付10元，在非故障状态下，该业务请求将被路由至主数据中心的业务系统。

如图2所示，主数据中心本地的业务系统a接收到业务处理请求后，首先针对该支付业务执行常规的业务处理逻辑，具体可以包括基本的扣款操作、落流水操作等等。这里假设本步骤整体处理耗时为t1。

上述业务逻辑执行完毕后，业务系统a将本次业务处理的涉及的余额变动情况(-10元)同步至备份数据中心侧的业务系统b，业务系统b进一步将上述余额变动信息写入备份数据中心侧的fo库中，写入完成后，业务系统b向业务系统a反馈响应，告知fo库写入成功。这里假设本步骤整体处理耗时为t2。

业务系统a接收到fo库写入成功响应后，向用户侧反馈业务处理成功消息，至此整个支付业务处理流程结束。

另外，在数据库层面，主数据中心本地数据库a也会向备份数据中心的数据库b复制数据，由于数据库本身并不理解数据的业务含义，因此该过程采用数据库的原生数据复制方案，以表级别进行数据复制，只能实现异步复制。也就是说，从业务数据在数据库a写入完毕，到该业务数据成功备份到数据库b，还会再有一段延迟。

通过上述过程可以看出，对于业务请求方而言，办理一次业务需要等待的时间≈t1+t2，其中t1是业务逻辑执行所必须的，而t2则是应用层数据同步所导致的。根据实际测试，在数据中心部署距离1000km左右的异地容灾系统中，t2的值为30ms左右，如果数据中心的部署距离更远，则t2的值还会进一步提升。

针对现有的应用层数据强同步导致业务处理等待时间过长的问题，本申请提供的方案是：在数据备份时对流入类业务和流出类业务进行区别处理，从而实现降低流出类业务处理等待时间的效果。

图3所示，为本申请提供的数据备份方法的流程图，该方法可以包括以下步骤：

s101，数据备份源侧接收业务请求方发送的业务处理请求后，判断当前业务的业务类型；

在本申请方案中，业务类型特指两类：流入类业务和流出类业务；其中，流入类业务是指会导致系统中记录的资产(可以是实际资产或虚拟资产)余额增加的业务；流出类业务则是指会导致系统中记录的资产(可以是实际资产或虚拟资产)余额减小的业务。例如，对于财务系统中的某个账户而言，流入类业务可以包括：存款、汇入、第三方退款、资金解冻等等；对应的流出类业务则可以包括：取款、汇出、支付、资金冻结等等。

当然，在实际应用中，除了上述两类业务之外，还包括很多其他的业务类型，例如余额查询业务，用户信息修改业务等等。这些业务的处理方式仍可以 采用现有的处理方案，本申请并不限定。可以理解的是，这里所说的“现有的处理方案”并不限于应用层数据强同步，例如对于一些不涉及数据写入的业务，可能并不存在备份需求，或者对于一些重要程度较低数据的写入，可以采用对时效性要求较低的数据备份方式，等等。

在本步骤中，业务请求方可以是用户设备、第三方系统设备等，数据备份源侧的业务系统接收到业务请求方发送的业务处理请求后，判断当前业务(即所请求处理的业务)的流入/流出类型，如果判断当前业务属于流出类业务，则以并行方式触发s102及s103；

s102，执行当前业务的处理逻辑；

数据备份源侧的业务系统在本地执行当前业务处理逻辑，例如存款/取款操作、落流水操作等等，具体的处理过程本申请并不进行限定。

s103，将当前业务对应的额度变化量数据同步到数据备份目标侧的故障切换库；

数据备份源侧的业务系统将本次业务处理的涉及的额度变化信息同步至数据备份目标侧的业务系统，数据备份目标侧的业务系统进一步将上述额度变化信息写入数据备份目标侧的fo库中，写入完成后，目标侧业务系统向源侧业务系统反馈响应，告知fo库写入成功。

这里需要说明的是，由于“额度变化量数据”可以直接从业务处理请求信息中提取，例如“支付10元”对应的额度变化量数据为-10、“汇入50元”对应的额度变化量数据为+50，等等，因此s102与s103的并行执行是完全可行的。

s104，向业务请求方发送业务处理响应。

数据备份源侧的业务系统等待当前业务的处理逻辑完成、并且接收到目标侧的fo库写入成功响应后，向业务请求方发送业务处理成功消息，至此整个业务处理流程结束。

下面仍以财务系统处理支付业务为例，对本申请所提供的数据备份方法进行说明：

参见图4所示，假设用户账户的初始余额为100元，用户侧向业务系统发 送业务处理请求，请求向第三方支付10元，在非故障状态下，该业务请求将被路由至主数据中心的业务系统。

主数据中心本地的业务系统a接收到业务处理请求后，首先判断该业务对应的资金流向，由于支付业务为流出类业务，因此后续采用并行处理方式：

一方面，业务系统a首先针对该支付业务执行常规的业务处理逻辑，具体可以包括基本的扣款操作、落流水操作等等。这里仍假设本步骤整体处理耗时为t1。

另一方面，业务系统a开启另一个处理线程，将本次业务处理的涉及的余额变动情况(-10元)同步至备份数据中心侧的业务系统b，业务系统b进一步将上述余额变动信息写入备份数据中心侧的fo库中，写入完成后，业务系统b向业务系统a反馈响应，告知fo库写入成功。这里仍假设本步骤整体处理耗时为t2。

业务系统a接收到fo库写入成功响应后，向用户侧反馈业务处理成功消息，至此整个支付业务处理流程结束。

另外，在数据库层面，数据库a与数据库b之间仍采用异步复制方式备份数据，本实施例中不再重复说明。

通过上述过程可以看出，应用本申请方案，由于将现有的串行处理流程变更为并行处理流程，因此对于业务请求方而言，可以将办理一次流出类业务需要等待的时间从t1+t2缩短至max(t1,t2)，性能得到了明显的改善。

这里需要说明的是，本申请方案对于业务等待时间的改善，并不适用于流入类业务，下面将结合基于上述数据备份方案的容灾处理方案，具体分析这样处理的原因：

从账户额度的角度来看，理想状态下，存在以下关系：

可用余额＝总流入额度-总流出额度(1)

利用现有的应用层串行强同步，可以保证数据备份源侧和目标侧在上述关系上的一致性。而本申请为了改善现有技术所存在的问题，实际上放宽了对账户余额的一致性要求，具体而言，允许数据备份目标侧在容灾切换后，处于以 下状态：

系统记录的总流出额度≥真实的总流出额度(2)

系统记录的总流入额度≤真实的总流入额度(3)

也就是说：允许实际没有发生流出、但系统记录中体现了，允许实际发生了资产流入，但系统记录中没有体现。这样放宽条件对应的实际意义是：不能允许系统记录的余额超过实际的余额，以避免资损情况的发生。而如果系统记录的余额小于实际的余额，仅可能导致将原本能够处理的业务判断为无法处理，与发生资损相比，这种情况的严重程度可以忽略不计。

结合本申请方案，由于“额度变化量数据同步”与“业务逻辑处理”是并行方式执行，因此可能出现的情况是：数据备份目标测先获得额度变化记录、然后额度变化才真实发生。依据前述的放宽条件，对于流出类业务，可以允许先“存在流出记录”然后“流出真实发生”；但是对于流入类业务，则必须在“流入真实发生”后，才允许“存在流入记录”。

以上分析解释了本申请方案不适用于流入类业务的原因，实际应用中，对于流入类业务，可以仍然采用应用层串行强同步的方式，即在数据备份源侧本地执行完当前业务的处理逻辑之后，再将该业务对应的额度变化量数据同步到数据备份目标侧。当然，由于本申请方案本身并不针对流入类业务，因此也不需要对流入类业务的具体备份方式进行限定。

下面将进一步介绍在前述放宽条件以及数据备份方法的基础上，如何进行容灾处理。

首先对本申请方案中需要使用到的“安全可用余额”参数进行说明：

由前面的公式(2)与公式(3)可以得到：

系统记录的总流入额度-系统记录的总流出额度

≤真实的总流入额度-真实的总流出额度(4)

将公式(4)左端的表达式定义为“安全可用余额”，进一步结合公式(1)可以得到：

安全可用余额≤真实可用余额(5)

可见公式(5)也与前面的分析结论相一致，即：不能允许系统记录的余额超过实际的余额，以避免资损情况的发生。

实际应用中，数据备份目标侧(即容灾切换后的实际业务处理侧)可以根据本地的备库数据及fo库数据确定安全可用余额，具体而言，对于任意账户，其安全可用余额可以用以下公式进行计算：

安全可用余额＝备库记录的最新可用余额+fo库记录的额度变化量

可以看出，如果在应用层串行强同步的情况下，上式的计算结果其实就是“真实可用余额”，事实上这也正是应用层串行强同步在容灾切换后所采用的数据恢复方案。

而基于本申请的并行同步方案，由于“fo库记录的额度变化量”一项存在不确定性，因此计算得到的安全可用余额是可能小于真实可用余额的。基于“避免发生资损”这一前提需求，要求在容灾切换期间，后续业务处理对应的额度变动不得超出安全可用余额的限制，具体方案如下：

在容灾切换状态下，数据备份目标侧(即容灾切换后的实际业务处理侧)接收到业务处理请求后，判断当前业务所对应的额度变化量是否小于安全可用余额的相反数，如果是则停止处理该业务，否则正常处理该业务。

根据实际的业务特点，事实上只有流出类业务可能导致资损，因此上述方案具体也可用采用以下方式实现：

接收到业务处理请求后，首先判断当前业务(即所请求处理的业务)的流入/流出类型。

如果当前业务为流入类业务，则直接转入相应的业务处理流程，正常处理该业务；

如果当前业务为流出类业务，则需要进一步判断该业务对应的流出额度是否小于安全可用余额，如果是则正常处理该业务，否则停止处理该业务。

仍以财务系统处理支付业务为例，对上述容灾处理方法进行说明。图5所示出的业务需求场景与图4所示出业务需求场景一致，并且都采用并行方式进行备份处理。区别在于：在本实施例中，由于某种原因(例如支付密码输入错 误)，导致实际支付失败，因此业务处理结束后实际账户余额仍为100元。而此时余额变动情况(-10元)已经同步到异地的fo库中。

假设在“支付失败”以及“余额变动情况同步到fo”完成之后、且数据库a尚未与数据库b完成数据备份之前，发生容灾切换，那么此时fo库记录的账户额度变化量为-10元，而数据库b记录账户余额仍为100元。

通过计算，可得到该账户的安全可用余额为100+(-10)＝90元，那么，在容灾切换期间，业务系统b将以90为基准判断是否处理后续接收到的业务请求。例如：

用户请求存入20元，对应的金额变动为+20，由于20＞-90，因此正常处理该业务；

用户请求取出60元，对应的金额变动为-60，由于-60＞-90，因此正常处理该业务；

用户请求取出90元，对应的金额变动为-90，由于-90＝-90，因此正常处理该业务；

用户请求取出95元，对应的金额变动为-95，由于-95＜-90，因此拒绝处理处理该业务。

事实上，对于第4种情形，用户账户的实际余额(100元)是可以满足取出条件的，但是在容灾切换场景下，业务系统b并不能确定(-10元)对应的流出业务是否实际发生，出于避免资损的目的，将以该流出业务已发生为准，进行后续处理。

在实际处理中，一种可行的安全可用余额计算方式是：发生故障后，立即将所有账户的安全可用余额都计算出来；然而在实际应用中，考虑到故障切换库只是临时代替主库，因此没有必要计算全量的数据。在本申请的一种具体实施方式中，可以采用按需计算安全可用余额恢复数据的方式，即：在发生故障后，待收到业务处理请求后，再计算对应的安全可用余额，甚至可以进一步在确定业务处理需要用到安全可用余额时，再计算对应的安全可用余额，从而减少不必要的数据恢复所消耗的时间。

在计算安全可用余额时，fo库可能存在多条额度变动记录。根据fo库的基本原理，在fo库中只需要保存“最新”的额度变动情况，这里的“最新”的一种实现方式是：

可以是仅保留最近一段时长t内发生的额度变动数据，其中t应该不小于主库向备库异步备份数据的平均时延d，一般取d值的a倍作为t值，其中a的取值不小于1，综合安全性及存储效率考虑，可以将a值取在1至2之间，例如可以取a＝1.5。

在有些应用场景下，数据库中除了会存储余额数据之外，可能还会存储额度变化量数据。这种情况下，容灾切换处理侧可以根据备库中的额度变化量数据对安全可用余额计算进行优化，具体方案如下：

在fo库记录的额度变化量数据中，检查是否存在与备库记录的额度变化量数据相匹配的数据；进而在计算安全可用余额时，仅保留无法匹配到的fo库记录的额度变化量数据参与计算。

例如，数据库中存在“可用余额”与“额度流水”两张表，发生故障切换后，某账户在备库中两张表的最后几条记录如下所示：

可用余额表：

……

余额100元

余额90元

余额75元

额度流水表：

……

id101，流出10元

id102，流出15元

而fo库中记录的该账户额度变化情况如下：

id101，流出10元

id102，流出15元

id103，流出20元

此时，账户的实际可用余额应为55元，备库记录的最新可用余额为75元，而fo库中记录了3条额度变化数据。如果按照本申请前面实施例提供的基本安全余额方案，计算得到的安全余额r1＝75-10-15-20＝30元。

而应用本实施例提供的优化方案，通过检查可以发现，fo库记录的额度3条变化量数据中，前2条都是能够在备库中找到匹配记录的，那么前2条记录可以不参与安全余额计算，因此优化后计算得到的安全余额r2＝75-20＝55元，可见，r2与r1相比更为接近账户的实际可用余额

另外，如果在备库和fo库中记录的数据支持时间戳，并且时间戳精度能够满足实际需求，那么也可以根据时间戳来实现安全余额的优化计算。具体方案如下：

在fo库记录的额度变化量数据中，滤除更新时刻早于备库中最后更新时刻的额度变化量数据；进而在计算安全可用余额时，仅保留更新时刻晚于或小于备库中最后更新时刻的额度变化量数据参与计算。

例如，备库与fo库中的记录均支持时间戳，数据库中存在“可用余额”与“额度流水”两张表，发生故障切换后，某账户备库中两张表的最后几条记录如下所示：

可用余额表：

……

余额100元12:00更新

余额90元12:06更新

余额75元12:07更新

额度流水表：

……

id101，流出10元12:06更新

id102，流出15元12:07更新

而fo库中记录的该账户额度变化情况如下：

id101，流出10元12:05更新

id102，流出15元12:06更新

id103，流出20元12:10更新

而应用本实施例提供的优化方案，通过检查可以发现，fo库记录的额度3条变化量数据中，前2条的更新时刻都早于备库中最后的更新时刻(12:07)，那么前2条记录可以不参与安全余额计算，因此优化后计算得到的安全余额r3＝75-20＝55元。可见，r3与r1相比更为接近账户的实际可用余额。

当然，如果备库和fo库中记录的数据均支持时间戳，并且时间戳精度能够满足实际需求，那么也可用直接利用时间戳来实现“仅在fo库中保存“最新”的额度变动情况”，具体方案为：在fo库中，仅保留备库余额数据最后一次更新时刻之后发生的额度变动数据；这样在计算安全可用余额时，就不需要再次优化，而且还可用进一步降低fo库的存储开销。

相应于上述方法实施例，本申请还提供一种应用于数据备份源侧的数据备份装置，参见图6所示，该装置可以包括：

业务类型判断模块110，用于接收业务请求方发送的业务处理请求后，判断当前业务的业务类型，业务类型可以包括：流入类业务和流出类业务；

控制模块120，用于在当前业务为流出类业务的情况下，控制业务处理模块130及数据同步模块140以并行方式执行各自功能；

业务处理模块130用于：在本地执行当前业务的处理逻辑；

数据同步模块140用于：将当前业务对应的额度变化量数据同步到数据备份目标侧的故障切换库；

业务处理响应模块150，用于在控制业务处理模块130及数据同步模块140的操作均执行完成后，向业务请求方发送业务处理响应。

在本申请的一种具体实施方式中，控制模块120还用于在当前业务为流入类业务的情况下，控制业务处理模块及数据同步模块以串行方式执行各自功能。

在本申请的一种具体实施方式中，故障切换库中保留最新数据的对应时长t，根据主库向备库异步备份数据的平均时延d确定：t＝ad；其中，主库位于数据 备份源侧，备库及故障切换库位于数据备份源侧，a的取值不小于1。

参见图7所示，本申请还提供一种容灾切换业务处理装置，应用于数据备份目标侧，该装置包括业务处理模块210及安全可用余额确定模块220；

业务处理模块210，用于在容灾切换状态下，接收到业务处理请求后，判断当前业务所对应的额度变化量是否小于安全可用余额的相反数，如果是则停止处理该业务，否则正常处理该业务；

可用余额确定模块220，用于根据数据备份目标侧本地的备库数据及故障切换库数据确定安全可用余额，对于任意账户，其安全可用余额＝备库记录的该账户最新可用余额+故障切换库记录的该账户额度变化量。

在本申请的一种具体实施方式中，业务处理模块210可以具体用于：

在容灾切换状态下，接收到业务处理请求后，判断当前业务的业务类型，如果当前业务为流入类业务，则正常处理该业务；

如果当前业务为流出类业务，则进一步判断该业务对应的流出额度是否小于安全可用余额，如果是则正常处理该业务，否则停止处理该业务。

在本申请的一种具体实施方式中，可用余额确定模块220可以具体用于：

在故障切换库记录的额度变化量数据中，检查是否存在与备库记录的额度变化量数据相匹配的数据；在计算安全可用余额时，仅保留无法匹配到的故障切换库记录的额度变化量数据参与计算。

在本申请的一种具体实施方式中，可用余额确定模块220还可以具体用于：

在故障切换库记录的额度变化量数据中，滤除更新时刻早于备库中最后更新时刻的额度变化量数据；在计算安全可用余额时，仅保留更新时刻晚于或小于备库中最后更新时刻的额度变化量数据参与计算。

本申请还提供一种容灾系统，该系统可以包括位于数据备份源侧的第一应用服务器、主库，以及位于数据备份目标侧的第二应用服务器、备库、故障切换库。其中，第一应用服务器中配置有前述的数据备份装置，第二应用服务器中配置有前述的容灾切换业务处理装置。

通过以上的实施方式的描述可知，本领域的技术人员可以清楚地了解到本 申请可借助软件加必需的通用硬件平台的方式来实现。基于这样的理解，本申请的技术方案本质上或者说对现有技术做出贡献的部分可以以软件产品的形式体现出来，该计算机软件产品可以存储在存储介质中，如rom/ram、磁碟、光盘等，包括若干指令用以使得一台计算机设备(可以是个人计算机，服务器，或者网络设备等)执行本申请各个实施例或者实施例的某些部分所述的方法。

本说明书中的各个实施例均采用递进的方式描述，各个实施例之间相同相似的部分互相参见即可，每个实施例重点说明的都是与其他实施例的不同之处。尤其，对于装置或系统实施例而言，由于其基本相似于方法实施例，所以描述得比较简单，相关之处参见方法实施例的部分说明即可。以上所描述的装置或系统实施例仅仅是示意性的，其中所述作为分离部件说明的模块可以是或者也可以不是物理上分开的，在实施本申请方案时可以把各模块的功能在同一个或多个软件和/或硬件中实现。也可以根据实际的需要选择其中的部分或者全部模块来实现本实施例方案的目的。本领域普通技术人员在不付出创造性劳动的情况下，即可以理解并实施。

以上所述仅是本申请的具体实施方式，应当指出，对于本技术领域的普通技术人员来说，在不脱离本申请原理的前提下，还可以做出若干改进和润饰，这些改进和润饰也应视为本申请的保护范围。