TIDB 架构及分布式协议Paxos和Raft对比

近来newsql大热,尤以TIDB最火,pingcap不断打磨TiDB,现如今版本已经迭代到3.0,产品已经基本趋于成熟。
对于TiDB,整体架构图如下图所示

是由四个模块组成,TiDB Server,PD Server,TiKV Server,TiSpark。

  • TiDB Server负责接受SQL请求,处理SQL的相关逻辑,并通过PD找到存储计算所需数据的TiKV地址,与TiKV交互获取数据,最终返回结果。TiDB Server是无状态的,其本身并不存储数据,只负责计算,可以无限水平扩展,可以通过负载均衡组件(如LVD,HAPROXY,F5等)对外提供统一的接入地址。推荐部署俩个实例,前端通过负载均衡组件对外提供服务,当单个实例失效时,会影响正在这个实例上进行的session,从应用的角度看,会出现单次请求失败的情况,重新连接后即可继续获得服务。
  • Placement Driver (简称 PD),是整个集群的管理模块,其主要的工作有三个,一是存储集群的元信息,(某个Key存储在哪个TiKV节点上);二是对TiKV集群进行调度和负载均衡(如数据的迁移,Raft group leader的迁移等),三是分配全局唯一且递增的事务ID。PD 通过 Raft 协议保证数据的安全性。Raft 的 leader server 负责处理所有操作,其余的 PD server 仅用于保证高可用。单个实例失效时,如果这个实例不是 Raft 的 leader,那么服务完全不受影响;如果这个实例是 Raft 的 leader,会重新选出新的 Raft leader,自动恢复服务。PD 在选举的过程中无法对外提供服务,这个时间大约是3秒钟。推荐至少部署三个 PD 实例。
  • TiKV Server 负责存储数据,从外部看 TiKV 是一个分布式的提供事务的 Key-Value 存储引擎。存储数据的基本单位是 Region,每个 Region 负责存储一个 Key Range(从 StartKey 到 EndKey 的左闭右开区间)的数据,每个 TiKV 节点会负责多个 Region。TiKV 使用 Raft 协议做复制,保持数据的一致性和容灾。副本以 Region 为单位进行管理,不同节点上的多个 Region 构成一个 Raft Group,互为副本。数据在多个 TiKV 之间的负载均衡由 PD 调度,这里也是以 Region 为单位进行调度。TiKV 是一个集群,通过 Raft 协议保持数据的一致性(副本数量可配置,默认保存三副本),并通过 PD 做负载均衡调度。单个节点失效时,会影响这个节点上存储的所有 Region。对于 Region 中的 Leader 结点,会中断服务,等待重新选举;对于 Region 中的 Follower 节点,不会影响服务。当某个 TiKV 节点失效,并且在一段时间内(默认 30 分钟)无法恢复,PD 会将其上的数据迁移到其他的 TiKV 节点上。
  • TiSpark作为 TiDB 中解决用户复杂 OLAP 需求的主要组件,将 Spark SQL 直接运行在 TiDB 存储层上,同时融合 TiKV 分布式集群的优势,并融入大数据社区生态。至此,TiDB 可以通过一套系统,同时支持 OLTP 与 OLAP,免除用户数据同步的IO损耗。


分布式协议Paxos和Raft
算法演进过程

Paxos

Paxos算法是Leslie Lamport在1990年提出的一种基于消息传递的一致性算法。由于算法难以理解,起初并没有引起大家的重视,Lamport在1998年将论文重新发表到TOCS上,即便如此Paxos算法还是没有得到重视,2001年Lamport用可读性比较强的叙述性语言给出算法描述。

06年Google发布了三篇论文,其中在Chubby锁服务使用Paxos作为Chubby Cell中的一致性算法,Paxos的人气从此一路狂飙。

基于Paxos协议的数据同步与传统主备方式最大的区别在于:Paxos只需超过半数的副本在线且相互通信正常,就可以保证服务的持续可用,且数据不丢失。

Basic-Paxos

Basic-Paxos解决的问题:在一个分布式系统中,如何就一个提案达成一致。

需要借助两阶段提交实现:

Prepare阶段:

Proposer选择一个提案编号n并将prepare请求发送给 Acceptor。
Acceptor收到prepare消息后,如果提案的编号大于它已经回复的所有prepare消息,则Acceptor将自己上次接受的提案回复给Proposer,并承诺不再回复小于n的提案。

Accept阶段:

当一个Proposer收到了多数Acceptor对prepare的回复后,就进入批准阶段。它要向回复prepare请求的Acceptor发送accept请求,包括编号n和根据prepare阶段决定的value(如果根据prepare没有已经接受的value,那么它可以自由决定value)。
在不违背自己向其他Proposer的承诺的前提下,Acceptor收到accept请求后即接受这个请求。

Mulit-Paxos

Mulit-Paxos解决的问题:在一个分布式系统中,如何就一批提案达成一致。

当存在一批提案时,用Basic-Paxos一个一个决议当然也可以,但是每个提案都经历两阶段提交,显然效率不高。Basic-Paxos协议的执行流程针对每个提案(每条redo log)都至少存在三次网络交互:1. 产生log ID;2. prepare阶段;3. accept阶段。

所以,Mulit-Paxos基于Basic-Paxos做了优化,在Paxos集群中利用Paxos协议选举出唯一的leader,在leader有效期内所有的议案都只能由leader发起。

这里强化了协议的假设:即leader有效期内不会有其他server提出的议案。因此,对于后续的提案,我们可以简化掉产生log ID阶段和Prepare阶段,而是由唯一的leader产生log ID,然后直接执行Accept,得到多数派确认即表示提案达成一致(每条redo log可对应一个提案)。

相关产品

X-DB、OceanBase、Spanner都是使用Multi-Paxos来保障数据一致性。

MySQL Group Replication的xcom中也使用了Multi-Paxos。

PaxosStore

PaxosStore是腾讯WXG基于Paxos实现的分布式一致性中间件,在微信的用户账号管理、用户关系管理、即使消息、社交网络、在线支付等场景中广泛应用。

Raft

Raft是斯坦福大学的Diego Ongaro、John Ousterhout两个人以易理解为目标设计的一致性算法,在2013年发布了论文:《In Search of an Understandable Consensus Algorithm》。从2013年发布到现在,已经有了十几种语言的Raft算法实现框架,较为出名的有etcd,Google的Kubernetes也是用了etcd作为他的服务发现框架。

与Paxos相比,Raft强调的是易理解、易实现,Raft和Paxos一样只要保证超过半数的节点正常就能够提供服务。

众所周知,当问题较为复杂时,可以把问题分解为几个小问题来处理,Raft也使用了分而治之的思想,把算法分为三个子问题:

选举(Leader election)
日志复制(Log replication)
安全性(Safety)

分解后,整个raft算法变得易理解、易论证、易实现。

相关产品

etcd使用Raft来保障数据一致性。

Mulit-Raft

许多NewSQL数据库的数据规模上限都定位在100TB以上,为了负载均衡,都会对数据进行分片(sharding),所以就需要使用多个Raft集群(即Multi-Raft),每个Raft集群对应一个分片。

在多个Raft集群间可增加协同来减少资源开销、提升性能(如:共享通信链接、合并消息等)。

相关产品

TiDB、CockroachDB、PolarDB都是使用Mulit-Raft来保障数据一致性。

Raft和Multi-Paxos的区别

Raft是基于对Multi-Paxos的两个限制形成的:

发送的请求的是连续的, 也就是说Raft的append 操作必须是连续的, 而Paxos可以并发 (这里并发只是append log的并发, 应用到状态机还是有序的)。
Raft选主有限制,必须包含最新、最全日志的节点才能被选为leader. 而Multi-Paxos没有这个限制,日志不完备的节点也能成为leader。

Raft可以看成是简化版的Multi-Paxos。

Multi-Paxos允许并发的写log,当leader节点故障后,剩余节点有可能都有日志空洞。所以选出新leader后, 需要将新leader里没有的log补全,在依次应用到状态机里。

Raft选举过程
Raft协议中,一个节点有三个状态:Leader、Follower和Candidate,但同一时刻只能处于其中一种状态。Raft选举实际是指选举Leader,选举是由候选者(Candidate)主动发起,而不是由其它第三者。

并且约束只有Leader才能接受写和读请求,只有Candidate才能发起选举。如果一个Follower和它的Leader失联(失联时长超过一个Term),则它自动转为Candidate,并发起选举。

发起选举的目的是Candidate请求(Request)其它所有节点投票给自己,如果Candidate获得多数节点(a majority of nodes)的投票(Votes),则自动成为Leader,这个过程即叫Leader选举。

在Raft协议中,正常情况下Leader会周期性(不能大于Term)的向所有节点发送AppendEntries RPC,以维持它的Leader地位。

相应的,如果一个Follower在一个Term内没有接收到Leader发来的AppendEntries RPC,则它在延迟随机时间(150ms~300ms)后,即向所有其它节点发起选举。

采取随机时间的目的是避免多个Followers同时发起选举,而同时发起选举容易导致所有Candidates都未能获得多数Followers的投票(脑裂,比如各获得了一半的投票,谁也不占多数,导致选举无效需重选),因而延迟随机时间可以提高一次选举的成功性。

原文地址:https://blog.51cto.com/liuminkun/2377029

时间: 2024-10-29 16:31:30

TIDB 架构及分布式协议Paxos和Raft对比的相关文章

搞懂分布式技术2:分布式一致性协议与Paxos,Raft算法

搞懂分布式技术2:分布式一致性协议与Paxos,Raft算法 2PC 由于BASE理论需要在一致性和可用性方面做出权衡,因此涌现了很多关于一致性的算法和协议.其中比较著名的有二阶提交协议(2 Phase Commitment Protocol),三阶提交协议(3 Phase Commitment Protocol)和Paxos算法. 本文要介绍的2PC协议,分为两个阶段提交一个事务.并通过协调者和各个参与者的配合,实现分布式一致性. 两个阶段事务提交协议,由协调者和参与者共同完成. 角色 XA概

分布式理论系列(二)2PC 到 3PC 到 Paxos 到 Raft 到 Zab

分布式理论系列(二)2PC 到 3PC 到 Paxos 到 Raft 到 Zab 本文介绍一致性实现的几种方案: 2PC 到 3PC 到 Paxos 到 Raft 到 Zab 两类一致性(操作原子性与副本一致性) 2PC 3PC 协议用于保证属于多个数据分片上的操作的原子性.这些数据分片可能分布在不同的服务器上,2PC 协议保证多台服务器上的操作要么全部成功,要么全部失败. Paxos Raft Zab 协议用于保证同一个数据分片的多个副本之间的数据一致性.当这些副本分布到不同的数据中心时,这个

图解分布式一致性协议Paxos

Paxos协议/算法是分布式系统中比较重要的协议,它有多重要呢? <分布式系统的事务处理>: Google Chubby的作者Mike Burrows说过这个世界上只有一种一致性算法,那就是Paxos,其它的算法都是残次品. <大规模分布式存储系统>: 理解了这两个分布式协议之后(Paxos/2PC),学习其他分布式协议会变得相当容易. 学习Paxos算法有两部分:a) 算法的原理/证明:b) 算法的理解/运作. 理解这个算法的运作过程其实基本就可以用于工程实践.而且理解这个过程相

[转]图解分布式一致性协议Paxos

Paxos协议/算法是分布式系统中比较重要的协议,它有多重要呢? <分布式系统的事务处理>: Google Chubby的作者MikeBurrows说过这个世界上只有一种一致性算法,那就是Paxos,其它的算法都是残次品. <大规模分布式存储系统>: 理解了这两个分布式协议之后(Paxos/2PC),学习其他分布式协议会变得相当容易. 学习Paxos算法有两部分:a) 算法的原理/证明:b) 算法的理解/运作. 理解这个算法的运作过程其实基本就可以用于工程实践.而且理解这个过程相对

分布式一致性算法:Raft 算法

Raft 算法是可以用来替代 Paxos 算法的分布式一致性算法,而且 raft 算法比 Paxos 算法更易懂且更容易实现.本文对 raft 论文进行翻译,希望能有助于读者更方便地理解 raft 的思想.如果对 Paxos 算法感兴趣,可以看我的另一篇文章:分布式系列文章--Paxos算法原理与推导 摘要Raft 是用来管理复制日志(replicated log)的一致性协议.它跟 multi-Paxos 作用相同,效率也相当,但是它的组织结构跟 Paxos 不同.这使得 Raft 比 Pax

分布式系统基本概念(一致性、数据分布、复制策略、分布式协议)

分布式系统基本概念 异常类型 1 服务器down机(随时发生.内存数据丢失(因此需要考虑数据持久化).down机重启之后要恢复内存信息) 2 网络异常(消息丢失.消息乱序(UDP)或者网络包数据错误.区域内可通信区域间不可通信) 3 磁盘故障(磁盘损坏(备份).磁盘数据错误(校验和解决)) 超时?不能简单的当做失败(分布式存储的3态成功.失败.超时) 一致性 副本是分布式存储系统容错技术的唯一手段 保证副本之间的一致性是整个分布式系统的理论核心 两个角度理解: 1 用户角度: (1)强一致性:A

分布式 一致性Paxos算法(转载)

文章1比较通俗易懂,可以入门,转载地址是http://www.cnblogs.com/linbingdong/p/6253479.html Paxos算法在分布式领域具有非常重要的地位.但是Paxos算法有两个比较明显的缺点:1.难以理解 2.工程实现更难. 网上有很多讲解Paxos算法的文章,但是质量参差不齐.看了很多关于Paxos的资料后发现,学习Paxos最好的资料是论文<Paxos Made Simple>,其次是中.英文版维基百科对Paxos的介绍.本文试图带大家一步步揭开Paxos

微服务架构的分布式事务场景及解决方案分析

分布式系统架构中,分布式事务问题是一个绕不过去的挑战.而微服务架构的流行,让分布式事问题日益突出! 下面我们以电商购物支付流程中,在各大参与者系统中可能会遇到分布式事务问题的场景进行详细的分析! 如上图所示,假设三大参与平台(电商平台.支付平台.银行)的系统都做了分布式系统架构拆分,按上数中的流程步骤进行分析: 1.电商平台中创建订单:预留库存.预扣减积分.锁定优惠券,此时电商平台内各服务间会有分布式事务问题,因为此时已经要跨多个内部服务修改数据: 2.支付平台中创建支付订单(选银行卡支付):查

分享一个大型进销存供应链项目(多层架构、分布式WCF多服务器部署、微软企业库架构)

分享一个大型进销存供应链项目(多层架构.分布式WCF多服务器部署.微软企业库架构) 这是一个比较大型的项目,准备开源了.支持N家门店同时操作.远程WCF+企业库5.0实现. 这块应该算是库存模块中的核心模块了,因为该块的业务逻辑比较多,比较繁琐,大致讲讲业务逻辑吧,大致的逻辑为:出库单/出库单-->填写订单-->出库/入库-->修改库存信息,按照这个顺序来完成入库出库,顺序不能颠倒,同时还要实现订单的删除,修改,在修改库存信息时由于表和表之间有很多的外键关系,所以要同时删除多张表中含有删