基于确定性的分布式数据库中间件设计及实现

王会羽， 夏飞， 黄迅， 戚林成

(国网江苏省电力有限公司 信息通信分公司， 江苏 南京 210000)

0 引言

当前正处于信息技术快速发展的阶段，许多新的网络传输技术以及计算机处理技术都获得了广泛应用，对整个社会的生产生活方式造成了明显影响[1-3]，同时也产生了大量的数据，因此对于存储设备的容量与数据处理效率都提出了更高的要求，在这种情况下采用普通的单体数据库已无法满足实际应用需求，许多企业只能通过分布式数据库系统来存储大量的数据[4-7]。该数据库的特点是可以能够对节点进行线性增加，因此具有良好的可扩展性，从而使整个系统获得更大的吞吐量[8-9]。根据相关研究可知，现阶段分布式数据库因具备分布式ACID属性，从而对其数据扩展造成了明显的约束[10-11]。随着分布式数据库中的节点不断增加达到某一临界值后，便会降低数据库性能的提升速率，最终处于一个相对稳定的状态。因此，如何更有效地提高可扩展性以达到高扩展性水平，同时依然具备事务ACID属性成为了当前研究分布式数据库的一项关键内容[12]。

本文采用确定性执行策略构建得到分布式数据库，同时克服数据库所具有的不确定性。现阶段人们已经开发出了许多不同功能的数据库中间件，不过这些产品都无法满足确定性执行策略的应用条件。针对上述情况，本文对数据库中间件进行了重新优化设计，同时分析了此数据库的各中间模块能够实现的具体功能。

1 中间件集群技术

中间件集群技术指的是以特定方式来组合多个独立运作的分布式数据库，并以中间件对上述过程实施协调。可以利用数据库中间件来独立归类网络通信和数据库的访问类型，以此消除各平台差异性，能够实现对各类异构平台进行数据库访问的功能。分布式数据库内的中间件位置，如图1所示。

图1 数据库中间件位置

由技术人员对中间件进行了长期改进后，目前已在市场上获得全面应用。该技术的优点较多，主要表现如下。首先，此技术具备良好的运行安全性。可以利用中间件来连接数据库和外部系统，能够消除不必要的限制，当外部对数据库进行访问的过程中应符合中间件设置的协议，如果为满足设定要求则中间件可能会拒绝来自外界的数据库访问请求。此外，也可以通过中间件来筛选外部连接方式，能够排出存在风险的访问操作，确保数据库达到安全运行的目标。其次，具备良好的使用性能。当应用层以中间件进行数据库访问的时候，底层结构可以被中间件所屏蔽，中间件接收应用层的请求后再执行相关操作，之后再把得到的结果反馈至应用层，由此能够以更加高效、便捷的方式开发得到所需的应用程序。当现有条件下，通过中间件来实现数据访问已经成为分布式存储的一种重要模式，并且还可以实现数据的一致性与可靠性。

2 系统整体架构及关键模块的设计

应用Calvin数据库时，系统通常被分成存储层、排序层、应用层、调用层，本研究采用Calvin数据库来整合各层的功能，可以将其置于数据库中来实现上述功能，通常可以把此系统分成不同的功能层。上述系统的具体各个组成部分，如图2所示。

图2 中间件系统架构图

事务请求通过应用层进行发送，并将数据存储到数据库层中，利用中间件层来实现连接应用层和数据库层的过程，同时可以将其作为中间件集群进行处理。为了保证底层数据库符合确定性条件，需要以中间件作为连接结构。并且以中间件层进行事务请求时，可以使应用层操作获得充分简化。

各数据库中间件与同一底层数据库相对应，信息的交换需要以中间件构建连接通道，再跟底层数据库之间完成数据交换过程。通过分析可知，在数据库中间件中包含了二个功能模块，具体功能结构，如图3所示。

图3 中间件功能结构图

2.1 数据收发功能的设计

由于在数据传输过程中需要为应用层设置和中间件连接的结构，这时需要发挥数据收发接口的作用，并以此作为连接桥梁来完成对事务请求的分析，实现对各项参数的全局定序并把计算得到的结果传输到对应的管理子模块内。本数据系统进行数据收发的工作模式，如图4所示。

图4 数据收发示意图

为了保证应用层数据获得了准确接收，需利用专业化监听设施对数据通信子模块状况进行检测，在初始化系统的时候需要对监听器也进行同步初始化，同时确保实现实时监听的功能。当来自应用层的事务数量满足监听器设置条件时，需把接收到的参数传输至数据通信子模块再对其进行计算分析，由此实现接收数据的过程。

2.2 消息定序功能的设计

数据定序处理属于通信子模块的一项关键功能，可以有效满足事务请求全局定序的需求，并且通常会以协商方法构建符合要求的序列。对于上述通过确定性执行策略实现的分布式数据库进行分析可以发现，其中包含了许多不同的数据库中间件，为方便区分，需对各数据库中间件实施编号。

完成数据库中间件的编号后，再选择合适的主节点。需通过主节点准确判断各事务的运行先后顺序，考虑到数据库中间件的数量较多，当不存在主节点时，可以通过数据库中间件把得到的处理结果传输到应用层，采用上述处理方法会造成网络中产生大量的通信数据，从而造成堵塞的问题，导致性能得不到充分利用，由此提高了应用层接收与识别的难度。当主节点属于数据库中间件时，更加快速地接收和分辨最终处理结果。

在各Layer中传输数据时，应先结合实际需求构建一个Event，其类型需要结合实际应用条件进行分析，在此基础上满足相应的功能。当Event构建结束后，再利用Appia接口函数来发送数据。考虑到在Qos内含有多个层结构，并且各Laye都有对应的Qos位置，因此在传递Event的过程中应规定实际传递方向，可以选择UP或选择DOWN等不同形式。利用这种设置便能够将Event传输至对应Layer的相邻层中再进行分析。

(1) 主节点进行原子广播。当DdChannel接收Event后，需要先把Event传递至DdAppl内再对其进行计算。当判断结果属于主节点时应构建PaxosPropose类型的Event时，则将其传输至其它数据库中间件第三层DdAccept中；当判断发现不属于主节点时，需把Event的数据赋值到DdTOB的cachedTom变量中，以Event的epoch值作为该节点epoch。上述具体过程，如图5所示。

(2) 利用主节点DdAccept监听来自其它各数据库的Event数据包。如果此Event属于WriteAck，则判断WriteAck内的epoch，当两者不同时将其抛弃，当具有和主节点相同的epoch时，则对主节点的WriteAck数增加1。如果WriteAck包的数量增加至数据库总量50%以上时，表明此时事务请求可以达到全局有序状态。当主节点DdTOB接收PaxosReturn时，把cachedTom的参数传递给DdTomResult类的Event，同时往上传输到DdAppl中再对其实施计算。上述处理过程的具体流程，如图6所示。

图5 发送原子广播

图6 主节点判断流程图

3 数据通信子模块的实现

通过数据通信子模块构建得到数据传输的通道，同时将处理后事务请求序列传输到事务管理子模块。该模块总共含有服务器端和客户端共两类，可以通过ServerAppl类与ClientAppl类来实现相关功能。上述二个类可以通过P2PMessage来完成通信，为便于监听P2PMessage，两者都需要保持与P2PMessagelistener接口同样的属性。

由于P2PMessage是对Serializable接口进行继承得到的结果，这使得P2PMessage具有可序列化的特征。P2PMessage的具体结构，如表1所示。

表1 P2PMessage结构

3.1 数据收发功能的实现

系统利用数据收发功能来连接数据库的不同功能层，再把完成全局定序处理后的事务转移至事务管理子模块中。

在事务管理子模块中进行Storedl数据存储，之后再把接收到的数据在Storedl内完成打包处理。需要先进行数据存储后再运行事务管理子模块，接着再把Storedl包含的各项参数传输至存储结构中并执行相关操作。在接收数据时形成的函数调用时序，如图7所示。

图7 数据接收功能时序图

利用数据通信子模块完成数据定序后，再将其传输至Message()函数，利用此函数调用Messag(e)函数，在事务管理子模块中执行TotalOrder Message。进行数据发送的具体时序结构，如图8所示。

图8 数据发送时序图

3.2 消息定序功能的实现

通过客户端的ClientAppl类把Storedl序列传输至P2pMessage，之后由服务器ServerAppl类接收ClientAppl类sendP2pMessage()函数。具体时序图，如图9所示。

图9 Client时序图

利用主节点DdAccept类的handleWriteAck()函数来监听writeAck包。此时只存在主节点DdAccept类处理writeAck包，而其它各节点则不会对writeAck包进行接收。在handleWriteAck()中包含了全局变量wAck，对于来自其它数据库的中间件WriteAck，将会先分析epoch与之前epoch是否一致。当两者不同时进入等待状态，当两者相同时对全局变量wAck进行增加1的数量。上述处理过程的具体流程，如图10所示。

图10 处理WriteAck流程图

4 总结

1) 在分析分布式数据库内的中间件位置的基础上，对系统整体架构及关键模块展开了设计。采用Calvin数据库来整合各层的功能，可以将其置于数据库中来实现上述功能。给出了本数据系统进行数据收发的工作模式。完成数据库中间件的编号后，再选择合适的主节点。当主节点属于数据库中间件时，更加快速地接收和分辨最终处理结果。

2) 通过数据通信子模块构建得到数据传输的通道，同时将处理后事务请求序列传输到事务管理子模块。系统利用数据收发功能来连接数据库的不同功能层，再把完成全局定序处理后的事务转移至事务管理子模块中。通过客户端的ClientAppl类把Storedl序列传输至P2pMessage，之后由服务器实现消息定序功能。