一种基于可信账本数据库的业务记录删除方法与流程

本说明书实施例涉及信息技术领域，尤其涉及一种基于可信账本数据库的业务记录删除方法。

背景技术：

可信账本数据库，是在区块链存储方案的基础上进行改进得到的新型存储方案，其能够克服了去中心化的区块链存储存在的吞吐量低、响应时间长等问题，同时又能满足用户对数据的可信存储需求。

可信账本数据库由中心化的数据库服务端在本地进行维护，其服务对象通常是企业级用户，用户在数据库服务端注册账户，并通过注册的账户将自身业务产生的业务数据封装成业务记录，将业务记录提交给数据库服务端，数据库服务端接收业务记录之后，将接收的业务记录写入本地的可信账本数据库进行存储。

可信账本数据库中，即按照一定的成块条件，将接收的各业务记录按批次打包成一个个数据块，每个数据块基于块体中封装的全部业务记录计算默克尔树根哈希，将根哈希写入数据块的块头，并且，下一个数据块的块头包含上一个数据块的哈希值（即对块头进行哈希计算得到的哈希值）。这种情况下，可信账本数据库实际上也属于一种块链式账本，可以确保难以对可信账本数据库中的部分业务记录进行篡改。还需要说明的是，可信账本数据库中序号为1的数据块（即第一个数据库）为创世数据块，其中一般会携带可信账本数据库的配置信息（如账本创建时间，账本维护方信息、账本有效期等）。

在实际应用中，有时用户想要将其拥有的产生时间过于久远的一些不重要的业务记录从可信账本数据库中删除，从而节约需要支付给数据库服务端的存储费用。为此，需要一种基于可信账本数据库的业务记录删除方法。

技术实现要素：

本申请实施例是为了解决现有的可信账本数据库不支持删除数据库的技术问题而提出的。

为解决上述技术问题，本申请实施例是这样实现的：

根据本说明书实施例的第1方面，提供一种基于可信账本数据库的业务记录删除方法，应用于数据库服务端，所述数据库服务端维护有可信账本数据库与其他可信账本数据库；

所述方法包括：

接收用户设备发送的业务记录删除请求；

根据所述业务记录删除请求，确定待删除数据块集合与待保留的重要业务记录集合；所述待删除数据块集合包括序号为1至序号为n的n个待删除数据块，n＞1；

按照各重要业务记录在所述可信账本数据库中的先后顺序，由先到后依次将所述重要业务记录集合中每个重要业务记录存入所述其他可信账本数据库中；

在保存所述重要业务记录集合之后，从可信账本数据库中删除所述待删除数据块集合，并且，重新生成创世数据块；其中，重新生成的创世数据块中包含原创世数据块携带的账本配置信息与第n个待删除数据块对应的块哈希。

根据本说明书实施例的第2方面，提供一种对重要业务记录的存在性验证方法，应用于用户设备，所述方法包括：

从数据库服务端获取待验证的重要业务记录，并计算所述重要业务记录的记录哈希；

将所述重要记录的记录哈希发送给数据库服务端，并接收所述数据库服务端返回对应于所述记录哈希的全局默克尔树路径；

基于所述重要记录的记录哈希与所述全局默克尔树路径，计算全局默克尔树的根哈希；

将计算得到的根哈希与保存的根哈希进行比对，若一致，则确定所述重要业务记录通过存在性验证。

通过本说明书实施例中所提供的方案，用户想要删除自己之前提交给可信账本数据库的一些不重要的业务记录时，可以向数据库服务端发送业务记录删除请求，请求数据库服务端从可信账本数据库中删除这些不重要的历史业务记录。由于可信账本数据库中前后相邻的数据块之间存在耦合性，因此，通常需要从创世数据块开始依次向后删除，删除之后，还需要重新生成创世数据块以便保留账本配置信息与最后一个被删除数据块的块哈希。此外，对于被删除数据块中重要的业务记录，需要另行保存至其他可信账本数据库。如此，另行保存的重要业务记录虽然不在原本的可信账本数据库中，但是对于用户来说依然是可信的。

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

此外，本说明书实施例中的任一实施例并不需要达到上述的全部效果。

附图说明

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

图1是本说明书提供的一种基于可信账本数据库的数据存储系统示意图；

图2是本说明书实施例提供的一种基于可信账本数据库的业务记录删除方法的流程示意图；

图3是本说明书提供的一种重要业务记录的存在性验证方法的流程示意图；

图4是本说明书实施例提供的一种基于可信账本数据库的业务记录删除装置的结构示意图；

图5是本说明书提供的一种重要业务记录的存在性验证装置的结构示意图；

图6是本说明书提供的一种业务记录完整性验证装置的结构示意图；

图7是用于配置本说明书实施例方法的一种设备的结构示意图。

具体实施方式

图1是本说明书提供的一种基于可信账本数据库的数据存储系统示意图。如图1所示，数据存储系统包括中心化的数据库服务端与多个客户端。其中，数据库服务端负责维护可信账本数据库，每个客户端对应于一个企业级用户（机构），如企业级用户a、企业级用户b、企业级用户c，每个企业级用户自身又进一步对接一个或多个个人用户，例如个人用户甲、个人用户乙、个人用户丙、个人用户丁。

例如，外卖平台与电商平台分别作为用户在数据库服务端上进行注册，获得用户账户，并且，分别在自己的设备上安装数据库服务端提供的客户端，在客户端中登录用户账户，从而具有与数据库服务端进行数据交互的能力。

而外卖平台与电商品台又分别对接各自的大量个人用户。某个个人用户使用自己的手机上安装的外卖客户端购买一份外卖食品后，外卖平台的设备会生成一外卖订单记录（即外卖平台基于业务产生的业务数据），外卖平台会通过自己在数据库服务端注册的用户账户将订单记录封装成记录（类似于区块链领域的业务记录，本文所述的记录是适用于可信账本数据库存储的专用数据结构），将记录提交给数据库服务端，以便数据库服务端将记录封装成记录写入可信账本数据库进行存储。类似地，电商平台也会将基于电商业务产生的每个电商订单封装成记录提交给数据库服务端。

为了描述的方便，后文所述的用户是指数据库服务端所服务的企业级用户，后文所述的用户账户，是指企业级用户在数据库服务端注册的账户。

通常，一个用户向数据库服务端提交的业务记录的先后顺序体现了记录所封装的业务数据产生的先后顺序，而数据库服务端可以根据同一用户提交的业务记录的先后顺序，依次将各业务记录存入可信账本数据库，如此，在可信账本数据库中，对于同一用户提交的若干业务记录而言，通常是顺序靠前的业务记录的存证时间早于顺序靠后的业务记录存证的时间。

因此，某个用户如果出于节省存储费用的考虑，想要将产生时间过于久远的业务记录（这些历史业务记录封装的业务数据往往已不具有使用价值）从可信账本数据库中删除，则相当于请求数据库服务端将封装有这些历史业务记录的每个数据块进行删除。

需要说明的是，对于可信账本数据库中的每个数据块，该数据块的块头中通常包含块体中所有业务记录构成的梅克尔树的根哈希（用于确保本数据块内所有业务记录不可篡改），一旦数据块中的任一业务记录被删除，则该数据块也就失去了存证的意义。

还需要说明的是，可信账本数据库中先后相邻的数据块之间具有耦合性，后一个数据块的块头中携带有前一个数据块的块头对应的哈希值，因此，即便某个用户请求删除的多个历史业务记录仅涉及个别不连续的数据块，数据库服务端从操作层面，也只能选择从创世数据块开始连续向后删除数据块，直至实现将该用户请求删除的所有历史业务记录都从可信账本数据库中删除的效果为止。

此外，考虑到可信账本数据库中的第1个数据块（创世数据块）往往需要携带可信账本数据库的账本配置信息，因此，如果从可信账本数据库从创世数据块开始删除一串数据块（包括删除原创世数据块），则需要重新生成创世数据块。

重新生成的创世数据块可以包含原创世数据块携带的账本配置信息，以及包含删除的最后序位（第n个）的数据块对应的块哈希（以便与保留的第n+1个数据块携带的第n个数据块的块哈希匹配，从而保留第n+1个数据块与被删除的数据块之间的耦合性）。

另外，对于历史上有些比较重要的业务记录（本文称之为重要业务记录，重要的标准可以由用户决定，例如涉及交易金额比较大的业务记录可以被视为重要业务记录），用户是不想删除的，但是由于可信账本数据库中的业务记录是被封装成数据块并且按时序进行存储的，因此，如果要删除一些不重要的业务记录，就不得不把同一数据块中的重要业务记录也从可信账本数据库中删除。

为此，在本说明书的一个或多个实施例中，在删除数据块之前，将重要业务记录集合另行保存（由于可信账本数据库中业务记录的时序性，因此，无法将重要的业务记录再存回可信账本数据库，只能另行保存）。同时，为了保证另行保存的重要业务记录对于用户的可信性（用户担心数据库服务端篡改重要业务记录），可以在数据库服务端在执行数据块删除之前，生成可信账本数据库的全局默克尔树，并且将全局默克尔树的根哈希返回给用户进行保管。如此，另行保存的重要业务记录虽然不在可信账本数据库中，但是由于全局默克尔树的存在，用户设备可以利用全局默克尔树的根哈希来验证重要的业务记录是否被数据库服务端篡改。

此外，也可以不预先生成全局默克尔树，而是按照各重要业务记录在所述可信账本数据库中的先后顺序，由先到后依次将所述重要业务记录集合中每个重要业务记录存入数据库服务端维护的其他可信账本数据库中。

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

以下结合附图，详细说明本说明书各实施例提供的技术方案。

图2是本说明书实施例提供的一种基于可信账本数据库的业务记录删除方法的流程示意图，包括如下步骤：

s200：接收用户设备发送的业务记录删除请求。

图2所示方法流程的执行主体是中心化的数据库服务端。数据库服务端不仅包括可信账本数据库，还包括其他可信账本数据库。可信账本数据库与其他可信账本数据库是相互独立的两个数据库，基于相同的存储方案。

在本说明书实施例中，业务记录删除请求可以不是业务记录这一数据结构，而是基于传统的客户端/服务端架构下，客户端向服务端发送的请求报文。数据库服务端对业务记录删除请求进行处理。

s202：根据所述业务记录删除请求，确定待删除数据块集合与待保留的重要业务记录集合。

在有些实施例中，业务记录删除请求中可以携带待删除数据块的序号范围[1，n]与每个待保留业务记录的记录标识。

再另一些实施例中，业务记录删除请求中可以携带待删除的每个业务记录的记录标识，数据库服务端据此确定待删除数据块集合与待保留的重要业务记录集合。

s208：在保存所述重要业务记录集合之后，从可信账本数据库中删除所述待删除数据块集合，并且，重新生成创世数据块。

数据库服务端可以将重要业务记录集合另行存储，需要说明的是，倘若用户对于重要业务记录有加密需求，数据库服务端可以将重要业务记录集合进行加密后存储。

进一步地，可以将重要业务记录集合中的每个重要业务记录，按照产生其在可信账本数据库中的存证先后顺序，依次另行存入数据库服务端维护的其他可信账本数据库。如此，相当于为用户另行开设了新的可信账本数据库，专用于存储从历史业务记录中保留下的重要业务记录。这种方式下，数据库服务端可以不需要在进行数据块删除之前构建可信账本数据库的全局默克尔树并返回给用户根哈希。

数据库服务端在删除数据块之前，可以先对待删除的1-n数据块进行完整性验证（即通过复盘业务记录的方式，将第1-第n个数据块重新推演一次，确保数据块内部各业务记录的耦合性以及数据块之间耦合性），确认无误后，再进行删除。

重新生成的创世数据块中包含原创世数据块携带的账本配置信息与第n个待删除数据块对应的块哈希。原创世数据块是指被删除的序号为1的数据块。

此处需要说明的是，账本配置信息可以是指与账本配置有关的任何信息。例如创建账本的账本创建业务记录，其中包含账本创建时间、账本创建方标识等信息。数据块对应的块哈希，一般是指对数据块的块头进行哈希计算得到的哈希值。

在本说明书实施例中，可以将重新生成的创世数据块存储至删除的第n个数据块原本所在的存储位置（即拼接到第n+1个数据块之前）。

通过本说明书实施例，可以在从可信账本数据库中删除历史数据块的情况下，依然不破坏可信账本数据库的可用性。

业务记录在可信账本数据库中的存储位置，具体可以是指业务记录所在的数据块的序号（或称块高）以及业务记录在数据块中的具体位置（即偏移量offset）。

另外，在本说明书实施例中，可以将重新生成的创世数据块对应的块哈希写入块删除业务记录对应的业务记录日志，并且将块删除业务记录与相应的业务记录日志一并写入可信账本数据库。这种情况下，可以不需要将重新生成的创世数据块拼接到第n+1个数据块之前，而是另行存储，根据所述业务记录日志可以查询到重新生成的创世数据块。

另外，在可信账本数据库场景下，每个用户账户可以有相应的状态，例如，每个用户账户的权限可能会频繁变动，每次变动都意味着用户账户对应的状态发生改变。又如，每个用户账户可以有资金余额，用户账户发起业务记录需要消耗余额，如此，用户账户对应的资金余额状态也会发生变化。

所有用户账户对应的状态信息的集合被称为世界状态。账本中的每个数据库都对应于一个世界状态。

在可信账本数据库场景下，通常并不会专门记录每个用户账户对应的状态信息，在可信账本数据库完整的情况下，可以通过账本溯源的方式，从第一个数据块复盘业务记录，推导出每个数据块对应的世界状态。

而在图2所示的方法流程中，如果删除了第1-第n的数据块，则意味着无法通过复盘业务记录的方式来推导出第1-第n个数据块分别对应的世界状态。为此，可以将第1-第n个数据块分别对应的世界状态信息写入重新生成的创世数据块，从而实现了对世界状态信息的保留。或者，可以仅将第n个数据块对应的世界状态信息写入重新生成的创世数据块，从而可以证明被删除的前n个数据块的世界状态与第n+1个数据块的世界状态耦合，未被篡改。

另外，在本说明书的有些实施例中，为可信账本数据库配置关联的状态树，状态树用于针对每个业务关键词，动态记录可信账本数据库中存储的该业务关键词对应的业务记录的数量。由于状态树是在每次向账本中写入数据块时进行更新的，而数据块成块就意味着数据块中的业务记录必然会存入账本，因此，相当于每个数据块都对应有一个状态树，表明该数据块成块时的世界状态（即各业务关键词对应的被账本存储的业务记录的数量）。而又由于每个数据块中携带有对应的状态树的根哈希，因此，可以确保对应的状态树不可篡改，从状态树中读取的某个业务关键词对应的已存储业务记录的数量是可信的。

具体而言，是这样实现：

所述数据库服务端还维护有状态树；针对所述状态树中每个叶子节点，该叶子节点对应的键key为一个业务关键词，该叶子节点对应的值value为包含该业务关键词的业务记录的数量；不同叶子节点对应于不同的key；所述数据库服务端每当向所述可信账本数据库中写入数据块时，更新所述状态树，并将更新后的状态树根哈希写入所述数据块。

进一步地，所述重新生成的创世数据块中还包含第n个待删除数据块携带的状态树根哈希；或者所述重新生成的创世数据块中还包含第1~n个待删除数据块分别对应的状态树。

相应地，可以采用如下方式验证业务记录的完整性：

获取用户设备发送的完整性验证请求；所述完整性验证请求包含所述用户设备指定的业务关键词；执行业务记录统计操作，以便从可信账本数据库中统计包含所述业务关键词的业务记录的第一数量；基于创世数据块对应的状态树，确定以所述业务关键词为key的叶子节点对应的value，作为第二数量；以及，基于最后一个数据块对应的状态树，确定以所述业务关键词为key的叶子节点对应的value，作为第三数量；计算第三数量与第二数量的差值，作为第四数量；判断所述第一数量与所述第四数量是否一致，若判断结果为是，则向所述用户设备返回验证成功结果。此外，若判断结果为否，则重新执行业务记录统计操作。

图3是本说明书提供的一种重要业务记录的存在性验证方法的流程示意图，包括如下步骤：

s300：从数据库服务端获取待验证的重要业务记录，并计算所述重要业务记录的记录哈希。

图3所示方法应用于用户设备。用户如果担心数据库服务端篡改另行保存的重要业务记录，则可以基于图3所示的方法流程验证业务记录的存在性。

业务记录的存在性是指，业务记录虽然被从可信账本数据库中删除了，但是业务记录依然锚定在可信账本数据库中，这种锚定性体现在，倘若业务记录被篡改，那么可信账本数据库的全局默克尔树的根哈希就会发生变动。

s302：将所述重要记录的记录哈希发送给数据库服务端，并接收所述数据库服务端返回对应于所述记录哈希的全局默克尔树路径。

全局默克尔树，是将可信账本数据库中的每个业务记录的记录哈希按照存证的时序顺序排列成叶子节点，基于叶子节点构建而成的。

对应于某个记录哈希的全局默克尔树路径，是指基于该记录哈希计算根哈希时，还需要获知的其他记录哈希组成的路径。

s304：基于所述重要记录的记录哈希与所述全局默克尔树路径，计算全局默克尔树的根哈希。

s306：将计算得到的根哈希与保存的根哈希进行比对，若一致，则确定所述重要业务记录通过存在性验证。

计算的根哈希与用户设备保存的根哈希（即数据库服务端在删除数据块之前返回给用户设备进行保存的全局默克尔树的根哈希）一致，则证明数据库服务端未篡改重要业务记录，通过了存在性验证。

此外，如果不一致，则证明数据库服务端篡改了重要业务记录，未通过存在性验证。

图4是本说明书实施例提供的一种基于可信账本数据库的业务记录删除装置的结构示意图，应用于数据库服务端，所述数据库服务端维护有可信账本数据库；预先基于所述可信账本数据库中的全部业务记录的记录哈希，构建全局默克尔树并保存，并将所述全局默克尔树的根哈希发送给用户设备进行保存；

所述装置包括：

接收模块401，接收用户设备发送的业务记录删除请求；

确定模块402，根据所述业务记录删除请求，确定待删除数据块集合与待保留的重要业务记录集合；所述待删除数据块集合包括序号为1至序号为n的n个待删除数据块，n＞1；

删除模块403，在保存所述重要业务记录集合之后，从可信账本数据库中删除所述待删除数据块集合，并且，重新生成创世数据块；其中，重新生成的创世数据块中包含原创世数据块携带的账本配置信息与第n个待删除数据块对应的块哈希。

图5是本说明书提供的一种重要业务记录的存在性验证装置的结构示意图，应用于用户设备，所述装置包括：

获取模块501，从数据库服务端获取待验证的重要业务记录，并计算所述重要业务记录的记录哈希；

发送接收模块502，将所述重要记录的记录哈希发送给数据库服务端，并接收所述数据库服务端返回对应于所述记录哈希的全局默克尔树路径；

计算模块503，基于所述重要记录的记录哈希与所述全局默克尔树路径，计算全局默克尔树的根哈希；

比对模块504，将计算得到的根哈希与保存的根哈希进行比对，若一致，则确定所述重要业务记录通过存在性验证。

图6是本说明书提供的一种业务记录完整性验证装置的结构示意图，应用于数据库服务端，包括：

获取模块601，获取用户设备发送的完整性验证请求；所述完整性验证请求包含所述用户设备指定的业务关键词；

执行模块602，执行业务记录统计操作，以便从可信账本数据库中统计包含所述业务关键词的业务记录的第一数量；

确定模块603，基于创世数据块对应的状态树，确定以所述业务关键词为key的叶子节点对应的value，作为第二数量；以及，基于最后一个数据块对应的状态树，确定以所述业务关键词为key的叶子节点对应的value，作为第三数量；

计算模块604，计算第三数量与第二数量的差值，作为第四数量；

判断处理模块605，判断所述第一数量与所述第四数量是否一致，若判断结果为是，则向所述用户设备返回验证成功结果。

本说明书实施例还提供一种计算机设备，其至少包括存储器、处理器及存储在存储器上并可在处理器上运行的计算机程序，其中，处理器执行所述程序时实现数据库服务端或用户设备的功能。

图7示出了本说明书实施例所提供的一种更为具体的计算设备硬件结构示意图，该设备可以包括：处理器1010、存储器1020、输入/输出接口1030、通信接口1040和总线1050。其中处理器1010、存储器1020、输入/输出接口1030和通信接口1040通过总线1050实现彼此之间在设备内部的通信连接。

处理器1010可以采用通用的cpu（centralprocessingunit，中央处理器）、微处理器、应用专用集成电路（applicationspecificintegratedcircuit，asic）、或者一个或多个集成电路等方式实现，用于执行相关程序，以实现本说明书实施例所提供的技术方案。

存储器1020可以采用rom（readonlymemory，只读存储器）、ram（randomaccessmemory，随机存取存储器）、静态存储设备，动态存储设备等形式实现。存储器1020可以存储操作系统和其他应用程序，在通过软件或者固件来实现本说明书实施例所提供的技术方案时，相关的程序代码保存在存储器1020中，并由处理器1010来调用执行。

输入/输出接口1030用于连接输入/输出模块，以实现信息输入及输出。输入输出/模块可以作为组件配置在设备中（图中未示出），也可以外接于设备以提供相应功能。其中输入设备可以包括键盘、鼠标、触摸屏、麦克风、各类传感器等，输出设备可以包括显示器、扬声器、振动器、指示灯等。

通信接口1040用于连接通信模块（图中未示出），以实现本设备与其他设备的通信交互。其中通信模块可以通过有线方式（例如usb、网线等）实现通信，也可以通过无线方式（例如移动网络、wifi、蓝牙等）实现通信。

总线1050包括一通路，在设备的各个组件（例如处理器1010、存储器1020、输入/输出接口1030和通信接口1040）之间传输信息。

需要说明的是，尽管上述设备仅示出了处理器1010、存储器1020、输入/输出接口1030、通信接口1040以及总线1050，但是在具体实施过程中，该设备还可以包括实现正常运行所必需的其他组件。此外，本领域的技术人员可以理解的是，上述设备中也可以仅包含实现本说明书实施例方案所必需的组件，而不必包含图中所示的全部组件。

本说明书实施例还提供一种计算机可读存储介质，其上存储有计算机程序，该程序被处理器执行时实现数据库服务端或用户设备的功能。

计算机可读介质包括永久性和非永久性、可移动和非可移动媒体可以由任何方法或技术来实现信息存储。信息可以是计算机可读指令、数据结构、程序的模块或其他数据。计算机的存储介质的例子包括，但不限于相变内存（pram）、静态随机存取存储器（sram）、动态随机存取存储器（dram）、其他类型的随机存取存储器（ram）、只读存储器（rom）、电可擦除可编程只读存储器（eeprom）、快闪记忆体或其他内存技术、只读光盘只读存储器（cd-rom）、数字多功能光盘（dvd）或其他光学存储、磁盒式磁带，磁带磁盘存储或其他磁性存储设备或任何其他非传输介质，可用于存储可以被计算设备访问的信息。按照本文中的界定，计算机可读介质不包括暂存电脑可读媒体（transitorymedia），如调制的数据信号和载波。

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

上述实施例阐明的系统、方法、模块或单元，具体可以由计算机芯片或实体实现，或者由具有某种功能的产品来实现。一种典型的实现设备为计算机，计算机的具体形式可以是个人计算机、膝上型计算机、蜂窝电话、相机电话、智能电话、个人数字助理、媒体播放器、导航设备、电子邮件收发设备、游戏控制台、平板计算机、可穿戴设备或者这些设备中的任意几种设备的组合。

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

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