CN108462737B - 基于批处理和流水线的分层数据一致性协议优化方法 - Google Patents
基于批处理和流水线的分层数据一致性协议优化方法 Download PDFInfo
- Publication number
- CN108462737B CN108462737B CN201810084245.5A CN201810084245A CN108462737B CN 108462737 B CN108462737 B CN 108462737B CN 201810084245 A CN201810084245 A CN 201810084245A CN 108462737 B CN108462737 B CN 108462737B
- Authority
- CN
- China
- Prior art keywords
- request
- nodes
- batch processing
- node
- protocol
- 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.)
- Active
Links
Images
Classifications
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L67/00—Network arrangements or protocols for supporting network services or applications
- H04L67/01—Protocols
- H04L67/10—Protocols in which an application is distributed across nodes in the network
- H04L67/1001—Protocols in which an application is distributed across nodes in the network for accessing one among a plurality of replicated servers
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F3/00—Input arrangements for transferring data to be processed into a form capable of being handled by the computer; Output arrangements for transferring data from processing unit to output unit, e.g. interface arrangements
- G06F3/06—Digital input from, or digital output to, record carriers, e.g. RAID, emulated record carriers or networked record carriers
- G06F3/0601—Interfaces specially adapted for storage systems
- G06F3/0628—Interfaces specially adapted for storage systems making use of a particular technique
- G06F3/0655—Vertical data movement, i.e. input-output transfer; data movement between one or more hosts and one or more storage devices
- G06F3/0659—Command handling arrangements, e.g. command buffers, queues, command scheduling
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F3/00—Input arrangements for transferring data to be processed into a form capable of being handled by the computer; Output arrangements for transferring data from processing unit to output unit, e.g. interface arrangements
- G06F3/06—Digital input from, or digital output to, record carriers, e.g. RAID, emulated record carriers or networked record carriers
- G06F3/0601—Interfaces specially adapted for storage systems
- G06F3/0628—Interfaces specially adapted for storage systems making use of a particular technique
- G06F3/0655—Vertical data movement, i.e. input-output transfer; data movement between one or more hosts and one or more storage devices
- G06F3/0661—Format or protocol conversion arrangements
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F9/00—Arrangements for program control, e.g. control units
- G06F9/06—Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
- G06F9/46—Multiprogramming arrangements
- G06F9/466—Transaction processing
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F9/00—Arrangements for program control, e.g. control units
- G06F9/06—Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
- G06F9/46—Multiprogramming arrangements
- G06F9/50—Allocation of resources, e.g. of the central processing unit [CPU]
- G06F9/5061—Partitioning or combining of resources
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F9/00—Arrangements for program control, e.g. control units
- G06F9/06—Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
- G06F9/46—Multiprogramming arrangements
- G06F9/54—Interprogram communication
- G06F9/546—Message passing systems or structures, e.g. queues
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L67/00—Network arrangements or protocols for supporting network services or applications
- H04L67/14—Session management
- H04L67/146—Markers for unambiguous identification of a particular session, e.g. session cookie or URL-encoding
Landscapes
- Engineering & Computer Science (AREA)
- Theoretical Computer Science (AREA)
- Software Systems (AREA)
- Physics & Mathematics (AREA)
- General Engineering & Computer Science (AREA)
- General Physics & Mathematics (AREA)
- Computer Networks & Wireless Communication (AREA)
- Signal Processing (AREA)
- Human Computer Interaction (AREA)
- Computer And Data Communications (AREA)
Abstract
本发明提供了一种基于批处理和流水线的分层数据一致性协议优化方法,包括以下步骤:S1、客户端判断待发送请求数是否大于0,如果是,则进入下一步骤,如果否,则结束;S2、客户端向随机节点发送请求;S3、当节点接收到请求后,转发给其他所有节点;S4、当其他节点收到转发请求后,保存当前请求和请求ID,并向其他所有节点发送只包含请求ID的确认消息;S5、如果对某一个请求ID接收到超过半数的节点的确认信息,则认为该请求已经被多数节点接收,处于可排序状态。本发明的有益效果是:能够有效降低Multi‑Paxos协议中领导者节点资源消耗,同时保证较高的系统性能并且易于工程实现。
Description
技术领域
本发明涉及分布式存储,尤其涉及分布式存储中一种基于批处理和流水线的分层数据一致性协议优化方法。
背景技术
信息技术的发展推动着时代的变革,新一代通信技术、新型计算模式的演进加深了科学研究、商业应用、日常生活等各个应用领域的信息化程度。大数据时代的到来和数据的爆炸性增长,如何高效、可靠地存储海量数据成为了一项极具挑战性的工作。传统的单一节点的集中式存储系统已经不能满足需求,越来越多的公司采用分布式存储系统。与集中式存储系统相比,分布式存储系统具有可避免单点故障,降低成本和高可扩展性等优点。
实现分布式系统的基本操作是数据复制。数据复制是指在可能分布于多个机架、机房、区域范围内甚至全球范围数据中心的不同服务器上对某个对象进行多份相同的拷贝。地域上的复制通过在不同的地理区域中复制冗余数据可以在全球范围内实现数据持久化、容错和容灾等功能。通过复制可以实现数据的高可用性、可扩展性以及实现快速响应。在全球范围服务和应用的时代,复制是解决大数据挑战的必需。
伴随着分布式存储系统中的复制产生的一个重要问题是如何保证副本间的数据一致性。分布式系统的数据一致性是指数据在多个副本之间能否保持一致的特性。即能够保证节点互通的情况下从各个节点请求到的数据必须是一致的,同时外部请求对数据做出修改时,各个节点之间也必须同步。
如果分布式系统没有做好一致性保证,那么当用户访问不同副本中同一个数据,得到的结果就会不一致,导致系统中的数据不可靠。对于金融或者一些其他的对数据的可靠性要求高的行业来说,数据一致性的要求更为必要。
目前能够同时保证较好的可靠性和可用性的分布式存储系统数据复制方式是状态机复制。它通常是基于复制日志实现的,每一个服务器存储一个包含一系列指令的日志,并且按照日志的顺序进行执行。保证复制日志相同是通过一致性算法来实现。就算有些服务器会宕机,一旦指令被正确的复制,每一个服务器的状态机按照日志顺序处理他们,就会输出结果返回给客户端。因此,服务器集群就形成了一个高可靠的状态机。也就是说,状态机复制的内部实现是通过一致性协议来保证各个节点达成一致的执行顺序。
在分布式领域为了解决数据的一致性问题,已经有很多研究者提出了不同的一致性协议,其中比较有代表性的有二阶段提交、三阶段提交、Paxos协议以及Raft协议。Google分布式一致性库Chubby的作者曾总结到,所有的分布式一致性算法都是Paxos协议的一个不完备版本。近些年来提出的分布式一致性算法如ZAB协议、Raft协议等都是在Multi-Paxos的思想上加以改进的。这个观点强调了Paxos协议在分布式一致性协议中的重要地位。因此,针对Paxos协议的改进算法也有很多。
其中,研究如何解决领导者节点为中心的协议的节点瓶颈问题是近几年对Paxos的研究比较热门的方向之一。在以领导者为中心的分布式一致性协议中,如Multi-Paxos协议、Raft协议、ZAB协议等,领导者节点的资源消耗明显大于普通节点。当负载提高时,领导者节点最先消耗完节点资源成为系统瓶颈。针对这一问题,很多研究者提出了不同的优化方案:
a)Mencius Mencius为了避免领导者节点成为瓶颈,使用了一种轮转Leader的机制。这样可以实现负载在所有节点上的有效均衡,但是Mencius的一个明显缺点是:容错性很差,任意节点出现故障,都会使系统无法对外提供服务。
b)LCR LCR在一个逻辑环上放置副本并使用向量时钟进行消息的排序,LCR是一种高吞吐量的协议,所有工作在节点间平均分配,从而利用所有可用的系统资源。LCR的缺点是系统的延时随着环中节点的数量线性增加,此外,维持环状的结构也增加了协议的开销。
c)S-Paxos Nuno Santos等人提出了S-Paxos协议,该协议中负载传输工作由所有节点分布式地完成,领导者节点只对请求的ID进行排序,提高了系统资源的整体利用率,有效缓解了领导者节点的压力。该协议的局限性在于:与Multi-Paxos协议相比增加了系统传输的消息总量,在中低负载下,性能不如Multi-Paxos。
综上所述,上面的方案能够降低领导者节点负载或者采用无领导者的方式避免领导者节点瓶颈问题,但是这些方案都存在各自的局限之处,例如:Mencius协议虽然采用领导者轮值的方式降低领导者负载但是造成了系统容错性下降的问题;LCR协议使用环状结构分摊负载,但是造成了系统延时增加的问题。因此在高负载环境下,如何提出一种能够有效降低Multi-Paxos协议中领导者节点资源消耗,同时保证较高的系统性能并且易于工程实现的Multi-Paxos改进协议的方法是本领域技术人员所亟待解决的技术问题。
发明内容
为了解决现有技术中的问题,本发明提供了一种基于批处理和流水线的分层数据一致性协议优化方法。
本发明提供了一种基于批处理和流水线的分层数据一致性协议优化方法,包括以下步骤:
S1、客户端判断待发送请求数是否大于0,如果是,则进入下一步骤,如果否,则结束;
S2、客户端向随机节点发送请求;
S3、当节点接收到请求后,转发给其他所有节点;
S4、当其他节点收到转发请求后,保存当前请求和请求ID,并向其他所有节点发送只包含请求ID的确认消息;
S5、如果对某一个请求ID接收到超过半数的节点的确认信息,则认为该请求已经被多数节点接收,处于可排序状态;
S6、领导者节点将该请求ID加入当前的批处理包内,判断当前批处理包的大小是否超过限制以及判断形成当前批处理包的时间是否超过最大等待时间,如果超过大小或者超时或者既超过大小又超时,则进入下一步骤,如果既不超过大小又不超时,则将该请求ID放入当前批处理包中;
S7、发送当前的批处理包,并将该请求ID放入新的批处理包内;
S8、当领导者节点向其他所有节点发送完毕请求ID的批处理包后,判断当前并行运行窗口数是否小于设定值,如果是,则返回步骤S7,如果否,则进入下一步骤;
S9、当其他节点接收到请求ID的批处理包后,向其他所有节点发送确认消息,如果节点接收到超过半数的节点的确认消息,则认为该请求已经排序完毕,相应节点执行请求并回复客户端,返回步骤S1。
作为本发明的进一步改进,步骤S8中的并行运行窗口数的设定值的确定过程包括以下步骤:
推导分层Multi-Paxos协议在节点带宽饱和的情况下,批处理参数和流水线参数的关系;
假设一个分层Multi-Paxos系统有n个节点,每个节点接收到客户端的请求的概率为Pi,假设第k个节点接收到客户端的概率最大,为Pk;
确定瓶颈链路,
假设一段时间内客户端共发送了m个请求,此节点的发送消息量和接收消息量分别为Mout和Min,有:
Mout=mPk(n-1)Sreq+m(n-1)(1-Pk)Sack+mPkSans (4-1)
Min=mSreq+mPk(n-1)Sack (4-2)
其中由于Pk=Max{P1,P2...Pi},所以nPk-1≥0,由于确认消息只包含了请求ID,而请求消息包含了请求ID和负载,所以Sreq≥Sack,同时由于副本节点数n≥3,所以m(n-2)(1-Pk)Sack≥0,综上:Mout-Min≥0,即接收消息概率最大的节点的传出链路为整个系统的瓶颈链路;
得到传输层每秒能传递给排序层的最大请求ID个数为K,则
在排序层,完成一个接收阶段的实例的时间τdec为:
代入后整理得到并行运行的窗口数W:
其中,B为节点带宽,L为节点间的传输时延,n为节点个数,m为客户端个数,Sreq为请求消息的大小,Sbatch为批处理包的大小,△B为形成批处理包的最大等待时间,Lclient为客户端与节点间的传输时延。
作为本发明的进一步改进,由于每秒可以通过数据传输层传递给排序层的请求个数为K,排序层对这K个数据排序需要的时间为τdec,因此系统的理论最大吞吐量为由于(n-1)Sbatch_id+2Sack为Kb数量级,而带宽B一般为Mb数量级,因此这一项忽略不计,带入公式(4-5),得出系统的理论最大吞吐量Tlayerd-paxos为
由于Sack<<Sreq,Sack<<Sans,因此忽略分母中的Sack项,上述公式简化为:
本发明的有益效果是:随着客户端个数的增加,使用基于批处理和流水线的分层数据一致性协议优化方法的性能更高,且随着客户端请求个数增加,批处理和流水线带来的性能收益更大,直到达到性能饱和状态,能够有效降低Multi-Paxos协议中领导者节点资源消耗,同时保证较高的系统性能并且易于工程实现。
附图说明
图1是本发明一种基于批处理和流水线的分层数据一致性协议优化方法的流程图。
图2是Basic-Paxos协议的流程图。
图3是Multi-Paxos协议的消息流程图。
图4是分层Multi-Paxos协议的消息流程图。
图5是采用批处理的Multi-Paxos的消息模式图。
图6是采用流水线的Multi-Paxos的消息模式图。
图7是使用批处理和流水线的分层Multi-Paxos和不使用的分层Multi-Paxos的性能对比图。
具体实施方式
下面结合附图说明及具体实施方式对本发明作进一步说明。
分层一致性协议的原理与结构说明如下:
针对Multi-Paxos协议中存在的领导者节点的瓶颈问题,引出分层Multi-Paxos对这个问题的解决方案,以下分析详述其实现原理与结构。
谈到Multi-Paxos协议,不得不先理解Basic-Paxos协议的理论。在Basic-Paxos协议的运行过程中,将进程分为三种角色,分别是:提议者(Proposer)、接受者(Acceptor)和学习者(Learner)。
整个协议的流程如图2,协议分为准备阶段(Prepare)和接受阶段(Accept)两个阶段。第一阶段a,Proposer向Acceptor提出一个提案,第一阶段b进行计算提案,根据半数以上Acceptor的返回,选择提案编号最大的协议v,返回给Proposer。第二阶段a,Proposer将v发送给Acceptor,第二阶段b,在半数Acceptor返回了成功后,再返回客户端成功通过提案。不过在并发情况下可能会出现两个或者两个以上的提议者依次提出了一系列编号递增的提案的情况,也就是两个提案最终都无法被选定的情况,这个问题被称为“活锁”。
为了解决Basic-Paxos协议存在的活锁问题,Lamport提出了Multi-Paxos协议。Multi-Paxos协议的消息流程如图3。在阶段1中提议者抢占访问权,获得访问权的提议者成为领导者,之后在领导者的任期内不需要进行阶段1,直接向所有接受者发送阶段2a消息,接受者做出投票,如果学习者收到超过的确认消息即认为提议通过。如果领导者节点异常,则退化为Basic-Paxos的情况,直到选出一位新的领导者。
虽然Multi-Paxos协议通过选出领导者解决了Basic-Paxos协议的活锁问题,并简化了协议的流程,但也带来了其他问题:领导者节点的负载与其他节点很不均衡,领导者节点需要发送的数据量和进行的操作都比普通节点更多。然而节点的资源例如带宽和CPU是有限的,当同时发起请求的客户端数量增多时,领导者节点会最先消耗完节点资源,成为系统的瓶颈。从而制约了系统每秒能够处理请求的能力(吞吐量),也限制了系统的可扩展性。
为了解决领导者节点的瓶颈问题,Nuno Santos等人提出了一种分层的Multi-Paxos模型,称为S-Paxos协议。它通过在副本节点间平衡负载,降低领导者节点的负载,同时有效利用了其他副本的空闲资源,解决了领导者节点的瓶颈问题。
分层Multi-Paxos协议的消息流程如图4。首先,客户端向随机节点发送请求,当一个节点接收到请求后,将请求内容v和请求id发送给所有其他节点,当一个节点接收到了转发的请求后,记录请求v和请求id,保存在请求集合中,然后给所有其他节点发送一个只包含请求id的确认消息。
当对某个请求id收到超过半数来自不同节点的确认消息后,节点认为该请求处于可排序的状态,将这个请求id加入待排序请求集合,领导者节点对这个请求id发起提议,在排序层进行排序。
在排序层通过执行Multi-Paxos协议流程确定请求执行的顺序,唯一的区别是,排序层只对请求id进行排序。当排序完成后,节点根据请求id的排序顺序执行相应的请求。在异步网络的情况下,请求id可能在某些节点接收到请求前被排序,因此不能在顺序被确定后立即执行,而是记录id,等待节点收到请求且可以执行后再执行该请求。
批处理和流水线技术在分层Multi-Paxos协议中的应用如下:
批处理(Batch)和流水线(Pipeline)技术是能够提升分布式一致性协议性能的有效优化方式,在许多方面比如网络通信和系统设计等得到了广泛地研究和使用。本发明将这两项技术应用于分层Multi-Paxos协议的优化。
批处理技术可以很容易地在Paxos协议中得以实现,因为它不需要涉及对分布式一致性协议的大量修改。其在Paxos协议中的表现如图5所示:领导者在接收到请求后并不是直接发送请求,而是等待请求成为一个合适的批次后再发送。
流水线技术在Leslie Lamport最初关于Paxos的文献中已经有所提及。通过流水线处理,Paxos中的领导者可以在此前的实例完成之前启动新的实例。在网络延迟较高时,流水线处理方式尤为有效。其在Multi Paxos协议中的表现如图6所示。
在分层Multi-Paxos协议的传输层,可以使用批处理技术进行优化:当节点接收到一个客户端请求后,并不是直接将这个请求转发给其他节点,而是等待后续的请求,等形成一个比较大的批次后再转发给其他节点;在排序层,批处理技术和流水线技术可以相结合进行优化,领导者节点对于接收到的待提议的请求ID进行批处理,批处理策略与传输层一致,领导者发送完一个提议后,可以进行流水线优化,即不必等待当前的请求完成,可以直接发送下一个实例,直到当前运行的实例数达到最大限制。
使用批处理和流水线优化方案的关键点在于如何确定批处理包的尺寸和流水线方案中能够并行运行的Paxos的实例的个数,使系统的性能达到最优。下面本发明将推导分层Multi-Paxos协议在节点带宽饱和的情况下,批处理参数和流水线参数的关系。
假设一个分层Multi-Paxos系统有n个节点,每个节点接收到客户端的请求的概率为Pi,假设第k个节点接收到客户端的概率最大,为Pk。
1、确定瓶颈链路
假设一段时间内客户端共发送了m个请求,此节点的发送消息量和接收消息量分别为Mout和Min,有:
Mout=mPk(n-1)Sreq+m(n-1)(1-Pk)Sack+mPkSans (4-1)
Min=mSreq+mPk(n-1)Sack (4-2)
其中由于Pk=Max{P1,P2...Pi},所以nPk-1≥0,由于确认消息只包含了请求ID,而请求消息包含了请求ID和负载,所以Sreq≥Sack,同时由于副本节点数n≥3,所以m(n-2)(1-Pk)Sack≥0,综上:Mout-Min≥0,即接收消息概率最大的节点的传出链路为整个系统的瓶颈链路。
可以得到传输层每秒能传递给排序层的最大请求ID个数为K,则
在排序层,完成一个阶段2的实例的时间τdec为:
B'=KSid
代入后整理得:
上述公式给出了在带宽达到饱和时,如何选择批处理的尺寸和并行运行窗口数使系统能够达到最大的吞吐量。
由于每秒可以通过数据传输层传递给排序层的请求个数为K,排序层对这K个数据排序需要的时间为τdec,因此系统的理论最大吞吐量为由于(n-1)Sbatch_id+2Sack为Kb数量级,而带宽B一般为Mb数量级,因此这一项通常可以忽略不计,带入公式4-5,得出系统的理论最大吞吐量Tlayerd-paxos为
考虑到大多数情况:Sack<<Sreq,Sack<<Sans因此忽略分母中的Sack项,上述公式可简化为:
与批处理和流水线结合的分层Multi-Paxos协议的建模与仿真如下:
为了进一步研究这两项优化手段对协议性能的影响,将对与批处理和流水线结合的分层Multi-Paxos协议方案进行建模与仿真。
如图1所示,一种基于批处理和流水线的分层数据一致性协议优化方法,包括以下步骤:
S1、客户端判断待发送请求数是否大于0,如果是,则进入下一步骤,如果否,则结束;
S2、客户端向随机节点发送请求;
S3、当节点接收到请求后,转发给其他所有节点;
S4、当其他节点收到转发请求后,保存当前请求和请求ID,并向其他所有节点发送只包含请求ID的确认消息;
S5、如果对某一个请求ID接收到超过半数的节点的确认信息,则认为该请求已经被多数节点接收,处于可排序状态;
S6、领导者节点将该请求ID加入当前的批处理包内,判断当前批处理包的大小是否超过限制以及判断形成当前批处理包的时间是否超过最大等待时间,如果超过大小或者超时或者既超过大小又超时,则进入下一步骤,如果既不超过大小又不超时,则将该请求ID放入当前批处理包中;
S7、发送当前的批处理包,并将该请求ID放入新的批处理包内;
S8、当领导者节点向其他所有节点发送完毕请求ID的批处理包后,判断当前并行运行窗口数是否小于设定值,如果是,则返回步骤S7,如果否,则进入下一步骤;
S9、当其他节点接收到请求ID的批处理包后,向其他所有节点发送确认消息,如果节点接收到超过半数的节点的确认消息,则认为该请求已经排序完毕,相应节点执行请求并回复客户端,返回步骤S1。
代码使用Java语言编写,仿真过程中仿真参数见表1,仿真中假设通信环境是理想的(节点间的时延固定,不存在消息乱序、网络异常、节点宕机等情况),是一种理论上的结果。
表1仿真参数的含义及取值
仿真结果如图7所示,可见随着客户端个数的增加,使用批处理和流水线的方案性能更高,且随着客户端请求个数增加,批处理和流水线带来的性能收益更大,直到达到性能饱和状态。
本发明提供的一种基于批处理和流水线的分层数据一致性协议优化方法,随着客户端个数的增加,使用基于批处理和流水线的分层数据一致性协议优化方法的性能更高,且随着客户端请求个数增加,批处理和流水线带来的性能收益更大,直到达到性能饱和状态,能够有效降低Multi-Paxos协议中领导者节点资源消耗,同时保证较高的系统性能并且易于工程实现
以上内容是结合具体的优选实施方式对本发明所作的进一步详细说明,不能认定本发明的具体实施只局限于这些说明。对于本发明所属技术领域的普通技术人员来说,在不脱离本发明构思的前提下,还可以做出若干简单推演或替换,都应当视为属于本发明的保护范围。
Claims (1)
1.一种基于批处理和流水线的分层数据一致性协议优化方法,其特征在于,包括以下步骤:
S1、客户端判断待发送请求数是否大于0,如果是,则进入下一步骤,如果否,则结束;
S2、客户端向随机节点发送请求;
S3、当节点接收到请求后,转发给其他所有节点;
S4、当其他节点收到转发请求后,保存当前请求和请求ID,并向其他所有节点发送只包含请求ID的确认消息;
S5、如果对某一个请求ID接收到超过半数的节点的确认信息,则认为该请求已经被多数节点接收,处于可排序状态;
S6、领导者节点将该请求ID加入当前的批处理包内,判断当前批处理包的大小是否超过限制以及判断形成当前批处理包的时间是否超过最大等待时间,如果超过大小或者超时或者既超过大小又超时,则进入下一步骤,如果既不超过大小又不超时,则将该请求ID放入当前批处理包中;
S7、发送当前的批处理包,并将该请求ID放入新的批处理包内;
S8、当领导者节点向其他所有节点发送完毕请求ID的批处理包后,判断当前并行运行窗口数是否小于设定值,如果是,则返回步骤S7,如果否,则进入下一步骤;
S9、当其他节点接收到请求ID的批处理包后,向其他所有节点发送确认消息,如果节点接收到超过半数的节点的确认消息,则认为该请求已经排序完毕,相应节点执行请求并回复客户端,返回步骤S1。
Priority Applications (1)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
CN201810084245.5A CN108462737B (zh) | 2018-01-29 | 2018-01-29 | 基于批处理和流水线的分层数据一致性协议优化方法 |
Applications Claiming Priority (1)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
CN201810084245.5A CN108462737B (zh) | 2018-01-29 | 2018-01-29 | 基于批处理和流水线的分层数据一致性协议优化方法 |
Publications (2)
Publication Number | Publication Date |
---|---|
CN108462737A CN108462737A (zh) | 2018-08-28 |
CN108462737B true CN108462737B (zh) | 2021-02-02 |
Family
ID=63239402
Family Applications (1)
Application Number | Title | Priority Date | Filing Date |
---|---|---|---|
CN201810084245.5A Active CN108462737B (zh) | 2018-01-29 | 2018-01-29 | 基于批处理和流水线的分层数据一致性协议优化方法 |
Country Status (1)
Country | Link |
---|---|
CN (1) | CN108462737B (zh) |
Families Citing this family (3)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
CN110138863B (zh) * | 2019-05-16 | 2021-11-02 | 哈尔滨工业大学(深圳) | 基于Multi-Paxos分组的自适应一致性协议优化方法 |
CN110597809B (zh) * | 2019-08-21 | 2023-05-23 | 中山大学 | 一种支持树状数据结构的一致性算法系统及其实现方法 |
CN115333606B (zh) * | 2022-08-11 | 2023-06-20 | 哈尔滨工业大学(深圳) | 面向低轨星座存储网络的分布式编码数据下载与修复方法 |
Family Cites Families (6)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
JPH11191263A (ja) * | 1997-12-26 | 1999-07-13 | Toshiba Corp | 情報記録再生装置及びメディアアクセス制御方法 |
GB2484086A (en) * | 2010-09-28 | 2012-04-04 | Metaswitch Networks Ltd | Reliability and performance modes in a distributed storage system |
CN103428008B (zh) * | 2013-08-28 | 2016-08-10 | 浙江大学 | 面向多用户群的大数据分发方法 |
CN104008152B (zh) * | 2014-05-21 | 2017-12-01 | 华南理工大学 | 支持海量数据访问的分布式文件系统的架构方法 |
CN105227602A (zh) * | 2014-06-20 | 2016-01-06 | 北京新媒传信科技有限公司 | 一种负载均衡的方法、客户端、注册服务器和系统 |
CN105847175A (zh) * | 2016-04-21 | 2016-08-10 | 中国科学院信息工程研究所 | 数据中心网络中的应用层调度方法 |
-
2018
- 2018-01-29 CN CN201810084245.5A patent/CN108462737B/zh active Active
Also Published As
Publication number | Publication date |
---|---|
CN108462737A (zh) | 2018-08-28 |
Similar Documents
Publication | Publication Date | Title |
---|---|---|
Wang et al. | Hadoop high availability through metadata replication | |
US8117156B2 (en) | Replication for common availability substrate | |
US7630944B2 (en) | Method for consensus decision making in a distributed system | |
US8151062B2 (en) | Consistency models in a distributed store | |
US10445433B2 (en) | Methods and systems of query engines and secondary indexes implemented in a distributed database | |
CN113535656B (zh) | 数据访问方法、装置、设备及存储介质 | |
US11588926B2 (en) | Statistic multiplexed computing system for network-scale reliable high-performance services | |
CN108462737B (zh) | 基于批处理和流水线的分层数据一致性协议优化方法 | |
US20200112499A1 (en) | Multiple quorum witness | |
US10268506B2 (en) | Method and system for master less node communication | |
Netto et al. | Koordinator: A service approach for replicating docker containers in kubernetes | |
CN111316240A (zh) | 管理计算集群接口 | |
US20100322256A1 (en) | Using distributed timers in an overlay network | |
Biswas et al. | A novel leader election algorithm based on resources for ring networks | |
US8627412B2 (en) | Transparent database connection reconnect | |
US8694618B2 (en) | Maximizing data transfer through multiple network devices | |
Erciyes | Distributed mutual exclusion algorithms on a ring of clusters | |
Moraru et al. | A proof of correctness for Egalitarian Paxos | |
US11108663B1 (en) | Ring control data exchange system | |
Du et al. | Leader confirmation replication for millisecond consensus in private chains | |
Jia et al. | Fault Tolerance of Stateful Microservices for Industrial Edge Scenarios | |
Zhang et al. | A replicated file system for Grid computing | |
CN113204437B (zh) | 应用程序实例与客户端设备的连接 | |
US11288004B1 (en) | Consensus-based authority selection in replicated network-accessible block storage devices | |
Kim et al. | Flexrpc: a flexible remote procedure call facility for modern cluster file systems |
Legal Events
Date | Code | Title | Description |
---|---|---|---|
PB01 | Publication | ||
PB01 | Publication | ||
SE01 | Entry into force of request for substantive examination | ||
SE01 | Entry into force of request for substantive examination | ||
GR01 | Patent grant | ||
GR01 | Patent grant |