数据一致性的核验方法、装置及系统

摘要

本申请公开了一种数据一致性的核验方法、装置及系统。其中，该方法包括：通过业务接口系统接收多个业务系统的信息流；基于所述信息流进行资金链的金额和状态的一致性核验；根据核验结果触发规则系统产生相应级别的报警通知；通过预警系统将报警通知推送给相应的业务归属方。本申请解决了相关技术中不能检测数据一致性的技术问题。

说明书

技术领域

本申请涉及互联网金融领域，具体而言，涉及一种数据一致性的核验方法、装置及系统。

背景技术

在金融科技时代，支付公司的支付业务场景和架构基本上是基于分布式的大规模集群方式来解决高并发访问和交易响应能力，在核心支付系统支付链路上，包括：网关系统、收银台、银行通道、资金账户系统四个核心系统，为了支持高并发，每个系统各自独立，每个系统自己处理自己的基于资金的信息流。

采用这种技术方案，在按照时间周期(如每个月)进行系统资金核算时极容易出现资金不一致，数据不一致，状态不一致的情况，因此急需一种对各个业务系统进行有效资金核验和状态核验的方法，来解决系统的资金和状态一致性较差的问题。

针对上述的问题，目前尚未提出有效的解决方案。

发明内容

本申请实施例提供了一种数据一致性的核验方法、装置及系统，以至少解决相关技术中不能检测数据一致性的技术问题。

根据本申请实施例的一个方面，提供了一种系统一致性的核验系统，包括：资金安保系统，资金安保系统用于核验多个业务系统之间的数据一致性；业务接口系统，与资金安保系统和多个业务系统通信连接，用于向多个业务系统提供对接方案和接口包装服务；规则系统，与资金安保系统通信连接，用于根据资金安保系统的核验结果触发相应的报警通知；预警系统，与规则系统和资金安保系统通信连接，用于将报警通知推送给业务归属方。

根据本申请实施例的另一方面，还提供了一种数据一致性的核验方法，包括：通过业务接口系统接收多个业务系统的信息流；基于信息流进行资金链的金额和状态的一致性核验；根据核验结果触发规则系统产生相应级别的报警通知；通过预警系统将报警通知推送给相应的业务归属方。

根据本申请实施例的另一方面，还提供了一种数据一致性的核验装置，包括：接收单元，用于通过业务接口系统接收多个业务系统的信息流；核验单元，用于基于信息流进行资金链的金额和状态的一致性核验；报警单元，用于根据核验结果触发规则系统产生相应级别的报警通知；推送单元，用于通过预警系统将报警通知推送给相应的业务归属方。

根据本申请实施例的另一方面，还提供了一种存储介质，该存储介质包括存储的程序，程序运行时执行上述的方法。

根据本申请实施例的另一方面，还提供了一种电子装置，包括存储器、处理器及存储在存储器上并可在处理器上运行的计算机程序，处理器通过计算机程序执行上述的方法。

在本申请的系统一致性核验方案中，通过业务系统对接资金安保系统消息队列，将数据推送到资金安保系统，资金安保系统基于信息流的信息进行及时预警和响应，快速定位问题，相较于各业务系统自己进行资金核算，生产效率得到了有效提升，使其成为了一种有效的资金安全防范策略，可以解决了相关技术中不能检测数据一致性的技术问题。

附图说明

此处所说明的附图用来提供对本申请的进一步理解，构成本申请的一部分，本申请的示意性实施例及其说明用于解释本申请，并不构成对本申请的不当限定。在附图中：

图1是根据本申请实施例的数据一致性的核验系统的示意图；

图2是根据本申请实施例的一种可选的数据一致性的核验方法的流程图；

图3是根据本申请实施例的一种可选的数据一致性核验方案的示意图；

图4是根据本申请实施例的一种可选的数据链内容的示意图；

图5是根据本申请实施例的一种可选的数据一致性的核验装置的示意图；以及，

图6是根据本申请实施例的一种终端的结构框图。

具体实施方式

为了使本技术领域的人员更好地理解本申请方案，下面将结合本申请实施例中的附图，对本申请实施例中的技术方案进行清楚、完整地描述，显然，所描述的实施例仅仅是本申请一部分的实施例，而不是全部的实施例。基于本申请中的实施例，本领域普通技术人员在没有做出创造性劳动前提下所获得的所有其他实施例，都应当属于本申请保护的范围。

需要说明的是，本申请的说明书和权利要求书及上述附图中的术语“第一”、“第二”等是用于区别类似的对象，而不必用于描述特定的顺序或先后次序。应该理解这样使用的数据在适当情况下可以互换，以便这里描述的本申请的实施例能够以除了在这里图示或描述的那些以外的顺序实施。此外，术语“包括”和“具有”以及他们的任何变形，意图在于覆盖不排他的包含，例如，包含了一系列步骤或单元的过程、方法、系统、产品或设备不必限于清楚地列出的那些步骤或单元，而是可包括没有清楚地列出的或对于这些过程、方法、产品或设备固有的其它步骤或单元。

首先，在对本申请实施例进行描述的过程中出现的部分名词或者术语适用于如下解释：

JMS即Java消息服务(Java Message Service)应用程序接口，是一个Java平台中关于面向消息中间件(MOM)的API，用于在两个应用程序之间，或分布式系统中发送消息，进行异步通信。

包装类，Java提供了两个类型系统，基本类型与引用类型，使用基本类型在于效率，然而当要使用只针对对象设计的API或新特性(例如泛型)，那么基本数据类型的数据就需要用包装类来包装。

相关技术中的业务流程是串行模式，由业务系统发起，然后依次通过网关、收银台、银行通道等系统。这种模式下的各个系统各自独立，系统间没有基于信息流的核验，系统一致性完全无法核对，极易出现系统间状态不一致、金额不一致、数据不一致的情况。

例如，收单时可能发生的资金风险包括：重复入账，支付成功一笔订单给客户但入账多次；多入账，给客户入账金额大于支付成功金额；入错账：客户A的资金入给客户B；重复退款：交易退款时扣减商户账户余额一次但给持卡人多次退款；未扣款退款：交易退款未扣减商户账户余额一次但给持卡人多次退款；漏入账：订单支付成功未给客户入账；少入账：给客户入账金额小于支付成功金额；退错款：持卡人A的退款退给持卡人B；退款失败资金未退还：给客户入账金额小于支付成功金额。

出款时可能发生的资金风险包括：重复出款：扣减一次商户账户余额但向客户打款多次；多出款：给客户打款金額大于扣减账户的金额；出错款：应打给客户A的款项打款给了客户B；打款失败重复退回：一笔打款失败的交易资金被多次退回商户账户；未扣款出款：未扣减客户账户余额但给持卡人多次退款；扣款成功未打款：扣减了商户账户余額但未给客户打款；少出款：给客户打款金额小于扣减账户的金额。

针对以上问题，根据本申请实施例的一方面，提供了一种数据一致性的核验系统(或称资金安保引擎)的实施例。在本方案中，主要包括资金安保系统、业务接口系统、规则系统以及预警系统四部分。

资金安保系统：资金安保系统是处理资金交易的安全保障系统，用于保障系统双边交易的正确性，验证是否有单边错误。

主要的业务场景包括：1，业务系统订单业务状态和资金账户的业务状态是否一致的业务预警；2，业务系统的订单金额和资金账户的账务变动金额是否一致的业务预警；3，统计核对业务系统交易数量和资金安保系统的数据是否一致(T+1核对，即当天的数据会在第二天进行核对)。

其技术特点包括：1，和业务系统是松耦合的关系，业务系统不必通过facade接口报送数据；2，业务接口适应性强，依赖基础core和消息队列即可完成对接；3，系统提供T+1的数据核对方式，可以再次和业务系统验证数据正确性；4，系统处理引擎采用数据打标模式处理，业务数据表处理数据性能高；数据采用T+2的模式定期将信息采集表数据转移到历史表，保证预处理引擎工作效率。

业务接口系统：提供各个业务系统的对接策略(即对接方案)和包装服务，使各个业务系统对接简单，不需要关注代码的实现，只需要做简单的配置即可。

规则系统：定义系统的规则和报警响应级别，根据响应级别触发相应的响应策略。

预警系统：预警系统提供报警人接受配置，可以设定响应的报警组和接收人，根据业务平台归属报警给相关业务人，业务人员收到报警信息做响应的业务处理。

业务系统和资金安保系统的链接关系是：业务系统包括网关、收银台、银行通道、资金账户系统，四个业务系统通过业务接口系统的JMS消息和资金安保系统进行消息推送，当基于信息流的订单在以上四个业务系统流过的时候，触发相应的消息给资金安保系统，资金安保系统收到以上四个业务系统的消息后，进行基于资金链的金额和状态验证，验证通过信息落地，验证失败触发规则系统规则，规则系统通过相应级别的报警，推送给预警系统发送给业务归属方。

业务系统和业务接口系统的链接关系是：业务接口系统提供简单的包装服务接口，便于业务系统对接网关、收银台、银行通道、资金账户。

资金安保系统和规则系统的链接关系是：资金安保系统在处理资金信息数据链的账户平衡方面，比对四个业务系统的资金和状态标志，当状态不一致或资金金额不一致的时候，根据规则系统的规则级别触发响应报警。

资金安保系统和预警系统的链接关系是：规则系统触发的相关报警邮件，预警系统根据业务系统的业务配置关系，寻找响应的报警组，发送报警邮件给报警组用户。

图2是根据本申请实施例的一种可选的数据一致性的核验方法的流程图，如图2所示，该方法可以包括以下步骤：

步骤S202，资金安保系统通过业务接口系统接收多个业务系统的信息流。

如：通过业务接口系统接收网关的信息流；通过业务接口系统接收收银台的信息流；通过业务接口系统接收银行通道的信息流；通过业务接口系统接收资金账户的信息流。

步骤S204，资金安保系统基于信息流进行资金链的金额和状态的一致性核验。

可基于信息流对资金链在收单时发生的异常进行核验，如：基于信息流核验是否存在重复入账，重复入账表示支付成功一笔订单给客户但入账多次；基于信息流核验是否存在多入账，多入账表示给客户入账金额大于支付成功金额；基于信息流核验是否存在入错账，入错账表示应该给客户A的资金入给了客户B；基于信息流核验是否存在重复退款，重复退款表示交易退款时扣减商户账户余额一次但给持卡人多次退款；基于信息流核验是否存在未扣款退款，未扣款退款表示交易退款未扣减商户账户余额但给持卡人多次退款；基于信息流核验是否存在漏入账，漏入账表示订单支付成功但未给客户入账；基于信息流核验是否存在少入账，少入账表示给客户入账金额小于支付成功金额；基于信息流核验是否存在退错款，退错款表示将应该给持卡人A的退款退给了持卡人B；基于信息流核验是否存在退款失败资金未退还，退款失败资金未退还表示给客户的入账金额小于支付成功金额。

还可基于信息流对资金链在出款时发生的异常进行核验，如：基于信息流核验是否存在重复出款，重复出款表示扣减一次商户账户余额但向客户打款多次；基于信息流核验是否存在多出款，多出款表示给客户打款金額大于扣减账户的金额；基于信息流核验是否存在出错款，出错款表示应该打给客户A的款项打款给了客户B；基于信息流核验是否存在打款失败重复退回，打款失败重复退回表示一笔打款失败的交易资金被多次退回给商户账户；基于信息流核验是否存在未扣款出款，未扣款出款表示未扣减客户账户余额但给持卡人多次退款；基于信息流核验是否存在扣款成功未打款，扣款成功未打款表示扣减了商户账户余額但未给客户打款；基于信息流核验是否存在少出款，少出款表示给客户打款金额小于扣减账户的金额。

步骤S206，资金安保系统根据核验结果触发规则系统产生相应级别的报警通知。

步骤S208，资金安保系统通过预警系统将报警通知推送给相应的业务归属方。

通过上述步骤S202至步骤S208，在本申请的系统一致性核验方案中，通过业务系统对接资金安保系统消息队列，将数据推送到资金安保系统，资金安保系统基于信息流的信息进行及时预警和响应，快速定位问题，相较于各业务系统自己进行资金核算，生产效率得到了有效提升，使其成为了一种有效的资金安全防范策略，可以解决了相关技术中不能检测数据一致性的技术问题。

作为一种可选的实施例，下文结合具体实施方式进一步详述本申请的技术方案：

资金安保引擎工作方案如图1所示，网关系统、收银台系统、银行通道系统以及资金账户系统(即资金安保引擎所在的系统)之间的消息队列如图3所示，包括：业务系统消息队列queue://fundsafety.bussioness.queue、收银台消息队列queue://fundsafety.cashier.queue、银行通道队列queue://fundsafety.bankchannel.queue、账务系统队列queue://fundsafety.account.queue。

在该方案中，资金信息流高度集成，各业务系统只需要实现简单的接口对接即可，交易过程的信息流通过对接节点将完整的消息出点发送给资金安保工作引擎，工作引擎收到消息后，进行全信息链的信息匹配，从而达到一致性验证的目的，对业务系统业务逻辑耦合比较松散，并不影响原来的业务和性能，在综合压力下，实测性能达到800TPS(全称为Transactions Per Second，每秒传输的事物处理个数，即服务器每秒处理的事务数)。

整个方案的实现如下：

步骤1，对接业务系统通过fundsafetyBusinessProducer方法，同步组成消息参数，消息参数内容包括如下字段：

Dna：DNA信息；requestId：商户请求号；merchantId：商户编号；memberId：交易会员号；orderStatus：订单状态；Fee：交易手续费；orderAmount：订单金额；createDateTime：交易时间；completeDateTime：交易完成时间；Currency：币种；businessSource：业务来源；tradeType：交易类型。

将以上信息打包成MQ消息封装，发送给资金安保工作引擎(fundsafety)，该消息是创建订单的时候发送的首消息FristMsg。

步骤2，资金安保工作引擎收到业务系统发送的消息后，进行资金信息流的数据链创建，完整的数据链包括的内容如图4所示。此信息链包含完整的交易数据信息，包括网关，收银台，银行通道，资金账户中的账户金额、状态等。

步骤3，收银台依次调用fundsafetyCashReceiptProducer方法，发送收银台消息给资金安保系统，信息包括：

Dna：DNA信息；merchantId：商户编号；memberId：交易会员号；payerMemberId：付款人号；orderStatus：订单状态；requestNumber：请求号；businessSource：业务来源；orderAmount：交易金额；Currency：币种；createDateTime：创建时间；completeDateTime：交易完成时间。

将以上信息打包成MQ消息封装，发送给资金安保工作引擎(fundsafety)，该消息是创建订单的时候发送的第二消息TwoMsg。

步骤4，银行通道支付交易完成后，通过调用fundsafetyBankChannelProducer方法，发送封装消息给资金安保工作引擎，消息内容包括：

Dna：DNA订单信息；bankChannelId：银行通道编号；Status：交易状态；reqeustId:请求号；memberId：会员号；merchantId：商编号；orderAmount：订单金额；bankOrderNumber：银行订单号。

此消息是消息组成部分的第三部分ThreeMsg。

步骤5，资金安保工作引擎收到三方面的信息链后，开始调用doFillAndHandler方法检查信息链的完整性。

步骤6，资金安保从数据库中调用getRules方法获取统配的报警级别，报警级别包括：

RISK_LEVEL_01：业务系统、收银台、银行通道状态不一致；

RISK_LEVEL_02：业务系统、收银台、银行通道金额不一致；

RISK_LEVEL_03：业务系统重复交易；

RISK_LEVEL_04：收银台重复交易；

RISK_LEVEL_05：银行通道重复订单；

RISK_LEVEL_06：每日对账金额不一致；

RISK_LEVEL_07：每日对账状态不一致；

RISK_LEVEL_08：每日对账商户号不一致；

RISK_LEVEL_09：每日对账会员号不一致；

RISK_LEVEL_10：账务历史非法变动；

RISK_LEVEL_11：账务历史入账金额和信息流金额不一致。

步骤7，资金安保工作引擎匹配到资金金额，状态，或者商编和会员号不一致的情况即会触发对应的报警级别和方式。

步骤8，预警系统通过FundSafetyMonitor.sendMonitorMsg方法获取相关报警接收人的信息，把报警邮件按照对应的收件箱进行发送。

业务系统代码标识枚举类如下表1所示：

表1

业务系统消息队列的名称为queue://fundsafety.bussioness.queue，消息队列对应业务实体为com.ehking.fundsafety.entity.BusinessQueueEntity，业务字段描述如表2所示：

表2

资金账户消息队列的名称为queue://fundsafety.fundaccount.queue，对应业务实体为com.ehking.fundsafety.entity.FundAccountQueueEntity，业务字段描述如表3所示：

表3

业务系统订单流水明细如表4所示：

表4

业务汇总文件字段如表5所示：

表5

在接入流程中，各业务系统按照接入规则，完善接入的字段，各字段采集需要服务字段指定要求，流程如下：项目依赖资金安保的基础消息推送jms消息，producer对应的消息实体；在相关配置中，可在spring配置文件中配置扫描路径，如为"com.ehking.fundsafety.event"；启用相关代码；项目依赖消息队列服务，和sftp服务，引入相关的资源；业务系统需要T+1统计提交给资金安保系统的交易明细和汇总统计数据，以便资金安保工作引擎比对数据一致性，如在sftp核对策略中，每日凌晨1～5点将核对文件推送到指定的sftp服务器上，核对文件名称为，业务系统代码(参照业务系统编号)_yyyyMMdd.csv。

通过新的加解密方法后，应用系统性能和安全性有了完全的改变，综合性能如下：通过4台基于HA的分布式服务器，系统可处理的加解密请求达到3000TPS，单台服务器性能满足800TPS请求，且可以满足后续分布式扩展的需求，根据业务需求量可以理论上无限追加。

应用系统在传统加解密处理过程中，通过紧耦合的关系，开发难度和周期比新方法增加了开发周期成本，且安全性较低，易维护性较低。

通过新方法系统稳定性达到99.999％，操作简单，维护简便，不用关注密钥和证书的更换，且证书和密钥的更换支持新老密钥的双支持，双策略。

通过新方法降低了系统性能的消耗，极大提高了应用系统的稳定性和安全性，是一种显著的解耦方法。

需要说明的是，对于前述的各方法实施例，为了简单描述，故将其都表述为一系列的动作组合，但是本领域技术人员应该知悉，本申请并不受所描述的动作顺序的限制，因为依据本申请，某些步骤可以采用其他顺序或者同时进行。其次，本领域技术人员也应该知悉，说明书中所描述的实施例均属于优选实施例，所涉及的动作和模块并不一定是本申请所必须的。

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

根据本申请实施例的另一个方面，还提供了一种用于实施上述数据一致性的核验方法的数据一致性的核验装置。图5是根据本申请实施例的一种可选的数据一致性的核验装置的示意图，如图5所示，该装置可以包括：

接收单元51，用于通过业务接口系统接收多个业务系统的信息流；

核验单元53，用于基于所述信息流进行资金链的金额和状态的一致性核验；

报警单元55，用于根据核验结果触发规则系统产生相应级别的报警通知；

推送单元57，用于通过预警系统将报警通知推送给相应的业务归属方。

需要说明的是，该实施例中的接收单元51可以用于执行本申请实施例中的步骤S202，该实施例中的核验单元53可以用于执行本申请实施例中的步骤S204，该实施例中的报警单元55可以用于执行本申请实施例中的步骤S206，该实施例中的推送单元57可以用于执行本申请实施例中的步骤S208。

此处需要说明的是，上述模块与对应的步骤所实现的示例和应用场景相同，但不限于上述实施例所公开的内容。需要说明的是，上述模块作为装置的一部分可以运行在如图1所示的硬件环境中，可以通过软件实现，也可以通过硬件实现。

此处需要说明的是，上述模块与对应的步骤所实现的示例和应用场景相同，但不限于上述实施例所公开的内容。需要说明的是，上述模块作为装置的一部分可以运行在如图1所示的硬件环境中，可以通过软件实现，也可以通过硬件实现，其中，硬件环境包括网络环境。

根据本申请实施例的另一个方面，还提供了一种用于实施上述数据一致性的核验方法的服务器或终端。

图6是根据本申请实施例的一种终端的结构框图，如图6所示，该终端可以包括：一个或多个(仅示出一个)处理器201、存储器203、以及传输装置205，如图6所示，该终端还可以包括输入输出设备207。

其中，存储器203可用于存储软件程序以及模块，如本申请实施例中的数据一致性的核验方法和装置对应的程序指令/模块，处理器201通过运行存储在存储器203内的软件程序以及模块，从而执行各种功能应用以及数据处理，即实现上述的数据一致性的核验方法。存储器203可包括高速随机存储器，还可以包括非易失性存储器，如一个或者多个磁性存储装置、闪存、或者其他非易失性固态存储器。在一些实例中，存储器203可进一步包括相对于处理器201远程设置的存储器，这些远程存储器可以通过网络连接至终端。上述网络的实例包括但不限于互联网、企业内部网、局域网、移动通信网及其组合。

上述的传输装置205用于经由一个网络接收或者发送数据，还可以用于处理器与存储器之间的数据传输。上述的网络具体实例可包括有线网络及无线网络。在一个实例中，传输装置205包括一个网络适配器(Network Interface Controller，NIC)，其可通过网线与其他网络设备与路由器相连从而可与互联网或局域网进行通讯。在一个实例中，传输装置205为射频(Radio Frequency，RF)模块，其用于通过无线方式与互联网进行通讯。

其中，具体地，存储器203用于存储应用程序。

处理器201可以通过传输装置205调用存储器203存储的应用程序，以执行下述步骤：

通过业务接口系统接收多个业务系统的信息流；

基于所述信息流进行资金链的金额和状态的一致性核验；

根据核验结果触发规则系统产生相应级别的报警通知；

通过预警系统将报警通知推送给相应的业务归属方。

可选地，本实施例中的具体示例可以参考上述实施例中所描述的示例，本实施例在此不再赘述。

本领域普通技术人员可以理解，图6所示的结构仅为示意，终端可以是智能手机(如Android手机、iOS手机等)、平板电脑、掌上电脑以及移动互联网设备(Mobile InternetDevices，MID)、PAD等终端设备。图6其并不对上述电子装置的结构造成限定。例如，终端还可包括比图6中所示更多或者更少的组件(如网络接口、显示装置等)，或者具有与图6所示不同的配置。

本领域普通技术人员可以理解上述实施例的各种方法中的全部或部分步骤是可以通过程序来指令终端设备相关的硬件来完成，该程序可以存储于一计算机可读存储介质中，存储介质可以包括：闪存盘、只读存储器(Read-Only Memory，ROM)、随机存取器(RandomAccess Memory，RAM)、磁盘或光盘等。

本申请的实施例还提供了一种存储介质。可选地，在本实施例中，上述存储介质可以用于执行数据一致性的核验方法的程序代码。

可选地，在本实施例中，上述存储介质可以位于上述实施例所示的网络中的多个网络设备中的至少一个网络设备上。

可选地，在本实施例中，存储介质被设置为存储用于执行以下步骤的程序代码：

通过业务接口系统接收多个业务系统的信息流；

基于所述信息流进行资金链的金额和状态的一致性核验；

根据核验结果触发规则系统产生相应级别的报警通知；

通过预警系统将报警通知推送给相应的业务归属方。

可选地，本实施例中的具体示例可以参考上述实施例中所描述的示例，本实施例在此不再赘述。

可选地，在本实施例中，上述存储介质可以包括但不限于：U盘、只读存储器(ROM，Read-Only Memory)、随机存取存储器(RAM，Random Access Memory)、移动硬盘、磁碟或者光盘等各种可以存储程序代码的介质。

上述本申请实施例序号仅仅为了描述，不代表实施例的优劣。

上述实施例中的集成的单元如果以软件功能单元的形式实现并作为独立的产品销售或使用时，可以存储在上述计算机可读取的存储介质中。基于这样的理解，本申请的技术方案本质上或者说对现有技术做出贡献的部分或者该技术方案的全部或部分可以以软件产品的形式体现出来，该计算机软件产品存储在存储介质中，包括若干指令用以使得一台或多台计算机设备(可为个人计算机、服务器或者网络设备等)执行本申请各个实施例所述方法的全部或部分步骤。

在本申请的上述实施例中，对各个实施例的描述都各有侧重，某个实施例中没有详述的部分，可以参见其他实施例的相关描述。

在本申请所提供的几个实施例中，应该理解到，所揭露的客户端，可通过其它的方式实现。其中，以上所描述的装置实施例仅仅是示意性的，例如所述单元的划分，仅仅为一种逻辑功能划分，实际实现时可以有另外的划分方式，例如多个单元或组件可以结合或者可以集成到另一个系统，或一些特征可以忽略，或不执行。另一点，所显示或讨论的相互之间的耦合或直接耦合或通信连接可以是通过一些接口，单元或模块的间接耦合或通信连接，可以是电性或其它的形式。

所述作为分离部件说明的单元可以是或者也可以不是物理上分开的，作为单元显示的部件可以是或者也可以不是物理单元，即可以位于一个地方，或者也可以分布到多个网络单元上。可以根据实际的需要选择其中的部分或者全部单元来实现本实施例方案的目的。

另外，在本申请各个实施例中的各功能单元可以集成在一个处理单元中，也可以是各个单元单独物理存在，也可以两个或两个以上单元集成在一个单元中。上述集成的单元既可以采用硬件的形式实现，也可以采用软件功能单元的形式实现。

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