微信分布式数据存储协议对比——Paxos和Quorum

大数据

分布式系统是网络化的计算机系统,海量数据的互联网应用只能通过分布式系统协调大量计算机来支撑。微信后台存储大量使用了分布式数据存储方式的NoSQL集群,比如核心业务:账号、支付单据、关系链、朋友圈等。存储设备出现异常是必然,分布式系统通过多节点分布及冗余,避免个别异常节点影响到系统的正常服务,同时提供平行扩展能力。微信自研的分布式存储在发展的不同阶段,分别依赖过Paxos和Quorum两种方案维护一致性。Paxos和Quorum也是互联网企业主要使用的分布式协议,这里向有兴趣的读者做些分布式算法的粗略介绍,以及为什么需要它们。

关于一致性

为什么需要Paxos或Quorum算法?分布式系统实现数据存储,是通过多份数据副本来保证可靠,假设部分节点访问数据失败,还有其他节点提供一致的数据返回给用户。对数据存储而言,怎样保证副本数据的一致性当属分布式存储最重要的问题。 一致性是分布式理论中的根本性问题,近半个世纪以来,科学家们围绕着一致性问题提出了很多理论模型,依据这些理论模型,业界也出现了很多工程实践投影。何为一致性问题?简而言之,一致性问题就是相互独立的节点之间,在可控的时间范围内如何达成一项决议的问题。

强一致写、多段式提交

强一致写

解决这个问题最简单的方法 ,就是强一致写。在用户提交写请求后,完成所有副本更新再返回用户,读请求任意选择某个节点。数据修改少节点少时,方案看起来很好,但操作频繁则有写操作延时问题,也无法处理节点宕机。

两段式提交(2PC 、Three-Phase Commit)

既然实际系统中很难保证强一致,便只能通过两段式提交分成两个阶段,先由Proposer(提议者)发起事物并收集Acceptor(接受者)的返回,再根据反馈决定提交或中止事务。

第一阶段:Proposer发起一个提议,询问所有Acceptor是否接受;

第二阶段:Proposer根据Acceptor的返回结果,提交或中止事务。如果Acceptor全部同意则提交,否则全部终止。

两阶段提交方案是实现分布式事务的关键;但是这个方案针对无反馈的情况,除了“死等”,缺乏合理的解决方案。 Proposer在发起提议后宕机,阶段二的Acceptor资源将锁定死等。如果部分参与者接受请求后异常,还可能存在数据不一致的脑裂问题。

三段式提交(3PC、Three-Phase Commit)

为了解决2PC的死等问题,3PC在提交前增加一次准备提交(prepare commit)的阶段,使得系统不会因为提议者宕机不知所措。接受者接到准备提交指令后可以锁资源,但要求相关操作必须可回滚。

但3PC并没有被用在我们的工程实现上,因为3PC无法避免脑裂,同时有其他协议可以做到更多的特性又解决了死等的问题。

大数据

图1 三段式提交,在二段式提交基础上增加prepare commit阶段

主流的Paxos算法

微信后台近期开始主要推广Paxos算法用于内部分布式存储。Paxos是Leslie Lamport提出的基于消息传递的一致性算法,解决了分布式存储中多个副本响应读写请求的一致性,Paxos在目前的分布式领域几乎是一致性的代名词(据传Google Chubby的作者Mike Burrows曾说过这个世界上只有一种一致性算法, 那就是Paxos,其他算法都是残次品)。Paxos算法在可能宕机或网络异常的分布式环境中,快速且正确地在集群内部对某个数据的值达成一致,并且保证只要任意多数节点存活,都不会破坏整个系统的一致性。Paxos的核心能力就是多个节点确认一个值,少数服从多数,获得可用性和一致性的均衡。

大数据

图2 Paxos模型,节点间的交互关系

Paxos可以说是多节点交互的二段提交算法,Basic Paxos内的角色有Proposer(提议者)、Acceptor(接受提议者)、Learner(学习提议者),以提出Proposal(提议)的方式寻求确定一致的值。

用户喜欢...