一种基于区块链的数据库操作系统及方案

技术领域

本发明涉及区块链领域，尤其涉及一种基于区块链的数据库操作系统及方案。

背景技术

数据库是“按照数据结构来组织、存储和管理数据的仓库”。是一个长期存储在计算机内的、有组织的、可共享的、统一管理的大量数据的集合。数据库既是一个实体，能够合理保管数据，由用户在仓库中存放的要管理的事物构建而成，数据库也是数据管理的新方法和技术，能更合适地组织数据、更方便地维护数据、更严密的控制数据和更有效的利用数据。目前数据库已经演变成用户必不可少的管理数据方式，从最简单的存储数据的表单，到复杂的海量数据场景存储，数据库已经与计算机技术应用场景密不可分。

然而，现行的分布式数据库系统也存在着很多问题：数据安全性和保密性差、存取结构复杂等；并且，由于各个政府单位和企业间业务数据逻辑和责任划分不同的原因，数据并不能有效共享。如何构建相关不同部门间数据的可信互通，进而提高社会运行的稳定高效一直都是各界亟待解决的问题。本发明将数据库技术与区块链技术进行有机结合，设计了一套基于区块链的数据库操作系统：在利用区块链去中心化、不可篡改、安全透明优势的同时，保持分布式数据库存储量大、灵活、高可用、经济高效的特性，保留了原有数据库系统的管理与运行方式，保证多种类型数据库系统(如MySQL、SQLserver)的数据一致性。

发明内容

为解决上述问题，本发明提供了一种基于区块链的数据库操作系统及方案，针对区块链中数据库操作系统中所需要的数据一致性、数据操作便利性、分布式存储、数据面对特殊状况容错、和数据库与区块链通信中的数据安全等问题，本发明设计了相关分布式存储策略、分库分表操作、数据容灾容错机制和相关触发流程。

本发明的技术方案如下：

一种基于区块链的数据库操作系统，包括区块链服务器、监控服务器和数据库服务器；所述数据库服务器包括若干数据库节点；所述监控服务器存储有数据id及所述数据id对应的数据库节点地址的数据映射表；所述监控服务器可对新增数据进行分库分表操作；所述区块链服务器和所述监控服务器通信连接；所述监控服务器和若干所述数据库节点通信连接；所述区块链服务器和若干所述数据库节点通信连接。

新增所述数据库节点时，原有所述数据库节点的部分或全部数据迁移至新增所述数据库节点。

若干所述数据库节点中的部分所述数据库节点为备份数据库节点；所述数据库节点中存储的数据同步备份至所述备份数据库节点；所述监控服务器存储有数据id、所述数据id对应的数据库节点地址及所述数据id对应的备份数据库节点地址的数据映射表。

一种基于区块链的数据库操作方案，包括以下步骤，

S1，区块链节点接收来自用户的数据库操作请求；所述区块链节点查询所述区块链节点存储的数据映射表是否存在此数据id对应的数据库节点地址；若存在此数据id对应的数据库节点地址，则执行步骤S1.2；若不存在此数据id对应的数据库节点地址，则执行步骤S1.1

S1.1，所述区块链节点向监控服务器请求此数据id对应的数据库节点地址，所述监控服务器根据其存储的数据映射表，向所述区块链节点返回此数据id对应的数据库节点地址，然后执行步骤S1.2；

S1.2，所述区块链节点向相应的数据库节点发送所述数据库操作请求，然后执行步骤S2；

S2，相应的数据库节点判断接收的所述数据库操作请求具有权限且此数据存储在此数据库节点，则执行所述数据库操作请求，将执行结果返回至所述区块链节点，并且所述区块链节点在其存储的数据映射表中更新或添加此数据id和此数据id对应的数据库节点地址，所述监控服务器在其存储的数据映射表中更新或添加此数据id和此数据id对应的数据库节点地址；否则，不执行所述数据库操作请求，并将不执行的原因返回至所述区块链节点。

优选的，步骤S1，所述区块链节点接收来自用户的数据库操作请求包括增加数据、删除数据、修改数据或查询数据中的一种或几种；当所述数据库操作请求为增加数据时，所述区块链节点向监控服务器请求此数据id对应的数据库节点地址，所述监控服务器触发分库分表操作，并根据分库分表操作的结果向所述区块链节点返回此数据id对应的数据库节点地址，所述区块链节点向相应的数据库节点发送所述数据库操作。

优选的，所述分库分表操作包括垂直分表、水平分表或混合分表。

优选的，步骤S2中，相应的数据库节点执行所述数据库操作时，读取操作和写入操作分离，其中读取操作包括增加数据、删除数据、修改数据，写入操作包括查询数据。

优选的，步骤S2，相应的数据库节点判断接收的所述数据库操作请求具有权限且此数据未存储在此数据库节点，则再次执行步骤1中的S1.1，S1.2和S2。

优选的，步骤S2，若相应的数据库节点出现异常无法执行所述数据库操作请求，则所述区块链节点向监控服务器请求此数据id对应的备份数据库节点地址，所述监控服务器根据其存储的数据映射表，向所述区块链节点返回此数据id对应的备份数据库节点地址，然后所述区块链节点向相应的备份数据库节点发送所述数据库操作请求，相应的备份数据库节点判断接收的所述数据库操作请求具有权限且此数据存储在此备份数据库节点，则执行所述数据库操作请求，将执行结果返回至所述区块链节点，并且所述区块链节点在其存储的数据映射表中更新或添加此数据id和此数据id对应的数据库节点地址，所述监控服务器在其存储的数据映射表中更新或添加此数据id和此数据id对应的备份数据库节点地址。

优选的，在数据库系统和区块链集群中，引入交易锁机制来保证数据一致性和交易安全性。采取版本号作为乐观锁判断条件，版本号一致则交易成功执行。

与现有技术相比，本发明具有以下优势：

1.本发明设计了一种适用于数据库与区块链系统通信的分库分表策略，在不影响数据库和区块链效率特性的基础上，辅助提高系统的数据存储效率与安全性；

2.本发明设计了一种数据库操作系统与实现方案，引入监控集群服务作为本发明系统的辅助机制，在不影响区块链和数据库特性、不参与本发明系统实际业务逻辑的基础之上，解决了数据库与区块链集群通信问题，提高了系统的复用性与灵活性；

3.本发明设计了一种分库分表实现流程，解决了在实际使用过程中数据库分库分表策略的实现问题。

附图说明

图1为本发明的系统框架示意图。

图2为本发明的数据备份示意图。

图3为本发明的枚举类型数据id的BitMap存储方式的示意图。

图4为本发明的监控服务器分段分配方式示意图。

图5为本发明的监控服务器的模Hash依次分配方式的示意图。

具体实施方式

下面对本发明的实施例进行详细阐述，以使本发明的优点和特征能更易于被本领域技术人员理解，从而对本发明的保护范围做出更为清楚明确的界定。

本发明提供了一种基于区块链的数据库操作系统及方案。针对区块链中数据库操作系统中所需要的数据一致性、数据操作便利性、分布式存储、数据面对特殊状况容错和恢复机制等需求，本发明中设计了基于区块链的数据库操作系统和方案。本发明中的数据库操作系统涉及到监控服务器和数据库服务器模块构件，梳理和规范了一系列控制策略、操作方法和事务协调处理流程，并给出在异常状况下的容错容灾机制和流程。本发明不需要保存数据总表，仅在数据分布式存储的情况下，仍保证数据的一致性和便利性，并具备容错容灾等机制。

一、系统构成

如图1所示，本发明的一个系统实例框架图，涉及三个构件，具体说明如下：

(一)监控服务器

监控服务器定位为数据库与外界(包括区块链节点及用户客户端)通讯的桥梁。监控服务器是一种抽象的概念，在具体实践中可以采取具体的如RPC请求或分布式订阅系统等模块或方式来实现其功能。因此，监控服务器可以为单独提供相关功能的服务器，也可以为具有相关功能的服务器集群，即具备协调数据库与外界交流和协调数据库服务器数据的模块称为监控服务器。

监控服务器的具体工作流程如图1、2所示，根据数据库操作系统整体方案，监控服务器具备如下的功能：

1.存在数据唯一id与其所在服务器的地址(如IP地址)之间的映射，即通过监控服务器获取id对应数据所在服务器的联系方式和方法。其中id为每条数据都需要具备的属性，可以通过id来唯一的确定数据库中的某条数据，id应为递增的整数。服务器的地址也为抽象的地址，包括但不限于IP地址、UDP打洞、P2P技术。在这里服务器的地址可以视为与服务器连接和通讯的通道。

2.统筹协调数据库数据的功能。这些功能不仅仅包含简单的针对数据的增删改查，还应具有相关的机制和逻辑用于维护对数据表单的分库分表策略、分库分表方式、数据迁移方式的一系列操作。

3.具备针对数据库容错容灾和恢复流程的控制机制。这些机制不仅仅包括检测数据库服务器异常、检测数据库服务器数据一致性等功能，还需要具备在数据库服务器发生异常时所需要采取的操作和处理方法来恢复或修复数据库服务器的数据，保证数据库服务器中数据的安全可靠。

(二)数据库服务器

数据库服务器主要用来存储数据，由若干数据库节点构成，其每条数据如上所述需具备唯一id与其对应，此外其还需要具备检查检验措施保证数据库的安全性。另一方面，引入数据库分库分表技术，可以在方便数据维护的同时，节省数据库的存储空间，提高数据库的读写效率，减少单个节点的访问压力。

数据库节点具备如下的功能：

1.对数据库数据的监测预警功能。需要对数据库数据的增长率及数据库的热点数据进行监控，对于数据库中增长率高的数据及热点数据需要进行预警，并告知监控服务器，对监控服务器的分库分表等操作指令进行操作。

2.检测操作指令的合法性。即数据库节点需要具备一定的身份检测和识别功能，只有达到权限的用户或区块链节点或监控服务器等给出的操作指令才进行相应的操作，否则拒绝服务和操作。对于不合法的用户还需要具有拒绝服务功能，为了保护数据的安全性，这里的拒绝服务给出的提示不应具有太多可以被对方获取的信息。

3.对自身的数据范畴具有一定的认知功能。即如果用户或其他合法且具备权限的节点请求或操作的数据id与自身存储的数据范围不一致时，进行相关的提醒功能。这种情况可能发生在数据库数据被迁移而相关的节点没有更新本地的数据，或是相关的节点在操作过程中出现的错误，或是数据库物理环境出现意外状况等等异常状况。这些状况都应并告知监控服务器，利用其数据库容错容灾和恢复机制进行检查和纠错。

(三)区块链服务器

区块链网络是由P

区块链服务器具备如下的功能：

1.完整的区块链服务组件。包括区块链节点、交易背书组件、排序服务组件、通信组件等，能够完成区块链系统中例如交易背书、交易排序、打包出块提交上链等完整功能。

2.与监控服务器之间的通信功能。区块链服务器和监控服务器之间应当保持异步通信，区块链节点向监控服务器请求操作指令对应的数据库地址映射，监控服务器进行地址查询并返回给区块链系统，这个过程应当是异步或同步通信。

3.与数据库系统之间的通信功能。在交易执行过程中，区块链服务器应当与数据库之间保持通信同步，区块链服务器中新生成区块可以看作交易事务集合，并能够通过通信组件及时更新到数据库中。同时数据库系统的容错容灾、数据恢复机制都可以借助通信组件实现。

二、分库分表策略

(一)垂直分表

对于需要热门读取的数据进行垂直分表，对于表单中热门的一列或几列数据，需要单独与id一起单独组成新的表单。如用户在登陆时，需要常常访问用户表中密码加盐hash的hash值和盐值，因此需要把id列、hash值列与盐值列单独拿出构成分表。

对于需要热门写入或查询等操作的判定数据构造相关的索引。如用户登陆时，需要输入用户名，因此需要构建用户名与用户id数据的索引机制，即利用索引机制快速利用用户名获取其用户id，并利用其用户id和对应的垂直分表找到其登陆所需要验证的密码hash值及盐值。索引机制包括但不限于如下的方式：

1.对于枚举类型数据，设置BitMap来索引其id。BitMap的优势在于多条件查询时可以通过按位操作快速确定所需要的数据id，且占用空间较小。如图3所示，给出了一枚举类型数据id的BitMap存储方式的示意图。

2.其他类型数据，设置HashMap来反向索引其id。HashMap的Key设置为改列数据，Value设置为对应的id。可以通过key快速获取其id。

利用索引机制，可以快速获取所需要数据的id。同时也可以支持多条件查询，即将不同的数据得到对应的id集合取交集或并集。

(二)水平分表

水平分表用于表单数据量充分大造成操作效率降低，或是表单数据条目数增长率足够高等情况。利用水平分表技术分担数据库节点对表单的操作负担并提高数据库操作系统的运行效率。水平分表需要满足包括但不限于如下原则：

1.数据分布需要相对均匀。数据均匀可以使得各个数据服务器的操作负担均衡，避免某些热点区段的数据只存储于有限的数据库中造成其负担过重。如用户表单新用户访问较为频繁而老用户访问较少，新用户的数据较为集中于一台或几台数据库节点中，则造成这一台或几台数据库节点负担过重，使得存储老用户的数据库节点空闲而资源浪费。

2.数据所在地址均被监控服务器监控和主导。如前所述监控服务器的功能之一是映射数据id与所在服务器地址之间的映射。因此在数据库异常或数据迁移等情况时，需要以监控服务器为主导，在监控服务器的协调下完成水平分表的相关操作。

对于水平分表可以采取包括但不限于监控服务器分段分配方式，或使用模hash均匀分配方式。

1.监控服务器分段分配方式。

如图4所示，监控服务器可以对id划分区间，确定id区间与数据服务器地址之间的映射。为了确保数据分布相对均匀的原则，id区间的划分不应太大，且id的区间大小可以根据实际需求设置为1，即对每个id单独随机分配服务器地址。但是id区间大小与数据存储空间的关系是反比的，即id区间大小越大，所需要存储的映射关系就越少，因此建议在实际部署中划分适当的分段区间，不应太大或太小。因此这种分配方式适用于数据量适中的情况。

在增加数据库节点时，可以不进行数据迁移，当有新的数据增加时，调整监控服务器的分配权重，使得更多的新增数据偏向于存储在新增的数据库节点中，直到新增服务器与其他数据库数据规模相当时，降低其分配权重到正常的范畴，即均匀分配数据存储需求。如果有数据相对均匀分配的需求，也可以重新分配id区间与数据服务器地址之间的映射，然后通知各个服务器进行交互，使得最终各自拥有监控服务器中需要维护的数据。

监控服务器分段分配方式适用于数据量适中，对数据操作请求与数据新旧程度不敏感，且经常需要动态分配数据库节点个数的情况。这里数据新旧程度是指此条数据第一次被存放的时间，其与id相关。由于每条数据对应的id是唯一且递增的，因此数据对应的id越小说明这条数据越旧，反之则越新。

2.模hash均匀分配方式。

如图5所示，监控服务器确定维护同一个表单的数据库节点个数，设有n个数据库节点维护同一个表单，则监控服务器随机配置模hash后余数为i的id对应的数据存放在第i+1个数据库节点中，即把对应的数据存放在第hash(id)mod n+1个服务器中，其中id为该条数据对应的唯一的id。由于对id进行hash再取模后的计算结果是相对均匀的，因此模hash均匀分配方式可以将数据均匀的放置在数据库节点中。

此时，监控服务器只需要本地保存余数与服务器地址的映射表，这个表的长度为n。因此模hash均匀分配方式在监控服务器中所占据的额外空间极少。监控服务器只需要存储少量信息，即可以通过公式计算并简单的查找映射表即可得到数据所在的服务器节点地址，效率相对来说比较高。但缺点是在增加服务器节点时需要额外的进行数据迁移工作。

在增加数据库节点时，监控服务器重新分配余数与对应的数据服务器地址。告知各个数据服务器其需要存储的数据id模hash余数，并发送余数与服务器地址的映射表给各个数据库节点。各个服务器根据自身模hash余数以及映射表进行数据交互，在交互后使得各个服务器存储与自身分配的id模hash余数一致的数据。

模hash均匀分配方式适用于数据量较大，对数据库操作请求与数据新旧程度敏感，且对数据库节点不常需要动态分配的情况。

(三)混合分表

当面对表单中数据在水平上数据量比较大或数据量不断膨胀，在垂直上某些列数据为热点数据时，可以采取混合分表策略。混合分表是在水平分表的基础上进行垂直分表，也可以为在垂直分表的基础上进行水平分表。通过混合分表方式，使得每个分表都存储一部分数据，且每个分表的规模都足够小。因此在数据完整的基础上，提高了数据库节点的操作效率。

(四)读写分离

由于有些表需要频繁的增删改查，甚至需要读取的次数远远大于增删改的次数，此时可以执行读写分离策略。如用户经常频繁查询自己的账户余额，这需要刷新读取后台数据库中用户余额表单的查询，因此对后台数据库的读操作远远大于增删改，因此可以实行读写分离。

进行读写分离操作需要在主表的基础上创建从表。其中主表负责正常的表单增删改操作，从表负责对表单的读取操作。从表需要设置监控服务器监控主表的日志记录，并根据日志记录更新自身。

(五)备份数据库

基于容灾容错的需求，可以增加额外的备份数据库节点用于数据备份。可以简单的设置一台或多台数据库进行数据备份，但是这种类型的备份数据库节点仅仅进行增删改操作用于数据的备份和恢复，其执行效率不高，不能被用于提供业务服务。在数据库节点资源有限的情况下可以采取这种方式。

如果数据服务器资源充分时可以采取前面分库分表的技术，在监控服务器的映射表地址中额外增加备份服务器的地址即可。此时备份数据服务器由于具备和普通数据服务器的功能，其效率是相同的，因此也可以用于提供相关的业务服务。

三、分库分表的操作

(一)增加数据

1.监控服务器分段分配方式：首先设置分段规则，即设置映射规则，得到一个映射表将某段区间的数据映射到某台服务器的地址中，如第100-200条数据放在服务器A中，第200-300条数据放在服务器B中。新增加的数据首先发送给监控服务器，监控服务器根据分段规则，把这条数据发送给对应的需要存储此数据的服务器。

2.模hash均匀分配方式：首先监控服务器根据现有的服务器及分配规则，设置映射表，即某台服务器存储模hash后余数为某值。新增加的数据首先发送给监控服务器，监控服务器计算这条数据id模hash之后的余数，根据映射关系表，得到对应的数据服务器的地址，把这条数据发送给此数据服务器。

3.垂直分表：由于每个分表都具有id列，因此增加规则与分段分配方式和模hash分配方式一致，监控服务器确定此条数据的应该存放的数据库节点地址后，发送给对应的数据服务器，数据服务器根据id操作各个分表增加数据。

(二)删除数据

删除操作与增一致，要删除的数据首先发送给监控服务器，监控服务器确定此条数据的应该存放的数据库节点地址后，发送给对应的数据服务器，数据服务器根据id操作各个分表增加数据。

(三)修改数据

修改操作与增一致，要删除的数据首先发送给监控服务器，监控服务器确定此条数据的应该存放的IP地址后，发送给对应的数据服务器，数据服务器根据id操作各个分表增加数据。

(四)查询数据

监控服务器发送给各个数据服务器查询请求，各个数据服务器根据BitMap和HashMap等方式获取到对应的数据id，监控服务器汇总查询结果，得到对应的id集合，并根据id集合向各个服务器请求数据。

(五)数据迁移

在新增数据库节点、更换数据库节点、数据库。数据迁移主要是在新增加服务器，为了使得服务器之间存储的数据均衡，需要执行数据迁移。或者是在容错容灾机制被触发时发生数据迁移。

1.对于监控服务器分段分配方式，首先监控服务器根据需求重新分配数据id区间与数据库节点地址之间的映射关系，并把映射表发送给各个数据库节点。各个数据库节点将自身的数据与映射表之间的数据进行比对，原有数据对应的id与映射表中自身所需要存储的id区段一致则不需要迁移，如果不一致，则根据映射表查询此数据id对应的数据库节点地址，并发送给此数据服务器。数据库节点接收到其他数据库节点发送迁移数据，首先验证发送来的数据id是否属于自己需要保存的数据id区间内，如果是则保存此数据，如果否则向监控服务器发送错误信息，并拒绝存储此数据。监控服务器判断错误信息，并根据自身的数据id区间与数据库节点地址映射表进行对应的处理。最终，各个服务器依照监控服务器分配的数据id区间与数据库节点地址的映射关系存储自身需要存储的数据。

2.对于模hash均匀分配方式，首先监控服务器根据需求重新分配id模hash后余数与数据库节点地址之间的映射表，并把映射表发送给各个数据库节点。与监控服务器分段分配方式一致，各个数据库节点确定自身需要保存的数据以及需要迁移的数据。进行一系列交互后，各个数据库节点按照监控服务器的映射表存储自身需要存储的数据。

3.对于水平分配方式和混合分表方式，由于每个分表都具有id列，其数据迁移是依照监控数据库确定的id与数据库节点地址的映射关系来迁移数据。迁移方式与监控服务器分段分配方式与模hash均匀分配方式一致。

四、数据库操作系统流程

(一)初始化

1.监控服务器的初始化

首先需要设置规则，包括但不限于：id区间的范围规则、数据库节点与备份数据库节点个数、热点数据的判定规则(如某表某列操作占比达到某个数值以上)、表单数据增长趋势(如增长率＝新增条目数/单位时间超过给定的某个数值)、水平分表触发条件、垂直分表触发条件、监控服务器分段分表触发条件、模hash依次分表触发条件。

监控服务器根据一系列规则设置触发条件和监听接口，检测所需要数据库存储的信息和数据表单信息，配置数据库节点地址与数据id的映射表。并启动一系列接口，等待数据库节点的连接和通讯。等待数据库节点初始化，最后与数据库节点连接和确认与数据库通讯是否异常等数据库系统自检完成后，启动服务接口，接收处理区块链网络节点或用户客户端等服务请求。

2.数据库节点的初始化

数据库节点首先与监控服务器通信，获取需要存储的表单信息并建立相关的表单。此外还需获取数据id与此服务器地址的映射关系，即确认自身所需要操作的数据id规则，用于在异常情况下如请求的数据id并不在此数据库节点范围时返回错误信息。

数据库节点接着与监控服务器相关的身份接口连接，用于在处理区块链网络节点或用户客户端等服务请求时，进行身份审查通过后才进行一系列操作。

开启自身的检测进程，对表单数据操作请求进行统计分析，并根据分表触发规则以及容错容灾触发规则来检查自身的数据状态。当满足相应的规则和条件时触发相应的操作。

一系列初始化完成后通知监控服务器可以进行数据处理请求。

(二)水平分表触发流程

水平分表的触发规则包括但不限于：表单数据行数超过一定的范围、表单数据增长率超过一定数值。

当水平分表的规则被触发后，数据库节点发送消息给监控服务器，请求水平分表。监控服务器根据相应的规则设置数据id与数据库节点地址的映射关系表，并发送给各个数据库节点。各个数据库节点根据映射关系表，确定自身需要保存的数据与需要迁移的数据，按照数据迁移流程交互数据，最终完成数据迁移并实现水平分表。

(三)垂直分表触发流程

垂直分表的触发规则包括但不限于：某列或某几列的数据读取占比达到一定比例、某列查询占比达到一定的比例、某列或某几列修改占比达到一定比例、表单过大或列数过多。

对于读取或修改占比达到一定比例的列与id一起构成单独的分表，其读取时需要获取对应的id。对于查询占比达到一定比例的列(如用户名)构造BitMap或HashMap映射其与id的关系。

在垂直分表规则被触发后，数据库节点发送消息给监控服务器告知垂直分表需求。监控服务器根据垂直分表需求配置和协调各个数据库节点共同完成垂直分表过程。并设置垂直分表下进行操作(增删改查)的方式方法。

(四)容错容灾机制触发流程

容错容灾触发规则包括但不限于：数据库节点与备份数据库节点数据表单出现不一致、数据库节点通信或服务异常。

针对数据不一致等情况，首先需要设置规则，每隔特定的时间数据库节点与备份数据库节点需要将给定的表单摘要表进行hash后发送给监控服务器，当hash值一致时，则数据是一致的，否则数据存在不一致的情况。此时，可以执行回滚机制，回滚到上次数据hash值一致的位置，再重新从区块链服务器节点中请求需要执行的交易结果，重新写入服务器并进行验证。如果备份服务器足够多时，可以采取比例原则，如其他4个备份服务器中相同区段的数据hash值是一致的，只有一个数据库节点相应的数据与其他服务器不一致，则认为此服务器执行中出现了异常，此服务器需要重新回滚相应的操作并重新执行，最后验证相应的数据是否与其他服务器一致，如果仍不一致，则向监控服务器报告异常。由监控服务器协调各个数据库并检查相应的数据，最终需使得各个数据库中的数据一致。

针对数据库节点通信或服务异常的情况，一方面，数据库节点也需要监察自身的网络通信等情况，及时向监控服务器报告异常。另一方面监控服务器需要设置监听接口或与数据库节点保持长连接、或设置相应的心跳检测机制，检查数据服务器是否异常，如果异常则引导数据与备份数据库节点进行交互，并向管理员报告异常以人工确认问题。

在异常处理后，如果需要数据迁移操作的，监控服务器应根据需求协调数据库节点与备份数据库节点之间的数据迁移工作。

(五)交易结果同步、读写锁与执行流程

为了保证在高并发网络环境下数据的安全，本发明中引入了读写锁：采用了乐观锁的模式，假设认为数据一般情况下不会造成冲突，所以在数据进行提交更新的时候，才会正式对数据的冲突与否进行检测。与传统数据库所提供的锁机制不同的是，本发明采取的是对每个交易块中的交易事务添加版本号blockID，选择在上链后对交易事务进行加锁：因为在基于区块链的数据库系统中，排序服务组件已经完成了大量的冲突交易筛选工作，可以看做上链后的交易事务冲突较少发生，既节省了锁的开销，又加大了系统吞吐量。在上链后而不是交易提交一开始就加锁，保证了只会有较短的一段时间上锁，对其他交易过程影响较小。

读写锁触发流程如下：

1.用户发送交易，交易在一系列区块链中操作之后执行，并需要把执行结果同步到数据库中。当交易事务完成区块链排序服务后，就可以按照一定条件打包出块发送给区块链集群进行上链操作。

2.在排序阶段为交易事务添加交易锁，即数据版本号blockID。初始锁的数据版本号即为当前数据版本号lastBlockID，当前数据版本号为区块链上最后一个块的块号。任何事务交易版本号的读取中都应该不会遇到比lastblockID高的版本号。

3.上链后的交易事务集合进行乐观锁的判断：如果交易事务中读取到的版本号和当前区块链集群中保存的版本号一致，则认为交易可以顺利执行，并将数据版本号进行自增更新；如果不一致，就说明该数据读取集已经过时，认为此交易事务无效。失败的交易事务将会再次回到排序组件中的打包环节进行再次操作。成功的交易事务首先发送至监控服务器，监控服务器得到需要修改的数据对应的id或根据前面所述的查询方式后得到数据id。根据id和映射表得到此数据对应的数据库地址，并发送请求至各个对应的数据库节点，请求对数据相应地操作。

4.数据服务器根据监控服务器的要求，对数据执行相应地操作。执行完后更新当前状态的lastBlockID，将锁释放。

(六)用户与区块链节点操作数据库系统流程

首先统称用户或区块链节点等所有对数据库有操作需求的人或身份为数据库用户。

1.首先数据库用户本地存在数据映射表，即id与数据服务器地址的映射表。这个映射表是数据库用户请求过该数据成功时，则保存此数据id与数据服务器地址的映射，如果数据库用户再次需要查询数据，首先数据库用户查询id是否本地存在于服务器地址的映射。如果存在对应的数据服务器地址，则数据库用户直接向此数据服务器查询数据。

2.如果数据库用户本地不存在对应的数据服务器地址，则向监控服务器请求对应的数据，监控服务器根据此数据的id和映射表得到对应的数据服务器的地址，把此地址发送给用户。

3.数据库用户根据监控服务器发送来的数据库节点地址，向地址对应的数据服务器请求操作数据。

4.数据库节点首先验证用户的身份，如果没有通过身份验证则拒绝数据库用户请求。验证成功后检查要操作的数据库是否存放在此数据库中，如果不在则告知对方。如果此条数据存放在数据库中则操作对应的数据并返回执行结果。

5.数据库用户收到结果后，在映射表中更新或添加此数据id和对应的数据库节点地址。

6.如果数据经过了迁移，迁移过程均有监控服务器控制，因此监控服务器存有最新的数据id和数据库节点地址的映射表，而数据库用户本地并未更新此映射表，此时数据库用户请求此数据发现本地映射表中存在数据库节点的地址(此地址为未更新的地址而数据库用户并不知道未更新)，此时数据库用户向对对应的数据库节点请求数据，服务器按照3中步骤，告知经过身份验证成功的数据库用户此数据并不在此数据库中。

7.此时数据库用户认为此数据对应的映射关系失效，再次按照2中步骤重新向监控服务器请求对应的数据库节点地址。

8.如果数据库出现了异常，如网络中断或出现突然灾难等情况，导致某台数据库节点请求数据失败，则此时数据库用户告知监控服务器相关的异常，并重新向监控服务器请求对应的备份数据库节点地址。此后监控服务器触发异常处理机制，处理相关的异常状况。

上述实施例和图式并非限定本发明的产品形态和式样，任何所属技术领域的普通技术人员对其所做的适当变化或修饰，皆应视为不脱离本发明的专利范畴。