主备数据库同步方法、主节点、备节点及存储介质

摘要

本申请提供了一种主备数据库同步方法、主节点、备节点及存储介质，该方法包括：在进行备数据库的全量备份时，若获取到对第一记录的第一操作请求，则判断能否对第一记录执行第一操作请求对应的操作；若确定能对第一记录执行第一操作请求对应的操作，则将第一记录的操作结果写入修改集中；在完成备数据库的全量备份之后或者在获取到停止备份指令之后，合并修改集和备数据库的引擎文件，以使主数据库和备数据库同步。从而无需停止备节点的进程，一方面，用户可以继续访问主备数据库。另一方面，即使主数据库出现异常情况，由于备数据库可以立即代替主数据库提供服务，从而可以防止用户数据丢失的情况。

说明书

技术领域

本申请实施例涉及数据库技术领域，尤其涉及主备数据库同步方法、主节点、备节点及存储介质。

背景技术

数据库备份包括：全量备份和增量备份。其中，全量备份也被称为全量数据物理备份。

目前，备数据库进行全量数据物理备份时，一方面，因为要进行备数据库的引擎文件的备份，因此，备数据库的引擎文件不能有变化，这时需要停止备数据库的进程，导致用户无法访问主备数据库。另一方面，在停止备数据库的进程时，如果主数据库出现异常情况，由于备数据库无法立即提供服务，可能导致用户数据丢失的情况。

发明内容

本申请提供一种主备数据库同步方法、主节点、备节点及存储介质，从而无需停止备节点的进程，一方面，用户可以继续访问主备数据库。另一方面，即使主数据库出现异常情况，由于备数据库可以立即代替主数据库提供服务，从而可以防止用户数据丢失的情况。

第一方面，本申请提供一种主备数据库同步方法，方法应用于备节点，方法包括：在进行备数据库的全量备份时，若获取到对第一记录的第一操作请求，则判断能否对第一记录执行第一操作请求对应的操作；若确定能对第一记录执行第一操作请求对应的操作，则将第一记录的操作结果写入修改集中；在完成备数据库的全量备份之后或者在获取到停止备份指令之后，合并修改集和备数据库的引擎文件，以使主数据库和备数据库同步。

第二方面，本申请提供一种主备数据库同步方法，方法应用于主节点，方法包括：在进行备数据库的全量备份时，若获取到对第一记录的第一操作请求，则判断能否对第一记录执行第一操作请求对应的操作；若确定能对第一记录执行第一操作请求对应的操作，则对第一记录执行第一操作请求对应的操作。

第三方面，本申请提供一种备节点，包括：通信单元和处理单元；处理单元用于：在进行备数据库的全量备份时，若通信单元获取到对第一记录的第一操作请求，则判断能否对第一记录执行第一操作请求对应的操作；若确定能对第一记录执行第一操作请求对应的操作，则将第一记录的操作结果写入修改集中；在完成备数据库的全量备份之后或者在获取到停止备份指令之后，合并修改集和备数据库的引擎文件，以使主数据库和备数据库同步。

第四方面，本申请提供一种主节点，包括：通信单元和处理单元；处理单元用于：在进行备数据库的全量备份时，若通信单元获取到对第一记录的第一操作请求，则判断能否对第一记录执行第一操作请求对应的操作；若确定能对第一记录执行第一操作请求对应的操作，则对第一记录执行第一操作请求对应的操作。

第五方面，提供了一种备节点，包括：处理器和存储器，该存储器用于存储计算机程序，该处理器用于调用并运行该存储器中存储的计算机程序，以执行第一方面的方法。

第六方面，提供了一种主节点，包括：处理器和存储器，该存储器用于存储计算机程序，该处理器用于调用并运行该存储器中存储的计算机程序，以执行第二方面的方法。

第七方面，提供了一种计算机可读存储介质，用于存储计算机程序，该计算机程序使得计算机执行第一方面或第二方面的方法。

综上，在本申请中，在全量备份时，或者在完成备数据库的全量备份之后，或者在获取到停止备份指令之后，备节点无需停止备节点的进程，基于此，也不会触发主节点停止对外服务。一方面，用户可以继续访问主备数据库。另一方面，即使主数据库出现异常情况，由于备数据库可以立即代替主数据库提供服务，从而可以防止用户数据丢失的情况。

附图说明

为了更清楚地说明本发明实施例中的技术方案，下面将对实施例描述中所需要使用的附图作简单地介绍，显而易见地，下面描述中的附图仅仅是本发明的一些实施例，对于本领域普通技术人员来讲，在不付出创造性劳动的前提下，还可以根据这些附图获得其他的附图。

图1为本申请实施例提供的系统架构图；

图2为本申请实施例提供的备节点或者备数据库的状态切换示意图；

图3为本申请实施例提供的一种主备数据库同步方法的流程图；

图4为本申请实施例提供的备份状态下的增加记录过程的示意图；

图5为本申请实施例提供的备份状态下的删除记录过程的示意图；

图6为本申请实施例提供的备份状态下的修改记录过程的示意图；

图7为本申请实施例提供的备份状态下的查询记录过程的示意图；

图8为本申请实施例提供的合并状态下的增加记录过程的示意图；

图9为本申请实施例提供的合并状态下的删除记录过程的示意图；

图10为本申请实施例提供的合并状态下的修改记录过程的示意图；

图11为本申请实施例提供的合并状态下的查询记录过程的示意图；

图12为本申请实施例提供的正常状态、备份状态和合并状态下的系统架构示意图；

图13为本申请实施例提供的一种备节点的示意图；

图14为本申请实施例提供的一种主节点的示意图；

图15是本申请实施例提供的备节点1500的示意性框图；

图16是本申请实施例提供的主节点1600的示意性框图。

具体实施方式

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

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

数据库（Database），简而言之可视为电子化的文件柜——存储电子文件的处所，用户可以对文件中的数据进行新增、查询、更新、删除等操作。所谓“数据库”是以一定方式储存在一起、能与多个用户共享、具有尽可能小的冗余度、与应用程序彼此独立的数据集合。

应理解的是，本申请涉及的数据可以存储在区块链中，但不限于此。

区块链是分布式数据存储、点对点传输、共识机制、加密算法等计算机技术的新型应用模式。区块链（Blockchain），本质上是一个去中心化的数据库，是一串使用密码学方法相关联产生的数据块，每一个数据块中包含了一批次网络交易的信息，用于验证其信息的有效性（防伪）和生成下一个区块。区块链可以包括区块链底层平台、平台产品服务层以及应用服务层。

区块链底层平台可以包括用户管理、基础服务、智能合约以及运营监控等处理模块。其中，用户管理模块负责所有区块链参与者的身份信息管理，包括维护公私钥生成（账户管理）、密钥管理以及用户真实身份和区块链地址对应关系维护（权限管理）等，并且在授权的情况下，监管和审计某些真实身份的交易情况，提供风险控制的规则配置（风控审计）；基础服务模块部署在所有区块链节点设备上，用来验证业务请求的有效性，并对有效请求完成共识后记录到存储上，对于一个新的业务请求，基础服务先对接口适配解析和鉴权处理（接口适配），然后通过共识算法将业务信息加密（共识管理），在加密之后完整一致的传输至共享账本上（网络通信），并进行记录存储；智能合约模块负责合约的注册发行以及合约触发和合约执行，开发人员可以通过某种编程语言定义合约逻辑，发布到区块链上（合约注册），根据合约条款的逻辑，调用密钥或者其它的事件触发执行，完成合约逻辑，同时还提供对合约升级注销的功能；运营监控模块主要负责产品发布过程中的部署、配置的修改、合约设置、云适配以及产品运行中的实时状态的可视化输出，例如：告警、监控网络情况、监控节点设备健康状态等。

平台产品服务层提供典型应用的基本能力和实现框架，开发人员可以基于这些基本能力，叠加业务的特性，完成业务逻辑的区块链实现。应用服务层提供基于区块链方案的应用服务给业务参与方进行使用。

如上所述，目前，备数据库进行全量数据物理备份时，一方面，因为要进行备数据库的引擎文件的备份，因此，备数据库的引擎文件不能有变化，这时需要停止备数据库的进程，导致用户无法访问主备数据库。另一方面，在停止备数据库的进程时，如果主数据库出现异常情况，由于备数据库无法立即提供服务，可能导致用户数据丢失的情况。

为了解决上述技术问题，本申请的发明构思是：在备数据库进行全量数据物理备份时，无需停止备数据库的进程，即用户可以正常访问主备数据库。那么在备数据库进行全量数据物理备份时，当不停止备数据库的进程时，如何保证主备数据库同步，尤其针对用户的增加、删除、修改等操作，如何保证主备数据库同步，是本申请重点要解决的问题。

示例性的，图1为本申请实施例提供的系统架构图，其中，本申请技术方案可以应用于如图1所示的系统架构中，如图1所示，用户可以通过客户端110访问主数据库120和备数据库130，应理解的是，在主数据库120处于正常状态时，用户通过客户端110可以对主数据库120中的数据进行增加、删除、修改和查询等操作，而备数据库130与主数据库120中的数据实时保持同步。在主数据库120处于异常状态时，备数据库130代替主数据库120，这时用户通过客户端110可以对备数据库130中的数据进行增加、删除、修改和查询等操作。

应理解的是，上述主数据库可以位于主节点中，该主节点可以是任何智能设备，例如：是主服务器，该服务器可以是一台云服务器。同理，上述备数据库可以位于备节点中，该备节点也可以是任何智能设备，例如：是备服务器，该服务器可以是另一台云服务器。

值得一提的是，在本申请中，为了实现主备数据库的数据同步，将备节点或者备数据库的状态分为如下几种情况：正常状态、备份状态和合并状态。

备份状态：备数据库在全量备份时，该备数据库或者备节点处于备份状态，当备数据库处于备份状态时，备节点可以将对任一记录的操作结果写入修改集中；即该修改集可以记录对任一记录的增加、删除和修改。

合并状态：在完成备数据库的全量备份之后或者在获取到停止备份指令之后，备节点可以合并修改集和备数据库的引擎文件，在该合并过程中，称备数据库或者备节点处于合并状态。

正常状态：除在备数据库的全量备份过程，和，修改集和备数据库的引擎文件的合并过程之外的其他过程中时，称备数据库或者备节点处于正常状态。

图2为本申请实施例提供的备节点或者备数据库的状态切换示意图，如图2所示，正常状态下，用户发起数据库全量备份指令后，备数据库进入“备份状态”；在“备份状态”下，用户可随时发起停止备份指令或当备份完成之后，这时备数据库将立刻进入“合并状态”；在“合并状态”下，备数据库对修改集和备数据库的引擎文件的合并，完成数据合并之后，备节点将删除“修改集”，自动进入“正常状态”。

应理解的是，在“备份状态”或“合并状态”下，当备节点收到备份请求时，将返回正在备份或者正在合并的指示信息。

应理解的是，在“正常状态”下，用户请求增加、删除、修改或者查询引擎文件时，可以采用现有技术，本申请对此不再赘述。而本申请重点将介绍的是在“备份状态”和“合并状态”下，用户请求增加、删除、修改或者查询引擎文件时，尤其针对增加、删除、修改操作，如何进行数据同步是本申请的重点。

下面将对本申请技术方案进行重点阐述：

图3为本申请实施例提供的一种主备数据库同步方法的流程图，该方法应用于备节点，如图3所示，该方法包括如下步骤：

S310：在进行备数据库的全量备份时，若获取到对第一记录的第一操作请求，则判断能否对第一记录执行第一操作请求对应的操作。

S320：若确定能对第一记录执行第一操作请求对应的操作，则将第一记录的操作结果写入修改集中。

S330：在完成备数据库的全量备份之后或者在获取到停止备份指令之后，合并修改集和备数据库的引擎文件，以使主数据库和备数据库同步。

可选的，第一操作请求为以下任一项：第一增加请求、第一删除请求、第一修改请求。相应的，备节点判断能否对第一记录执行第一操作请求对应的操作。例如：判断能否对第一记录执行第一增加请求对应的增加操作。判断能否对第一记录执行第一删除请求对应的删除操作。判断能否对第一记录执行第一修改请求对应的修改操作。

应理解的是，第一记录可以是任一记录。因此，备节点通过执行S310和S320之后，所形成的修改集具有如下特点：该修改集包括了需要增加、删除和修改的记录的操作结果。

应理解的是，对于任一记录，即上述第一记录而言，其第一记录的操作结果可以是第一记录本身，也开始是带有第一删除标记的第一记录，该第一删除标记表示在对修改集和备数据库的引擎文件进行合并时，需要删除第一记录。

可选的，备节点可以启用一个线程，用于拷贝备数据库的引擎文件，以实现备数据库的全量备份。

应理解的是，如上所述，备节点或者备数据库的状态被划分为3个状态，即正常状态、备份状态和合并状态，而在任何状态下，引擎接口层对外暴露的增加、删除、修改和查询语义均相同，备节点在引擎接口层针对不同状态，对底层的备数据库的引擎文件进行不同的操作，以达到在全量备份时，不影响数据库的对外服务。基于此，在备份状态下，用户请求通过引擎接口层来执行增加、删除、修改和查询操作。如果用户请求需要两级算法以实现对应服务，那么备节点可以在引擎接口层合并修改集和备节点的引擎文件，并将合并结果返回给用户，以使用户根据该合并结果进行两级算法中的第二级算法。

可选的，在完成备数据库的全量备份之后或者在获取到停止备份指令之后，可以通过如下方式合并修改集和备数据库的引擎文件，但不限于此：对于修改集中记录的需要删除的记录，在合并修改集和备数据库的引擎文件时，从备数据库中删除该需要删除的记录。对于修改集中记录的需要增加的记录，在合并修改集和备数据库时，在备数据库中增加该需要增加的记录。对于修改集中记录的需要修改的记录，在合并修改集和备数据库时，对备数据库中将需要修改的记录更新为修改后的记录。即遍历修改集的每条记录，并判断是否带有删除标记：若带有删除标记，则将记录从修改集和备节点的引擎文件中都删除，若不带删除标记，则将记录从修改集删除，并写回备节点的引擎文件。直到修改集中没有记录，则完成合并流程，此时删除整个修改集，备数据库回归正常状态。

可选的，在完成备数据库的全量备份之后或者在获取到停止备份指令之后，备节点可以删除该修改集。

应理解的是，在本申请中，在全量备份时，或者在完成备数据库的全量备份之后，或者在获取到停止备份指令之后，备节点无需停止备节点的进程，基于此，也不会触发主节点停止对外服务。示例性的，在进行备数据库的全量备份时，若主节点获取到对第一记录的第一操作请求，则主节点判断能否对第一记录执行第一操作请求对应的操作。若确定能对第一记录执行第一操作请求对应的操作，则主节点对第一记录执行第一操作请求对应的操作。

需要说明的是，本申请对主节点如何对第一记录执行第一操作请求对应的操作不做限制。

总之，主节点在任何时候都可以采用正常状态下的实现方式对记录进行增加、删除或者修改操作。而备节点在进行全量备份时，其不影响引擎文件的正常备份，只是将对记录的操作结果先记录至修改集中，最后，在全量备份完毕之后，或者获取到停止备份指令之后，只需合并修改集合备节点的引擎文件，以使主数据库和备数据库同步。

由于采用本申请技术方案，需要停止备数据库的进程，因此，一方面，用户可以继续访问主备数据库。另一方面，即使主数据库出现异常情况，由于备数据库可以立即代替主数据库提供服务，从而可以防止用户数据丢失的情况。

如上所述，增加、删除和修改会改变数据库，因此，对于这三种操作，主备数据库同步至关重要，下面将通过三个示例分别对增加记录、删除记录和修改记录过程进行说明：

示例1：图4为本申请实施例提供的备份状态下的增加记录过程的示意图，该过程由备节点执行，如图4所示，该增加记录过程包括如下步骤：

S410：判断是否从修改集中读取第一记录成功。若从修改集对第一记录读取成功，则执行S420；否则，则执行S450。

S420：判断修改集中的第一记录是否带有第一删除标记，若修改集中的第一记录带有第一删除标记，则执行S430；否则，则执行S440。

S430：确定能对第一记录执行第一增加请求对应的增加操作，并删除修改集中的第一记录的第一删除标记。

S440：确定不能对第一记录执行第一增加请求对应的增加操作。

S450：判断是否从备数据库的引擎文件中读取第一记录成功。若从备数据库的引擎文件对第一记录读取成功，则执行S460；否则，则执行S470。

S460：确定不能对第一记录执行第一增加请求对应的增加操作。

S470：确定能对第一记录执行第一增加请求对应的增加操作，并将第一记录写入修改集中。

例如：第一记录是A=2，如果A=2从修改集中读取成功。判断修改集中的A=2是否带有第一删除标记，若修改集中的A=2带有第一删除标记，则删除修改集中的A=2的第一删除标记。即表示在合并修改集和备数据库的引擎文件时，需要将该A=2增加至该引擎文件中。若修改集中的A=2未带有第一删除标记，则表示A=2，已经被标注为在合并修改集和备数据库的引擎文件时，需要将该A=2增加至该引擎文件中，即A=2已存在，无需再增加该记录。如果A=2从修改集中读取失败，但是从备数据库的引擎文件中读取成功，表示备数据库的引擎文件中已经存在A=2的记录，因此无需再增加该记录。如果A=2从修改集中读取失败，但是从备数据库的引擎文件中也读取失败，可以A=2写入修改集中，表示在合并修改集和备数据库的引擎文件时，需要将该A=2增加至该引擎文件中。

示例2：图5为本申请实施例提供的备份状态下的删除记录过程的示意图，该过程由备节点执行，如图5所示，该删除记录过程包括如下步骤：

S510：判断是否从修改集中读取第一记录成功。若从修改集对第一记录读取成功，则执行S520；否则，则执行S550。

S520：判断修改集中的第一记录是否带有第一删除标记，若修改集中的第一记录带有第一删除标记，则执行S530；否则，则执行S540。

S530：确定不能对第一记录执行第一删除请求对应的删除操作。

S540：确定能对第一记录执行第一删除请求对应的删除操作，并向修改集中的第一记录添加第一删除标记。

S550：判断是否从备数据库的引擎文件中读取第一记录成功。若从备数据库的引擎文件对第一记录读取成功，则执行S560；否则，则执行S570。

S560：确定能对第一记录执行第一删除请求对应的删除操作，向修改集写入带有第一删除标记的第一记录。

S570：确定不能对第一记录执行第一删除请求对应的删除操作。

例如：第一记录是A=2，如果A=2从修改集中读取成功。判断修改集中的A=2是否带有第一删除标记，若修改集中的A=2带有第一删除标记，则表示在合并修改集和备数据库的引擎文件时，该A=2需要被删除。这种情况下，由于A=2已经被标注为在合并修改集和备数据库的引擎文件时，需要将A=2删除，因此，无需再删除A=2。如果A=2从修改集中读取成功。若修改集中的A=2没有带第一删除标记。这种情况下，备节点可以向修改集中的A=2添加第一删除标记。如果A=2从修改集中读取失败，但是从备节点的引擎文件读取成功，则向修改集写入带有第一删除标记的A=2。如果A=2从修改集中读取失败，从备节点的引擎文件也读取失败，说明修改集和引擎文件中均没有A=2，这种情况下，可以指示A=2不存在。

示例3：图6为本申请实施例提供的备份状态下的修改记录过程的示意图，该过程由备节点执行，如图6所示，该修改记录过程包括如下步骤：

S610：判断是否从修改集中读取第一记录成功。若从修改集对第一记录读取成功，则执行S620；否则，则执行S650。

S620：判断修改集中的第一记录是否带有第一删除标记，若修改集中的第一记录带有第一删除标记，则执行S630；否则，则执行S640。

S630：确定不能对第一记录执行第一修改请求对应的修改操作。

S640：确定能对第一记录执行第一修改请求对应的修改操作，并修改修改集中的第一记录。

S650：判断是否从备数据库的引擎文件中读取第一记录成功。若从备数据库的引擎文件对第一记录读取成功，则执行S660；否则，则执行S670。

S660：确定能对第一记录执行第一修改请求对应的修改操作，并向修改集写入第一记录对应的修改后的记录。

S670：确定不能对第一记录执行第一修改请求对应的修改操作。

例如：第一记录是A=2，如果A=2从修改集中读取成功。判断修改集中的A=2是否带有第一删除标记，若修改集中的A=2带有第一删除标记，则表示在合并修改集和备数据库的引擎文件时，该A=2需要被删除。这种情况下，由于A=2已经被标注为在合并修改集和备数据库的引擎文件时，需要将A=2删除，因此，不能再对A=2进行修改。如果A=2从修改集中读取成功。若修改集中的A=2没有带第一删除标记。这种情况下，备节点可以将A=2修改为A=3。如果A=2从修改集中读取失败，但是从备节点的引擎文件读取成功，则向修改集写入修改后的记录A=3。如果A=2从修改集中读取失败，从备节点的引擎文件也读取失败，说明修改集和引擎文件中均没有A=2，这种情况下，可以指示A=2不存在。

通过上述3个示例可知，在备份状态下，备节点获取到用户的增加、删除和修改请求之后，备节点只需要将第一记录的操作结果记录至修改集中，而备节点的引擎文件不做修改。

综上，在备节点或者备数据库的备份状态下，备节点可以执行如上的增加、删除和修改记录过程，以将第一记录的操作结果记录至修改集中。使得在全量备份完毕之后，或者获取到停止备份指令之后，只需合并修改集合备节点的引擎文件，来实现主数据库和备数据库的同步。

应理解的是，用户还可以查询记录，下面以用户查询第二记录为例，对记录查询过程进行示例性说明，其中该第二记录可以与上述第一记录相同，也可以不同，本申请对此不做限制：

示例4：图7为本申请实施例提供的备份状态下的查询记录过程的示意图，该过程由备节点执行，如图7所示，该查询记录过程包括如下步骤：

S710：判断是否从修改集中读取第二记录成功。若从修改集对第二记录读取成功，则执行S720；否则，则执行S750。

S720：判断修改集中的第二记录是否带有第二删除标记，若修改集中的第二记录带有第二删除标记，则执行S730；否则，则执行S740。

S730：返回第二记录不存在的结果。

S740：返回第二记录。

S750：判断是否从备数据库的引擎文件中读取第二记录成功。若从备数据库的引擎文件对第二记录读取成功，则执行S760；否则，则执行S770。

S760：返回第二记录。

S770：返回第二记录不存在的结果。

其中，第二删除标记表示在对修改集和备数据库的引擎文件进行合并时，需要删除第二记录。

例如：第二记录是A=3，如果A=3从修改集中读取成功。判断修改集中的A=3是否带有第二删除标记，若修改集中的A=3带有第二删除标记，则表示在合并修改集和备数据库的引擎文件时，该A=3需要被删除。这种情况下，由于A=3已经被标注为在合并修改集和备数据库的引擎文件时，需要将A=3删除，因此，在合并集合之后，该A=3无法被查询到。如果A=3从修改集中读取成功。若修改集中的A=3没有带第二删除标记。这种情况下，返回A=3。如果A=3从修改集中读取失败，但是从备节点的引擎文件读取成功，则返回A=3。如果A=3从修改集中读取失败，从备节点的引擎文件也读取失败，说明修改集和引擎文件中均没有A=3，这种情况下，可以指示A=3不存在。

应理解的是，在备份状态下，备节点可以从自身的引擎文件中查询记录。

应理解的是，针对主节点，在进行备数据库的全量备份时，若主节点获取到对第二记录的第一查询请求，则从主数据库的引擎文件查询第二记录。如果对第二记录查询成功，则主节点可以向用户返回查询到的第二记录。

下面将通过三个示例分别对合并状态下的增加记录、删除记录和修改记录过程进行说明：

应理解的是，下面是以第三记录的增加、删除和修改做示例的，其对应的请求操作分别为第二增加请求、第二删除请求、第二修改请求。

示例5：图8为本申请实施例提供的合并状态下的增加记录过程的示意图，该过程由备节点执行，如图8所示，该增加记录过程包括如下步骤：

S810：判断是否从修改集中读取第三记录成功。若从修改集对第三记录读取成功，则执行S820；否则，则执行S850。

S820：判断修改集中的第三记录是否带有第三删除标记，若修改集中的第三记录带有第三删除标记，则执行S830；否则，则执行S840。

S830：确定能对第三记录执行第二增加请求对应的增加操作，并删除修改集中的第三记录，将第三记录写入备数据库的引擎文件中。

S840：确定不能对第三记录执行第二增加请求对应的增加操作。

S850：判断是否从备数据库的引擎文件中读取第三记录成功。若从备数据库的引擎文件对第三记录读取成功，则执行S860；否则，则执行S870。

S860：确定不能对第三记录执行第二增加请求对应的增加操作。

S870：确定能对第三记录执行第二增加请求对应的增加操作，并将第三记录写入备数据库的引擎文件中。

例如：第三记录是A=2，如果A=2从修改集中读取成功。判断修改集中的A=2是否带有第三删除标记，若修改集中的A=2带有第三删除标记，则删除修改集中的A=2，将A=2写入备数据库的引擎文件中。若修改集中的A=2未带有第三删除标记，则表示A=2，已经被标注为在合并修改集和备数据库的引擎文件时，需要将该A=2增加至该引擎文件中，即A=2已存在，无需再增加该记录。如果A=2从修改集中读取失败，但是从备数据库的引擎文件中读取成功，表示备数据库的引擎文件中已经存在A=2的记录，因此无需再增加该记录。如果A=2从修改集中读取失败，但是从备数据库的引擎文件中也读取失败，可以A=2写入修改集中，表示在合并修改集和备数据库的引擎文件时，需要将该A=2增加至该引擎文件中。

示例6：图9为本申请实施例提供的合并状态下的删除记录过程的示意图，该过程由备节点执行，如图9所示，该删除记录过程包括如下步骤：

S910：判断是否从修改集中读取第三记录成功。若从修改集对第三记录读取成功，则执行S920；否则，则执行S950。

S920：判断修改集中的第三记录是否带有第三删除标记，若修改集中的第三记录带有第三删除标记，则执行S930；否则，则执行S940。

S930：确定不能对第三记录执行第二删除请求对应的删除操作。

S940：确定能对第三记录执行第二删除请求对应的删除操作，并从修改集和备数据库的引擎文件中删除第三记录。

S950：判断是否从备数据库的引擎文件中读取第三记录成功。若从备数据库的引擎文件对第三记录读取成功，则执行S960；否则，则执行S970。

S960：确定能对第三记录执行第二删除请求对应的删除操作，从备数据库的引擎文件中删除第三记录。

S970：确定不能对第三记录执行第二删除请求对应的删除操作。

例如：第三记录是A=2，如果A=2从修改集中读取成功。判断修改集中的A=2是否带有第三删除标记，若修改集中的A=2带有第三删除标记，则表示在合并修改集和备数据库的引擎文件时，该A=2需要被删除。这种情况下，由于A=2已经被标注为在合并修改集和备数据库的引擎文件时，需要将A=2删除，因此，无需再删除A=2。如果A=2从修改集中读取成功。若修改集中的A=2没有带第三删除标记。这种情况下，备节点可以从修改集和备数据库的引擎文件中删除A=2。如果A=2从修改集中读取失败，但是从备节点的引擎文件读取成功，则从备数据库的引擎文件中删除A=2。如果A=2从修改集中读取失败，从备节点的引擎文件也读取失败，说明修改集和引擎文件中均没有A=2，这种情况下，可以指示A=2不存在。

示例7：图10为本申请实施例提供的合并状态下的修改记录过程的示意图，该过程由备节点执行，如图10所示，该修改记录过程包括如下步骤：

S1010：判断是否从修改集中读取第三记录成功。若从修改集对第三记录读取成功，则执行S1020；否则，则执行S1050。

S1020：判断修改集中的第三记录是否带有第三删除标记，若修改集中的第三记录带有第三删除标记，则执行S1030；否则，则执行S1040。

S1030：确定不能对第三记录执行第二修改请求对应的修改操作。

S1040：确定能对第三记录执行第二修改请求对应的修改操作，并从修改集中删除第三记录，并修改备数据库的引擎文件中的第三记录。

S1050：判断是否从备数据库的引擎文件中读取第三记录成功。若从备数据库的引擎文件对第三记录读取成功，则执行S1060；否则，则执行S1070。

S1060：确定能对第三记录执行第二修改请求对应的修改操作，并从备数据库的引擎文件中删除第三记录，并将第三记录对应的修改后的记录写入备数据库的引擎文件中。

S1070：确定不能对第三记录执行所述第二修改请求对应的修改操作。

例如：第三记录是A=2，如果A=2从修改集中读取成功。判断修改集中的A=2是否带有第三删除标记，若修改集中的A=2带有第三删除标记，则表示在合并修改集和备数据库的引擎文件时，该A=2需要被删除。这种情况下，由于A=2已经被标注为在合并修改集和备数据库的引擎文件时，需要将A=2删除，因此，不能再对A=2进行修改。如果A=2从修改集中读取成功。若修改集中的A=2没有带第三删除标记。这种情况下，备节点可以从修改集中删除A=2，并修改备数据库的引擎文件中的A=2，例如：将A=2修改为A=3。如果A=2从修改集中读取失败，但是从备节点的引擎文件读取成功，则从备数据库的引擎文件中删除A=2，并将A=2对应的修改后的记录A=3写入备数据库的引擎文件中。如果A=2从修改集中读取失败，从备节点的引擎文件也读取失败，说明修改集和引擎文件中均没有A=2，这种情况下，可以指示A=2不存在。

通过上述3个示例可知，在合并状态下，备节点获取到用户的增加、删除和修改请求之后，备节点只能在修改集中对第三记录进行删除，而不能进行增加和修改。

综上，在备节点或者备数据库的合并状态下，备节点可以执行如上的增加、删除和修改记录过程，以实现主数据库和备数据库的同步。

应理解的是，用户还可以查询记录，下面以用户查询第四记录为例，对记录查询过程进行示例性说明，其中该第四记录可以与上述第三记录相同，也可以不同，本申请对此不做限制：

示例8：图11为本申请实施例提供的合并状态下的查询记录过程的示意图，该过程由备节点执行，如图11所示，该查询记录过程包括如下步骤：

S1110：判断是否从修改集中读取第四记录成功。若从修改集对第四记录读取成功，则执行S1120；否则，则执行S1150。

S1120：判断修改集中的第四记录是否带有第四删除标记，若修改集中的第四记录带有第四删除标记，则执行S1130；否则，则执行S1140。

S1130：返回第四记录不存在的结果。

S1140：返回第四记录。

S1150：判断是否从备数据库的引擎文件中读取第四记录成功。若从备数据库的引擎文件对第四记录读取成功，则执行S1160；否则，则执行S1170。

S1160：返回第四记录。

S1170：返回第四记录不存在的结果。

其中，第四删除标记表示在对修改集和备数据库的引擎文件进行合并时，需要删除第四记录。

例如：第四记录是A=3，如果A=3从修改集中读取成功。判断修改集中的A=3是否带有第四删除标记，若修改集中的A=3带有第四删除标记，则表示在合并修改集和备数据库的引擎文件时，该A=3需要被删除。这种情况下，由于A=3已经被标注为在合并修改集和备数据库的引擎文件时，需要将A=3删除，因此，在合并集合之后，该A=3无法被查询到。如果A=3从修改集中读取成功。若修改集中的A=3没有带第四删除标记。这种情况下，返回A=3。如果A=3从修改集中读取失败，但是从备节点的引擎文件读取成功，则返回A=3。如果A=3从修改集中读取失败，从备节点的引擎文件也读取失败，说明修改集和引擎文件中均没有A=3，这种情况下，可以指示A=3不存在。

应理解的是，针对主节点，在进行备数据库的全量备份时，若主节点获取到对第四记录的第二查询请求，则从主数据库的引擎文件查询第四记录。如果对第四记录查询成功，则主节点可以向用户返回查询到的第四记录。

下面将对正常状态、备份状态和合并状态下的系统架构进行说明：

图12为本申请实施例提供的正常状态、备份状态和合并状态下的系统架构示意图，如图12所示，备节点或者备数据库的状态被划分为3个状态，即正常状态、备份状态和合并状态，而在任何状态下，引擎接口层对外暴露的增加、删除、修改和查询语义均相同，备节点在引擎接口层针对不同状态，对底层的备数据库的引擎文件进行不同的操作，以达到在全量备份时，不影响数据库的对外服务。而在正常状态下，备节点通过引擎接口层对备节点的引擎文件进行增加、删除、修改和查询操作。在备份状态下，备节点通过引擎接口层可以对修改集进行增加、删除、修改和查询操作，但是也可以在引擎文件中进行记录查询，而该引擎文件可以被理解为静态引擎文件，即它的备份过程可以通过开启的一线程执行。当备份完毕或者收到停止备份的指令时，备节点或者备数据库进入合并状态，在合并状态下，备节点通过引擎接口层可以对修改集进行删除和查询操作，可以对引擎文件进行增加、删除、修改和查询操作。

综上，在本申请中，在全量备份时，或者在完成备数据库的全量备份之后，或者在获取到停止备份指令之后，备节点无需停止备节点的进程，基于此，也不会触发主节点停止对外服务。总之，主节点在任何时候都可以采用正常状态下的实现方式对记录进行增加、删除、修改和查询操作。而备节点在进行全量备份时，其不影响引擎文件的正常备份，只是将对记录的操作结果先记录至修改集中，最后，在全量备份完毕之后，或者获取到停止备份指令之后，只需合并修改集合备节点的引擎文件，以使主数据库和备数据库同步。一方面，用户可以继续访问主备数据库。另一方面，即使主数据库出现异常情况，由于备数据库可以立即代替主数据库提供服务，从而可以防止用户数据丢失的情况。

值得一提的是，本申请所提供的主备数据库同步方法也可以应用于主节点，即进行主数据库的全量备份，相应的，主节点侧需要建立修改集，以记录增加、删除、修改等操作记录，最后主节点对该修改集和自身的引擎文件进行合并，以实现主备数据库的同步。

图13为本申请实施例提供的一种备节点的示意图，如图13所示，该备节点包括：通信单元1310和处理单元1320。

处理单元1320用于：在进行备数据库的全量备份时，若通信单元1310获取到对第一记录的第一操作请求，则判断能否对第一记录执行第一操作请求对应的操作。若确定能对第一记录执行第一操作请求对应的操作，则将第一记录的操作结果写入修改集中。在完成备数据库的全量备份之后或者在获取到停止备份指令之后，合并修改集和备数据库的引擎文件，以使主数据库和备数据库同步。

可选的，第一操作请求为以下任一项：第一增加请求、第一删除请求、第一修改请求。

可选的，在第一操作请求是第一增加请求时，处理单元1320具体用于：从修改集中读取第一记录。若从修改集对第一记录读取成功，则判断修改集中的第一记录是否带有第一删除标记，第一删除标记表示在对修改集和备数据库的引擎文件进行合并时，需要删除第一记录。若修改集中的第一记录带有第一删除标记，则确定能对第一记录执行第一增加请求对应的增加操作。若修改集中的第一记录未带第一删除标记，则确定不能对第一记录执行第一增加请求对应的增加操作。若从修改集对第一记录读取失败，则从备数据库的引擎文件中读取第一记录。若从备数据库的引擎文件对第一记录读取成功，则确定不能对第一记录执行第一增加请求对应的增加操作。若从备数据库的引擎文件对第一记录读取失败，则确定能对第一记录执行第一增加请求对应的增加操作。

可选的，在第一操作请求是第一增加请求时，处理单元1320具体用于：若修改集中的第一记录带有第一删除标记，则删除修改集中的第一记录的第一删除标记。若从备数据库的引擎文件对第一记录读取失败，则将第一记录写入修改集中。

可选的，在第一操作请求是第一删除请求时，处理单元1320具体用于：从修改集中读取第一记录。若从修改集对第一记录读取成功，则判断修改集中的第一记录是否带有第一删除标记，第一删除标记表示在对修改集和备数据库的引擎文件进行合并时，需要删除第一记录。若修改集中的第一记录带有第一删除标记，则确定不能对第一记录执行第一删除请求对应的删除操作。若修改集中的第一记录未带第一删除标记，则确定能对第一记录执行第一删除请求对应的删除操作。若从修改集对第一记录读取失败，则从备数据库的引擎文件中读取第一记录。若从备数据库的引擎文件对第一记录读取成功，则确定能对第一记录执行第一删除请求对应的删除操作。若从备数据库的引擎文件对第一记录读取失败，则确定不能对第一记录执行第一删除请求对应的删除操作。

可选的，在第一操作请求是第一删除请求时，处理单元1320具体用于：若修改集中的第一记录未带第一删除标记，则向修改集中的第一记录添加第一删除标记。若从备数据库的引擎文件对第一记录读取成功，则向修改集写入带有第一删除标记的第一记录。

可选的，在第一操作请求是第一修改请求时，处理单元1320具体用于：从修改集中读取第一记录。若从修改集对第一记录读取成功，则判断修改集中的第一记录是否带有第一删除标记，第一删除标记表示在对修改集和备数据库的引擎文件进行合并时，需要删除第一记录。若修改集中的第一记录带有第一删除标记，则确定不能对第一记录执行第一修改请求对应的修改操作。若修改集中的第一记录未带第一删除标记，则确定能对第一记录执行第一修改请求对应的修改操作。若从修改集对第一记录读取失败，则从备数据库的引擎文件中读取第一记录。若从备数据库的引擎文件对第一记录读取成功，则确定能对第一记录执行第一修改请求对应的修改操作。若从备数据库的引擎文件对第一记录读取失败，则确定不能对第一记录执行第一修改请求对应的修改操作。

可选的，在第一操作请求是第一修改请求时，处理单元1320具体用于：若修改集中的第一记录未带第一删除标记，则修改修改集中的第一记录。若从备数据库的引擎文件对第一记录读取成功，则向修改集写入第一记录对应的修改后的记录。

可选的，处理单元1320还用于在进行备数据库的全量备份时，若通信单元1310获取到对第二记录的第一查询请求，则从修改集中读取第二记录。若对第二记录从修改集读取成功，则判断修改集中的第二记录是否带有第二删除标记，第二删除标记表示在对修改集和备数据库的引擎文件进行合并时，需要删除第二记录。若修改集中的第二记录带有第二删除标记，则返回第二记录不存在的结果。若修改集中的第二记录未带第二删除标记，则返回第二记录。若从修改集对第二记录读取失败，则从备数据库的引擎文件中读取第二记录。若从备数据库的引擎文件对第二记录读取成功，则返回第二记录。若从备数据库的引擎文件对第二记录读取失败，则返回第二记录不存在的结果。

可选的，处理单元1320还用于在合并修改集和备数据库的引擎文件时，若通信单元1310获取到对第三记录的第二操作请求，则判断能否对第三记录执行第二操作请求对应的操作。若确定能对第三记录执行第二操作请求对应的操作，则对第三记录执行第二操作请求对应的操作。

可选的，第二操作请求为以下任一项：第二增加请求、第二删除请求、第二修改请求。

可选的，在第二操作请求是第二增加请求时，处理单元1320具体用于：从修改集中读取第三记录。若从修改集对第三记录读取成功，则判断修改集中的第三记录是否带有第三删除标记，第三删除标记表示在合并修改集和备数据库的引擎文件时，需要删除第三记录。若修改集中的第三记录带有第三删除标记，则确定能对第三记录执行第二增加请求对应的增加操作。若修改集中的第三记录未带第三删除标记，则确定不能对第三记录执行第二增加请求对应的增加操作。若从修改集对第三记录读取失败，则从备数据库的引擎文件中读取第三记录。若从备数据库的引擎文件对第三记录读取成功，则确定不能对第三记录执行第二增加请求对应的增加操作。若从备数据库的引擎文件对第三记录读取失败，则确定能对第三记录执行第二增加请求对应的增加操作。

可选的，在第二操作请求是第二增加请求时，处理单元1320具体用于：若修改集中的第三记录带有第三删除标记，则删除修改集中的第三记录，并将第三记录写入备数据库的引擎文件中。若从备数据库的引擎文件对第三记录读取失败，则将第三记录写入备数据库的引擎文件中。

可选的，在第二操作请求是第二删除请求时，处理单元1320具体用于：从修改集中读取第三记录。若对第三记录从修改集读取成功，则判断修改集中的第三记录是否带有第三删除标记，第三删除标记表示在合并修改集和备数据库的引擎文件时，需要删除第三记录。若修改集中的第三记录带有第三删除标记，则确定不能对第三记录执行第二删除请求对应的删除操作。若修改集中的第三记录未带第三删除标记，则确定能对第三记录执行第二删除请求对应的删除操作。若从修改集对第三记录读取失败，则从备数据库的引擎文件中读取第三记录。若从备数据库的引擎文件对第三记录读取成功，则确定能对第三记录执行第二删除请求对应的删除操作。若从备数据库的引擎文件对第三记录读取失败，则确定不能对第三记录执行第二删除请求对应的删除操作。

可选的，在第二操作请求是第二删除请求时，处理单元1320具体用于：若修改集中的第三记录未带第三删除标记，则从修改集和备数据库的引擎文件中删除第三记录。若从备数据库的引擎文件对第三记录读取成功，则从备数据库的引擎文件中删除第三记录。

可选的，在第二操作请求是第二修改请求时，处理单元1320具体用于：从修改集中读取第三记录。若对第三记录从修改集读取成功，则判断修改集中的第三记录是否带有第三删除标记，第三删除标记表示在合并修改集和备数据库的引擎文件时，需要删除第三记录。若修改集中的第三记录带有第三删除标记，则确定不能对第三记录执行第二修改请求对应的修改操作。若修改集中的第三记录未带第三删除标记，则确定能对第三记录执行第二修改请求对应的修改操作。若从修改集对第三记录读取失败，则从备数据库的引擎文件中读取第三记录。若从备数据库的引擎文件对第三记录读取成功，则确定能对第三记录执行第二修改请求对应的修改操作。若从备数据库的引擎文件对第三记录读取失败，则确定不能对第三记录执行第二修改请求对应的修改操作。

可选的，在第二操作请求是第二修改请求时，处理单元1320具体用于：若修改集中的第三记录未带第三删除标记，则从修改集中删除第三记录，并修改备数据库的引擎文件中的第三记录。若从备数据库的引擎文件对第三记录读取成功，则从备数据库的引擎文件中删除第三记录，并将第三记录对应的修改后的记录写入备数据库的引擎文件中。

可选的，处理单元1320还用于：在合并修改集和备数据库的引擎文件时，若通信单元1310获取到对第四记录的第二查询请求，则从修改集中读取第四记录。若对第四记录从修改集读取成功，则判断修改集中的第四记录是否带有第四删除标记，第四删除标记表示在合并修改集和备数据库的引擎文件时，需要删除第四记录。若修改集中的第四记录带有第四删除标记，则返回第四记录不存在的结果。若修改集中的第四记录未带第四删除标记，则返回第四记录。若从修改集对第四记录读取失败，则从备数据库的引擎文件中读取第四记录。若从备数据库的引擎文件对第四记录读取成功，则返回第四记录。若从备数据库的引擎文件对第四记录读取失败，则返回第四记录不存在的结果。

应理解的是，装置实施例与方法实施例可以相互对应，类似的描述可以参照方法实施例。为避免重复，此处不再赘述。具体地，图13所示的备节点可以执行本申请备节点对应的方法实施例，并且图13所示的备节点中的各个模块的前述和其它操作和/或功能分别为了实现备节点对应的各个方法中的相应流程，为了简洁，在此不再赘述。

上文中结合附图从功能模块的角度描述了本申请实施例的备节点。应理解，该功能模块可以通过硬件形式实现，也可以通过软件形式的指令实现，还可以通过硬件和软件模块组合实现。具体地，本申请实施例中的方法实施例的各步骤可以通过处理器中的硬件的集成逻辑电路和/或软件形式的指令完成，结合本申请实施例公开的方法的步骤可以直接体现为硬件译码处理器执行完成，或者用译码处理器中的硬件及软件模块组合执行完成。可选地，软件模块可以位于随机存储器，闪存、只读存储器、可编程只读存储器、电可擦写可编程存储器、寄存器等本领域的成熟的存储介质中。该存储介质位于存储器，处理器读取存储器中的信息，结合其硬件完成上述方法实施例中的步骤。

图14为本申请实施例提供的一种主节点的示意图，如图14所示，该备节点包括：通信单元1410和处理单元1420。其中，处理单元1420用于：在进行备数据库的全量备份时，若通信单元1410获取到对第一记录的第一操作请求，则判断能否对第一记录执行第一操作请求对应的操作。若确定能对第一记录执行第一操作请求对应的操作，则对第一记录执行第一操作请求对应的操作。

可选的，处理单元1420还用于：在进行备数据库的全量备份时，若通信单元1410获取到对第二记录的第一查询请求，则从主数据库的引擎文件查询第二记录。

可选的，处理单元1420还用于：在合并修改集和备数据库的引擎文件时，若通信单元1410获取到对第三记录的第二操作请求，则判断能否对第三记录执行第二操作请求对应的操作。若确定能对第三记录执行第二操作请求对应的操作，则对第三记录执行第二操作请求对应的操作。

可选的，处理单元1420还用于：在合并修改集和备数据库的引擎文件时，若通信单元1410获取到对第四记录的第二查询请求，则从主数据库的引擎文件查询第四记录。

应理解的是，装置实施例与方法实施例可以相互对应，类似的描述可以参照方法实施例。为避免重复，此处不再赘述。具体地，图14所示的主节点可以执行本申请主节点对应的方法实施例，并且图14所示的主节点中的各个模块的前述和其它操作和/或功能分别为了实现主节点对应的各个方法中的相应流程，为了简洁，在此不再赘述。

上文中结合附图从功能模块的角度描述了本申请实施例的主节点。应理解，该功能模块可以通过硬件形式实现，也可以通过软件形式的指令实现，还可以通过硬件和软件模块组合实现。具体地，本申请实施例中的方法实施例的各步骤可以通过处理器中的硬件的集成逻辑电路和/或软件形式的指令完成，结合本申请实施例公开的方法的步骤可以直接体现为硬件译码处理器执行完成，或者用译码处理器中的硬件及软件模块组合执行完成。可选地，软件模块可以位于随机存储器，闪存、只读存储器、可编程只读存储器、电可擦写可编程存储器、寄存器等本领域的成熟的存储介质中。该存储介质位于存储器，处理器读取存储器中的信息，结合其硬件完成上述方法实施例中的步骤。

图15是本申请实施例提供的备节点1500的示意性框图。

如图15所示，该备节点1500可包括：

存储器1510和处理器1520，该存储器1510用于存储计算机程序，并将该程序代码传输给该处理器1520。换言之，该处理器1520可以从存储器1510中调用并运行计算机程序，以实现本申请实施例中的方法。

例如，该处理器1520可用于根据该计算机程序中的指令执行上述方法实施例。

在本申请的一些实施例中，该处理器1520可以包括但不限于：

通用处理器、数字信号处理器（Digital Signal Processor，DSP）、专用集成电路（Application Specific Integrated Circuit，ASIC）、现场可编程门阵列（FieldProgrammable Gate Array，FPGA）或者其他可编程逻辑器件、分立门或者晶体管逻辑器件、分立硬件组件等等。

在本申请的一些实施例中，该存储器1510包括但不限于：

易失性存储器和/或非易失性存储器。其中，非易失性存储器可以是只读存储器（Read-Only Memory，ROM）、可编程只读存储器（Programmable ROM，PROM）、可擦除可编程只读存储器（Erasable PROM，EPROM）、电可擦除可编程只读存储器（Electrically EPROM，EEPROM）或闪存。易失性存储器可以是随机存取存储器（Random Access Memory，RAM），其用作外部高速缓存。通过示例性但不是限制性说明，许多形式的RAM可用，例如静态随机存取存储器（Static RAM，SRAM）、动态随机存取存储器（Dynamic RAM，DRAM）、同步动态随机存取存储器（Synchronous DRAM，SDRAM）、双倍数据速率同步动态随机存取存储器（Double DataRate SDRAM，DDR SDRAM）、增强型同步动态随机存取存储器（Enhanced SDRAM，ESDRAM）、同步连接动态随机存取存储器（synch link DRAM，SLDRAM）和直接内存总线随机存取存储器（Direct Rambus RAM，DR RAM）。

在本申请的一些实施例中，该计算机程序可以被分割成一个或多个模块，该一个或者多个模块被存储在该存储器1510中，并由该处理器1520执行，以完成本申请提供的方法。该一个或多个模块可以是能够完成特定功能的一系列计算机程序指令段，该指令段用于描述该计算机程序在该备节点中的执行过程。

如图15所示，该备节点还可包括：

收发器1530，该收发器1530可连接至该处理器1520或存储器1510。

其中，处理器1520可以控制该收发器1530与其他设备进行通信，具体地，可以向其他设备发送信息或数据，或接收其他设备发送的信息或数据。收发器1530可以包括发射机和接收机。收发器1530还可以进一步包括天线，天线的数量可以为一个或多个。

应当理解，该备节点中的各个组件通过总线系统相连，其中，总线系统除包括数据总线之外，还包括电源总线、控制总线和状态信号总线。

图16是本申请实施例提供的主节点1600的示意性框图。

如图16所示，该主节点1600可包括：

存储器1610和处理器1620，该存储器1610用于存储计算机程序，并将该程序代码传输给该处理器1620。换言之，该处理器1620可以从存储器1610中调用并运行计算机程序，以实现本申请实施例中的方法。

例如，该处理器1620可用于根据该计算机程序中的指令执行上述方法实施例。

在本申请的一些实施例中，该处理器1620可以包括但不限于：

通用处理器、DSP、ASIC、FPGA或者其他可编程逻辑器件、分立门或者晶体管逻辑器件、分立硬件组件等等。

在本申请的一些实施例中，该存储器1610包括但不限于：

易失性存储器和/或非易失性存储器。其中，非易失性存储器可以是ROM、PROM、EPROM、EEPROM或闪存。易失性存储器可以是RAM，其用作外部高速缓存。通过示例性但不是限制性说明，许多形式的RAM可用，例如SRAM、DRAM、SDRAM、DDR SDRAM、ESDRAM、SLDRAM和DRRAM。

在本申请的一些实施例中，该计算机程序可以被分割成一个或多个模块，该一个或者多个模块被存储在该存储器1610中，并由该处理器1620执行，以完成本申请提供的方法。该一个或多个模块可以是能够完成特定功能的一系列计算机程序指令段，该指令段用于描述该计算机程序在该主节点中的执行过程。

如图16所示，该主节点还可包括：

收发器1630，该收发器1630可连接至该处理器1620或存储器1610。

其中，处理器1620可以控制该收发器1630与其他设备进行通信，具体地，可以向其他设备发送信息或数据，或接收其他设备发送的信息或数据。收发器1630可以包括发射机和接收机。收发器1630还可以进一步包括天线，天线的数量可以为一个或多个。

应当理解，该主节点中的各个组件通过总线系统相连，其中，总线系统除包括数据总线之外，还包括电源总线、控制总线和状态信号总线。

本申请还提供了一种计算机存储介质，其上存储有计算机程序，该计算机程序被计算机执行时使得该计算机能够执行上述方法实施例的方法。或者说，本申请实施例还提供一种包含指令的计算机程序产品，该指令被计算机执行时使得计算机执行上述方法实施例的方法。

当使用软件实现时，可以全部或部分地以计算机程序产品的形式实现。该计算机程序产品包括一个或多个计算机指令。在计算机上加载和执行该计算机程序指令时，全部或部分地产生按照本申请实施例该的流程或功能。该计算机可以是通用计算机、专用计算机、计算机网络、或者其他可编程装置。该计算机指令可以存储在计算机可读存储介质中，或者从一个计算机可读存储介质向另一个计算机可读存储介质传输，例如，该计算机指令可以从一个网站站点、计算机、服务器或数据中心通过有线（例如同轴电缆、光纤、数字用户线（digital subscriber line，DSL））或无线（例如红外、无线、微波等）方式向另一个网站站点、计算机、服务器或数据中心进行传输。该计算机可读存储介质可以是计算机能够存取的任何可用介质或者是包含一个或多个可用介质集成的服务器、数据中心等数据存储设备。该可用介质可以是磁性介质（例如，软盘、硬盘、磁带）、光介质（例如数字视频光盘（digital video disc，DVD））、或者半导体介质（例如固态硬盘（solid state disk，SSD））等。

本领域普通技术人员可以意识到，结合本文中所公开的实施例描述的各示例的模块及算法步骤，能够以电子硬件、或者计算机软件和电子硬件的结合来实现。这些功能究竟以硬件还是软件方式来执行，取决于技术方案的特定应用和设计约束条件。专业技术人员可以对每个特定的应用来使用不同方法来实现所描述的功能，但是这种实现不应认为超出本申请的范围。

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

作为分离部件说明的模块可以是或者也可以不是物理上分开的，作为模块显示的部件可以是或者也可以不是物理模块，即可以位于一个地方，或者也可以分布到多个网络单元上。可以根据实际的需要选择其中的部分或者全部模块来实现本实施例方案的目的。例如，在本申请各个实施例中的各功能模块可以集成在一个处理模块中，也可以是各个模块单独物理存在，也可以两个或两个以上模块集成在一个模块中。

以上该，仅为本申请的具体实施方式，但本申请的保护范围并不局限于此，任何熟悉本技术领域的技术人员在本申请揭露的技术范围内，可轻易想到变化或替换，都应涵盖在本申请的保护范围之内。因此，本申请的保护范围应以该权利要求的保护范围为准。