《从Paxos到Zookeeper》——第一、二、三章：分布式基础

目录

第一章 分布式架构

1.1 分布式的特点（集中式/分布式）

1.2 分布式环境中的各种经典问题

1.3 分布式事务理论

1.3.1 CAP定理

1.3.2 BASE理论

第二章 一致性协议

2.1 2PC 和 3PC

2.1.1 2PC — 两阶段提交

2.1.2 3PC — 三阶段提交

2.2 Paxos算法（细节略过）

第三章 Paxos的工程实践

3.1 Chubby

3.2 Hypertable

第一章 分布式架构

1.1 分布式的特点（集中式/分布式）

①集中式：在20世纪大型主机的时代，集中式架构是主流（20世纪三大商业成就：IBM的System/360系列大型主机，波音707，福特T型车），但是随着网络化与微型化的发展，高昂的成本与单点问题日益显著。

②分布式：

• 分布式的定义（来自《分布式系统概念与设计》）：分布式系统是一个硬件或软件组件分布在不同的网络计算机上，彼此之间仅仅通过消息传递进行通信和协调的系统。

• 分布式特性：

  • 分布性：在网络空间的随意分布

  • 对等性：没有主从之分，所有节点对等

  • 并发性：对共享资源的并发操作，也是当前最大挑战

  • 缺乏全局时钟：在分布式系统中，很难定义两个事件的谁先谁后，因为缺乏全局的时钟序列

  • 故障总是会发生（分布式黄金定律）：任何在设计阶段考虑到的异常情况一定会在系统实际运行中发生，并且，在系统实际运行的过程中还会遇到很多在设计时未能考虑到的异常故障

1.2 分布式环境中的各种经典问题

• 通信异常：网络不可靠，引起消息丢失，消息延迟

• 网络分区：俗称"脑裂"。分布式集群中，节点之间由于网络不通，导致集群中节点形成不同的子集，子集中节点间的网络相通，而子集和子集间网络不通。也可以说，网络分区是子集与子集之间在网络上相互隔离了

• 三态：每次请求和响应，都可能存在三态：成功，失败，超时（不确定是否执行完成）

• 节点故障：服务器节点宕机

1.3 分布式事务理论

在单机数据库中，我们很容易实现一套符合ACID特性的事务处理系统。但在分布式中，分布式事务面临巨大挑战。在探讨分布式难题时，出现了CAP和BASE两大经典理论。

1.3.1 CAP定理

①Consistency（一致性）：这里是指强一致性

• 强一致性：分布式环境中，多个副本之间严格保证数据始终是一致的

• 弱一致性

  • 最终一致性：没有实时性要求，最终一致就行

    • DNS（Domain Name System）

    • Gossip（Cassandra的通信协议）

②Availability（可用性）：服务器可用，即有限时间内能返回结果

• 不同业务场景对有限时间的阈值不同：搜索引擎通常在一秒内，Hive查询通常需要分钟级别

③Partition tolerance（分区容错性）

• 分区容错性约束了一个分布式系统需要具有如下特性：分布式系统在遇到任何网络分区故障（网络中断，消息丢失）的时候，都能对外提供满足一致性和可用性的服务，除非是整个网络发生了故障。

• 一句话概括：CAP定理证明了，一个分布式系统不可能同时满足CAP三项，最多满足两项

  • 对于分布式互联网应用，必须保证P，要么满足AP，要么满足CP。根据业务权衡A和C。

1.3.2 BASE理论

①来源：ebay架构师的文章：Base: An Acid Alternative。Base是对CAP中一致性C和可用性A权衡的结果，来源于对大规模互联网分布式实践的总结，是CAP的演化

②核心思想：不同于ACID的强一致性模型，BASE提出可以牺牲强一致性，允许数据在一段时间内是不一致的，使用合适的方式使系统达到最终一致性

• Basically Available（基本可用）：保证基本可用，允许损失一点响应时间或者功能

• Soft state（软状态）：弱状态（非强一致），在不影响系统整体可用性的前提下，允许系统之间的数据同步存在延时

• Eventually consistent（最终一致性）：要求能达到最终一致性

③意义：传统事务强调ACID强一致性，BASE结合实践经验，提出可以牺牲强一致性来获得可用性

---

第二章 一致性协议

所谓一致性协议，可理解为解决一致性问题的算法

2.1 2PC 和 3PC

引入两个角色

• 协调者（Coordinator）：统一调度所有分布式节点

• 参与者（Participant）：被协调者调度的节点

2.1.1 2PC — 两阶段提交

①阶段一：询问事务提交（投票阶段）

• 客户端向协调者发送执行事务请求：协调者先提交事务

• 协调者事务询问：协调者向各个参与者发送事务请求，询问各个参与者是否能执行事务提交

• 参与者执行事务：各个参与者执行事务，将Redo和Undo记入事务日志

• 参与者反馈：如果参与者可以执行，返回Yes；否则返回No

②阶段二：执行事务提交

• 如果协调者收到的全是Yes：执行事务提交

  • 1. 协调者向所有参与者发送Commit

  • 2. 参与者收到Commit并提交后，反馈Ack给协调者

  • 3. 协调者收到所有Ack后，完成事务

• 如果收到任何一个No，或者超时等待没有收到全部的反馈：中断事务

  • 1. 协调者发送回滚Rollback

  • 2. 参与者事务回滚并反馈Ack

  • 3. 协调者收到所有Ack后，自己也回滚，完成事务中断

③优缺点

• 优点：原理简单，实现方便

• 缺点：

  • 同步阻塞：各个参与者都要等其他参与者的响应，期间无法进行任何操作。性能差

  • 单点问题：协调者一旦出现问题，整个分布式无法运作

  • 数据不一致：如果有少部分参与者因为网络问题没有收到Commit，数据不一致

  • 太过保守：如果有一个节点出了问题，整个事务都失败。没有容错机制

2.1.2 3PC — 三阶段提交

3PC把2PC的第一个阶段细分成了CanCommit和PreCommit

①阶段一(CanCommit)：询问

• 事务询问：协调者给参与者发送CanCommit

• 参与者响应：如果认为自己可以执行事务，则回复Yes，否则回复No

②阶段二(PreCommit)：执行预提交

• 如果收到的全部是Yes

  • 协调者向参与者发送preCommit，进入prepare阶段

  • 各个参与者执行事务，将Redo和Undo记入事务日志

  • 参与者反馈Ack。并等待commit或者abort

• 如果有No或者超时等待

  • 协调者发送abort

  • 参与者收到abort中断事务，或者参与者超时等待也会中断事务

③阶段三(doCommit)：真正执行提交

• 如果收到的全是Ack

  • 协调者向参与者发送doCommit

  • 参与者收到后进行事务提交，并返回ack

  • 协调者收到所有参与者的ack后，完成事务

• 如果没有收到全部的Ack

  • 协调者发送abort

  • 参与者根据事务日志回滚，回滚完发送Ack

  • 参与者收到全部ack后，中断事务

④优缺点

• 优点

  • 解决了单点问题：如果这一阶段协调者宕机或者网络不畅通，参与者无法收到doCommit或者abort，参与者都会在超时等待后提交事务

  • 解决了参与者的阻塞：添加了PreCommit过程，避免了无限等待

• 缺点

  • 参与者在接收到preCommit后，如果出现网络分区，这个参与者仍然会进行事务提交，其他参与者会进行abort，导致数据不一致

2.2 Paxos算法（细节略过）

①概述

• Paxos算法是目前公认的解决分布式一致性问题的最有效算法之一

• 可以在节点失效，网络分区，网络延迟等各种异常情况下保证所有节点处于同一状态

• 引入“过半”理念，即少数服从多数原则

②应用

• Google Chubby：基于该算法的分布式锁服务，GFS和Big Table底层都用它来解决分布式问题

• Hypertable：C++语言开发的数据库，定位是分布式海量高性能数据库

③Basic Paxos流程：

• 阶段一

  • Proposer：提出一个提案发送给advisor，编号为N。N必须大于这个proposer之前提出过的提案编号

  • Advisor：

    • 如果N大于此advisor之前接受过的任何提案编号——>接受；

    • 否则拒绝

• 阶段二

  • Proposer：如果收到了大于一半的接受。再发送accept请求，包含之前的提案N和提案内容

  • Advisor：

    • 在这等待期间如果有大于N的其他提案，比如N+1，接受N+1；

    • 否则忽略

---

第三章 Paxos的工程实践

3.1 Chubby

chubby是google实现的分布式锁服务，在google内部广泛使用，GFS，BigTable的选主都是基于此服务，遗憾的是google并没有将此服务开源，不过yahoo公司基于google公开的chubby论文实现了zookeeper，功能与chubby相当

3.2 Hypertable

Hypertable是一个用C++语言开发的开源、高性能、可伸缩的数据库，其以Google的BigTable论文为基础指导，采用与HBase相似的分布式模型