ZooKeeper架构设计分析

ZooKeeper架构设计

Posted by lowe on June 11, 2021
   


分布式一致性解决方案产生背景
分布式事务 2PC 和 3PC 详解
分布式一致性算法(Paxos,Raft,ZAB)
NWR 读写模型 + Quorum议会制
CAP 定理 和 BASE 理论
ZooKeeper 核心工作机制

1 分布式一致性产生的背景

为了解决集中式服务扩展到分布式服务服务时使用多副本手段为了保证数据和服务高可用而产生的副本间数据状态不一致的问题

1.1 集中式服务

数据的存储和控制处理完全由主机完成

1.2 集中式服务的优点

  • 组成结构简单
  • 应用部署简单
  • 项目架构简单

    1.3 集中式服务缺点

  • 大型主机的研发人才和维护人才培养成本非常高
  • 大型主机非常昂贵
  • 单点故障问题,主机一挂,所有服务终止
  • 大型主机的性能扩展受限于摩尔定律

    去IOE:(IOE 指的是 IBM 小型机、Oracle 数据库、EMC 高端存储)
    单机处理能力存在瓶颈,稳定性和可用性这两个指标很难完全达标
    硬件的扩展不可靠,靠软件来做!所以出现各种分布式系统!

2 分布式服务

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

作用:用来解决单台服务器解决不了的费时费资源的复杂需求。

2.1 分布式系统的特点

  • 分布性:分布式系统中的多台计算机都会在空间上随意分布,同时,它们的分布情况也会随时变动
  • 对等性:集群中的每个工作节点的角色是一样的。注意副本这个概念
  • 并发性:多个机器可能同时操作一个数据库或者存储系统,可能引发数据不一致的问题
  • 缺乏全局时钟:分布式系统中的多个主机上的事件的先后顺序很难界定(分布式场景中最复杂的一个问题之一)
  • 故障总发生:组成分布式系统的所有计算机,都有可能发生任何形式的故障。比如服务器宕机,网络拥堵和延迟

    和集中式系统相比,分布式系统的性价比更高、处理能力更强、可靠性更高、也有很好的扩展性。

2.2 分布式系统常见异常问题

  • 通信异常:网络不可用(消息延迟或者丢失),会导致分布式系统内部无法顺利进行一次网络通信进行沟通协调,所以可能造成多节点数据丢失和 状态不一致,还有可能造成数据乱序。解决方案:重试机制
  • 网络分区:网络不连通,但各个子网络的内部网络是正常的,从而导致整个系统的网络环境被切分成了若干个孤立的区域,分布式系统就会出现局 部小集群造成数据不一致。解决方案:把数据状态不是最新的给下线掉
  • 节点故障/机器宕机:服务器节点出现的宕机或”僵死”现象,这是常态,而不是异常。解决方案:数据副本协议,异步复制
  • 分布式三态:即成功、失败和超时,分布式环境中的网络通信请求发送和结果响应都有可能丢失,所以请求发起方无法确定消息是否处理成功。分 布式系统的可用性:在用户能忍受的时间范围内,一定给出响应!解决方案:超时处理
  • 存储数据丢失:对于有状态节点来说,数据丢失意味着状态丢失,通常只能从其他节点读取、恢复存储的状态。解决方案:副本协议

    2.3 分布式系统性能指标

  • 性能:下面三个性能指标(吞吐,延迟,并发)往往会相互制约,追求高吞吐的系统,往往很难做到低延迟;系统平均响应时间较长时,也很难提高 QPS。

    系统的吞吐能力,指系统在某一时间可以处理的数据/请求总量,通常可以用系统每秒处理的总数据/总请求量来衡量; 系统的响应延迟,指系统完成某一功能需要使用的时间; 系统的并发能力,指系统可以同时完成某一功能的能力,通常也用QPS(query per second)来衡量。

  • 可用性:系统的可用性(availability)指系统在面对各种异常时可以正确提供服务的能力。系统的可用性可以用系统停服务的时间与正常服务的时间 的比例来衡量,也可以用某功能的失败次数与成功次数的比例来衡量。可用性是分布式的重要指标,衡量了系统的鲁棒性,是系统容错能力的体现。(5 个 9 的可靠性:一年只有 5 分钟的宕机时间!6 个 9 的可靠性,也就是 31 秒,99.9999%)
  • 可扩展性:系统的可扩展性(scalability)指分布式系统通过扩展集群机器规模提高系统性能(吞吐、延迟、并发)、存储容量、计算能力的特性。好 的分布式系统总在追求 “线性扩展性”,也就是使得系统的某一指标可以随着集群中的机器数量线性增长。最期望的情况:动态热部署
  • 一致性:分布式系统为了提高可用性,总是不可避免的使用副本的机制,从而引发副本一致性的问题。越是强的一致性的模型,对于用户使用来说使 用起来越简单。

    2.4 分布式系统一致性

一致性级别

  • 1、强一致性 :写操作完成后,读操作一定能读到最新数据。在分布式场景中,很难实现,后续讲解的 Paxos 算法,Quorum 机制,ZAB 协议等都是解 决方案。
  • 2、弱一致性 :不承诺立即可以读到最新写入的值,也不承诺多久之后数据能够达到一致, 但会尽可能地保证到某个时间级别(比如秒级别)后,数据能 够达到一致状态。
  • 3、读写一致性 :用户读取自己写入结果的一致性,保证用户永远能够第一时间看到自己更新的内容。比如我们发一条朋友圈,朋友圈的内容是不是第一 时间被朋友看见不重要,但是一定要显示在自己的列表上。
  • 4、单调读一致性 : 本次读到的数据不能比上次读到的旧。多次刷新返回旧数据出现灵异事件。解决方案:将请求通过 hash 映射到同一台机器。
  • 5、因果一致性 :如果节点 A 在更新完某个数据后通知了节点 B,那么节点 B 之后对该数据的访问和修改都是基于 A 更新后的值。与此同时,和节点 A 无因果关系的节点 C 的数据访问则没有这样的限制。
  • 6、最终一致性 :是所有分布式一致性模型当中最弱的。不考虑中间的任何状态,只保证经过一段时间之后,最终系统内数据正确。它最大程度上保证了 系统的并发能力,也因此,在高并发的场景下,它也是使用最广的一致性模型。 关于分布式一致性的问题,是分布式系统,最容易遇到的问题。一般的各种分布式系统,都会提供分布式一致性的解决方案。分布式一致性的级别有多种,在不同分布式系统的实现中可以根据需求考虑采用不同的一致性级别。
    一致性作用
  • 为了提高系统的可用性,以防止单点故障引起的系统不可用
  • 提高系统的整体性能,通过负载均衡技术,能够让分布在不同地方的数据副本,都能够为用户提供服务

    分布式系统的数据一致性的问题:

    • 1、事务 + 分布式事务
    • 2、分布式一致性算法 + 分布式共识算法
    • 3、Quorum机制 + NWR机制

    HDFS为了保证数据的安全性,其实提供了两个解决方案:

    • 副本机制
    • 纠删码:如果一个数据块要保证安全,默认是3个副本,所以占用了三倍磁盘资源。纠删码,消除了副本机制,每个数据块都只有一个副本,那怎么 保证安全?往原始数据文件中,插入一些辅助数据,进行编码,然后拆开成多个数据块进行存储。如果丢失一个数据块,我们从通过这个文件的剩 下的数据块的内容通过逆编码来恢复。有专业机构通过测试:加入的辅助数据大概是 原始数据的 40% 就能保证和 3 个副本一样的安全级别!