CN110543485A - 一种基于快照的区块链预约归档方法 - Google Patents

Abstract

本发明公开了一种基于快照的区块链预约归档方法。首先，用户需要大于或等于当前区块高度的归档请求，在区块提交到请求指定的高度后，通过区块提交过程中产生的修改集制作链上账本数据针对指定高度的快照。当快照完成后，对链上数据包括：区块数据、交易数据、回执数据、非法交易以及相关的索引数据做数据归档。该过程涉及了多个、多种底层数据库，因而过程中提供了原子性保障。本发明借助快照的概念，提供了区块链系统的账本数据和区块数据的归档解决方案，并在归档过程的提供了原子性保障。

Description

一种基于快照的区块链预约归档方法

技术领域

本发明涉及区块链存储归档技术，尤其涉及一种基于快照的区块链预约归档方法。

背景技术

区块链系统存储的数据一般可以分为两大类：一是区块数据，二是账本数据。但随着区块的提交，区块链链上数据会变得十分庞大，因而，在大数据量的场景下，需要进行数据归档操作。目前的典型区块链系统中还没有成熟的可商用的归档方案。

因而，本申请提供了一种方法，允许外部用户对大于或等于当前链上区块高度的区块号发起预约归档的请求，在到达指定高度时生成账本数据的快照，并基于账本快照和当前区块高度，对当前区块高度之前的链上数据包括：区块数据、交易数据、回执数据、非法交易以及相关的索引数据等做数据归档，该过程提供了原子性保证。

发明内容

本发明针对区块链链上数据量庞大的场景，提出了可以保证原子性的基于快照的链上数据归档解决方案。

本发明是通过以下技术方案实现的：一种基于快照的区块链预约归档方法，具体包括以下步骤：

S1:接收到用户对指定高度的快照请求：若用户指定区块高度大于或等于当前区块高度，则执行快照请求，获得到目标高度为止的账本数据，并将所述账本数据绑定到一个全局唯一的ID。接收用户发起所述ID的归档请求，并解析本次归档的区块号范围，分别对线上和线下数据库创建原子性批处理缓冲，所述本次归档的区块号范围即为本次归档范围内的区块。

S2：将非法交易数据写入所述线下数据库批处理缓冲，然后从线上数据库批处理缓冲删除，并统计非法交易变更数目。

S3：将迁移范围内的最后一个区块对应的非法交易数据、区块数据以及Journal数据写入所述线下数据库批处理缓冲。

S4：对每一个区块创建线上和线下数据库批处理缓冲，在线上数据库批处理缓冲中删除区块相应的索引信息，接着遍历每一个区块中的交易列表，将每一笔交易的回执信息写入所述区块对应的线下数据库批处理缓冲，并在所述区块对应的线上数据库批处理缓冲中删除；然后将所述区块中的交易对应的索引信息在线上数据库批处理缓冲中删除；然后向线上数据库批处理缓冲中写入一个由“ArchiveNumber”字符串与当前区块号构成的键值对数据。在遍历每笔交易的过程中，将交易和回执的统计数目做加一处理。在所述每一个区块中的交易完成后，依次提交线下、线上数据库批处理缓冲中的修改到各自的数据库中。

S5：重复执行S4，遍历所述归档范围内的区块。

S6：重复执行S5直至区块超出所述归档范围内的区块，将存储在filelog数据库中的区块数据和Journal数据从起始区块号至末尾区块号减一范围内的数据迁移到线下filelog路径中。

S7：更新线上区块链相关信息到线上数据库批处理缓冲中，并提交线下、线上数据库批处理缓冲中的修改内容，所述区块链相关信息包括Genesis、系统内发生迁移的交易总数目、系统内发生迁移的交易回执总数目、系统内发生迁移的区块总数目。

S8：更新归档元数据文件，所述归档元数据文件中的数据表示当前线下的数据量，分别将本次归档过程中涉及的区块数目、交易数目、回执数目以及非法交易数目增加到文件中的相应字段下，即完成区块链预约归档。

进一步地，所述索引信息包括：交易回执、交易索引、区块索引、交易操作日志信息。

进一步地，若归档过程中异常退出，再次启动时，则进入异常恢复流程，具体为：

在执行模块启动时，根据filelog数据库中的Genesis区块号和当前链上的Genesis区块号做对比，分析本次启动前的归档过程是否处于异常状态：

当filelog数据库中的Genesis区块号和当前链上的Genesis区块号相等时，则比较所述S4中的“ArchiveNumber”对应的区块号与本次归档的区块号范围的边界值：如果“ArchiveNumber”不存在，则不需要进入恢复流程；如果“ArchiveNumber”对应的区块号等于所述归档范围内起始区块号，则认为上次归档未发生，不需要进入恢复流程；如果“ArchiveNumber”对应的区块号等于所述归档范围内末尾区块号，则认为上次归档成功，不需要进入恢复流程；如果“ArchiveNumber”对应的区块号不等于所述归档范围内任一边界值且在范围内，则进入进入恢复流程。即对起始区块号到“ArchiveNumber”对应的区块号范围内的每一个区块创建线上、线下数据库批处理缓冲，将区块中所有的交易对应的回执信息写入线上数据库批处理缓冲。然后依次将相应的批处理缓冲提交至线上、线下数据库。最后，直接从线上数据库中删除“ArchiveNumber”键值对。

当filelog数据库中的Genesis区块号大于当前链上的Genesis区块号时，则将filelog数据库中的存储的区块数据和Journal数据分别与区块链上Genesis区块号进行比较。如果出现不等情况，将filelog数据库中的数据按照归档记录中的范围，将之前迁移到线下路径的数据重新恢复到线上。如果所述数据重新恢复到线上执行成功，则需要读取所述S4中的“ArchiveNumber”对应的区块号，对起始区块号到“ArchiveNumber”对应的区块号范围内的每一个区块创建线上、线下数据库批处理缓冲，将区块中所有的交易对应的回执信息写入线上数据库批处理缓冲。然后依次将相应的批处理缓冲提交至线上、线下数据库。最后，直接从线上数据库中删除“ArchiveNumber”键值对。

进一步地，所述异常恢复流程执行完后，重复步骤S1～S8，完成区块链预约归档。

本发明的有益效果是：本发明为区块链系统的链上数据提供了数据归档解决方案，有效降低了联盟链场景下链上数据持续快速增长给服务器和存储设备带来的维护成本。可以在在不影响联盟链中各节点数据一致性的前提下，不需要外部运维人员的接入，实现系统根据用户请求完成自动化的数据归档。考虑归档过程中可能出现的如服务器宕机，底层文件操作错误等等不可预见的异常情况，上述发明相应的提供了异常恢复逻辑，保障了整个归档流程的原子性。相比于传统的运维介入的数据归档，该解决方案更具鲁棒性，也同时更加自动化、更加方便。。

附图说明

图1基于快照的的预约归档的详细流程图；

图2基于快照的的预约归档的异常恢复流程图。

具体实施方式

下面根据附图和优选实施例详细描述本发明，本发明的目的和效果将变得更加明白，以下结合附图和实施例，对本发明进行进一步详细说明。应当理解，此处所描述的具体实施例仅仅用以解释本发明，并不用于限定本发明。

如图1所示，本发明提供了基于快照的区块链数据归档解决方案，该方法具体包括以下步骤：

S1:接收到用户对指定高度的快照请求：若用户指定区块高度大于或等于当前区块高度，则执行快照请求，获得到目标高度为止的账本数据，并将所述账本数据绑定到一个全局唯一的ID。接收用户发起所述ID的归档请求，并解析本次归档的区块号范围，分别对线上和线下数据库创建原子性批处理缓冲，所述本次归档的区块号范围即为本次归档范围内的区块。

S2：将非法交易数据写入所述线下数据库批处理缓冲，然后从线上数据库批处理缓冲删除，并统计非法交易变更数目。

S3：将迁移范围内的最后一个区块对应的非法交易数据、区块数据以及Journal数据写入所述线下数据库批处理缓冲。

S4：对每一个区块创建线上和线下数据库批处理缓冲，在线上数据库批处理缓冲中删除区块相应的索引信息，接着遍历每一个区块中的交易列表，将每一笔交易的回执信息写入所述区块对应的线下数据库批处理缓冲，并在所述区块对应的线上数据库批处理缓冲中删除；然后将所述区块中的交易对应的索引信息在线上数据库批处理缓冲中删除；然后向线上数据库批处理缓冲中写入一个由“ArchiveNumber”字符串与当前区块号构成的键值对数据。在遍历每笔交易的过程中，将交易和回执的统计数目做加一处理。在所述每一个区块中的交易完成后，依次提交线下、线上数据库批处理缓冲中的修改到各自的数据库中。

S5：重复执行S4，遍历所述归档范围内的区块。

S6：重复执行S5直至区块超出所述归档范围内的区块，将存储在filelog数据库中的区块数据和Journal数据从起始区块号至末尾区块号减一范围内的数据迁移到线下filelog路径中。

S7：更新线上区块链相关信息到线上数据库批处理缓冲中，并提交线下、线上数据库批处理缓冲中的修改内容，所述区块链相关信息包括Genesis、系统内发生迁移的交易总数目、系统内发生迁移的交易回执总数目、系统内发生迁移的区块总数目。

S8：更新归档元数据文件，所述归档元数据文件中的数据表示当前线下的数据量，分别将本次归档过程中涉及的区块数目、交易数目、回执数目以及非法交易数目增加到文件中的相应字段下，即完成区块链预约归档。

所述S2、S3中，使用的是该过程中创建的唯一的线下、线上数据库批处理缓冲，写入缓冲或从缓冲中删除两种操作，仅仅是在相应的批处理缓冲中增加修改记录，最后提交时才会真正写入数据库。

所述S4中，为每个区块新建线上、线下数据库批处理缓冲，并在每个区块内部的数据迁移完成后，提交批处理缓冲，在提交之前，会写入所述“ArchiveNumber”与当前区块号的键值对映射，以标识该区块的处理已经完成，用于后续的原子性保证。

所述S6中，filelog内部保证了单词归档操作的原子性，S6可以认为区块数据和Journal数据的filelog内部归档操作分别是原子性的。

所述S7中，向S1中创建的线上数据库批处理缓冲中更新链上数据后，在进行线上与线下数据库的批处理缓冲的提交，保证了S2、S3与S7中的数据向线下数据库写入的原子性以及从线上数据库删除的原子性。

所述S4与S6中，数据库批处理缓冲的提交行为都是按照先做线下再做线上的顺序进行的，这样保证了线上线下的数据的数据集合至少是完整的归档前数据。

若归档过程中异常退出，再次启动时，提供了宕机恢复功能以保证归档流程的完整性。在执行模块启动时，根据filelog数据库中的Genesis区块号和当前链上的Genesis区块号做对比，分析本次启动前的归档过程是否处于异常状态：(1)由于链上数据是最后一项更新内容，因此当filelog数据库与链上记录的Genesis相等时，包括上一次归档在迁移filelog数据前失败，或者上一次归档迁移filelog数据库与更新链上Genensis信息同时成功，即上一次归档成功，可以认为filelog的数据不需要恢复。因而该情况下，如果是失败的情况，则需要将其事区块到“ArchiveNumber”之前已迁移的回执信息重新恢复到线上；如果是成功的情况，则不需要进入恢复流程。(2)filelog中的Genesis号与链上记录的Genesis区块号不等，则说明在S6-S7的过程中出现了异常，需要进行filelog数据的恢复，恢复目标为该次失败的归档操作执行前的状态；同时在filelog数据库恢复成功后，需要将已经完成的S4步骤中涉及的交易回执数据从线下恢复到线上。

所述异常恢复流程如图2所示，具体为：

当filelog数据库中的Genesis区块号和当前链上的Genesis区块号相等时，则比较所述S4中的“ArchiveNumber”对应的区块号与本次归档的区块号范围的边界值：如果“ArchiveNumber”不存在，则不需要进入恢复流程；如果“ArchiveNumber”对应的区块号等于所述归档范围内起始区块号，则认为上次归档未发生，不需要进入恢复流程；如果“ArchiveNumber”对应的区块号等于所述归档范围内末尾区块号，则认为上次归档成功，不需要进入恢复流程；如果“ArchiveNumber”对应的区块号不等于所述归档范围内任一边界值且在范围内，则进入进入恢复流程。即对起始区块号到“ArchiveNumber”对应的区块号范围内的每一个区块创建线上、线下数据库批处理缓冲，将区块中所有的交易对应的回执信息写入线上数据库批处理缓冲。然后依次将相应的批处理缓冲提交至线上、线下数据库。最后，直接从线上数据库中删除“ArchiveNumber”键值对。

当filelog数据库中的Genesis区块号大于当前链上的Genesis区块号时，则将filelog数据库中的存储的区块数据和Journal数据分别与区块链上Genesis区块号进行比较。如果出现不等情况，将filelog数据库中的数据按照归档记录中的范围，将之前迁移到线下路径的数据重新恢复到线上。如果所述数据重新恢复到线上执行成功，则需要读取所述S4中的“ArchiveNumber”对应的区块号，对起始区块号到“ArchiveNumber”对应的区块号范围内的每一个区块创建线上、线下数据库批处理缓冲，将区块中所有的交易对应的回执信息写入线上数据库批处理缓冲。然后依次将相应的批处理缓冲提交至线上、线下数据库。最后，直接从线上数据库中删除“ArchiveNumber”键值对。异常恢复成功后，直接从数据库中删除“ArchiveNumber”，下一次再进入恢复流程，如果获取不到“ArchiveNumber”，则认为之前经历过恢复且恢复成功，本次恢复操作不需要执行。

异常恢复过程已经为归档操作的失败恢复流程，如果该过程中出错，则选择直接通知外部用户，归档操作失败且其恢复流程也失败，需要外部运维人员手动介入，进行数据的维护和整理。

所述异常恢复流程执行完后，重复步骤S1～S8，即完成区块链预约归档。

Claims (4)

1.一种基于快照的区块链预约归档方法，其特征在于，具体包括以下步骤：

S1:接收到用户对指定高度的快照请求：若用户指定区块高度大于或等于当前区块高度，则执行快照请求，获得到目标高度为止的账本数据，并将所述账本数据绑定到一个全局唯一的ID。接收用户发起所述ID的归档请求，并解析本次归档的区块号范围，分别对线上和线下数据库创建原子性批处理缓冲，所述本次归档的区块号范围即为本次归档范围内的区块。

S2：将非法交易数据写入所述线下数据库批处理缓冲，然后从线上数据库批处理缓冲删除，并统计非法交易变更数目。

S3：将迁移范围内的最后一个区块对应的非法交易数据、区块数据以及Journal数据写入所述线下数据库批处理缓冲。

S4：对每一个区块创建线上和线下数据库批处理缓冲，在线上数据库批处理缓冲中删除区块相应的索引信息，接着遍历每一个区块中的交易列表，将每一笔交易的回执信息写入所述区块对应的线下数据库批处理缓冲，并在所述区块对应的线上数据库批处理缓冲中删除；然后将所述区块中的交易对应的索引信息在线上数据库批处理缓冲中删除；然后向线上数据库批处理缓冲中写入一个由“ArchiveNumber”字符串与当前区块号构成的键值对数据。在遍历每笔交易的过程中，将交易和回执的统计数目做加一处理。在所述每一个区块中的交易完成后，依次提交线下、线上数据库批处理缓冲中的修改到各自的数据库中。

S5：重复执行S4，遍历所述归档范围内的区块。

S6：重复执行S5直至区块超出所述归档范围内的区块，将存储在filelog数据库中的区块数据和Journal数据从起始区块号至末尾区块号减一范围内的数据迁移到线下filelog路径中。

S7：更新线上区块链相关信息到线上数据库批处理缓冲中，并提交线下、线上数据库批处理缓冲中的修改内容，所述区块链相关信息包括Genesis、系统内发生迁移的交易总数目、系统内发生迁移的交易回执总数目、系统内发生迁移的区块总数目。

S8：更新归档元数据文件，所述归档元数据文件中的数据表示当前线下的数据量，分别将本次归档过程中涉及的区块数目、交易数目、回执数目以及非法交易数目增加到文件中的相应字段下，即完成区块链预约归档。

2.根据权利要求1所述区块链预约归档方法，其特征在于，所述索引信息包括：交易回执、交易索引、区块索引、交易操作日志信息。

3.根据权利要求1所述区块链预约归档方法，其特征在于，若归档过程中异常退出，再次启动时，则进入异常恢复流程，具体为：

在执行模块启动时，根据filelog数据库中的Genesis区块号和当前链上的Genesis区块号做对比，分析本次启动前的归档过程是否处于异常状态：

当filelog数据库中的Genesis区块号和当前链上的Genesis区块号相等时，则比较所述S4中的“ArchiveNumber”对应的区块号与本次归档的区块号范围的边界值：如果“ArchiveNumber”不存在，则不需要进入恢复流程；如果“ArchiveNumber”对应的区块号等于所述归档范围内起始区块号，则认为上次归档未发生，不需要进入恢复流程；如果“ArchiveNumber”对应的区块号等于所述归档范围内末尾区块号，则认为上次归档成功，不需要进入恢复流程；如果“ArchiveNumber”对应的区块号不等于所述归档范围内任一边界值且在范围内，则进入进入恢复流程。即对起始区块号到“ArchiveNumber”对应的区块号范围内的每一个区块创建线上、线下数据库批处理缓冲，将区块中所有的交易对应的回执信息写入线上数据库批处理缓冲。然后依次将相应的批处理缓冲提交至线上、线下数据库。最后，直接从线上数据库中删除“ArchiveNumber”键值对。

当filelog数据库中的Genesis区块号大于当前链上的Genesis区块号时，则将filelog数据库中的存储的区块数据和Journal数据分别与区块链上Genesis区块号进行比较。如果出现不等情况，将filelog数据库中的数据按照归档记录中的范围，将之前迁移到线下路径的数据重新恢复到线上。如果所述数据重新恢复到线上执行成功，则需要读取所述S4中的“ArchiveNumber”对应的区块号，对起始区块号到“ArchiveNumber”对应的区块号范围内的每一个区块创建线上、线下数据库批处理缓冲，将区块中所有的交易对应的回执信息写入线上数据库批处理缓冲。然后依次将相应的批处理缓冲提交至线上、线下数据库。最后，直接从线上数据库中删除“ArchiveNumber”键值对。

4.根据权利要求1所述区块链预约归档方法，其特征在于，所述异常恢复流程执行完后，重复步骤S1～S8，完成区块链预约归档。