CN101751292A - Atc系统中一种实现多机关键数据一致性功能的方法 - Google Patents

Abstract

本发明提供了ATC系统中实现多机关键数据一致性功能的方法。利用加锁机制避免多个主机多个进程并行对数据进行修改，加锁机制按每个Key值为粒度，需要对除本机节点外的其他主机发出加锁请求，发出请求前形成等待队列，请求带有逻辑时戳，各节点对收到的来自其他主机的加锁请求进行比较以决定是否发出请求回应；发出加锁请求的节点在检查到等待队列为空时，认为自己已经获得锁并开始分发数据。在等待加锁等待队列为空的过程中，如果本机使用该服务的进程对该key值提出更新请求，则覆盖前一个对同Key值的更新请求，作为一种压缩性的处理。当某个Key值需要被某节点读取时，也需要使用加锁数据，这样不会读到在某条数据更新中的脏数据，保证了各节点同一个Key值按并发顺序性出现。

Description

ATC系统中一种实现多机关键数据一致性功能的方法

技术领域

本发明涉及计算机分布式系统应用领域，尤其是ATC系统中一种实现多机关键数据一致性功能的方法，可用于中小型分布式系统中数据一致性功能的实现。

背景技术

在现代空中交通管制系统(简称ATC)中，通常有承担显示任务的多台席位机器，另外还有多台服务器和通讯处理机，需要保持这些机器中相应数据的一致性。当某主机一个进程提出修改某一共享的资源时，也可能其它主机的进程也在试图修改这一资源，如何保证他们的修改按照合理的顺序进行而又不相互干扰一直是需要解决的问题之一。另外，当需要保证一致的数据在一个节点上被修改了，如何保证该修改及时地扩展到整个系统中，即保证数据各副本一致也是另一个需要解决的问题。在ATC系统中目前的趋势是不采用特殊的设备，尤其是网络设备，所以ATC系统目前广泛采用TCP/IP协议作为内部通讯的协议，网络也主要采用一台网为主的高速通信网，进程间数据传递也主要是以基于消息传递的方法为主。本研究适用于ATC系统中运行中非频繁变化但又对运行起关键作用的数据，这些数据以“KEY-Value”的方式进行组织，即每个数据有一个全系统唯一的Key值，Value为该值对应的内容数据；比如ATC系统中席位中划定的临时背景图，是否进行遥传输出等均可以用一个Key表示。以期在保证这些系统中设置的KEY的内容在每个机器上均相同。当一个节点A需要修改一个KEY的值时，它需要向系统中所有其他节点发送请求获得该KEY修改权，我们又称为加锁请求的信息，当一个节点B收到A发来的加锁请求时，B查看自己有没有也在请求修改KEY，若无请求，则B就回应A，告诉A自己允许其修改该KEY，当A收齐了系统中所有其它节点的回应，且该请求在A的请求列表中是最高请求时，它就可以修改该KEY的数据了。经文献检索暂未发现有这方面的公开报道。

发明内容

本发明旨在解决以ATC系统为代表的分布式系统中保证数据一致性与资源访问的互斥问题。

实现本发明之目的的技术解决方案是这样的：

ATC系统中一种实现多机关键数据一致性功能的方法，包括在ATC分布式系统中的每台主机都运行数据一致性服务端跨平台软件(简称KDC)，所述KDC提供了编程接口LibKDC库，每个需要使用关键数据一致性功能的应用进程都需要使用这个接口库，作为KDC的客户端，并按照接口要求提供进程号；其特征是：

(1)当一个使用编程接口LibKDC的进程需要修改某个Key值的信息时，需要向数据一致性服务端KDC程序发出加锁请求；

(2)数据一致性服务端KDC向其他主机的KDC通过消息机制进行询问；

(3)当确认加锁成功后，需要将该数据向其他主机同步，最后修改本地数据库；

(4)完成后进程发出锁使用完毕的报文，数据一致性服务端KDC对还在等待进行锁请求回应的主机锁发出批准报文，这样其他进程也可以访问该Key的数据；

(5)收到更新数据的数据一致性服务端KDC修改本地数据；

(6)在更新数据以后，查询对该Key值发起过订阅的进程，对这些进程发出指令。

所述的ATC系统中一种实现多机关键数据一致功能性的方法，其特征是，所述的加锁请求与更新数据的步骤如下：

(2.1)运行开始，数据一致性服务端KDC收到客户端请求，对系统中除了本机外的活跃节点发出加锁请求，并形成回应等待队列；

(2.2)暂时没有获得锁但又收到本机任意客户端对同一Key的请求，覆盖原请求；

(2.3)询问收到锁请求，其逻辑时戳比本地等待中的最小的时戳要小吗？如果是，对加锁请求发出加锁回应报文，如果回答不是，对该请求暂时放入队列中；

(2.4)接收加锁回应报文，并在期待列表中去掉报文发出节点；

(2.5)再次询问是否该锁的期待回应为空？如果回答不是，则返回(2.2)步；

(2.6)如果回答是，则使用最新的对Key对应的Value值对数据进行修改，并传递到其它主机；

(2.7)检查发向本地的请求锁队列中逻辑时戳最小的请求，对其发出加锁回应；

(2.8)运行结束。

本发明能够支持1～32台主机，这些主机可以在硬件配置和操作系统平台上不一致，至少可以支持全系统中有100个KEY，且KEY的设置是任意的，与具体应用无关。对于需要同步的数据，系统间节点间耦合度较低，任何节点主机都是平等的，任何一个机器或者进程退出都不会对系统造成较大影响，新加入的主机可以很快很好的融入到系统中。使用该功能的是系统中每个主机的进程，每个进程在一台主机上是唯一的，如果一个进程在一台主机上需要运行成两个实例，应在使用本发明提供的API接口时能够予以区分；本发明要求对整个系统进程按类型进行编号，编号应不重复，但具体的进程编号与本发明提供的方法是无关和隔离的，同时本发明与应用是无关，不仅可以应用于ATC系统对其他类似分布式系统同样适用。

与现有技术比较本发明具有突出的优点。其一，该发明实现了中小型分布式系统中数据一致性的保证，该方法具有通用性，适用其他类似系统，具有较大的应用前景和价值。其二，本发明描述的KDC操作的粒度为每一个Key值，粒度较小具有很好的并发性，同时所使用的KEY是自定义的与应用无关。其三，在ATC系统中试用效果良好，实现了本发明的目的。

附图说明

图1是本发明所述数据一致性服务端(KDC)跨平台软件部署示意图。

图2是本发明所述的加锁及数据更新流程示意图。

图3图4是本发明所述的逻辑时戳与KDC互斥机制原理示意图。

图5是本发明所述的KDC修改数据过程实施例示意图。

图6是本发明所述的KDC版本同步实施例示意图。

具体实施方式

参见附图给出实施例并对发明做出进一步的说明。从图1可知，本发明中要求分布式系统中的每台主机都运行数据一致性服务端KDC一个，该软件是一个跨平台软件，目前可在WIN32\SOLARIS\LINUX\VXWORK平台上运行。该软件的运行需要系统配置文件。

KDC提供了编程接口LibKDC库，每个需要使用关键数据一致性功能的应用进程都需要使用这个接口库，作为KDC的客户端，并按照接口要求提供进程号等信息。KDC的配置文件对全系统有效，各主机使用同意内容的配置文件，LibKDC会用到配置文件的一部分，LibKDC需要知道系统中定义的KEY和KDC用于监听的端口号等信息。

KDC服务端使用嵌入式数据库BDB(Berkely DB)运行，Key-Value信息作为一个记录被写入和读出；KDC客户端提供对指定Key的加锁、解锁、写入、读出、指定对某Key值的订阅功能，同时支持当某个Key被修改时的异步通知对此Key订阅过进程的功能。

KDC与使用LibKDC的进程间通过进程间(IPC)方式进行通讯，本发明中IPC使用IP为127.0.0.1的主机本地回环(Loopback)地址，KDC作为TCP服务端，LibKDC作为TCP客户端完成。

嵌入式数据库BDB可以支持一台主机内不同进程的并发访问，KDC与多个使用LibKDC的程序可以同时访问BDB形成的数据库。

设计中每个Key为一个字符串，对特定系统要求将所用的Key全部列入配置文件中，并进行连续编号，每个编号即为该Key的索引，在代码实现中是以每个Key对应的索引用以内部操作和数据传输中区分不同Key，编程接口。参见图2，

(1)当一个使用编程接口LibKDC的进程需要修改某个Key值的信息时，需要向数据一致性服务端KDC程序发出加锁请求；

(2)数据一致性服务端KDC向其他主机的KDC通过消息机制进行询问；

(3)当确认加锁成功后，需要将该数据向其他主机同步，最后修改本地数据库；

(4)完成后进程发出释放锁的请求，数据一致性服务端KDC再通知其他主机锁已经释放了锁，这样其他进程也可以访问该Key的数据；

(5)收到更新数据的数据一致性服务端KDC修改数据进程所在的本地KDC；

(6)在更新数据以后，查询对该Key值发起过订阅的进程，对这些进程发出指令；

(7)进程收到该指令后，可以立即读取该Key值的数据。

在所述的ATC系统中一种实现多机关键数据一致功能性的方法中，所述的加锁请求与更新数据的步骤如下：

(2.1)运行开始，数据一致性服务端KDC收到客户端请求，对系统中除了本机外的活跃节点发出加锁请求，并形成回应等待队列；

(2.2)暂时没有获得锁但又收到本机任意客户端对同一Key的请求，覆盖原请求；

(2.3)询问收到锁请求，其逻辑时戳比本地等待中的最小的时戳要小吗？如果是，对加锁请求发出加锁回应报文，如果回答不是，对该请求暂时放入队列中；

(2.4)接收加锁回应报文，并在期待列表中去掉报文发出节点；

(2.5)再次询问是否该锁的期待回应为空？如果回答不是，则返回(2.2)步；

(2.6)如果回答是，则使用最新的对Key对应的Value值对数据进行修改，并传递到其它主机；

(2.7)检查发向本地的请求锁队列中逻辑时戳最小的请求，对其发出加锁回应；

(2.8)运行结束。

本发明最重要的是使用了加锁机制避免多个主机多个进程并地对数据进行修改，加锁机制按每个Key值为粒度，需要对除本机节点外的其他主机发出加锁请求，发出请求前形成等待队列，请求带有逻辑时戳，各节点对收到的来自其他主机的加锁请求进行比较以决定是否发出请求回应；发出加锁请求的节点在检查到等待队列为空时，认为自己已经获得锁并开始分发数据。在等待枷锁等待队列为空的过程中，如果本机使用该服务的进程对该key值提出更新请求，则覆盖前一个对同Key值的更新请求，作为一种压缩性的处理。当某个Key值需要被某节点读取时，也需要使用加锁数据，这样不会读到在某条数据更新过程中的脏数据，该方法保证了个节点同一个Key值按并发的顺序性出现。

图3图4给出了所述的逻辑时戳与KDC互斥机制原理示意图。本发明中消息传递使用逻辑时间戳，分布式系统没有内在统一时钟，本方案采用Lamport逻辑时钟生成的逻辑时钟作为内部时钟，即每个进程Pi都有一个逻辑时钟Lci＞0，且非减的整数序列，(m，Lci，i)Lci的更新基于以下规则：

规则1：在发生一个事件之前，我们更新Lci：lci＝lci+d(d＞0)

规则2：当收到一个带时戳的消息时，Pi执行更新：Lci＝max(Lci，LCj)+

假设每个lci初始化为INIT＞0，对于不同的进程可以有不同的初始化值Lamport逻辑时钟给出了一种分布式系统中所有事件分配时间的方法，它遵循下面规则：

(a)：若在同一进程中a在b之前发生，则C(a)＜C(b)。

(b)：若a和b分别代表发送一个消息和接收该消息的事件则C(a)＜C(b)。

(c)：对于所有不同的事件a和b，C(a)≠C(b)。

图4说明了P1具有较小逻辑时戳先获得锁：

这个算法提供了一种对系统中所有的事件进行完全的排序的方法，对比各主机物理时钟，该算法使用因果关系产生时钟，如图4所示。为实现整个分布式系统中对指定Key值数据的互斥访问，任何一个进程在修改某Key的数据前都需要通过消息先向系统中的其他主机请求该KEY的锁，收到该节点请求的节点，会根据自己的状态来决定是否立即给予应答它，若自己没有逻辑时间戳比收到的这个请求更早的未决请求，就立即回应，若自己有逻辑时间戳比收到的这个请求更早的请求(即未决请求)，则就将对方的请求放入本地的请求队列；只有收齐了其他所有主机的回应才可以获得锁。只有获得锁的进程才可以对其内容进行修改。当多个进程请求锁时，依照图4所示原理确定给锁的先后顺序：

图中箭头方向代表发送请求锁的报文的方向，箭头上的数字代表请求的逻辑时戳，方框代表分布式进程。在P1和P2几乎同时发出加锁请求时因为P1发出时的逻辑时戳比P2的小，所以P1首先获得锁，在P1释放锁后，P2才会获得锁。

图5是本发明的一个实施例。当hostl上的进程1需要修改KEY的数据时，它直接调用客户端库LibKdc的Modify函数，该函数指定要修改的Key值和对应的数据，Modify函数先将分布式锁的请求报文发到本地的KDC，本地KDC收到请求后将该请求发送到系统中的其它主机，当其它主机收到加锁请求报文后根据上诉算法选择立即回复或者稍后回复，当hostl上的KDC收齐了其他主机的回应，它就向客户端进程发送加锁成功报文，当客户端收到加锁成功报文后就将数据部分发到本地KDC服务进程中，当本地KDC向其他主机发送完刷新数据后修改本地BDB数据库，本地KDC通知本地客户端锁已经释放，其修改操作完成。步骤如图5所示。为了保存自己本地的未决的请求和其他主机发来的自己暂时未回应的请求，KDC设计了一个请求队列，该队列以KEY为索引来存储针对它的请求，我们设计了变量map<WORD，list<tagReqLock>>map RequestList，即以第一项Key的索引，第二项请求信息>来保存请求队列。

当KDC向当前系统中活动的其它节点发送加锁请求时，它每向一个节点发送请求它都期待从该节点得到答复，只有收到了所有的答复它才能获得锁，因此，我们需要记录它都向哪些主机节点发送了请求并等待这些节点的回复(因为系统中的节点可能加入也可能退出，所以仅仅参照活动节点列表是不够的)，为此，我们设计了期望请求队列map<string，list<WORD>>mapExpReplyList；//<logic_stamp，list<host_num>>，这个映射的第一项是一个字符串表示超过一个长整型的大整数的逻辑时戳需要说明的是为满足长时间工作的需要，标准的4字节长整形可能不满足要求，所以需要有位数更长的大整数来进行表示；第二项是期望回复的主机列表，逻辑时戳可以唯一标志一个本地请求，每个本地请求都有一个期望回复队列，这个队列在请求发送到其它节点时添加，每成功地将加锁请求发向一个主机就将这个主机的主机号添加到这个对应的list中去，这样，当发送完后，list中有几项数据就等于一共向几个主机发送了请求。当发送请求的KDC收到了某主机的回应的时候，就将回应主机的主机号从这个期望列表中删除。总之，期望列表中存放的是期望从其得到回应的主机号，得到回应后就将其删除。可知，当list为空的时候就说明收齐了回应。此时若该请求在本地一收集完回应的同Key值请求中逻辑时钟最小，即判定获得锁。

需要说明的是图1中KDC系统中各部分之间的联系，在本方案中网络通信是联系LibKdc和KDC、KDC和KDC之间的纽带，所有的交互信息都是通过socket网络通信实现的，例如：所述的LibKdc与KDC，这两类软件均在一台主机上运行，可选的IPC通信方案很多，为了更好地实现跨平台的特性，本方案选用的是所谓的主机loopback IP地址“127.0.0.1”，协议为TCP协议。我们采用了双TCP连接策略，即在LibKdc与KDC之间存在两条TCP连接，一条是数据端连接，主要是用来传输需要刷新的数据，另一条是控制连接，用来交互控制报文。KDC作为服务端在一个固定端口上侦听；LibKdc接这个端口。KDC中核心互斥算法设计采用一个单线程程序，内部使用select多路复用机制，LibKdc与KDC的通信部分中接收模块为一个线程，该线程中一样使用select多路复用机制。TCP协议通信的任何一端退出时，另一端调用recv会返回小于或等于零，在本方案中使用这一技术作为双方判断对方是否退出的依据，并决定响应动作。当KDC发现LibKdc退出时将立即清除该LibKdc的请求和订阅等信息。关于KDC与KDC之间的联系，KDC之间也设置了TCP连接，也有数据端连接和控制端连接，其分工与上面一样；这两个连接的FD都在一个线程里，其内部使用select多路复用机制。此外，每两个KDC之间都还有一个用于数据刷新的TCP连接，这个连接运行在一个独立线程中，为的是避免因刷新的数据可能比较大而影响控制信息的发送。另外，KDC之间还有心跳报文的广播，目的是让其他KDC知道彼此的一些重要的信息，同时也可以在对方假死或者对方网线被拔掉时作为判定该主机退出的判断依据。

图6是本发明所述的KDC版本同步实施例。在实践中存在这样一类节点，在获得锁的节点更新某个KEY值时，如果这个节点没有启动或节点故障，在更新操作执行以后该节点恢复运行，但此后这个KEY的信息在系统中再无节点提出更新请求并进行更新，这个节点该KEY的数据将长时间处于低版本，本发明设计一种使数据版本一致的方法。每个节点都广播自己的KEY及其版本号，当最后一次对这个KEY值刷新的节点KDC发现系统中存在某些节点的版本号过低且持续了一段时间，它就会申请去同步这个低版本的数据，当然，它也需要经过申请锁、刷新旧版本节点、释放锁这几个步骤。

每个节点内部维护了两个列表。当前系统最大版本号列表m_LastVersionSys，为map<unsigned short，KeyVersionStampConst>和本机本地版本号列表m_LocalVersion为map<unsigned short，largeint>。系统最大版本号列表用于判断哪些节点属于旧版本节点，以便在发起版本同步时向其发送更新数据，本机本地版本号列表用于在心跳中发送本机版本信息。m_LastVersionSys和m_LocalVersion内对应KEY值的版本号不一定相等，当且仅当最新版本由本地刷新时相等。

版本号由一个字符串存储的大数表示，在系统最初启动时，系统内部所有KEY值对应的数据的版本号均为0。在部分节点关闭重启时，需要从数据库中读取各个KEY值的版本号。版本号增长的一般情况为：某节点收到来自客户端对某KEY值的数据刷新请求，在得到锁之后，将客户端的刷新数据向其他节点发送，然后刷新本节点的数据库，并相应将本地数据库的对应KEY值的版本号加1。实际情况下，有部分节点刷新该版本的数据可能没有成功。或者在某个时刻部分节点已经被关闭，在它们重新启动之后，数据需要和系统内的其他节点保持一致性。为了达到这个目的，系统采用了心跳报文广播节点KEY值和其对应版本号和主动版本同步两种机制来共同保证一致性。

另外在运行中需要注意的是系统初始化。KDC运行之初的状态我们称为初始化阶段，在系统初始化阶段，本发明设计为从起始到稳定需要以下过程：只有最后处于稳定状态的KDC才可以为客户端提供服务，没有处于稳定状态的KDC只能收发心跳包，而不能证实作为节点加入数据一致的工作。KDC节点初始化时只可能在下面两种情况下达到稳定状态：A收到了另外一个已经处于稳定状态的节点发来的心跳报文，或者，B自己已经运行了配置文件中设置的最长初始化时间。要达到稳定状态目的是让自己的逻辑时戳与系统中的逻辑时戳同步，以免一个刚刚加进来的节点突然发送一个逻辑时钟很小的请求。设置最大初始化时间的目的是存在这样一种情况：系统中只有一台KDC在运行时，它收不到心跳报文，它需要经过一个初始化时间以后才能够稳定。

Claims (2)

1.ATC系统中一种实现多机关键数据一致性功能的方法，包括在ATC分布式系统中的每台主机都运行数据一致性服务端跨平台软件(简称KDC)，所述KDC提供了编程接口LibKDC库，每个需要使用关键数据一致性功能的应用进程都需要使用这个接口库，作为KDC的客户端，并按照接口要求提供进程号；其特征是：

(1)当一个使用编程接口LibKDC的进程需要修改某个Key值的信息时，需要向数据一致性服务端KDC程序发出加锁请求；

(2)数据一致性服务端KDC向其他主机的KDC通过消息机制进行询问；

(3)当确认加锁成功后，需要将该数据向其他主机同步，最后修改本地数据库；

(4)完成后进程发出锁使用完毕的报文，数据一致性服务端KDC对还在等待进行锁请求回应的主机发出批准报文，这样其他进程也可以访问该Key的数据；

(5)收到更新数据的数据一致性服务端KDC修改本地数据；

(6)在更新数据以后，查询对该Key值发起过订阅的进程，对这些进程发出通知指令；

(7)进程收到该指令后，可以立即读取该Key值的数据。

2.根据权利要求1所述的ATC系统中一种实现多机关键数据一致功能性的方法，其特征是，所述的加锁请求与更新数据的步骤如下：

(2.1)运行开始，数据一致性服务端KDC收到客户端请求，对系统中除了本机外的活跃节点发出加锁请求，并形成回应等待队列；

(2.2)暂时没有获得锁但又收到本机任意客户端对同一Key的请求，覆盖原请求；

(2.3)询问收到锁请求，其逻辑时戳比本地等待中的最小的时戳要小吗？如果是，对加锁请求发出加锁回应报文，如果回答不是，对该请求暂时放入队列中；

(2.4)接收加锁回应报文，并在期待列表中去掉报文发出节点；

(2.5)再次询问是否该锁的期待回应为空？如果回答不是，则返回(2.2)步；

(2.6)如果回答是，则使用最新的对Key对应的Value值对数据进行修改，并传递到其它主机；

(2.7)检查发向本地的请求锁队列中逻辑时戳最小的请求，对其发出加锁回应；

(2.8)运行结束。

Images