Raft一致性算法分析与总结

2023-11-11

Raft简介

Raft是一个用于日志复制,同步的一致性算法。它提供了和Paxos一样的功能和性能,但是它的算法结构与Paxos不同。这使得Raft相比Paxos更好理解,并且更容易构建实际的系统。为了强调可理解性,Raft将一致性算法分解为几个关键流程(模块),例如选主,安全性,日志复制,通过将分布式一致性这个复杂的问题转化为一系列的小问题进而各个击破的方式来解决问题。同时它通过实施一个更强的一致性来减少一些不必要的状态,进一步降低了复杂性。Raft还包括了一个新机制,允许线上进行动态的集群扩容,利用有交集的大多数机制来保证安全性。

####一些背景知识

#####A. 一致性算法简单回顾

一致性算法允许一个集群像一个整体一样工作,即使其中一些机器出现故障也不会影响正常服务。正因为如此,一致性算法在构建可信赖的大型分布式系统中都扮演着重要的角色。Paxos算法在过去10年中统治着这一领域:绝大多数实现都是基于Paxos,同时在教学领域讲解一致性问题时Paxos也经常拿来作为范例。但是不幸的是,尽管有很多工作都在试图降低它的复杂性,但是Paxos仍然难以理解。并且,Paxos自身算法的结构不能直接用于实际系统中,想要使用必须要进行大幅度改变,这些都导致无论在工业界还是教育界,Paxos都让人很DT。

时势造英雄,在这样的背景下Raft应运而生。Raft算法使用了一些特别的技巧使得它易于理解,包括算法分解(Raft主要分为选主,日志复制和安全三个大模块),同时在不影响功能的情况下,减少复制状态机的状态,降低复杂性。Raft算法或多或少的和已经存在的一些一致性算法有着相似之处,但是也具有如下特征:

  • 强leader语义:相比其他一致性算法,Raft使用增强形式的leader语义。举个例子,日志只能由leader复制给其它节点。这简化了日志复制需要的管理工作,使得Raft易于理解。
  • leader的选择:Raft使用随机计时器来选择leader,它的实现只是在心跳机制(任何一致性算法中都必须实现)上多做了一点“文章”,不会增加延迟和复杂性。
  • 关系改变:Raft使用了一个新机制joint consensus允许集群动态在线扩容,保障Raft的可持续服务能力。

Raft算法已经被证明是安全正确的,同时也有实验支撑Raft的效率不比其他一致性算法差。最关键是Raft算法要易于理解,在实际系统应用中易于实现的特点使得它成为了解决分布式系统一致性问题上新的“宠儿”。

#####B. 复制状态机

一致性算法是从复制状态机中提出的。简单地讲,复制状态机就是通过彼此之间的通信来将一个集群从一个一致性状态转向下一个一致性状态,它要能容忍很多错误情形。经典如GFS,HDFS都是使用了单独的复制状态机负责选主,存储一些能够在leader crash情况下进行恢复的配置信息等,比如Chubby和ZooKeeper。

复制状态机的典型实现是基于复制日志,如下图所示:

每个server上存储了一个包含一系列指令的日志,这些指令,状态机要按序执行。每一个日志在相同的位置存放相同的指令(可以理解成一个log包含一堆entry,这些entry组成一个数组,每个entry是一个command,数组相同偏移处的command相同),所以每一个状态机都执行了相同序列的指令。一致性算法就是基于这样一个简单的前提:集群中所有机器当前处于一个一致性状态,如果它们从该状态出发执行相同序列的指令走状态机的话,那么它们的下一个状态一定一致。但由于分布式系统中存在三态(成功,失败,无响应),如何来确保每台机器上的日志一致就非常复杂,也是一致性算法需要解决的问题。通常来讲,一致性算法需要具有以下特征:

  • 安全性:在非拜占庭故障下,包括网络分区,延迟,丢包,乱序等等情况下都保证正确。
  • 绝对可用:只要集群中大多数机器正常,集群就能错误容忍,进行正常服务。
  • 不依赖时序保证一致性:由于使用逻辑时钟,所以物理时钟错误或者极端的消息延迟都不影响可用性。
  • 通常情况下,一个指令可以在一轮RPC周期内由大多数节点完成,宕机或者运行速度慢的少数派不影响系统整体性能。

####Raft算法

前面对Raft算法进行了简要的介绍,这里开始对它进行深入分析。Raft实现一致性的机制是这样的:首先选择一个leader全权负责管理日志复制,leader从客户端接收log entries,将它们复制给集群中的其它机器,然后负责告诉其它机器什么时候将日志应用于它们的状态机。举个例子,leader可以在无需询问其它server的情况下决定把新entries放在哪个位置,数据永远是从leader流向其它机器。一个leader可以fail或者与其他机器失去连接,这种情形下会有新的leader被选举出来。

通过leader机制,Raft将一致性难题分解为三个相对独立的子问题:

  • Leader选举:当前leader跪了的情况下,新leader被选举出来。
  • 日志复制:leader必须能够从客户端接收log entries,然后将它们复制给其他机器,强制它们与自己一致。
  • 安全性:如果任何节点将偏移x的log entry应用于自己的状态机,那么其他节点改变状态机时使用的偏移x的指令必须与之相同。

#####A. Raft基本知识

一个Raft集群包含单数个server,5个是一个典型配置,允许该系统最多容忍两个机器fail。在任何时刻,每个server有三种状态:leader,follower,candidate。正常运行时,只有一个leader,其余全是follower。follower是被动的:它们不主动提出请求,只是响应leader和candidate的请求。leader负责处理所有客户端请求(如果客户端先连接某个follower,该follower要负责把它重定向到leader)。第三种状态candidate用于选主。下图展示了这些状态以及它们之间的转化:

Raft将时间分解成任意长度的terms,如下图所示:

terms有连续单调递增的编号,每个term开始于选举,这一阶段每个candidate都试图成为leader。如果一个candidate选举成功,它就在该term剩余周期内履行leader职责。在某种情形下,可能出现选票分散,没有选出leader的情况,这时新的term立即开始。Raft确保在任何term都只可能存在一个leader。term在Raft用作逻辑时钟,servers可以利用term判断一些过时的信息:比如过时的leader。每台server都存储当前term号,它随时间单调递增。term号可以在任何server通信时改变:如果某台server的当前term号小于其它servers,那么这台server必须更新它的term号,与它人保持一致;如果一个candidate或者leader发现自己的term过期,它就必须要“放下身段”变成follower;如果某台server收到一个过时的请求(拥有过时的term号),它会拒绝该请求。Raft servers使用RPC交互,基本的一致性算法只需要两种RPC。RequestVote RPCs由candidate在选举阶段发起。AppendEntries RPCs在leader复制数据时发起,leader在和其他人做心跳时也用该RPC。servers发起一个RPC,如果在没得到响应,则需要不断重试。另外,发起RPC是并行的。

#####B. leader选举

Raft使用心跳机制来触发选举。当server启动时,初始状态都是follower。每一个server都有一个定时器,超时时间为election timeout,如果某server没有超时的情况下收到来自leader或者candidate的任何RPC,定时器重启,如果超时,它就开始一次选举。leader给其他人发RPC要么复制日志,要么就是用来告诉followers老子是leader,你们不用选举的心跳(告诉followers对状态机应用日志的消息夹杂在心跳中)。如果某个candidate获得了大多数人的选票,它就赢得了选举成为新leader。每个server在某个term周期内只能给最多一个人投票,按照先来先给的原则。新leader要给其他人发送心跳,阻止新选举。

在等待选票过程中,一个candidate,假设为A,可能收到它人的声称自己是leader的AppendEntries RPC,如果那家伙的term号大于等于A的,那么A承认他是leader,自己重新变成follower。如果那家伙比自己小,那么A拒绝该RPC,继续保持candidate状态。

还有第三种可能性就是candidate既没选举成功也没选举失败:如果多个followers同时成为candidate去拉选票,导致选票分散,任何candidate都没拿到大多数选票,这种情况下Raft使用超时机制来解决。Raft给每一个server都分配一个随机长度的election timeout(一般是150——300ms),所以同时出现多个candidate的可能性不大,即使机缘巧合同时出现了多个candidate导致选票分散,那么它们就等待自己的election timeout超时,重新开始一次新选举(再一再二不能再三再四,不可能每次都同时出现多个candidate),实验也证明这个机制在选举过程中收敛速度很快。

#####C. 日志复制

一旦选举出了一个leader,它就开始负责服务客户端的请求。每个客户端的请求都包含一个要被复制状态机执行的指令。leader首先要把这个指令追加到log中形成一个新的entry,然后通过AppendEntries RPCs并行的把该entry发给其他servers,其他server如果发现没问题,复制成功后会给leader一个表示成功的ACK,leader收到大多数ACK后应用该日志,返回客户端执行结果。如果followers crash或者丢包,leader会不断重试AppendEntries RPC。Logs按照下图组织:

每个log entry都存储着一条用于状态机的指令,同时保存从leader收到该entry时的term号。该term号可以用来判断一些log之间的不一致状态。每一个entry还有一个index指明自己在log中的位置。

leader需要决定什么时候将日志应用给状态机是安全的,被应用的entry叫committed。Raft保证committed entries持久化,并且最终被其他状态机应用。一个log entry一旦复制给了大多数节点就成为committed。同时要注意一种情况,如果当前待提交entry之前有未提交的entry,即使是以前过时的leader创建的,只要满足已存储在大多数节点上就一次性按顺序都提交。leader要追踪最新的committed的index,并在每次AppendEntries RPCs(包括心跳)都要捎带,以使其他server知道一个log entry是已提交的,从而在它们本地的状态机上也应用。

Raft的日志机制提供两个保证,统称为Log Matching Property:

  • 不同机器的日志中如果有两个entry有相同的偏移和term号,那么它们存储相同的指令。
  • 如果不同机器上的日志中有两个相同偏移和term号的日志,那么日志中这个entry之前的所有entry保持一致。

第一个保证是由于一个leader在指定的偏移和指定的term,只能创建一个entry,log entries不能改变位置。第二个保证通过AppendEntries RPC的一个简单的一致性检查机制完成。当发起一个AppendEntries RPC,leader会包含正好排在新entries之前的那个entry的偏移和term号,如果follower发现在相同偏移处没有相同term号的一个entry,那么它拒绝接受新的entries。这个一致性检查以一种类似归纳法的方式进行:初始状态大家都没有日志,不需要进行Log Matching Property检查,但是无论何时followers只要日志要追加都要进行此项检查。因此,只要AppendEntries返回成功,leader就知道这个follower的日志一定和自己的完全一样。

在正常情形下,leader和follower的日志肯定是一致的,所以AppendEntries一致性检查从不失败。然而,如果leader crash,那么它们的日志很可能出现不一致。这种不一致会随着leader或者followers的crash变得非常复杂。下图展示了所有日志不一致的情形:

如上图(a)(b)followers可能丢失日志,(c)(d)有多余的日志,或者是(e)(f)跨越多个terms的又丢失又多余。在Raft里,leader强制followers和自己的日志严格一致,这意味着followers的日志很可能被leader的新推送日志所覆盖。

leader为了强制它人与自己一致,势必要先找出自己和follower之间存在分歧的点,也就是我的日志与你们的从哪里开始不同。然后令followers删掉那个分歧点之后的日志,再将自己在那个点之后的日志同步给followers。这个实现也是通过AppendEntries RPCs的一致性检查来做的。leader会把发给每一个follower的新日志的偏移nextIndex也告诉followers。当新leader刚开始服务时,它把所有follower的nextIndex都初始化为它最新的log entry的偏移+1(如上图中的11)。如果一个follower的日志和leader的不一致,AppendEntries RPC会失败,leader就减小nextIndex然后重试,直到找到分歧点,剩下的就好办了,移除冲突日志entries,同步自己的。当然这里有很大的优化余地,完全不需要一步一步回溯,怎么玩请自己看论文 1,很简单。

#####D. 安全性

前文讲解了Raft如何选主和如何进行日志复制,然而这些还不足以保证不同节点能执行严格一致的指令序列,需要额外的一些安全机制。比如,一个follower可能在当前leader commit日志时不可用,然而过会它又被选举成了新leader,这样这个新leader可能会用新的entries覆盖掉刚才那些已经committed的entries。结果不同的复制状态机可能会执行不同的指令序列,产生不一致的状况。这里Raft增加了一个可以确保新leader一定包含任何之前commited entries的选举机制。

(1) 选举限制

Raft使用了一个投票规则来阻止一个不包含所有commited entries的candidate选举成功。一个candidate为了选举成功必须联系大多数节点,假设它们的集合叫A,而一个entry如果能commit必然存储在大多数节点,这意味着对于每一个已经committed的entry,A集合中必然有一个节点持有它。如果这个candidate的Log不比A中任何一个节点旧才有机会被选举为leader,所以这个candidate如果要成为leader一定已经持有了所有commited entries(注意我说的持有指只是储存,不一定被应用到了复制状态机中。比如一个老的leader将一个entry发往大多数节点,它们都成功接收,老leader随即就commit这个entry,然后挂掉,此时这个entry叫commited entry,但是它不一定应用在了集群中所有的复制状态机上)。这个实现在RequestVote RPC中:该RPC包含了candidate log的信息,选民如果发现被选举人的log没有自己新,就拒绝投票。Raft通过比较最近的日志的偏移和term号来决定谁的日志更新。如果两者最近的日志term号不同,那么越大的越新,如果term号一样,越长的日志(拥有更多entries)越新。

(2) 提交早期terms的entries

正如前面所述的那样,一个leader如果知道一个当前term的entry如果储在大多数节点,就认为它可以commit。但是,一个leader不能也认为一个早于当前term的entry如果存在大多数节点,那么也是可以commit的。下图展示了这样一种状况,一个老的log存储在大多数节点上,但是仍有可能被新leader覆盖掉:

要消除上图中的问题,Raft采取针对老term的日志entries绝不能仅仅通过它在集群中副本的数量满足大多数,就认为是可以commit的。完整的commit语义也演变成:一个日志entry如果能够被认为是可以提交的,必须同时满足两个条件:

  • 这个entry存储在大多数节点上
  • 当前term至少有一个entry存储在大多数节点。

以上图为例,这两个条件确保一旦当前leader将term4的entry复制给大多数节点,那么S5不可能被选举为新leader了(日志term号过时)。综合考虑,通过上述的选举和commit机制,leaders永远不会覆盖已提交entries,并且leader的日志永远绝对是”the truth”。

(3) 调解过期leader

在Raft中有可能同一时刻不只一个server是leader。一个leader突然与集群中其他servers失去连接,导致新leader被选出,这时刚才的老leader又恢复连接,此时集群中就有了两个leader。这个老leader很可能继续为客户端服务,试图去复制entries给集群中的其它servers。但是Raft的term机制粉碎了这个老leader试图造成任何不一致的行为。每一个RPC servers都要交换它们的当前term号,新leader一旦被选举出来,肯定有一个大多数群体包含了最新的term号,老leader的RPC都必须要联系一个大多数群体,它必然会发现自己的term号过期,从而主动让贤,退变为follower状态。

然而有可能是老leader commit一个entry后失去连接,这时新leader必然有那个commit的entry,只是新leader可能还没commit它,这时新leader会在初次服务客户端前先把这个entry再commit一次,followers如果已经commit过直接返回成功,没commit就commit后返回成功而已,不会造成不一致。

#####E. Follower 或者candidate crash

Followers和candidate的crash比起leader来说处理要简单很多,它们的处理流程是相同的,如果某个follower或者candidate crash了,那么未来发往它的RequestVote和AppendEntries RPCs 都会失败,Raft采取的策略就是不停的重发,如果crash的机器恢复就会执行成功。另外,如果server crash是在完成一个RPC但在回复之前,那么在它恢复之后仍然会收到相同的RPC(让它重试一次),Raft的所有RPC都是幂等操作,如果follower已经有了某个entry,但是leader又让它复制,follower直接忽略即可。

#####F. 时间与可用性

Raft集群的可用性需要满足一个时间关系,即下面的公式:

broadcastTime代表平均的广播延迟(从并行发起RPC开始,直到收到大多数的回复为止)。electionTimeout就是前文所述的超时时间间隔,MTBF代表一个机器两次宕机时间间隔的平均值。broadcastTime必须远远小于electionTimeout,否则会频繁触发无意义的选举重启。electionTimeout远远小于MTBF就很好理解了。

####集群扩容

迄今为止的讨论都是假设集群配置不变的情况下(参与一致性算法的机器数目不变),但是实际中集群扩容(广义概念,泛指集群容量变化,可增可减)有时是必须的。比如业务所需,集群需要扩容,或者某机器永久损坏,需要从集群中剔除等等。

扩容最大的挑战就是保证一致性很困难,因为扩容不是原子的,有可能集群中一部分机器用老配置信息,另一部分用新配置信息,如上图所示,因此究竟多少算大多数在集群中可能存在分歧。扩容一般都分为两个阶段,有很多实现方法,比较典型的就是第一阶段,使所有旧配置信息失效,这段时间不对外提供服务;第二阶段允许新配置信息,重新对外服务。在Raft中集群第一阶段首先使集群转向一个被称作联合一致性(joint consensus)的状态;一旦这个联合一致性(有一个特殊的Cold,new entry表征)被提交,这个系统就开始向新配置迁移。joint consensus既包含老配置信息,又包含新配置信息,它的规则(Cold,new规则)如下:

  • log entries复制给集群中所有机器,不管配置信息新旧
  • 任何配置的server都有权利当leader
  • 达成一致所需要的大多数(不管是选举还是entry提交),既要包括老配置中的一个大多数也要包括新配置机器中的一个大多数。

joint consensus允许集群配置平滑过渡而不失去安全和一致性,同时集群可正常对外服务。集群配置信息以一个特殊的entry表征,存储在log中并和其他entry语义一样。当一个leader收到扩容请求,它就创建一个Cold,new的entry,并复制给集群其它其它机器,一旦有某个follower收到此entry并追加到自己的日志中,它就使用Cold,new规则(不需要committed)。leader按照Cold,new 规则对Cold,new进行commit。如果一个leader crash了,新leader既可能是没收到Cold,new的又可能是收到的,但是这两种情况都不会出现leader用Cnew规则做决策。

一旦Cold,new被提交,就开始向新配置转换。Raft保证只有拥有Cold,new的节点才会被选举为leader。现在leader可以很安全地创建一个叫Cnew的entry,然后复制给集群中属于新配置的节点。配置信息还是节点一收到就可以用来做决策。Cnew的commit使用Cnew 规则,旧配置已经与集群无关,新配置中不存在的机器可以着手关闭,Raft通过保证不让Cold和Cnew的节点有机会同时做决策来保障安全性。配置改变示意图如下:

有三个要注意的点:

(1) 新server加入进集群时也许没有存储任何log entries,它们需要很长时间来追上原有机器的“进度”,为了防止集群性能出现巨大的抖动,Raft在配置改变前又引入了一个特殊的阶段,当新机器加入集群时,它们作为无投票权的节点,即leader还是会将log entries复制给它们,但是不会被当做大多数对待。一旦这些“新人”追上了其他机器的进度,动态扩容可以像上述一样执行。

(2) 当前leader也许不是集群新配置中的一份子,在这种情况下,一旦Cnew被提交,这个leader就主动退出。这意味着当Cnew提交过程中这个leader要管理一个不包括它自己的集群。这时,它在给其他节点复制log entries时不把自己计入大多数。当Cnew提交成功,这个leader的使命就光荣完成了,在这个时间点前,只有Cold的节点才会被选举为leader。

(3) 第三个问题是被移除的机器可能会影响集群服务。这些机器不会再接收到心跳信息,它们因此可能重启选举,结果是它们用一个更新的term号发起RequestVote RPCs,当前leader无奈的退化为follower。新leader(拥有新配置的)还是会被选举出来,但是那些被移除的机器还是继续超时,开启选举,导致系统可用性降低。为解决这一问题,需要有一个机制让集群中节点能够忽略这种RequestVote RPCs,相信当前leader正在正常工作。Raft使用最小超时延迟(前面说过,Raft会随机为每个节点指定一个随机的election timeout,典型的是150ms到300ms,最小超时延迟就是它们之间的最小值)来保证,如果一个节点在最小超时延迟前收到一个RequestVote RPCs,那么该节点不会提升term号,也不会为其投票。这个不会影响正常的选举,因为正常选举中都是至少等待一个最小超时延迟才开始下一次选举的。

####Raft新集群扩容方案

为了降低集群扩容的复杂性,Raft还有一个可以备选的方案。它增强了扩容的限制:一次只允许一台机器加入或移除集群。复杂的扩容可以通过一系列的单机增加或删除变向实现。

当从集群中添加或删除一台机器时,任何旧配置集群中的大多数和任何新配置集群中的大多数必然存在一个交集,如下图所示。

注意就是这个交集让集群不可能存在两个互相独立,没有交集的大多数群体。因此系统中不会同时存在两个leader(一个由旧配置集群选举出来,一个由新配置集群选举出来),因此扩容是安全的,集群可以直接从旧配置转向新配置。

当leader收到添加或删除一台机器的请求,它将该Cnew添加到自己的log中,然后使用一样的复制机制,把这个entry复制给属于新配置集群的所有节点。只要节点把Cnew添加进log,就马上使用新配置信息,无需等到该entry提交。leader使用Cnew规则对Cnew进行提交,一旦提交完成,扩容就宣告完成,leader就知道任何没有Cnew的节点都不可能形成一个大多数,这样的节点也不可能成为集群的leader。Cnew的提交暗示了以下三件事情:

  1. leader获知扩容成功完成
  2. 如果新配置移除一台机器,那么这台机器可以着手关闭
  3. 新的扩容可以开始

正如上面所讲的那样,servers永远使用log中最新的配置,不管这个配置entry是否被提交。这样leader知道一

本文内容由网友自发贡献,版权归原作者所有,本站不承担相应法律责任。如您发现有涉嫌抄袭侵权的内容,请联系:hwhale#tublm.com(使用前将#替换为@)

Raft一致性算法分析与总结 的相关文章

  • TIDB使用时的注意点笔记

    场景 xff1a 虽然TiDB号称完全兼容MySQL 5 7 协议 MySQL 5 7 常用的功能及语法 xff0c 但是其与MySQL数据库仍然存在一些差异 xff0c 可能会导致下游TiDB环境故障 以下是我们使用TiDB时需要重点关注
  • TiDB-部署(tiup方式)

    一 环境 ip xff08 非真实 xff09 功能配置192 168 1 1中控机 xff08 监控等位置所在 xff09 最低192 168 1 2TIDB PD TIFLUSH 如果机器多可以分开 高192 168 1 3TIKV 1
  • rocksdb 编译安装 日志

    Compilation RocksDB s library should be able to compile without any dependency installed although we recommend installin
  • 猿创征文

    猿创征文 国产数据库实战之TiDB 数据库快速入门 一 系统检查 1 检查系统版本 2 查看本地IP地址 3 TiDB集群介绍 二 快速部署本地测试集群 1 安装 TiUP工具 2 声明全局环境变量 3 快速部署TiDB 集群 三 连接 T
  • 大数据时代的Tcaplus游戏存储

    大数据时代的Tcaplus游戏存储 shiweizhang 2015 10 27 1 7k浏览 游戏开发数据分析场景 想免费获取内部独家PPT资料库 观看行业大牛直播 点击加入腾讯游戏学院游戏开发行业精英群711501594 摘要 大数据具
  • 分布式系统一致性研究,paxos算法

    感谢eric的敦促 感谢shuai的感召 我尝试记录一点混乱的思考 什么是分布式系统 毋庸置疑 Internet和DNS是两个典型的成功的分布式系统 那么 分布式系统是不是就是计算机网络 1990年 Sun Microsystems 公司提
  • tikv的操作

    tikv的操作 kvproto master proto raft cmdpb proto message Request optional CmdType cmd type 1 optional GetRequest get 2 opti
  • TIDB简介及TIDB部署、原理和使用介绍

    TiDB简介及TiDB部署 原理和使用介绍 从MySQL架构到TiDB 数据库分类 介绍TiDB数据库之前 先引入使用场景 如今的数据库种类繁多 RDBMS 关系型数据库 NoSQL Not Only SQL NewSQL 在数据库领域均有
  • TiDB数据库权限管理

    TiDB数据库权限管理 TiDB 的权限管理系统按照 MySQL 的权限管理进行实现 TiDB 支持大部分的 MySQL 的语法和权限类型 本文主要介绍 TiDB 权限相关操作 各项操作需要的权限以及权限系统的实现 权限相关操作 授予权限
  • 香橙派4和树莓派4B构建K8S集群实践之八: TiDB

    目录 1 说明 2 准备工作 3 安装 3 1 参考Tidb官方 v1 5安装说明 3 2 准备存储类 3 3 创建crd 3 4 执行operator 3 5 创建cluster dashboard monitor容器组 3 6 设置访问
  • PingCAP 创始人刘奇:开源分布式数据库如何搞定 OLTP

    7月28日 以 科技 洞见未来 为主题的 QingCloud Insight 2016 大会将在北京召开 连接云计算产业链上下游 展示 IT 领域最新研发成果 作为 NewSQL 技术的代表 PingCAP 联合创始人 CEO 刘奇将在本次
  • TiDB介绍

    目录 TiDB 简介 一 四大核心应用场景 二 TiDB 整体架构 三 TiDB 数据库的存储 Key Value Pairs 键值对 本地存储 RocksDB Raft 协议 Region MVCC 分布式 ACID 事务 参考 TiDB
  • 共识算法 --- PBFT、Raft和Paxos

    目录 一 Raft共识算法 1 什么是Raft 2 Raft的工作流程 3 Raft的相关应用 4 Raft的缺陷 5 Raft中三个子问题 5 1 Leader选举 Election 5 1 1 节点的三种角色 5 1 2 选举过程 5
  • 基于 TiDB 的 Apache APISIX 高可用配置中心的最佳实践

    项目背景 什么是 Apache APISIX API 网关作为微服务架构中的重要组件 是流量的核心出入口 用于统一处理和业务相关的请求 可有效解决海量请求 恶意访问等问题 保障业务安全性与稳定性 作为开源的云原生 API 网关 Apache
  • Golang Http Server源码阅读

    这篇文章出现的理由是业务上需要创建一个Web Server 创建web是所有语言出现必须实现的功能之一了 在nginx fastcgi php广为使用的今天 这里我们不妨使用Go来进行web服务器的搭建 前言 使用Go搭建Web服务器的包有
  • Raft一致性算法分析与总结

    Raft简介 Raft是一个用于日志复制 同步的一致性算法 它提供了和Paxos一样的功能和性能 但是它的算法结构与Paxos不同 这使得Raft相比Paxos更好理解 并且更容易构建实际的系统 为了强调可理解性 Raft将一致性算法分解为
  • 猿创征文|国产数据库之TiDB详解和安装使用

    文章目录 前言 1 TiDB简介 2 TiDB架构 3 TiDB的安装使用 3 1 部署本地测试集群 3 2 在单机上模拟部署生产环境集群 4 在生产环境部署TiDB 4 1 软硬件环境需求及前置检查 4 2 环境与系统配置检查 4 3 在
  • 【TIDB】TIDB数据类型详解

    TIDB的数据类型 文章目录 TIDB的数据类型 1 数值类型 2 日期和时间类型 3 字符串类型 3 SET 类型 4 JSON类型 1 数值类型 1 整数类型 2 浮点类型 3 定点类型 decamal 20 6 2 日期和时间类型 3
  • /usr/lib/libstdc++.so.6: version `GLIBCXX_3.4.15' not found错误的解决

    http www cnblogs com weinyzhou p 4983306 html 在安装cmake3 5 1运行 bootstrap的时候出现如下提示 code class hljs asciidoc has numbering
  • 分布式一致性协议Raft原理与实例

    thesecretlivesofdat 分布式一致性协议Raft原理与实例 标签 分布式算法 2015 09 30 20 43 3519人阅读 评论 15 收藏 举报 分类 Hadoop 7 版权声明 本文为博主原创文章 未经博主允许不得转

随机推荐

  • 分析师:芯片短缺至少还将持续一年

    众所周知 半导体行业对需求突然增加的反应很慢 一些分析家认为 现在芯片需求超过供应约30 要赶上需求将需要三到四个季度 从本质上讲 这意味着芯片短缺将一直持续到2022年 芯片需求正在蓬勃发展 如今 几乎所有电子设备中都装有芯片 因此对半导
  • 面试官:谈谈你对大数据平台架构的理解?

    笼统的来说 大数据的架构一共有五层 首先是数据源层 即最原始的数据层 数据在这一层里 还只是杂草地里的野菜 如果要问这片地的具体信息 目前来讲有三个地方 一个地方是企业内部自有数据 例如淘宝 京东等电商平台的用户信息 订单信息 商品信息等
  • 数字化转型成熟度模型介绍

    中关村信息技术和实体经济融合发展联盟提出了一种数字化转型成熟度模型系列标准 目前已经被众多央企采用 作为数字化转型战略框架和评价的依据 用友作为全球领先的数智化服务商 也参与了这一系列标准的制定 今天我们就来介绍一下这套成熟度模型 并讨论对
  • k8s基础概念:port ,targetport,nodeport

    在Kubernetes中 有三种类型的端口与Service相关 port targetPort和NodePort 它们分别用于不同的用途 port port字段定义了Service暴露给集群内部和外部的端口号 当你创建一个Service时
  • web前端职业规划(转)

    关于一个WEB前端的职业规划 其实是有各种的答案 没有哪种答案是完全正确的 全凭自己的选择 只要是自己选定了 坚持去认真走 就好 在这里 我只是简要说一下自己对于这块儿内容的理解 有一个观点想要分享给大家的是 任何规划和目标的实现都依赖于知
  • 矩阵连乘问题C++实现

    矩阵连乘问题C 1 认真审阅题目 明确题目的已知条件和求解的目标 2 问题建模 3 算法设计 4 编码实现 1 认真审阅题目 明确题目的已知条件和求解的目标 给定n个矩阵 A1 A2 A3 An 其中Ai与Ai 1 i 1 2 3 4 n
  • 从0到1带你构建——低代码开发入门案例

    个人简介 个人主页 前端杂货铺 学习方向 主攻前端方向 也会涉及到服务端 Node js 个人状态 在校大学生一枚 已拿多个前端 offer 秋招 未来打算 为中国的工业软件事业效力 n 年 推荐学习 前端面试宝典 Vue2 Vue3 Vu
  • 目标检测:锚点介绍及应用

    目标检测 锚点介绍及应用 介绍 应用 生成锚点图 步骤 锚点匹配 步骤 介绍 锚点相当于在待预测的特征数据上预设出可能的物体边界框 即预设出特征数据可能代表的物体区域 每个区域通常由两个属性构成 尺度 scale或size 和比例 rati
  • laravel实战项目搭建及代码管理

    本文目录 前言 一 安装laravel和装插件 1 1 安装laravel 1 2 安装开发插件 二 运行项目及配置 2 1 配置虚拟主机与绑定hosts文件 2 2 配置数据库连接 2 3 本地化配置 2 4 删除默认文件或目录 三 gi
  • 算法训练Day11

    目录 LeetCode232 用栈实现队列 1 思路 2 代码实现 3 复杂度分析 4 思考 LeetCode225 用队列实现栈 1 思路 2 代码实现 3 复杂度分析 4 思考 LeetCode20 有效的括号 方法一 使用栈和字典 1
  • Ubuntu18配置ssh免密登录

    安装配置 sudo apt get install openssh server cd ssh 若没有该目录 请先执行一次 ssh localhost ssh keygen t rsa 会有提示 都按回车就可以 cat id rsa pub
  • JSON注入与CSRF漏洞原理与复现

    JSON注入与CSRF漏洞原理与复现 1 JSON JavaScript Object Notation JavaScript对象表示法 2 它是一种数据格式 而不是一种编程语言 3 JSON的语法 有三种类型的值 简单值 对象 数组 关于
  • 【深度学习】 Python 和 NumPy 系列教程(十六):Matplotlib详解:2、3d绘图类型(2)3D散点图(3D Scatter Plot)

    目录 一 前言 二 实验环境 三 Matplotlib详解 1 2d绘图类型 2 3d绘图类型 0 设置中文字体 1 线框图 Wireframe Plot 2 3D散点图 3D Scatter Plot 一 前言 Python是一种高级编程
  • Qt for Android——关于版本的选择(ABI和CPU版本)

    1 前景介绍 之前在开发Qt for Android程序的时候 不知道如何选择套件的版本 乱选一通 经常是程序开发完 到了运行选择设备的时候告诉我设备不匹配 不支持这个ABI 下面就来讲讲这些版本 2 Qt中套件对应的版本 在我们安装Qt的
  • JTest

    接到parasoft公司一位先生打来的电话 说下个月第二周到上海来 希望顺便给我们组培训一下JTest和C Test的使用 我是用java的 自然对JTest更感兴趣一些 上网一搜 原来JTest这么出名 自己的确孤陋寡闻了 看了一下价格
  • 如何下载微信支付证书(API证书)

    一 登录微信商户平台 1 商户平台登陆网址 微信支付 中国领先的第三方支付平台 微信支付提供安全快捷的支付方式http pay weixin qq com 2 登录方式 扫码登录登录 二 进入微信商户平台下载证书 1 点击账户中心 账户设置
  • Vue简易登陆页面

    目录 1 效果展示 2 Vue代码 3 存点图片 1 效果展示 2 Vue代码
  • selenium练习实例

    1 项目流程 2 中心调度 中心调度 defmain try total search total int re compile d search total group 1 fori inrange 2 total 1 next page
  • 一分钟解决Chrome浏览器主页被hao123、360和2345篡改简单有效方法

    当你打开浏览器看到各种首页跳转的页面 对于强迫症的我是不能接受的 各种情况都碰到了 现在给出解决方法 按照下面的方式去排查就可以一定能解决你的问题 如果不行的话你来打我呀 如果问题解决了希望你能推荐给其他人 提示 检查下杀毒软件有没有绑定浏
  • Raft一致性算法分析与总结

    Raft简介 Raft是一个用于日志复制 同步的一致性算法 它提供了和Paxos一样的功能和性能 但是它的算法结构与Paxos不同 这使得Raft相比Paxos更好理解 并且更容易构建实际的系统 为了强调可理解性 Raft将一致性算法分解为