CN101751292A - Atc***中一种实现多机关键数据一致性功能的方法 - Google Patents
Atc***中一种实现多机关键数据一致性功能的方法 Download PDFInfo
- Publication number
- CN101751292A CN101751292A CN200910216673A CN200910216673A CN101751292A CN 101751292 A CN101751292 A CN 101751292A CN 200910216673 A CN200910216673 A CN 200910216673A CN 200910216673 A CN200910216673 A CN 200910216673A CN 101751292 A CN101751292 A CN 101751292A
- Authority
- CN
- China
- Prior art keywords
- data
- request
- kdc
- locking
- node
- Prior art date
- Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
- Granted
Links
Images
Landscapes
- Information Retrieval, Db Structures And Fs Structures Therefor (AREA)
- Multi Processors (AREA)
Abstract
本发明提供了ATC***中实现多机关键数据一致性功能的方法。利用加锁机制避免多个主机多个进程并行对数据进行修改,加锁机制按每个Key值为粒度,需要对除本机节点外的其他主机发出加锁请求,发出请求前形成等待队列,请求带有逻辑时戳,各节点对收到的来自其他主机的加锁请求进行比较以决定是否发出请求回应;发出加锁请求的节点在检查到等待队列为空时,认为自己已经获得锁并开始分发数据。在等待加锁等待队列为空的过程中,如果本机使用该服务的进程对该key值提出更新请求,则覆盖前一个对同Key值的更新请求,作为一种压缩性的处理。当某个Key值需要被某节点读取时,也需要使用加锁数据,这样不会读到在某条数据更新中的脏数据,保证了各节点同一个Key值按并发顺序性出现。
Description
技术领域
本发明涉及计算机分布式***应用领域,尤其是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)运行结束。
Priority Applications (1)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
CN200910216673XA CN101751292B (zh) | 2009-12-10 | 2009-12-10 | Atc***中一种实现多机关键数据一致性功能的方法 |
Applications Claiming Priority (1)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
CN200910216673XA CN101751292B (zh) | 2009-12-10 | 2009-12-10 | Atc***中一种实现多机关键数据一致性功能的方法 |
Publications (2)
Publication Number | Publication Date |
---|---|
CN101751292A true CN101751292A (zh) | 2010-06-23 |
CN101751292B CN101751292B (zh) | 2012-11-07 |
Family
ID=42478304
Family Applications (1)
Application Number | Title | Priority Date | Filing Date |
---|---|---|---|
CN200910216673XA Active CN101751292B (zh) | 2009-12-10 | 2009-12-10 | Atc***中一种实现多机关键数据一致性功能的方法 |
Country Status (1)
Country | Link |
---|---|
CN (1) | CN101751292B (zh) |
Cited By (4)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
CN103369601A (zh) * | 2013-07-15 | 2013-10-23 | 厦门卓讯信息技术有限公司 | 为手机客户端提供大并发处理及流量控制的方法 |
CN106557562A (zh) * | 2016-11-14 | 2017-04-05 | 天津南大通用数据技术股份有限公司 | 一种单机数据库数据的查询方法及装置 |
WO2017088180A1 (zh) * | 2015-11-27 | 2017-06-01 | 华为技术有限公司 | 向队列存储数据的方法、装置及设备 |
CN114726836A (zh) * | 2022-04-25 | 2022-07-08 | 四川智能建造科技股份有限公司 | 一种分布式应用分发部署方法和*** |
Family Cites Families (2)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
CN1268100C (zh) * | 2002-11-27 | 2006-08-02 | 华为技术有限公司 | 利用与承载无关的呼叫控制协议业务节点处理信令的方法 |
CN101110835B (zh) * | 2007-09-06 | 2010-12-29 | 中兴通讯股份有限公司 | 共享初始过滤规则集的下发方法 |
-
2009
- 2009-12-10 CN CN200910216673XA patent/CN101751292B/zh active Active
Cited By (5)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
CN103369601A (zh) * | 2013-07-15 | 2013-10-23 | 厦门卓讯信息技术有限公司 | 为手机客户端提供大并发处理及流量控制的方法 |
CN103369601B (zh) * | 2013-07-15 | 2016-01-20 | 厦门卓讯信息技术有限公司 | 为手机客户端提供大并发处理及流量控制的方法 |
WO2017088180A1 (zh) * | 2015-11-27 | 2017-06-01 | 华为技术有限公司 | 向队列存储数据的方法、装置及设备 |
CN106557562A (zh) * | 2016-11-14 | 2017-04-05 | 天津南大通用数据技术股份有限公司 | 一种单机数据库数据的查询方法及装置 |
CN114726836A (zh) * | 2022-04-25 | 2022-07-08 | 四川智能建造科技股份有限公司 | 一种分布式应用分发部署方法和*** |
Also Published As
Publication number | Publication date |
---|---|
CN101751292B (zh) | 2012-11-07 |
Similar Documents
Publication | Publication Date | Title |
---|---|---|
EP4030315A1 (en) | Database transaction processing method and apparatus, and server and storage medium | |
EP2932370B1 (en) | System and method for performing a transaction in a massively parallel processing database | |
US10503699B2 (en) | Metadata synchronization in a distrubuted database | |
US10296629B2 (en) | Server supporting a consistent client-side cache | |
US5452445A (en) | Two-pass multi-version read consistency | |
US8401994B2 (en) | Distributed consistent grid of in-memory database caches | |
CN109753364A (zh) | 一种基于网络的分布式锁的实现方法、设备及介质 | |
US20020035559A1 (en) | System and method for a decision engine and architecture for providing high-performance data querying operations | |
US20190384775A1 (en) | Active Transaction List Synchronization Method and Apparatus | |
CN106021468B (zh) | 分布式缓存和本地缓存的更新方法和*** | |
CN103036717A (zh) | 分布式数据的一致性维护***和方法 | |
KR101296778B1 (ko) | NoSQL 데이터베이스를 위한 결과적 트랜잭션 처리 방법 | |
CN113010549B (zh) | 基于异地多活***的数据处理方法、相关设备及存储介质 | |
CN106681861A (zh) | 一种新环境隔离的配置数据管理方法及*** | |
CN113315710A (zh) | 基于异步动态路由的中台api网关管理配置及扩展方法 | |
CN110968603A (zh) | 一种数据访问方法及装置 | |
CN101751292B (zh) | Atc***中一种实现多机关键数据一致性功能的方法 | |
US20230110826A1 (en) | Log execution method and apparatus, computer device and storage medium | |
Wu et al. | Tango: a flexible mobility-enabled architecture for online and offline mobile enterprise applications | |
US20230098963A1 (en) | Object processing method and apparatus, computer device, and storage medium | |
US7752225B2 (en) | Replication and mapping mechanism for recreating memory durations | |
CN111736809A (zh) | 分布式机器人集群网络管理框架及其实现方法 | |
CN111400097A (zh) | 数据的备份方法、装置、***和计算机可读存储介质 | |
CN117493458A (zh) | 一种redis多从节点链式复制自动搭建的方法 | |
CN112966047B (zh) | 一种基于分布式数据库的复制表功能实现方法 |
Legal Events
Date | Code | Title | Description |
---|---|---|---|
C06 | Publication | ||
PB01 | Publication | ||
C10 | Entry into substantive examination | ||
SE01 | Entry into force of request for substantive examination | ||
C14 | Grant of patent or utility model | ||
GR01 | Patent grant |