从paxos到zookeeper分布式一致性原理与实践

Posted 咖啡日记本

tags:

篇首语:本文由小常识网(cha138.com)小编为大家整理,主要介绍了从paxos到zookeeper分布式一致性原理与实践相关的知识,希望对你有一定的参考价值。

架构的演进-分布式架构

集中式

系统就是由一台或多台主计算机组成的中心节点, 数据集中存储于这个中心节点,并且这个系统的所有业务单元都集中部署在这个中心节点上,系统的所有功能均有其集中处理.

集中式系统中,每个终端或客户端仅仅负责数据的录入和输出, 而数据的存储于控制处理完全交由主机来完成

分布式

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

分布式系统特征:

1.分布性

分布式系统中的多台计算机都会在空间上随意分布,同时,机器的分布情况也回随时变动

2.对等性

分布式系统中的计算机没有主/从之分,既没有控制整个系统的主机,也没有被控制的从机,组成分布式系统的所有计算机节点都是对等的.

3.并发性

如何准确并高效的协调分布式并发操作也成为了分布式系统架构与设计中最大的挑战之一.

4.缺乏全局时钟

由于分布式系统分布性,进程之间通过消息进行通信,很难定义两个事件的谁先谁后,原因就是分布式系统缺乏一个全局时钟的时钟序列控制.

5.故障总会发生

组成分布式系统的所有计算机,都有可能发生任何形式的故障.

集中式到分布式 从ACID到CAP/BASE

ACID

事务(Transaction)是由一系列对系统中对数据进行访问与更新的操作所组成的一个程序执行逻辑单元,狭义上的事务特指数据库事务.

事务具有四个特征,分别是原子性(Atomicity),一致性(Consistency),隔离性(Isolation),持久性(Durability)

1.原子性(Atomicity)

    事务原子性是指事务必须是一个原子操作,只允许出现以下两个状态:
    全部执行成功
    全部不执行

2.一致性(Consistency)

    事务的一致性是指事务的执行不能破坏数据库的完整性和一致性,一个事物在执行前和执行后,数据库都必须处于一致性状态

3.隔离性(Isolation)

    事务的隔离性是指在并发环境中,并发的事务是相互隔离的,一个事务的执行不能被另一个事务干扰.    sql规范中,定义了4个事务隔离级别:

    未授权读取(Read Uncommitted)也叫读未提交
    授权读取(Read Committed)也叫读已提交
    可重复读(Repeatable Read)
    串行化(Serializable)
隔离级别 脏读 可重复读 幻读
未授权读取 存在 不可以 存在
授权读取 不存在 不可以 存在
可重复读 不存在 可以 存在
串行化 不存在 可以 不存在

4.持久性(Durability)

    事务的持久性也称为永久性,是指一个事务一旦提交,它对数据库中对应数据的状态变更就应该是永久性的.

分布式事务

在分布式数据库中,数据分散在不同的机器上,如何对这些数据进行分布式的事务处理具有非常大的挑战,面对分布式事务的种种问题,为了保证分布式应用程序的可靠性,分布式事务是无法回避的.

CAP和BASE理论

CAP定理

一个分布式系统不可能同时满足一致性(C:Consistency),可用性(A:Availability)和分区容错性(P:Partition tolerance)这三个基本需求,最多只能同时满足其中两项

1.一致性

在分布式环境中,一致性是指数据在多个副本之间是否能够保持一致性的特征.在一致性的需求下,当一个系统在数据一致的状态下执行更新操作后,应该保证系统的数据仍然处于一致状态.

2.可用性

可用性,顾名思义, 是指系统提供的服务必须一致处于可用状态,对于用户的没一个操作请求总是能够在有限的时间内返回结果

3.分区容错性

分区容错性约束了一个分布式系统需要具有如下特征:
分布式系统在遇到任何网络分区故障的时候,仍然需要能够保证对外提供满足一致性和可用性的服务,除非是整个网络环境都发生了故障

CAP定理示意图


CAP定理应用

BASE理论

BASE是Basically Available(基本可用)Soft state(软状态)Eventually consistent(最终一致性)三个短语的简写, 是由来自eBay的架构师Dan Pritchett第一次明确提出的.
BASE是对CAP中一致性和可用性权衡的结果,其来源于大规模互联网系统分布式时间总结.是基于CAP定理演化来的

基本可用

基本可用是指分布式系统在出现不可预知故障的时候,允许损失部分可用性.---- 基本可用不等于系统不可用.
以下就是"基本可用"的典型例子:

  • 响应时间上的损失: 正常情况下, 一个在线搜索引擎需要在0.5秒内返回给用户相应的查询结果,由于出现故障,查询结果的响应时间增加到了1~2秒

  • 功能上的损失: 正常情况下,在一个电子商务网站上进行购物,消费者几乎能够顺利的完成每一笔订单, 但是在一些节日大促购物高峰的时候,由于消费者的购物行为激增,为了保护购物系统的稳定性,部分消费者可能会被引导到一个降级页面.

弱状态

弱状态也称为软状态,和硬状态相对,是指允许系统中的数据存在中间状态,并认为该中间状态的存在不会影响系统的整体可用性.即允许系统在不同节点的数据副本之间进行数据同步的过程存在延时.

最终一致性

最终一致性强调的是系统中所有的数据副本,在经过一段时间的同步后,最终能够达到一个一致的状态.
最终一致性是一种特殊的弱一致性

在实际工程实践中,最终一致性存在以下五类主要的变种:

  1. 因果一致性(Causal consistency)

    因果一致性是指,如果进程A在更新完某个数据项后通知了进程B,那么进程B之后对该数据项的访问都应该能够获取到进程A更新后的新值,并且如果进程B要对该数据项进行更新操作的话,务必基于进程A更新后的最新值,即不能发生丢失更新的情况,与此同时,与进程A无因果关系的进程C的数据访问则没有这样的限制

  2. 读己之所写(Read your writes)

    读己之所写是指,进程A更新一个数据项之后,他自己总是能够访问到更新过的最新值,而不会看到旧值.读己之所写也可以看做是是一种特殊的因果一致性.

  3. 会话一致性(Session consistency)

    会话一致性将对系统数据的访问过程框定在了一个会话当中,系统能够保证在同一个有效的绘画中实现"读己之所写"的一致性,也就是说,执行更新操作之后,客户端能够在同一个会话中时钟读取到该数据项的最新值.

  4. 单调读一致性(Monotonic read consistency)

    单调读一致性是指如果一个进程从系统中度取出一个数据项的某个值后,纳闷系统对于该进程后续的任何数据访问都不应该返回更旧的值.

  5. 单调写一致性(Monotonic write consistency)

    单调写一致性是指,一个系统需要能够保证来自同一个进程的写操作被顺序的执行.


以上是关于从paxos到zookeeper分布式一致性原理与实践的主要内容,如果未能解决你的问题,请参考以下文章

《从PAXOS到ZOOKEEPER分布式一致性原理与实践》pdf

《从Paxos到Zookeeper:分布式一致性原理与实践》PDF下载

从Paxos到Zookeeper分布式一致性原理与实践 -笔记

从Paxos到Zookeeper分布式一致性原理与实践 -笔记

《从Paxos到Zookeeper 分布式一致性原理与实践》——第三章

第二篇:《从Paxos到zookeeper分布式一致性原理与实践》一致性协议与zookeeper