CN104468722A - 一种航管训练系统中训练数据分类存储的方法 - Google Patents

一种航管训练系统中训练数据分类存储的方法 Download PDF

Info

Publication number
CN104468722A
CN104468722A CN201410631306.7A CN201410631306A CN104468722A CN 104468722 A CN104468722 A CN 104468722A CN 201410631306 A CN201410631306 A CN 201410631306A CN 104468722 A CN104468722 A CN 104468722A
Authority
CN
China
Prior art keywords
coordinator
request
node
client
data
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
Application number
CN201410631306.7A
Other languages
English (en)
Other versions
CN104468722B (zh
Inventor
胡术
李科磊
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
The Chinese People's Liberation Army 92232 Troops
Sichuan Chuanda Zhisheng Software Co Ltd
Original Assignee
Sichuan Chuanda Zhisheng Software Co Ltd
Priority date (The priority date 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 date listed.)
Filing date
Publication date
Application filed by Sichuan Chuanda Zhisheng Software Co Ltd filed Critical Sichuan Chuanda Zhisheng Software Co Ltd
Priority to CN201410631306.7A priority Critical patent/CN104468722B/zh
Publication of CN104468722A publication Critical patent/CN104468722A/zh
Application granted granted Critical
Publication of CN104468722B publication Critical patent/CN104468722B/zh
Active legal-status Critical Current
Anticipated expiration legal-status Critical

Links

Classifications

    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L67/00Network arrangements or protocols for supporting network services or applications
    • H04L67/01Protocols
    • H04L67/10Protocols in which an application is distributed across nodes in the network
    • H04L67/1097Protocols in which an application is distributed across nodes in the network for distributed storage of data in networks, e.g. transport arrangements for network file system [NFS], storage area networks [SAN] or network attached storage [NAS]
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L67/00Network arrangements or protocols for supporting network services or applications
    • H04L67/01Protocols
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L67/00Network arrangements or protocols for supporting network services or applications
    • H04L67/01Protocols
    • H04L67/10Protocols in which an application is distributed across nodes in the network
    • H04L67/1095Replication or mirroring of data, e.g. scheduling or transport for data synchronisation between network nodes
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L67/00Network arrangements or protocols for supporting network services or applications
    • H04L67/50Network services
    • H04L67/56Provisioning of proxy services
    • H04L67/568Storing data temporarily at an intermediate stage, e.g. caching

Abstract

本发明公开了一种航管训练系统中训练数据分类存储的方法。系统运行于航管训练系统中,在航管训练系统的服务器节点中对等的部署分类数据存储,由客户端代理和服务端两部分组成。客户端代理提供访问接口供客户使用,接管客户和系统各个节点的通信以及其它系统补足功能。服务端节点有协调者节点和存储节点。协调者节点运行协调者程序,其内部运行共识算法对请求达成一致,存储系统的重要数据;一个或者多个存储节点组成一个复制组,其上存储某种类型的数据,通过冗余达到数据存储的高可靠性,每个存储节点可以属于不同的复制组,存储不同种类的数据。本发明实现了在同一系统架构下以不同的一致性存储不同种类的航管训练系统数据,方便实用。

Description

一种航管训练系统中训练数据分类存储的方法
一、所属技术领域
本发明涉及计算机应用领域,尤其涉及航管训练系统,具体是一种航管训练系统数据分类存储的方法。
二、背景技术
航管训练要正常运行既需要训练的额准备数据,也有运行中产生的数据,在大型的航管训练系统进行长时间的、复杂流程的训练活动时对运行数据的存储提出了不同的要求,有的需要保存历史上最近的几个,有的需要在全系统都进行分发并生效,有的需要在仿真服务器副本间保持高度的一致,避免因为仿真服务器部分故障带来的长时间训练活动的混乱。
航管训练系统中,航管训练运行中的数据主要有四类:
第一类数据是基础数据,包括受训数据中的机场信息、进离场航线、地标点、导航台站信息、机型数据、飞机性能参数、航路航线等。在一次训练中,这类数据几乎不改变。这些数据的原始信息一般存放在关系型数据库中,这些数据的创建、编辑、修改操作主要通过训练准备席位完成,数据发布时需要通过训练准备席位生成受训基础数据,如数据字典,XML文件,在下一次训练开始前,一般需要对这些数据重新制作发布并在训练系统重新启动后生效。一般把这类数据叫做训练静态数据,也就是说这类数据存放于数据库并在训练前作为准备数据的一部分,按照特定格式生成并分发到训练系统各主机,在随后的训练中使用。
第二类数据是系统在运行中不断产生但一般情况下人们只关心最近的N个数据。如模拟服务器发出的目标轨迹数据,训练正常进行时受训席位只需要正常运行就可以接收和使用,无需从仿真计算服务器或其他受训席位获取之前的历史数据,这些数据由仿真服务器生成并在受训席位保存最近N个历史的点的数据。
第三类数据是系统运行中用户根据受训想定任务需要临时编辑、修改的数据。如临时背景图、临时设置空域的激活时间等,这些数据需要传送到模拟数据处理服务器参加处理和相关席位进行显示。这类数据一般变化频率低,发起编辑修改的主要是受训席位、训练控制席位。这类数据需要存在于训练系统各主机,但更新频率很低,允许各主机间一段时间内数据存在差异。
第四类数据是如模拟飞行数据这样的动态数据,主要表现在:仿真计算服务器运行中的内部计算会对这类数据进行修改,同时受训席位也提供对数据的编辑、修改操作,数据更新 频率高。这些数据需要通过使用具备高可靠性的复制技术确保数据不错、不丢、不乱,这类数据仅存在于仿真服务器中,要求仿真服务器间这类数据严格的一致,否则会出现仿真数据不一致,模拟飞行数据版本丢失、错乱的问题。
以上四类数据中,第三类和第四类数据需要采用分布式复制方法予以实现。
三、发明内容
本发明针对航管训练系统中训练数据使用的不同需要和要求,不同种类的航管训练系统数据有不同的存储特点,提供一种训练数据分类存储的方法。这种方法充分考虑训练时对各种数据的不同需要,站在全系统设计的基础上,在同一系统架构下以不同的一致性存储不同种类的航管训练系统数据,以提供更为灵活的存储访问方式。
由于最终一致性用于分布式复制,复制的效率较高,虽然它可能造成数据的失序或者中间版本丢失。但是在一些一致性要求较低,却对性能要求较高、副本较多的场景下,最终一致性是一个可以接受的选择。因此,我们使用最终一致性模型进行第三类数据的存储——比如对于临时编辑空域,所有的服务器上在一个时间窗口之后最终会具有相同的临时空域编辑数据,这样每个席位最终都会具有相同的显示。
第四类数据的数据量小,更新频繁,存储副本数量少,我们可以使用强一致性模型存储第四类数据——任意时刻,任意席位在任意服务器中,读到的数据都是最近一次成功更新的。为了保证这一点,我们使用共识算法以在多个副本之间对请求序列达成一致。
本发明的目的是这样达到的:本发明的系统运行于航管训练系统中,使用异步通信,并使用超时重传机制,选择远程过程通信RPC作为网络通信的方式;在航管训练系统的服务器节点中对等的部署分类数据存储,通过数据流控制结构实现数据存储的副本数、读写请求的性能以及回应的发送时机,并为使用该系统的应用程序提供对数据进行访问的读写接口,实现分类数据的可靠、高效存储。
系统由客户端代理和服务端两部分组成,其中客户端代理提供访问接口供使用分类数据的客户即应用程序使用,接管客户和系统各个节点的通信以及其它系统补足功能;服务端节点有两种角色:协调者节点和存储节点,一个节点可以同时扮演两种角色;协调者节点运行协调者程序,其内部运行共识算法对请求达成一致,存储系统的重要数据;一个或者多个存储节点组成一个复制组,其上存储某种类型的数据,通过冗余达到数据存储的高可靠性,每个存储节点可以属于不同的复制组,存储不同种类的数据。
使用协调算法达成当前成员组成的共识,实现协调者的一致性;使用Master选举算法选 举协调者的主态机,实现使用中心化副本控制协议;运行成员移除和加入算法,提高系统的可用性;在复制组层面上,通过定义一致性控制结构来达到不同的一致性。
整个系统的请求处理流程是:
1)协调者Coordinator集群内部首先通过协调算法达成稳定状态;
2)然后协调者Coordinator集群向存储Storager复制组中的选定节点发送租约消息;
3)存储Storager复制组的节点回应租约消息,整个系统进入稳定状态;
4)客户端通过客户端代理ClientProxy向系统发送读、写请求;
5)客户端代理ClientProxy先向协调者Coordinator集群请求存储Storager复制组的信息;
6)协调者Coordinator集群返回Storager复制组信息; 
7)客户端代理ClientProxy向正确的存储Storager复制组发送请求;
8)存储Storager复制组内部根据本组数据一致性要求进行数据操作;
9)存储Storager复制组将执行结果返回给客户端代理ClientProxy;
10)客户端代理ClientProxy将请求返回给客户端。
所述系统由客户端代理和服务端两部分组成,其系统的架构是:
位于系统最上层的是一个全局的协调者Coordinator,使用协调协议来实现协调者内部数据的复制强一致性,并进行协调者内部的动态成员管理,协调者主机中存放各种重要数据;
协调者之下是由存储Storager节点组成的复制组构成的存储层,一个存储Storager节点可以属于多个复制组,存储Storager复制组每个主机上部署开源key-value存储引擎Redis,同时定时向协调者报告状态,提供多种一致性语义。
位于客户端和存储层之间的是一个客户端代理,客户端代理在某应用程序启动时向协调者发送连接请求,以获取该应用程序数据存储的通信地址,同时自动连接到这个存储节点准备进行操作。
所述使用协调算法达成当前成员组成的共识,实现协调者的一致性是:
协调者Coordinator使用协调算法来达成协调者各节点对需协调的事件的一致性认知,协调的事件包括:协调者内部增加成员、协调者内部减少成员、选举协调者内部的主态机Master节点,系统内部存储Storager节点复制组当前的组成和当前的主态机Primary主机。
协调者Coordinator内部节点采用依次的方法进行通信,三个主机组成协调者时,其IP地址依次为IP1、IP2、IP3,这里IP1<IP2<IP3,IP1不断向IP2主机报告心跳,IP2不断向 IP3报告心跳,IP3向IP1报告心跳信息。
协调算法的流程是:初始时,将参与算法的主机数目Host_num赋予系统配置的主机数n,同时将协调编号Agreed_id赋值为零,主机通过数Agreed_count赋值为零,协调内容最终通过数Fin_count赋值为零,设置超时等待时间T1;发起协调的主机发出包含Agreed_id的协调请求报文,如果其他主机没有答应其他主机发出的协调请求,就回应愿意就Agreed_id进行协调;发起协调的主机如果没有收集到超过参与协调主机半数以上主机的回应,继续等待直到超时;如果在超时的时间内收到了超过半数的参与协调人员的回应,就进入下一个发送协调内容的阶段;如果在设定的超时时间内都无法满足条件,则回到开始部分重新开始,设定超时等待时间T2;在发送协调内容阶段,发起协调的主机对参与算法的主机发出包含(cor_id,cor_content)的报文,其中cor_content为需要协调的内容,如果节点在之前准备阶段做出了回应,则对协调内容cor_content做出接受的回应,发起协调的主机如果在超时时间T2前收到大多数的回应,则协调认为成功。
所述使用Master选举算法选举协调者的主态机,实现使用中心化副本控制协议是:协调者Coordinator中的Master负责响应客户端的命令,协调者Coordinator内部的Master选举也使用协调算法进行,协调时将协调算法中协调的内容设为某个节点成为主态机Master。
所述运行成员移除和加入算法,提高系统的可用性是:在协调者Coordinator内部出现节点失效后,协调算法中将协调内容设置为移除一个节点,并在协调后完成将该节点移出协调者的工作;当一个节点试图加入到协调者Coordinator时,先向协调者中任意节点发出查询主态机Master的命令,然后向协调者中主态机Master提出加入请求,将加入该节点作为内部协调的内容进行内部协调,完成将该节点加入协调者Coordinator的工作。
所述在复制组层面上,通过定义一致性控制结构来达到不同的一致性:
存储层基于协调者选择一个主态机Primary节点作为中心化副本控制协议的中心控制点,这个节点由协调者指定,并通过租约的方式进行更新,将一个复制组的基本信息存储在协调者中,根据该复制组中运行时间最久的节点作为主态机Primary节点,向其发放租约,即一个时间段,这个节点在收到租约消息后,间隔二分之一的租约时间向协调者发送续租消息;主态机Primary节点选取出来之后,复制组达到稳定状态开始处理客户端的请求;当主态机Primary节点无法收到其它从态机Slave节点的请求回应时,复制组达到不稳定状态,该节点向协调者报告,协调者更新复制组消息,重新进行主态机Primary节点的确定,使复制组重新到达稳定状态;当从态机Slave节点在一个时间段内无法收到主态机Primary节点的心跳 时,复制组达到不稳定状态,协调者更新复制组消息,将复制组信息发送给主态机Primary节点,使复制组重新到达稳定状态。
存储Storager节点复制组使用下述的结构来达成不同的一致性控制和读写性能:
当can_write_slave和can_read_slave为false,并且can_resp_slave_num等于副本数时,一致性是最强的。
所述当can_write_slave和can_read_slave为false,并且can_resp_slave_num等于副本数时,一致性是最强的,其强一致性-写:
客户端代理设置一致性结构的属性,can_write_slave为false,并且can_resp_slave_num等于副本数replicate_num-1,它的更新求首先发送到主态写请求Primary节点,主态Primary节点向所有的从态Secondary节点发送该请求,并启动一个定时器,以避免无限地等待下去,只有收到can_resp_slave_num数目的请求回应之后,主态Primary节点才会在本地执行该请求,并将执行结果返回给客户端;在客户端代理也会设置一个请求回应的定时器,如果在指定时间内收不到请求的回应,则会向协调者查询复制组信息,以确定客户端代理与主态Primary节点的网络连接是否正常,或者在主态Primary节点失效时及时得到通知。
强一致性读:当can_read_slave为false时,客户端代理只能向主态Primary节点发送查询读请求。
如果对可靠性要求不太高,而对性能和响应速度有高要求,设置can_resp_slave_num小于副本数,为1,Primary节点在收到can_resp_slave_num个回应之后在本地执行请求并返回结果,而不是等到收到replicate_num个回应之后,但是它仍然需要在指定时间内收到can_resp_slave_num个回应,,该方式仍然为强一致,为强一致性读操作。
最终写一致性写:
设置can_write_slave为true,设置can_resp_slave_num的数目为不同于副本数的值,客户端代理向从态Secondary节点发送更新写请求,从态Secondary节点向该组其他剩余Primary、Secondary节点传播该请求,并启动一个定时器,只有收到can_resp_slave_num数 目的请求回应之后,从态Secondary节点将该请求向该组剩余Primary、Secondary节点传播请求,在本地执行该请求,并将执行结果返回给客户端;在客户端代理也设置一个请求回应的定时器,如果在指定时间内收不到请求的回应,则会向协调者查询复制组信息,以确定客户端代理与主态Primary节点的网络连接是否正常,或者在主态Primary节点失效时及时得到通知。
最终一致性读:设置can_read_slave为true,客户端代理向从态Secondary节点发起查询读请求,开启请求定时器,等待执行结果,将查询结果发送到客户端代理,在定时器时间内收到请求回应,请求回应成功,在定时器时间内收不到请求回应,向协调者查询复制组消息,客户端代理再次向从态Secondary节点发起查询读请求,直到请求执行成功。
客户端代理包括通信代理和请求代理,通信代理包括与协调者通信,获得元数据信息;同存储节点通信,进行数据操作;同时控制剧本数据传输;请求代理包括为请求编号,缓存请求;记录请求状态;请求速率控制。
客户端完全与系统分离,客户端只需在本地运行一个客户代理的实例即可,无需自己处理同系统的通信,在一个客户加入到系统前,它应该首先向协调者进行元数据——存储Primary节点所在的位置——信息的查询,在得到Primary节点的通信地址后与Primary节点建立连接;在协调者失效时,客户端代理等待协调者稳定状态的达成,或者到达一定的时间后报告一个错误;当所访问的复制组节点发生不可达等失效时,向协调者发送对应的请求消息,并在此之后获得新的存储节点信息,自动连接到该节点。
客户端向客户端代理发送一个consisitency_model_def_t类型的变量,来控制副本中的数据流动,达到自己想要的一致性。
在客户端代理的请求管理中,客户端代理为每个客户端的请求进行编号,以实现请求的最多一次语义和其它语义,这通过将请求编号储存在内存中,每次发送一个请求,其编号就加1;同时记录请求状态:客户端所有的请求都被标记为三种不同的状态:
1)、安全状态:该类状态的请求已经被执行,并被复制到足够数量的副本,客户端可以放心认为此类请求的执行是安全的;
2)、不稳定状态:在允许请求传播到一定副本数量就可以返回的副本控制协议中,请求的执行状态被分为两次返回给客户代理——第一次的返回说明请求已经在给定数量的副本中被执行;第二次的返回则说明请求被传播到足够数量的副本;
3)、危险状态:这个请求已经发出,但是还没有收到执行的返回结果,客户端代理缓存这些请求,等待复制组的稳定状态达成,如果此时客户端要求退出,那么客户端代理进行提醒, 或者是将这些请求发送到协调者,由协调者代为发送。
所述请求速率控制的标准是请求的个数和请求的总大小,到达了一定的请求个数或者危险状态请求大小到达一个阈值后,开始运行速率控制,客户端代理将客户请求缓存到本地,等到前面请求执行完成后再进行发送。
所述客户端所有的请求都被标记为三种不同的状态:
是使用下面的结构来标记请求的状态:
本发明的积极效果是:在航管系统中,不同种类的航管训练系统数据有不同的存储特点,本发明提出使用一种分类数据的存储机制,在同一系统架构下以不同的一致性存储不同种类的航管训练系统数据,以提供更为灵活的存储访问方式,实现了对航管训练系统中分类数据的可靠、高效存储,方便实用,对航管系统软件建设有着十分现实的积极意义。
四、附图说明
图1是本发明系统请求流程图。
图2是本发明系统架构示意图。
图3是本发明协调算法流程图。
图4是复制组主态机Primary节点选取的租约算法流程图。
图5是强一致性写流程图。
图6是强一致性读流程图。
图7是在写入少于副本数后返回流程图。
图8是最终一致性写Secondary副本流程图。
图9是最终一致性读流程图。
图10是客户端代理功能示意图。
五、具体实施方式
航管训练系统是典型的C/S模式,它包括受训席位、控制席位/仿真计算处理服务器集群。
本发明的系统运行于航管训练系统中。在部署上,系统由客户端代理和服务端两部分组 成,其中客户端代理提供访问接口供使用分类数据的客户--应用程序使用,接管客户和系统各个节点的通信以及其它系统补足功能。服务端节点有两种角色:协调者节点和存储节点,一个节点可以同时扮演两种角色;协调者节点运行协调者程序,其内部运行共识算法对请求达成一致,存储系统的重要数据;一个或者多个存储节点组成一个复制组,其上存储某种类型的数据,通过冗余达到数据存储的高可靠性,每个存储节点可以属于不同的复制组,存储不同种类的数据
本发明在航管训练系统的服务器节点中对等的部署分类数据存储,通过数据流控制结构实现数据存储的副本数、读写操作的性能以及回应的发送时机等,并为使用该系统的应用程序提供对数据进行访问的读写接口,实现分类数据的可靠、高效存储。
本发明中使用异步通信,并使用超时重传机制,因此,选择远程过程通信RPC作为网络通信的方式。为了实现协调者的一致性,使用协调算法达成当前成员组成的共识;为了使用中心化副本控制协议,使用Master选举算法选举协调者的主态机;为了提高系统的可用性,运行成员移除和加入算法。在复制组层面上,通过定义一致性控制结构来达到不同的一致性。这样,整个系统的请求处理流程就变为如图1所示。
1)协调者Coordinator集群内部首先通过协调算法达成稳定状态;
2)然后协调者Coordinator集群向存储Storager复制组中的选定节点发送租约消息;
3)存储Storager复制组的节点回应租约消息,整个系统进入稳定状态;
4)客户端通过客户端代理ClientProxy向系统发送读、写请求;
5)客户端代理ClientProxy先向协调者Coordinator集群请求存储Storager复制组的信息;
6)协调者Coordinator集群返回Storager复制组信息; 
7)客户端代理ClientProxy向正确的存储Storager复制组发送请求;
8)存储Storager复制组内部根据本组数据一致性要求进行数据操作;
9)存储Storager复制组将执行结果返回给客户端代理ClientProxy;
10)客户端代理ClientProxy将请求返回给客户端。
为实现本发明的数据分类有效存储,采用了图2的系统构架。
本系统中,将节点间的通信机制使用远程过程调用RPC进行通信。
位于系统最上层的是一个全局的协调者Coordinator,使用协调议来实现协调者内部数据的复制强一致性,并进行协调者内部的动态成员管理。协调者主机中存放各种重要数据。协调 者之下是由存储Storager节点组成的复制组构成的存储层。一个存储Storager节点可以属于多个复制组——这是为了提高存储层的整体性能。存储Storager复制组每个主机上部署key-value存储引擎Redis,同时定时向协调者报告状态,还有提供多种一致性语义。位于客户端Client和存储层之间的是一个客户端代理ClientProxy。客户端代理可以在某应用程序启动时向协调者发送连接请求,以获取该应用程序数据存储的通信地址,同时自动连接到这个存储节点准备进行操作。
协调者Coordinator使用协调算法来达成协调者各节点对需协调的事件的一致性认知,协调的事件包括:协调者内部增加成员、协调者内部减少成员、选举协调者内部的主态机Master节点,系统内部存储Storager节点复制组当前的组成和当前的主态机Primary主机,协调者的算法流程如图3所示。
该协调算法的思想如下:在固定节点集群中发起协调动作,协调内容可以是任何需要在该集群中需要协调的事物,如本发明中复制存储storage哪台主机为主态机等,每次协调由发起协调的主机发出含有协调编号的报文发起协调,其他节点如果之前没有对大于或等于该协调编号的报文进行回应,就对该协调报文发回应,否则就表示该节点之前参与过更高编号的协调活动,将不参加本次协调活动;如果发起协调的节点在超时时间内收到大多数节点的回应,就表示协调成功,否则增加协调编号发起下一次协调。图3展示了该协调算法的流程,初始时,将参与算法的主机数目Host_num赋予系统配置的主机数n,同时将协调编号Agreed_id赋值为零,主机通过数Agreed_count赋值为零,协调内容最终通过数Fin_count赋值为零,设置一个超时的时间点T1;发起协调的主机发出包含Agreed_id的协调请求报文,如果其他主机没有答应其他主机发出的协调请求,就回应愿意就Agreed_id进行协调;发起协调的主机如果没有收集到超过参与协调主机半数以上主机的回应,继续等待直到超时;如果在超时的时间内收到了超过半数的参与协调人员的回应,就进入下一个发送协调内容的阶段;如果在超时时间内都无法满足条件,则回到开始部分重新开始;在发送协调内容阶段,发起协调的主机对参与算法的主机发出包含(cor_id,cor_content)的报文,其中cor_content为需要协调的内容,如果节点在之前准备阶段做出了回应,则对协调内容cor_content做出接受的回应,发起协调的主机如果在超时时间T2前收到大多数的回应,则协调认为成功。
为了快速响应客户端的命令,协调者Coordinator中的Master负责响应客户端的命令,协调者Coordinator内部的Master选举也使用协调算法进行,只是协调算法中协调的内容为某个节点成为主态机Master。
主态机Master选举出来后,协调者内部达成稳定状态,可以进行客户端请求处理。在协调者Coordinator内部出现节点失效是不可避免的,为了提高协调者Coordinator的可用性,使其在少数节点失效的情况下仍然保持可读可写,需要将失效节点从协调者中移除,并能够使失效节点恢复后重新加入到协调者中。为此,将上述协调者算法中将协调内容设置为移除一个节点或加入一个节点即可以实现组成员移除和加入功能。
协调者Coordinator内部节点采用依次的方法进行通信,即以三个主机组成协调者为例,其IP地址依次为IP1、IP2、IP3,这里IP1<IP2<IP3,那么IP1不断向IP2主机报告心跳,IP2不断向IP3报告心跳,IP3向IP1报告心跳信息,这样做的好处是,只要其中一个节点发生心跳超时i,总有一个节点可以使用协调算法将该节点移除。
当一个节点试图加入到协调者Coordinator时,先向协调者中任意节点发出查询主态机Master的命令,然后向协调者中主态机Master提出加入请求,将加入该节点作为内部协调的内容进行内部协调,完成将该节点加入协调者Coordinator的工作。
存储层基于协调者选择一个主态机Primary节点作为中心化副本控制协议的中心控制点。这个节点由协调者指定,并通过租约的方式进行更新——一个复制组的基本信息存储在协调者中,根据该复制组中运行时间最久的节点作为Primary节点,向其发放租约(一个时间段),这个节点在收到租约消息后,间隔二分之一租约时间向协调者发送续租消息;主态机Primary节点选取出来之后,复制组达到稳定状态开始处理客户端的请求;当主态机Primary节点无法收到其它从态机Slave节点的请求回应时,复制组达到不稳定状态,该节点向协调者报告,协调者更新复制组消息,重新进行主态机Primary节点的确定,使复制组重新到达稳定状态;当从态机Slave节点在一个时间段内无法收到主态机Primary节点的心跳时,复制组达到不稳定状态,协调者更新复制组消息,将复制组信息发送给主态机Primary节点,使复制组重新到达稳定状态。整个流程如图4所示。图中,左侧的开始节点为协调者,右侧的开始节点为复制组节点。
存储Storager节点复制组使用下述的结构来达成不同的一致性控制和读写性能。
当can_write_slave和can_read_slave为false,并且can_resp_slave_num等于副本数时,一致性是最强的,如图5、图6所示。
图5中,客户端代理设置一致性结构的属性,can_write_slave为false,并且can_resp_slave_num等于副本数replicate_num-1,它的更新求会首先发送到主写请态Primary节点,主态Primary节点向所有的从态Secondary节点发送该请求,并启动一个定时器,以避免无限地等待下去。只有收到can_resp_slave_num数目的请求回应之后,主态Primary节点才会在本地执行该请求,并将执行结果返回给客户端。在客户端代理也会设置一个请求回应的定时器,如果在指定时间内收不到请求的回应,则会向协调者查询复制组信息,以确定客户端代理与主态Primary节点的网络连接是否正常,或者在主态Primary节点失效时及时得到通知。
图6示出,在强一致性读中,当can_read_slave为false时,客户端只能向主态Primary节点发送查询读请求。
参见图7。如果对可靠性要求不太高,而对性能和响应速度有高要求,设置can_resp_slave_num小于副本数,为1,Primary节点在收到can_resp_slave_num个回应之后在本地执行请求并返回结果,而不是等到收到replicate_num个回应之后,但是它仍然需要在指定时间内收到can_resp_slave_num个回应,,该方式仍然为强一致,为强一致性读操作。
参见图8。如果设置can_write_slave为true,则可以处理只有覆写操作或者增量操作的数据,此时同强一致性一样,仍然可以根据性能要求设置can_resp_slave_num的数目为不同于副本数的值,实现最终一致性写Secondary副本。客户端代理向从态Secondary节点发送更新写请求。从态Secondary节点向其它节点(Primary、Secondary)传播该请求,达到一定条件后在本地执行请求。由于数据量一般较大,所以设置定时器时间间隔长一些。
参见图9。设置can_read_slave为true,则可以在与主态Primary节点的网络发生拥塞或者节点繁忙时得到更高的读取性能,实现最终一致性读。
参见图10。客户端代理在本发明中有通信代理和请求管理的功能。
与分布式系统中的其它角色进行通信是客户端代理的基本功能。在一个客户加入到系统前,它应该首先向协调者进行元数据——存储Primary节点所在的位置——信息的查询,在得到Primary节点的通信地址后与Primary节点建立连接。在协调者失效时,客户代理应该等待协调者稳定状态的达成,或者到达一定的时间后报告一个错误;当所访问的复制组节点发生不 可达等失效时,向协调者发送对应的请求消息,并在此之后获得新的存储节点信息,自动连接到该节点。
通信代理的功能使客户端完全与系统分离开来,客户端只需在本地运行一个客户代理的实例即可,无需自己处理同系统的通信,大大减少了应用程序使用本系统的难度。
另外,客户端可以向客户代理发送一个consisitency_model_def_t类型的变量,来控制副本中的数据流动,达到自己想要的一致性。
在进行请求管理时客户代理为每个客户端的请求进行编号,以实现请求的最多一次语义和其它语义。这通过将请求编号储存在内存中,每次发送一个请求,其编号就加1。不使用持久化存储是因为系统有下面请求状态的记录做保证,它需要客户端自己进行选择。
记录请求状态的功能是客户端代理的一个特色功能。客户端所有的请求都被标记为三种不同的状态:
1、安全状态:该类状态的请求已经被执行,并被复制到足够数量的副本,客户端可以放心认为此类请求的执行是安全的。
2、不稳定状态:在允许请求传播到一定副本数量就可以返回的副本控制协议中,请求的执行状态被分为两次返回给客户代理——第一次的返回说明请求已经在给定数量的副本中被执行;第二次的返回则说明请求被传播到足够数量的副本。
3、危险状态:这个请求已经发出,但是还没有收到执行的返回结果。客户代理应该缓存这些请求,等待复制组的稳定状态达成。如果此时客户端要求退出,那么客户代理应该进行提醒。或者另一个可行的方案是将这些请求发送到协调者,由协调者代为发送。
如果危险状态的请求过多,说明复制组节点过于繁忙或者网络太过拥塞。客户端此时不应该再继续向复制组节点发送太多的请求——因为此时远端节点可能已经失效,而且,这有可能造成本机内存的浪费或者处理器的无谓忙碌。
客户代理将客户请求缓存到本地,等到前面请求执行完成后再进行发送。请求速率控制的标准可以是请求的个数和请求的总大小。到达了一定的请求个数或者红色状态请求大小到达一个阈值后,开始运行速率控制。
由于TCP请求的顺序性,安全状态的请求一定在不稳定状态之前,危险状态的请求一定在不稳定状态的请求之后,也就是说,一个请求会经历如下的状态转换:危险>不稳定->安全。因此,可以只使用请求编号来记录请求的不同状态。使用下面的结构来标记请求的状态:
客户代理端请求状态标记结构
比如对于一个req_state_record_t型的变量r,可能有r.danger=10,r.instable=5,r.safe=3。它的意思是请求(从1开始编号)1到3已经成功执行,并被复制到足够的副本;4和5已经得到回应,但是并没有复制足够的副本;编号6到10的请求没有收到执行回应。为了保险起见,客户端不应该在此时断开连接。

Claims (9)

1.一种航管训练系统中训练数据分类存储的方法,其特征在于:本发明的系统运行于航管训练系统中,使用异步通信,并使用超时重传机制,选择远程过程通信RPC作为网络通信的方式;在航管训练系统的服务器节点中对等的部署分类数据存储,通过数据流控制结构实现数据存储的副本数、读写请求的性能以及回应的发送时机,并为使用该系统的应用程序提供对数据进行访问的读写接口,实现分类数据的可靠、高效存储;
系统由客户端代理和服务端两部分组成,其中客户端代理提供访问接口供使用分类数据的客户即应用程序使用,接管客户和系统各个节点的通信以及其它系统补足功能;服务端节点有两种角色:协调者节点和存储节点,一个节点可以同时扮演两种角色;协调者节点运行协调者程序,其内部运行共识算法对请求达成一致,存储系统的重要数据;一个或者多个存储节点组成一个复制组,其上存储某种类型的数据,通过冗余达到数据存储的高可靠性,每个存储节点可以属于不同的复制组,存储不同种类的数据;
使用协调算法达成当前成员组成的共识,实现协调者的一致性;使用Master选举算法选举协调者的主态机,实现使用中心化副本控制协议;运行成员移除和加入算法,提高系统的可用性;在复制组层面上,通过定义一致性控制结构来达到不同的一致性。
2.如权利要求1所述的航管训练系统中训练数据分类存储的方法,其特征在于:
整个系统的请求处理流程是:
1)协调者Coordinator集群内部首先通过协调算法达成稳定状态;
2)然后协调者Coordinator集群向存储Storager复制组中的选定节点发送租约消息;
3)存储Storager复制组的节点回应租约消息,整个系统进入稳定状态;
4)客户端通过客户端代理ClientProxy向系统发送读、写请求;
5)客户端代理ClientProxy先向协调者Coordinator集群请求存储Storager复制组的信息;
6)协调者Coordinator集群返回存储Storager复制组信息;
7)客户端代理ClientProxy向正确的存储Storager复制组发送请求;
8)存储Storager复制组内部根据本组数据一致性要求进行数据操作;
9)存储Storager复制组将执行结果返回给客户端代理ClientProxy;
10)客户端代理ClientProxy将请求返回给客户端。
3.如权利要求1所述的航管训练系统中训练数据分类存储的方法,其特征在于:
所述系统由客户端代理和服务端两部分组成,其系统的架构是:
位于系统最上层的是一个全局的协调者Coordinator,使用协调协议来实现协调者内部数据的复制强一致性,并进行协调者内部的动态成员管理,协调者主机中存放各种重要数据;
协调者之下是由存储Storager节点组成的复制组构成的存储层,一个存储Storager节点可以属于多个复制组,存储Storager复制组每个主机上部署开源key-value存储引擎Redis,同时定时向协调者报告状态,提供多种一致性语义;
位于客户端和存储层之间的是一个客户端代理,客户端代理在某应用程序启动时向协调者发送连接请求,以获取该应用程序数据存储的通信地址,同时自动连接到这个存储节点准备进行操作。
4.如权利要求1所述的航管训练系统中训练数据分类存储的方法,其特征在于:
所述使用协调算法达成当前成员组成的共识,实现协调者的一致性是:
协调者Coordinator使用协调算法来达成协调者各节点对需协调的事件的一致性认知,协调的事件包括:协调者内部增加成员、协调者内部减少成员、选举协调者内部的主态机Master节点,系统内部存储Storager节点复制组当前的组成和当前的主态机Primary主机;
协调者Coordinator内部节点采用依次的方法进行通信,三个主机组成协调者时,其IP地址依次为IP1、IP2、IP3,这里IP1<IP2<IP3,IP1不断向IP2主机报告心跳,IP2不断向IP3报告心跳,IP3向IP1报告心跳信息;
协调算法的流程是:初始时,将参与算法的主机数目Host_num赋予系统配置的主机数n,同时将协调编号Agreed_id赋值为零,主机通过数Agreed_count赋值为零,协调内容最终通过数Fin_count赋值为零,设置超时等待时间T1;发起协调的主机发出包含Agreed_id的协调请求报文,如果其他主机没有答应其他主机发出的协调请求,就回应愿意就Agreed_id进行协调;发起协调的主机如果没有收集到超过参与协调主机半数以上主机的回应,继续等待直到超时;如果在超时的时间内收到了超过半数的参与协调人员的回应,就进入下一个发送协调内容的阶段;如果在设定的超时时间内都无法满足条件,则回到开始部分重新开始,设定超时等待时间T2;在发送协调内容阶段,发起协调的主机对参与算法的主机发出包含(cor_id,cor_content)的报文,其中cor_content为需要协调的内容,如果节点在之前准备阶段做出了回应,则对协调内容cor_content做出接受的回应,发起协调的主机如果在超时时间T2前收到大多数的回应,则协调认为成功;
所述使用Master选举算法选举协调者的主态机,实现使用中心化副本控制协议是:协调者Coordinator中的Master负责响应客户端的命令,协调者Coordinator内部的Master选举也使用协调算法进行,协调时将协调算法中协调的内容设为某个节点成为主态机Master;
所述运行成员移除和加入算法,提高系统的可用性是:在协调者Coordinator内部出现节点失效后,协调算法中将协调内容设置为移除一个节点,并在协调后完成将该节点移出协调者的工作;当一个节点试图加入到协调者Coordinator时,先向协调者中任意节点发出查询主态机Master的命令,然后向协调者中主态机Master提出加入请求,将加入该节点作为内部协调的内容进行内部协调,完成将该节点加入协调者Coordinator的工作。
5.如权利要求1所述的航管训练系统中训练数据分类存储的方法,其特征在于:
所述在复制组层面上,通过定义一致性控制结构来达到不同的一致性:
存储层基于协调者选择一个主态机Primary节点作为中心化副本控制协议的中心控制点,这个节点由协调者指定,并通过租约的方式进行更新,将一个复制组的基本信息存储在协调者中,根据该复制组中运行时间最久的节点作为主态机Primary节点,向其发放租约,即一个时间段,这个节点在收到租约消息后间隔二分之一的租约时间向协调者发送续租消息;主态机Primary节点选取出来之后,复制组达到稳定状态开始处理客户端的请求;当主态机Primary节点无法收到其它从态机Slave节点的请求回应时,复制组达到不稳定状态,该节点向协调者报告,协调者更新复制组消息,重新进行主态机Primary节点的确定,使复制组重新到达稳定状态;当从态机Slave节点在一个时间段内无法收到主态机Primary节点的心跳时,复制组达到不稳定状态,协调者更新复制组消息,将复制组信息发送给主态机Primary节点,使复制组重新到达稳定状态;
存储Storager节点复制组使用下述的结构来达成不同的一致性控制和读写性能:
当can_write_slave和can_read_slave为false,并且can_resp_slave_num等于副本数时,一致性是最强的。
6.如权利要求5所述的航管训练系统中训练数据分类存储的方法,其特征在于:
所述当can_write_slave和can_read_slave为false,并且can_resp_slave_num等于副本数时,一致性是最强的,为强一致性写操作:
客户端代理设置一致性结构的属性,can_write_slave为false,并且can_resp_slave_num等于(副本数replicate_num-1),它的更新求首先发送到主态写请求Primary节点,主态Primary节点向所有的从态Secondary节点发送该请求,并启动一个定时器,以避免无限地等待下去,只有收到can_resp_slave_num数目的请求回应之后,主态Primary节点才会在本地执行该请求,并将执行结果返回给客户端;在客户端代理也会设置一个请求回应的定时器,如果在指定时间内收不到请求的回应,则会向协调者查询复制组信息,以确定客户端代理与主态Primary节点的网络连接是否正常,或者在主态Primary节点失效时及时得到通知;
强一致性读:当can_read_slave为false时,客户端代理只能向主态Primary节点发送查询读请求;
如果对可靠性要求不太高,而对性能和响应速度有较高要求,设置can_resp_slave_num小于副本数,为1,Primary节点在收到can_resp_slave_num个回应之后在本地执行请求并返回结果,而不是等到收到replicate_num个回应之后,但是它仍然需要在指定时间内收到can_resp_slave_num个回应,该方式仍然为强一致,为强一致性读操作。
7.如权利要求5所述的航管训练系统中训练数据分类存储的方法,其特征在于:最终写一致性写:
设置can_write_slave为true,设置can_resp_slave_num的数目为不同于副本数的值,客户端代理向从态Secondary节点发送更新写请求,从态Secondary节点向该组其他剩余Primary、Secondary节点传播该请求,并启动一个定时器,只有收到can_resp_slave_num数目的请求回应之后,从态Secondary节点将该请求向该组剩余Primary、Secondary节点传播请求,在本地执行该请求,并将执行结果返回给客户端;在客户端代理也设置一个请求回应的定时器,如果在指定时间内收不到请求的回应,则会向协调者查询复制组信息,以确定客户端代理与主态Primary节点的网络连接是否正常,或者在主态Primary节点失效时及时得到通知;
最终一致性读:设置can_read_slave为true,客户端代理向从态Secondary节点发起查询读请求,开启请求定时器,等待执行结果,将查询结果发送到客户端代理,在定时器时间内收到请求回应,请求回应成功,在定时器时间内收不到请求回应,向协调者查询复制组消息,客户端代理再次向从态Secondary节点发起查询读请求,直到请求执行成功。
8.如权利要求1所述的航管训练系统中训练数据分类存储的方法,其特征在于:
客户端代理包括通信代理和请求代理,通信代理包括与协调者通信,获得元数据信息;同存储节点通信,进行数据操作;同时控制剧本数据传输;请求代理包括为请求编号,缓存请求;记录请求状态;请求速率控制;
客户端完全与系统分离,客户端只需在本地运行一个客户代理的实例即可,无需自己处理同系统的通信,在一个客户加入到系统前,它首先向协调者进行元数据——存储Primary节点所在的位置——信息的查询,在得到Primary节点的通信地址后与Primary节点建立连接;在协调者失效时,客户端代理等待协调者稳定状态的达成,或者到达一定的时间后报告一个错误;当所访问的复制组节点发生不可达失效时,向协调者发送对应的请求消息,并在此之后获得新的存储节点信息,自动连接到该节点;
客户端向客户端代理发送一个consisitency_model_def_t类型的变量,来控制副本中的数据流动,达到自己想要的一致性;
在客户端代理的请求管理中,客户端代理为每个客户端的请求进行编号,以实现请求的最多一次语义和其它语义,这通过将请求编号储存在内存中,每次发送一个请求,其编号就加1;同时记录请求状态:客户端所有的请求都被标记为三种不同的状态:
1)、安全状态:该类状态的请求已经被执行,并被复制到足够数量的副本,客户端可以放心认为此类请求的执行是安全的;
2)、不稳定状态:在允许请求传播到一定副本数量就可以返回的副本控制协议中,请求的执行状态被分为两次返回给客户代理——第一次的返回说明请求已经在给定数量的副本中被执行;第二次的返回则说明请求被传播到足够数量的副本;
3)、危险状态:这个请求已经发出,但是还没有收到执行的返回结果,客户端代理缓存这些请求,等待复制组的稳定状态达成,如果此时客户端要求退出,那么客户端代理进行提醒,或者是将这些请求发送到协调者,由协调者代为发送;
所述请求速率控制的标准是请求的个数和请求的总大小,到达了一定的请求个数或者危险状态请求大小到达一个阈值后,开始运行速率控制,客户端代理将客户请求缓存到本地,等到前面请求执行完成后再进行发送。
9.如权利要求8所述的航管训练系统中训练数据分类存储的方法,其特征在于:所述客户端所有的请求都被标记为三种不同的状态:
是使用下面的结构来标记请求的状态:
CN201410631306.7A 2014-11-10 2014-11-10 一种航管训练系统中训练数据分类存储的方法 Active CN104468722B (zh)

Priority Applications (1)

Application Number Priority Date Filing Date Title
CN201410631306.7A CN104468722B (zh) 2014-11-10 2014-11-10 一种航管训练系统中训练数据分类存储的方法

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
CN201410631306.7A CN104468722B (zh) 2014-11-10 2014-11-10 一种航管训练系统中训练数据分类存储的方法

Publications (2)

Publication Number Publication Date
CN104468722A true CN104468722A (zh) 2015-03-25
CN104468722B CN104468722B (zh) 2017-11-07

Family

ID=52914075

Family Applications (1)

Application Number Title Priority Date Filing Date
CN201410631306.7A Active CN104468722B (zh) 2014-11-10 2014-11-10 一种航管训练系统中训练数据分类存储的方法

Country Status (1)

Country Link
CN (1) CN104468722B (zh)

Cited By (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN105677251A (zh) * 2016-01-05 2016-06-15 上海瀚之友信息技术服务有限公司 基于Redis集群的存储系统
CN106997394A (zh) * 2017-04-12 2017-08-01 成都四方伟业软件股份有限公司 一种数据乱序到达处理方法和系统
CN109088937A (zh) * 2018-08-28 2018-12-25 郑州云海信息技术有限公司 一种基于统一管理的集群授权方法及装置
CN109952740A (zh) * 2016-08-25 2019-06-28 张建钢 大规模可扩展、低延迟、高并发性和高吞吐量的去中心化共识算法
CN111386522A (zh) * 2017-11-22 2020-07-07 亚马逊科技公司 数据库表的多区多主复制

Citations (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US6067545A (en) * 1997-08-01 2000-05-23 Hewlett-Packard Company Resource rebalancing in networked computer systems
US8468132B1 (en) * 2010-12-28 2013-06-18 Amazon Technologies, Inc. Data replication framework
CN103607448A (zh) * 2013-11-18 2014-02-26 四川川大智胜软件股份有限公司 一种atc系统动态数据存储的方法

Patent Citations (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US6067545A (en) * 1997-08-01 2000-05-23 Hewlett-Packard Company Resource rebalancing in networked computer systems
US8468132B1 (en) * 2010-12-28 2013-06-18 Amazon Technologies, Inc. Data replication framework
CN103607448A (zh) * 2013-11-18 2014-02-26 四川川大智胜软件股份有限公司 一种atc系统动态数据存储的方法

Non-Patent Citations (1)

* Cited by examiner, † Cited by third party
Title
陈虹宇,胡术等: ""航管仿真训练系统运行控制的设计与实现"", 《计算机工程与科学》 *

Cited By (8)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN105677251A (zh) * 2016-01-05 2016-06-15 上海瀚之友信息技术服务有限公司 基于Redis集群的存储系统
CN109952740A (zh) * 2016-08-25 2019-06-28 张建钢 大规模可扩展、低延迟、高并发性和高吞吐量的去中心化共识算法
CN106997394A (zh) * 2017-04-12 2017-08-01 成都四方伟业软件股份有限公司 一种数据乱序到达处理方法和系统
CN106997394B (zh) * 2017-04-12 2019-06-14 成都四方伟业软件股份有限公司 一种数据乱序到达处理方法和系统
CN111386522A (zh) * 2017-11-22 2020-07-07 亚马逊科技公司 数据库表的多区多主复制
CN111386522B (zh) * 2017-11-22 2023-11-03 亚马逊科技公司 用于数据存储的系统和方法
CN109088937A (zh) * 2018-08-28 2018-12-25 郑州云海信息技术有限公司 一种基于统一管理的集群授权方法及装置
CN109088937B (zh) * 2018-08-28 2021-10-26 郑州云海信息技术有限公司 一种基于统一管理的集群授权方法及装置

Also Published As

Publication number Publication date
CN104468722B (zh) 2017-11-07

Similar Documents

Publication Publication Date Title
EP3039549B1 (en) Distributed file system using consensus nodes
CN102037463B (zh) 使用全局确认的提交进行分布式事务的基于日志的复制
US9521196B2 (en) Methods, devices and systems for dynamically managing memberships in replicated state machines within a distributed computing environment
CN103973725B (zh) 一种分布式协同方法和协同器
CN104468722A (zh) 一种航管训练系统中训练数据分类存储的方法
CN102880658B (zh) 基于地震数据处理的分布式文件管理系统
CN105357296A (zh) 一种Docker云平台下弹性缓存系统
EP3452919A1 (en) Splitting and moving ranges in a distributed system
KR102192442B1 (ko) 쿠버네티스 클러스터에서의 리더 분산 방법 및 리더 분산 시스템
CN111338773A (zh) 一种分布式定时任务调度方法、调度系统及服务器集群
CN102882927A (zh) 一种云存储数据同步框架及其实现方法
CN101930463B (zh) 一种基于内存数据库的仿真网格节点快速迁移方法
CN106484321A (zh) 一种数据存储方法及数据中心
CN110490334A (zh) 一种低延迟的机器学习即服务的生成方法
CN108347455A (zh) 元数据交互方法及系统
CN109302324A (zh) 一种私有云监控预警方法及系统
EP3632086B1 (en) Server system for processing a virtual space
CN112351106B (zh) 一种含事件网格的服务网格平台及其通信方法
CN110213359A (zh) 一种基于d2d的车联网组网数据推送系统和方法
US20230421669A1 (en) Network Protocol for View Replication Over Unreliable Networks
CN109491767A (zh) 分布式事务的处理方法和分布式系统
CN113476853A (zh) 交互任务的数据处理方法、装置、电子设备、存储介质
US10848549B1 (en) Leaderless, parallel, and topology-aware protocol for achieving consensus
CN106790647A (zh) 一种自适应服务管理的方法和系统
CN113254511B (zh) 一种分布式向量检索系统及方法

Legal Events

Date Code Title Description
C06 Publication
PB01 Publication
SE01 Entry into force of request for substantive examination
ASS Succession or assignment of patent right

Owner name: NO. 92232 TROOPS OF PLA

Effective date: 20150819

C41 Transfer of patent application or patent right or utility model
C53 Correction of patent of invention or patent application
CB03 Change of inventor or designer information

Inventor after: Hu Shu

Inventor after: Zou Wei

Inventor after: Zhang Jinwu

Inventor after: Zhang Pixu

Inventor after: Zhou Xuan

Inventor after: Zhao Guohui

Inventor before: Hu Shu

Inventor before: Li Kelei

COR Change of bibliographic data

Free format text: CORRECT: INVENTOR; FROM: HU SHU LI KELEI TO: HU SHU ZOU WEI ZHANG JINWU ZHANG PIXU ZHOU XUAN ZHAO GUOHUI

TA01 Transfer of patent application right

Effective date of registration: 20150819

Address after: 610045 Sichuan city of Chengdu province Wuhou District Vuko East Road No. seven

Applicant after: Chuandazhisheng Software Co., Ltd., Sichuan

Applicant after: The Chinese People's Liberation Army 92232 Troops

Address before: 610045 Sichuan city of Chengdu province Wuhou District Vuko East Road No. 7

Applicant before: Chuandazhisheng Software Co., Ltd., Sichuan

GR01 Patent grant
GR01 Patent grant