09 zookeeper 分布式架构(集中式和分布式的优缺点)事务ACID,分布式事务,CAP定理,BASE理论

  • 在zookeeper专栏中,记录了个人学习zk的笔记, 从下载到集群再到java原生api的简单使用。已经对zk的使用和部署有一个简单的认知。
  • 后面这个专栏将持续介绍更多内容,如zkClient API 和curator API的介绍。
  • 这些都是基于对zk的原理有一定的了解,中间这几章 我讲个人学习zk原理的笔记贴出来,希望对你有帮助。

1 从集中式到分布式

1.1 集中式的特点

  • 集中式系统是指一个一台或多台计算机组成中心节点,数据集中存储于这个中心节点中,且整个系统所有的业务单元都集中部署在这个中心节点上,系统所有的功能均在其集中处理。
  • 集中式系统,每台终端,客户机仅仅负责数据的录入和输出,数据的存储和处理完全交于主机来完成。
  • 集中式系统部署简单。基于底层性能卓越的大型主机。无需考虑对服务进行多节点部署,和节点之间分布式协作问题。

1.2 分布式的特点

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

  • 分布性:多台计算机在空间上随意部署,机器的分布情况随时变动。
  • 对等性:计算机没有主从之分,组成分布式系统的计算机节点都是对等的。(副本、数据副本、服务副本区别)
    副本指的是分布式系统对数据和服务提供的一宗冗余方式,对外提供高可用的服务。
    数据副本是指在不同的节点上持久化同一份数据,当某个节点上数据丢失时,可以从副本上读取数据。
    服务副本指多个节点提供同样的服务,每个节点都有能力接受来自外部的请求并进行相应的处理。
  • 并发性
  • 缺乏全局时钟,分布式系统主机空间分布随意性,
  • 故障总是会发生,

1.3 分布式环境的各种问题

  • 通信异常:网络本身的不可靠性,各类网络硬件故障导致通信失败;单机内存访问延时纳秒级(10ns),一次通信的延迟在0.1-1ms(是单机的106倍)。故消息丢失和消息延迟非常普遍。
  • 网络分区:网络异常,导致分布式系统节点之间的网络延时不断增大,最终导致部分节点不能正常通信,这种想象称为网络分析,俗称“脑裂”
  • 分布式系统三态:成功、失败、超时(网络不可靠)。网络异常两种情况:请求没有被成功接收;响应没有反馈到发送方。
  • 节点故障:节点宕机或“僵死”的现象

2 从ACID到CAP/BASE

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

2.1 事务ACID

  • 事务Transaction 是一系列对系统中数据进行访问与更新的操作所组成的一个程序执行逻辑单元。
  • 并发访问时,事务为应用程序之间提供隔离方法,使彼此之间操作互不干扰。
  • 提供从失败中恢复到常态的方法,同时异常状态下保持数据完整性。

事务Transaction 四个特征

  • 原子性 Atomicity
  • 一致性 Consistency
  • 隔离性 Isolation
  • 持久性 Durability

延展知识:表中SQL92规范中,定义了4个事务隔离级别:
在这里插入图片描述

  • 未授权读取:又称读未提交,顾名思义就是读取内存没有提交的数据。
    在这里插入图片描述

  • 授权读取:又称读已提交。事务B是无法看到A没有提交的数据,只能读取到0或者100

  • 可重复读取

  • 串行化:不能并发执行。
    在这里插入图片描述

2.2 分布式事务

分布式事务是指事务的参与者、支持事务的服务器、资源服务器以及事务管理器分别位于分布式系统的不同节点至上。分布式事务一般会涉及对多个数据源或业务系统的操作。

分布式事务场景:跨行转账,本地服务器A执行取款服务,异地服务器B执行存款服务,取款服务和存款服务本身是无状态且相互独立的,共同构成一个完整的分布式事务。取款服务和存款服务称为子服务。

2.3 CAP定理 和BASE理论

如何构建一个兼顾可用性和一致性的分布式系统,出现了CAP和BASE这样的分布式经典理论。

CAP定理

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

  • 一致性 C
    在分布式环境,多个副本之间的数据是否能够保持一致的特性。
  • 可用性 A
    系统提供的服务一直处于可用的状态,每一个请求总能在“有限的时间内” “返回结果”。
  • 分区容错性 P
    分布式系统在遇到任何网络分区故障时,仍然需要能够保证对外提供满足一致性和可用性的服务,除非整个网络故障。

BASE理论

BASE是Basically Available(基本可用),Sort state(软状态) 和 Eventually consistent (最终一致性)三个短语的简写。基于CAP定理演化而来的。

基本可用
  • 分布式系统出现不可预测的故障时,允许失去部分可用性,达到基本可用的状态。
  • 响应时间上的损失,功能上的损失。
  • 软状态,运行系统节点间数据传输过程存在延迟。
  • 允许系统在不同节点的数据副本之间进行数据同步的过程存在延时。
  • 最终一致性
    系统中所有数据的副本,在经过一段时间的同步后,最终能够达到一个一致的状态。
    在没有发生故障的前提下,数据达到一致状态的时间延迟,取决于网络延迟、系统负载和数据复制方案设计等因素。

最终一致性存在5类变种:

  • 因果一致性(Causal consistency):进程A更新完数据后,通知进程B,那么进程B访问该数据时,应该是最新的数据。没有通知进程C,进程C访问数据则没有限制。

  • 读已之所写(Read your writes):进程A更新一个数据项之后,自己总能访问最新的值。对于单个数据获取者来说,其读取到的数据一定不会比自己上次写入的值旧。

  • 会话一致性(Session consistency):系统数据访问过程框定在一个会话中,同一个会话中实现 “读已之所写” 。

  • 单调读一致性(Monotonic read consistency):如果一个进程从系统中读取一个数据项的某个值后,那么系统对于该进程后续的任何数据访问都不应该返回更旧的值。

  • 单调写一致性(Monotonic write consistency):如果一个进程从系统中读取一个数据项的某个值后,那么系统对于该进程后续的任何数据访问都不应该返回更旧的值。

  • 0
    点赞
  • 2
    收藏
    觉得还不错? 一键收藏
  • 打赏
    打赏
  • 0
    评论

“相关推荐”对你有帮助么?

  • 非常没帮助
  • 没帮助
  • 一般
  • 有帮助
  • 非常有帮助
提交
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包

打赏作者

EngineerForSoul

你的鼓励是我孜孜不倦的动力

¥1 ¥2 ¥4 ¥6 ¥10 ¥20
扫码支付:¥1
获取中
扫码支付

您的余额不足,请更换扫码支付或充值

打赏作者

实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值