《云计算技术系列丛书 云原生分布式存储基石: etcd深入解析》——1分布式系统与一致性协议

举报
华章计算机 发表于 2019/06/02 17:14:45 2019/06/02
【摘要】 本书摘自《云计算技术系列丛书 云原生分布式存储基石: etcd深入解析》一文中的第1章,第1.1节,作者是华为云容器服务团队、杜军等编著。

第一部分

基础篇

本部分简单介绍分布式系统的基本理论,详细讲解Raft算法的工作原理,帮助读者了解etcd的基础知识,主要包括以下章节:

第1章 分布式系统与一致性协议


第1章

分布式系统与一致性协议

       现如今,摩尔定律的影响已经严重衰减甚至近于失效,但我们却实实在在地看到了计算能力的大幅度提升。在围棋人机大战里,人工智能AlphaGo打败李世石、柯洁的事实仍历历在目。计算能力的提升在很多时候都是源于系统(大数据、人工智能、云计算、区块链等)采用了分布式架构。《分布式系统概念与设计》一书中对分布式系统概念的定义如下:

       分布式系统是一个硬件或软件组件分布在不同的网络计算机上,彼此之间仅仅通过消息传递进行通信和协调的系统。

       简单来说,分布式系统就是一组计算机节点和软件共同对外提供服务的系统。但对于用户来说,操作分布式系统就好像是在请求一个服务器。因为在分布式系统中,各个节点之间的协作是通过网络进行的,所以分布式系统中的节点在空间分布上几乎没有任何限制,可以分布于不同的机柜、机房,甚至是不同的国家和地区。

       分布式系统的设计目标一般包括如下几个方面。

       可用性:可用性是分布式系统的核心需求,其用于衡量一个分布式系统持续对外提供服务的能力。

       可扩展性:增加机器后不会改变或极少改变系统行为,并且能获得近似线性的性能提升。

       容错性:系统发生错误时,具有对错误进行规避以及从错误中恢复的能力。

       性能:对外服务的响应延时和吞吐率要能满足用户的需求。

       虽然分布式架构可以组建一个强大的集群,但实际工作中遇到的挑战要比传统单体架构大得多,具体表现如下所示。

       1)节点之间的网络通信是不可靠的,存在网络延时和丢包等情况。

       2)存在节点处理错误的情况,节点自身随时也有宕机的可能。

       3)同步调用使系统变得不具备可扩展性。

1.1 CAP原理

       提到分布式系统,就不得不提CAP原理。CAP原理在计算机科学领域广为人知,如果说系统架构师将CAP原理视作分布式系统的设计准则一点也不为过。

       下面让我们先来回顾一下CAP的完整定义。

       C:Consistency(一致性)。这里的一致性特指强一致,通俗地说,就是所有节点上的数据时刻保持同步。一致性严谨的表述是原子读写,即所有读写都应该看起来是“原子”的,或串行的。所有的读写请求都好像是经全局排序过的一样,写后面的读一定能读到前面所写的内容。

       A:Availability(可用性)。任何非故障节点都应该在有限的时间内给出请求的响应,不论请求是否成功。

       P:Tolerance to the partition of network(分区容忍性)。当发生网络分区时(即节点之间无法通信),在丢失任意多消息的情况下,系统仍然能够正常工作。

       相信大家都非常清楚CAP原理的指导意义:在任何分布式系统中,可用性、一致性和分区容忍性这三个方面都是相互矛盾的,三者不可兼得,最多只能取其二。本章不会对CAP原理进行严格的证明,感兴趣的读者可以自行查阅Gilbert和Lynch的论文[1],下面将给出直观的说明。

       1)AP满足但C不满足:如果既要求系统高可用又要求分区容错,那么就要放弃一致性了。因为一旦发生网络分区(P),节点之间将无法通信,为了满足高可用(A),每个节点只能用本地数据提供服务,这样就会导致数据的不一致(!C)。一些信奉BASE(Basic Availability,Soft state,Eventually Consistency)原则的NoSQL数据库(例如,Cassandra、CouchDB等)往往会放宽对一致性的要求(满足最终一致性即可),以此来换取基本的可用性。

       2)CP满足但A不满足:如果要求数据在各个服务器上是强一致的(C),然而网络分区(P)会导致同步时间无限延长,那么如此一来可用性就得不到保障了(!A)。坚持事务ACID(原子性、一致性、隔离性和持久性)的传统数据库以及对结果一致性非常敏感的应用(例如,金融业务)通常会做出这样的选择。

       3)CA满足但P不满足:指的是如果不存在网络分区,那么强一致性和可用性是可以同时满足的。

       CAP原理最初的提出者Eric Brewer在CAP猜想提出12年之际(2012年)对该原理重新进行了阐述[2],明确了CAP原理只适用于原子读写的场景,而不支持数据库事务之类的场景。同时指出,只有极少数网络分区在非常罕见的场景下,三者才有可能做到有机的结合。无独有偶,Lynch也重写了论文“Perspectives on the CAP Theorem”[3],引入了活性(liveness)和安全属性(safety),并认为CAP是活性与安全性之间权衡的一个特例。CAP中的C(一致性)属于活性,A(可用性)属于安全性。

       正如热力学第二定律揭示了任何尝试发明永动机的努力都是徒劳的一样,CAP原理明确指出了完美满足CAP三种属性的分布式系统是不存在的。了解CAP原理的目的在于,其能够帮助我们更好地理解实际分布式协议实现过程中的取舍,比如在后面的章节中将会提到的lease机制、quorum机制等。


【版权声明】本文为华为云社区用户转载文章,如果您发现本社区中有涉嫌抄袭的内容,欢迎发送邮件进行举报,并提供相关证据,一经查实,本社区将立刻删除涉嫌侵权内容,举报邮箱: cloudbbs@huaweicloud.com
  • 点赞
  • 收藏
  • 关注作者

评论(0

0/1000
抱歉,系统识别当前为高风险访问,暂不支持该操作

全部回复

上滑加载中

设置昵称

在此一键设置昵称,即可参与社区互动!

*长度不超过10个汉字或20个英文字符,设置后3个月内不可修改。

*长度不超过10个汉字或20个英文字符,设置后3个月内不可修改。