CN101901237B

CN101901237B - 一种基于SQlite构建的类型-索引-内容方式分布式数据库

Info

Publication number: CN101901237B
Application number: CN2009102165440A
Authority: CN
Inventors: 胡术; 杨铮; 刘舒; 喻德军; 徐薇
Original assignee: Sichuan Chuanda Zhisheng Software Co Ltd
Current assignee: Sichuan Chuanda Zhisheng Software Co Ltd; Wisesoft Co Ltd
Priority date: 2009-12-04
Filing date: 2009-12-04
Publication date: 2012-05-23
Anticipated expiration: 2029-12-04
Also published as: CN101901237A

Abstract

本发明公开了一种基于SQlite构建的“类型-索引-内容”方式分布式数据库，可用于空中交通管制(简称ATC)***。包括为整个***提供分布式互斥锁的管理与分派的分布式锁服务进程(DLS)，为所有更新数据库需要的进程提供服务的使用DLS的分布式数据库服务端(DDB)；分布式锁服务进程(DLS)提供了编程接口LibDLS库，分布式数据库服务端(DDB)提供了编程接口LibDDB库；在利用sqlite数据库指定表(type)进行数据***、删除、更新操作的客户端进程，需调用编程接口LibDDB客户端；所述的编程接口LibDDB客户端，将请求IPC发送到DDB服务器，并在获得加锁之后再将数据提交到DDB。所述的分布式锁服务进程(DLS)是基于R-A算法的DLS；其生成的索引值Index直接由改进逻辑时钟+本地IP信息生成。

Description

一种基于SQlite构建的类型-索引-内容方式分布式数据库

技术领域

本发明涉及计算机应用领域分布式***中的分布式数据库，可用于空中交通管制(简称ATC)***中以“类型-索引-内容”(简称Type-Index-Value)形式分布式地保存数据。

在现代大型分布式***中，各主机如果不是访问一台固定主机上的数据库服务器，而是每个数据库均安装在各主机上，同时数据库呈现多副本状态，这就是分布式数据库。Type-Index-Value形式的数据库是一种关系型数据库，这类数据库存在数据量大，***、查询频繁，但必须满足多机数据的一致性。ATC***要求能够24小时连续运行，同时能够有较强的容错能力，分布式数据库可以满足这样的要求。但在实用中，存在对一类数据进行存储、查询的要求，而不仅仅是一般的“key-Value”方式，即要求以“Type-Index-Value”形式进行存储。基于SQLite的“类型-索引-内容”方式分布式数据库的构建则是解决空中交通管制(ATC)***中以“类型-索引-内容”(Type-Index-Value)形式分布式地保存数据要求的一种途径，该发明已经应用于空管自动化***的飞行情报数据在***中的分布式部署中。中国专利申请号200810097631.4“一种实现分布式存储的内存数据库***及应用”文献中虽然涉及到了数据库存储与利用SQL请求问题，但是从其目的、解决措施与本发明比较则是完全不一样的。

本发明的目的是在解决以ATC***为代表的“类型-索引-内容”方式分布式数据库的实现。

实现本发明目的之技术方案如下：

一种基于SQlite构建的“类型-索引-内容”方式分布式数据库，其特征是包括：为整个***提供分布式互斥锁的管理与分派的分布式锁服务进程(DLS)；使用DLS的分布式数据库服务端(简称DDB)；所述的分布式锁服务进程(DLS) 提供了编程接口LibDLS库，所述的分布式数据库服务端(DDB)提供了编程接口LibDDB库；在利用sqlite数据库指定表(type)进行数据***、删除、更新操作的客户端进程，需调用编程接口LibDDB客户端；所述的编程接口LibDDB客户端，将请求IPC(即进程间通信)发送到DDB服务器，并在获得加锁之后再将数据提交到DDB；DDB数据库服务器收到客户端的请求后，向DLS锁服务器发送对指定类型指定记录(即Type_index合成的字符串)的加锁的请求，并异步等待加锁结果；分布式锁服务进程(DLS)将生成的索引值Index返回给DDB，DDB刷新本地(即写入本地Sqlite数据库中)和其他主机该数据之后，向LibDDB异步发送数据加入结果，索引值Index作为参数返回给使用客户端的进程。

所述构建“类型-索引-内容”方式分布式数据库的方法，其特征是：加锁请求可以来自客户端，也可以来自其他主机节点使用客户端的进程，其加锁请求步骤如下：

①收到来自客户端的加锁请求之后，为其打上逻辑时间戳，将请求加入请求列表，并向其他节点发送加锁请求；

②收到来自其他节点的加锁请求之后，比较加锁请求中的时间戳和本地逻辑时间戳，取最大值加1，先判断来自本地客户端的同时还未收集齐其他主机应答的优先级最高的锁请求的时间戳(即时间戳最小者)和该加锁请求的时间戳谁更早，如果该请求早，则发送回应，反之，则直接加入REQUEST(请求)队列；

③收到来自客户端的解锁请求之后，按报文中的加锁对象和时间戳，删除请求列表中对应的项，并检查下一个优先级最高的请求。

所述的一种构建“类型-索引-内容”方式分布式数据库的方法，其特征是：所述的逻辑时间戳采用真实时间戳来作为一个节点逻辑时钟的起始点即一个节点开始进入工作状态前，先获得当前本地的真实时间戳，后启动主机的时戳应大于之前的主机时戳，锁服务中发生事件时递增1微妙的时间戳作为递增值。

所述的一种构建“类型-索引-内容”方式分布式数据库的方法，其特征是：所述的分布式锁服务进程(DLS)生成的索引值Index直接由改进逻辑时钟+本地IP信息生成，其生成出来的Index在各主机间是不同的，由于时间在流逝，即使同一主机就是出现了关机的现象，Index也不可能重复。

所述的一种构建“类型-索引-内容”方式分布式数据库的方法，其特征是： DDB负责处理用户进程对Sqlite数据库的操作请求。用户进程如果要***数据，只需要将要操作Type的表名和数据通过LibDDB的API发送到DDB，DDB处理请求并承担申请锁、获得锁之后向其他DDB节点刷新数据的任务；用户进程只需要用LibDDB异步等待数据刷新结果和获得返回的索引Index即可，用户进程如果要修改数据，则需要用LibDDB的API发送“表名、索引、数据”到DDB，DDB负责操作。

所述的一种构建“类型-索引-内容”方式分布式数据库的方法，其特征是：所述的DDB刷新数据的任务即版本刷新由两个步骤完成，发送版本心跳和版本刷新合并，版本刷新的处理流程如下：流程开始，收到关于版本信息的心跳报文；比较；判定是删除的记录吗？如果是，则做删除处理；如果不是，则再次判定是否则收到版本(本地版本)？如果是，再次判定自己是否拥有本记录最高版本的主机中IP最小的，如果不是则回到开始阶段重新开始；如果是，则加入被更新列表，在版本稳定一段时间后更新这些版本旧的节点；流程结束。

本发明的有益效果体现在ATC空管***中的实际应用，解决并实现了分布式***中对按类型进行数据存储，检索的问题。

附图说明

图1是本发明所述的DDB的构建结构框图示意图。

图2是本发明所述的DLS基于R-A算法的示意图。

图3是本发明所述的加锁解锁请求步骤流程示意图。

图4是本发明所述的版本数据同步的处理流程示意图。

图5是本发明所述实施例与SQLite连接操作示意图。

具体实施方式

参见图1可以看出本发明所述的分布式数据库构建分布。包括采用分布式互斥算法实现的分布式锁服务程序DLS(Distributed Lock Service)和使用DLS的分布式数据库服务端DDB(Distributed DataBase)；分布式锁服务程序DLS提供了编程接口LibDLS库，每个需要对互斥资源进行操作的DDB进程都需要使用该客户端申请分布式锁，并通过异步调用方式获得加锁结果。DDB提供了编程接口LibDDB库，每个需要对数据库进行更新的进程按Type-Index-Value方式将数据提交到DDB，并通过同步调用方式获得操作结果。

DLS和DDB的配置文件对全***有效，各主机的DLS和DDB分别使用统一内容的配置文件，LibDLS和LibDDB会用到配置文件的一部分，它们需要知道***中定义Type，即数据库存在的表有哪些，以及DLS、DDB作为服务端用于监听的端口号等信息。

本发明使用开源的嵌入式关系数据库Sqlite，按Type-Index-Value的方式存储数据。Type是表名，表项有Index-Value-VersionNumber。在sqlite数据库指定表(type)进行数据***、删除、更新操作的客户端进程，应调LibDDB客户端。

如果是新增某类型数据，并将包含Type-Value信息的请求提交给LibDDB，LibDDB将请求IPC发送到DDB服务器，并在获得锁之后再将数据提交到DDB。DDB数据库一致***器收到客户端的请求后，向DLS锁服务器发送对指定Type的加锁的请求，并异步等待加锁结果；DLS将生成的索引值Index返回给DDB，DDB刷新本地(写入本地Sqlite数据库中)和其他主机该数据之后，向LibDDB异步发送数据加入结果，索引值Index作为参数返回给使用客户端的进程。

如果是查询某Type指定Index数据，则直接由进程通过使用LibDDB直接读取本地Sqlite数据库。

当其他主机修改、新增、删除了某Type的数据，对于对该Type进行了订阅的进程，DDB会通知改进程，告诉其发生事件的类型包括修改、新增、删除。

所述的分布式锁服务进程(DLS)是基于R-A算法的DLS，运行其DLS进程可以为整个分布式***提供锁服务，每个要申请锁的进程，都通过客户端API默认访问本地的DLS。R-A算法要求要进入临界区的节点必须向所有其他节点发送请求，并且必须等待所有节点回复的报文之后才有进入临界区的资格。在DLS中，我们称这种状态为获得锁。图2是R-A算法示意图，可以看出S1，S2，S3三台主机申请同一个临界资源进行访问，从左到右的事件发生时间可知，S1首先向S2和S3发出带时间戳的请求，S2和S3收到请求之后，S3也向S1和S2提出了对该资源的请求，S2由于本身节点内没有其他对该临界资源更早的请求，便立即回复S1。而S3虽然也提出了请求，但是请求的时间晚于S1的请求时间，便回复S1。于是得到全部回复的S1进入临界区。对于S3的请求，S2自身没有请求，立即回复，S1已经进入临界区，暂不回复，则S3处于等待所有回复收齐的阶段，即没有得到锁。当S1结束访问临界资源，便可以回复S3，那么S3也收齐了所有的回复，S3进入临界区。S1结束访问临界资源，回复S3的过程在DLS中，我们称之为释放锁。

分布式***中为了遵循时间的先后顺序，一般采用逻辑时钟来作为整个***的发生事件时间参照。逻辑时钟可以采用单纯记数器算法，但会存在一些缺陷，比如在某个中途启动的DLS，与其他DLS通过心跳统一时钟之前，这段时间的逻辑时钟都处于不准确状态。这段时间收到的请求所打上的逻辑时间戳无法和***同步，由于锁服务的锁分配采用的R-A算法，时间戳越小的得到锁的优先级越高，那么这些请求会使***的加锁顺序混乱，从而导致数据刷新混乱。所述的逻辑时间戳采用真实时间戳来作为一个节点逻辑时钟的起始点即一个节点开始进入工作状态前，先获得当前本地的真实时间戳，后启动主机的时戳应大于之前的主机时戳，锁服务中发生事件时递增1微妙的时间戳作为递增值。锁服务中发生以下事件时递增1微妙的时间戳：

①收到来自客户端的锁请求，自身时间戳递增

②收到来自其他节点的锁请求，和自身时间戳相比取最大值递增

③收到来自其他节点的回应请求，和自身时间戳相比取最大值递增

④收到来自其他节点的心跳报文，和自身时间戳相比取最大值递增

⑤发送自己的心跳报文，自身时间戳递增

⑥测试其他节点通断时，自身时间戳递增

另外，为了进一步提高可靠性，可以在配置文件中设置节点距启动到进入稳定状态的时间间隔。在进入稳定状态之前，不处理来自客户端的请求。

所述的分布式锁服务进程(DLS)生成的索引值Index直接由改进逻辑时钟+本地IP信息生成，其生成出来的Index在各主机间是不同的，由于时间在流逝，即使同一主机就是存在关机的现象，Index也不可能重复。因此Index的生成是很关键的。对于“Type-Index-Value”数据库，如果Index是按照从1开始递增的顺序生成显然存在问题，如两台不同主机在没有网络连接情况下各自生成了一些数据，Index都是从1递增的，那么当这两个主机通过网络连接时，就存在一个分布式情况下数据合并的问题；而且就是两个主机就是连在一个网上如果两个主机各自从1递增开始生成Index也会产生歧义。我们注意到Index其实只是起着区分数据的作用，连续与否并不重要，这里提供的方法是，Index由DLS生成，直接使用上述的改进逻辑时钟+本地IP信息生成，具体方法是：当获得锁时，DLS会因此生成一个新的逻辑时钟送给DDB，新的逻辑时钟＝MAX(逻辑时钟，最后一个REPLY报文中的逻辑时钟)+1，这个逻辑时钟由DLS送DDB，其微秒部分最大为99999，在微秒的4个字节中只需要占用三个字节，最后一个字节取IP地址的最后一个字节即可，而IP地址的最后一个字节即如”192.168.18.16”这样的IP地址的最后一个字节即16(0x0A)；对于IP地址第3个字节(即上例中的18)仍然存在不同的局域网，可以将Index中4字节秒信息(从1980年1月1日零时开始)部分固定减去一个较大的值，使秒信息控制在3字节以内，将IP地址部分的第3字节作为秒信息的第4字节，这样生成出来的Index在各主机间是不同的，由于时间在流逝，即使同一主机就是出现了关机的现象，Index也不可能重复。

所述的DDB刷新数据的任务即版本刷新由两个步骤完成，发送版本心跳和版本刷新合并，版本刷新的处理流程如下：流程开始，收到关于版本信息的心跳报文；比较；判定是删除的记录吗？如果是，则做删除处理；如果不是，则再次判定是否则收到版本(本地版本)？如果是，再次判定自己是否拥有本记录最高版本的主机中IP最小的，如果不是则回到开始阶段重新开始；如果是，则加入被更新列表，在版本稳定一段时间后更新这些版本旧的节点；流程结束。

虽然有分布式互斥锁的保证，但是***中会存在新加入主机或者主机退出后重启、网络出现分割的情形，这些主机缺失的数据需要被更新，不同主机各自生成的数据需要合并，DDB承担了这个数据刷新的任务。DDB的版本刷新由两个步骤完成，发送版本心跳和版本刷新合并。

本发明中所述版本号(Version)和Index-Value一起作为一个记录计入Sqlite数据库，版本号即为使用DLS获得锁时得到的逻辑时间戳，根据R-A算法，该时间戳可以反映数据在时间流逝中的变化即可以记录该版本被更新的时间。

版本心跳的内容包括发送本节点某个表所有项的Index信息和Version信息以及最近一次该Type全部删除操作的时间戳(为执行全删除操作时加锁时从DLS得到的逻辑时间戳)，如果进行的是某条记录的删除，将该记录的version置为0。其他节点接收到版本心跳以后，对比自己数据库的该表对应表项的版本号以及时间戳。如下几种情形进行相应处理。

以下为版本号不为0(即被删除)的处理：

①对同一Index，收到的心跳内版本号＜本地节点版本号

说明该心跳主机的指定Index的版本过旧，DDB记录该主机加入旧版本主机列表，在记录时如果发现存在比自己高的版本存在，则删除该列表；在记录时发现存在另一个和自己一样都是最高版本的主机，通过比较本机和该机的IP地址，IP地址小的主机删除改列表；在收到心跳信息后的15秒(可配置)后，申请锁，然后对这些版本旧的该类型所有主机进行版本更新。

②收到心跳内版本号＞本节点版本号

忽略，等待高版本主机的更新

③收到心跳内版本号＝本节点版本号

忽略，不处理

以下为出现全删除时戳的处理：

①收到的心跳中全删除时间戳＜本地节点某index版本号

保留该index的记录

②收到的心跳中全删除时间戳＞＝本地节点某index版本号

删除该index记录

以下为版本号不为0(即被单记录删除)的处理

①收到的心跳中删除的Index＝本地节点某index

将本地该Index的version置为0，并立即广播心跳信息。

单删除的发起主机收取其他主机该记录删除的信息，当发现***中主机均已删除(存在两种情况，1.vetsion字段置为0；2.无该index的信息)时，对version为0的主机发出删除该记录信息的命令，各主机收到后彻底删除该记录，当发现其他主机再无该index记录时，发起机删除本地该记录。

图5是本发明所述实施例与数据库SQLite接口连接操作示意图。

Sqlite是一个开源的嵌入式关系数据库，它能减少应用程序管理数据的开销，SQLite可移植性好，很容易使用，很小，高效而且可靠。SQLite嵌入到使用它的应用程序中，它们共用相同的进程空间，而不是单独的一个进程。在进程内部，它是完整的，自包含的数据库引擎；嵌入式数据库的一大好处就是在你的程序内部不需要网络配置，也不需要管理。因为客户端和服务器在同一进程空间运行。SQLite的数据库权限只依赖于文件***，没有用户帐户的概念。SQLite有数据库级锁定，没有网络服务器。其使用开销很小，适合用于嵌入式设备。

本发明中主要使用Sqlite做数据库中数据的本地保存，用于客户端的直接读写。

本发明中对Sqlite数据库实施写操作主要是由DDB完成的，而读操作主要是由使用libDDB的客户端进程完成，图5中显示了这个关系，该图中客户端进程只绘制了一个，但所有客户端进程均按此完成。由于锁服务不使用Sqlite本图中没有绘制DLS进程。

每个所述DDB节点为每一个type在Sqlite中创建一个表，每一个表的字段包括：【dataIndex1，dataIndex2，version1，version2，dataValue，dataBinary】，dataIndex1和dataIndex2为index的两个组成部分，字段中的version1，version2是数据被修改时，增加版本号对应的逻辑时间戳。

操作sqlilte数据库时，应该打开数据库，并在结束时关闭数据库。

Claims

1.一种基于Sqlite构建“类型-索引-内容”方式分布式数据库的方法，其特征是包括：为整个分布式数据库提供分布式互斥锁管理的分布式锁服务进程DLS；使用DLS的分布式数据库服务端DDB；所述的分布式锁服务进程DLS提供了编程接口LibDLS库，所述的分布式数据库服务端DDB提供了编程接口LibDDB库，在进行数据***、删除、更新操作的客户端进程，需调用编程接口LibDDB客户端；所述的编程接口LibDDB客户端，将对数据库的操作请求通过进程间通信IPC发送到DDB服务器，并在获得加锁之后再将数据提交到DDB；DDB数据库服务器收到客户端的对数据库的操作请求后，向DLS锁服务器发送对指定类型指定记录即Type_index合成的字符串的加锁的请求，然后异步等待加锁结果；在获得锁以后进行分布式刷新过程中，更新发起节点的DDB在刷新本地即写入本地Sqlite数据库中和其他主机该数据之后，向LibDDB异步发送数据加入结果，索引值Index作为参数返回给使用客户端的进程。

2.根据权利要求1所述的构建“类型-索引-内容”方式分布式数据库的方法，其特征是：所述的分布式锁服务进程DLS是基于R-A算法的DLS，运行其可以为整个分布式数据库提供锁服务，每个要申请锁的进程，都通过客户端API默认访问本地的DLS。

3.根据权利要求1所述的构建“类型-索引-内容”方式分布式数据库的方法，其特征是：所述的DDB负责处理用户进程对Sqlite数据库的操作请求；用户进程如果要***数据，只需要将要操作Type的表名和数据通过LibDDB的API发送到DDB，DDB处理请求并承担申请锁、获得锁之后向其他DDB节点刷新数据的任务；用户进程只需要用LibDDB异步等待数据刷新结果和获得返回的索引Index即可。

4.根据权利要求1所述的构建“类型-索引-内容”方式分布式数据库的方法，其特征是：所述加锁请求可以来自客户端，也可以来自其他主机节点使用客户端的进程，其加锁解锁请求步骤如下：

②收到来自其他节点的加锁请求之后，比较加锁请求中的时间戳和本地逻辑时间戳，取最大值加1，先判断来自本地客户端的同时还未收集齐其他主机应答的优先级最高的加锁请求的时间戳即时间戳最小者和该加锁请求的时间戳谁更早，如果该请求早，则发送回应，反之，则直接加入请求REQUEST队列；

5.根据权利要求4所述的构建“类型-索引-内容”方式分布式数据库的方法，其特征是：所述的逻辑时间戳采用真实时间戳来作为一个节点逻辑时钟的起始点即一个节点开始进入工作状态前，先获得当前本地的真实时间戳，后启动主机的时戳应大于之前的主机时戳，锁服务中发生事件时递增1微妙的时间戳作为递增值。

6.根据权利要求1所述的构建“类型-索引-内容”方式分布式数据库的方法，其特征是：所述的分布式锁服务进程DLS生成的索引值Index直接由改进逻辑时钟+本地IP信息生成，其生成出来的Index在各主机间是不同的，由于时间在流逝，即使同一主机出现了关机的现象，Index也不可能重复。

7.根据权利要求3所述的构建“类型-索引-内容”方式分布式数据库的方法，其特征是：所述的DDB刷新数据的任务即版本刷新由两个步骤完成，发送版本心跳和版本刷新合并，版本刷新的处理流程如下：流程开始，收到关于版本信息的心跳报文；比较；判定是删除的记录吗，如果是，则做删除处理；如果不是，则再次判定是否则收到版本，如果是，再次判定自己是否拥有本记录最高版本的主机中IP最小的，如果不是则回到开始阶段重新开始；如果是，则加入被更新列表，在版本稳定一段时间后更新这些版本旧的节点；流程结束。