分布式系统概念与设计 读书笔记
---书籍有点旧了,没有什么面试题。概念性强,不细看了
理由,现在互联网项目的分布式事务基本是以seata柔性事务为主,满足BASE理论即可。二阶段提交和三阶段提交的刚性事务,在实际应用中少。
第1章 分布式系统的特征
分布式系统是其组件分布在联网的计算机上,组件之间通过传递消息进行通信和动作协调的系统。
1.1 简介
并发
缺乏全局时钟
故障独立性
1.5 挑战
1.5.1 异构性
网络
计算机硬件
操作系统
编程语言
由不同开发者完成的软件实现
1.5.2 开放性
1.5.3 安全性
1.5.4 可伸缩性
控制物理资源的开销
控制性能的损失
防止软件资源的用尽
避免性能瓶颈
现在多用Kubernetes
1.5.5 故障处理
检测故障
掩盖故障
容错
故障恢复
冗余
1.5.6 并发性
1.5.7透明性
1.5.8透明性
第2章 系统模型
2.1 简介
2.2 物理模型
2.3 体系结构模型
2.3.1 体系结构元素
为了理解一个分布式系统的基础构建块,需要考虑四个问题:
在分布式系统中进行通信的实体是什么
它们如何通信,特别是使用什么通信范型
它们在整个体系中扮演什么(可能改变的)角色,承担什么责任
它们怎样被映射到物理分布式基础设施上(它们被放置在哪里)
通信范型,重点!
进程间通信
远程调用
间接通信
第3章 网络与网际互联
3.3.4 协议
传输层协议
TCP是面向连接)的可靠协议,UDP是一个不能保证可靠传输的数据报协议。
第4章 进程间通信
4.1 简介
UDP的应用接口提供了消息传递(message passing)
抽象--进程间通信的最简单形式。这使得一个发送进程能够给一个进程传递一个消息。包含这些消息的独立的数据包称为数据报(datagram)
.在Java和UNIX API中,发送方用套接字(socket)
指定目的地,套接字是对目的计算机的目标进程使用的一个特定端口的间接引用。
TCP的应用接口提供了进程对之间的双向流(two-way)抽象。相互通信的消息由没有消息边界的一连串数据项组成。流为生产者-消费者通信提供了构造成分。生产者和消费者形成一对进程,前置的作用是产生数据项,后者的作用是消费数据项。由生产者发送给消费者的数据项按到达顺序排在队列中,直到消费者准备好接受它们为止。在没有可用的数据项时,消费者必须等待。如果存放入队数据项的存储空间耗尽的话,生产者也必须等待。
4.2 互联网协议的API
4.2.1 进程间通信的特征
同步和异步通信 每个消息目的地与一个队列相关。发送进程将消息添加到远程队列中,接收进程从本地队列中移除消息。发送进程和接受进程之间的通信可以是同步的也可以是异步的。在同步形式的通信中,发送进程和接受进程在每个消息上同步。这时,send和receive都是阻塞操作。
4.2.3 UDP数据通信
由UDP发送的数据报从发送进程传输到接受进程,它不需要确认或重发。如果发生故障,消息可能无法到达目的地。
经常使用在视频直播
4.2.4 TCP流通信
为了满足可靠通信的完整性,TCP流使用校验和检查并丢弃损坏的数据包,使用序列号检测和丢弃重复的数据包。为了保证有效性,TCP流使用超时和重传来处理丢失的数据包。
使用在:
HTTP
FTP
SMTP邮件传输
第5章 远程调用
分布式系统通信的两个最主要的远程调用技术:
远程过程调用(RPC)Remote Procedure Call,RPC将过程调用的通用编程抽象拓展到了分布式环境。一个调用过程可以像调用本地节点上的过程那样去调用一个远程节点上的过程
远程方法调用(RMI)Remote Method Invocation,RMI与RPC类似,不过RMI可以把对象引用作为参数。
5.2 请求-应答协议
HTTP基于TCP实现。在该协议最初版本中,每个客户/服务器交互都由下面的步骤组成:
客户端请求(连接),而服务器在一个默认端口或URL指定的端口接受连接
客户端向服务器发送请求消息。
服务器向客户端发送应答
连接断开
HTTP方法
GET:请求在参数中给出的URL对应的资源。
HEAD:该请求和GET相同,但是它不返回任何数据
POST:指定资源的URL,该资源可处理在请求消息体中提供数据。
PUT:要求请求中提供的数据在存储时以指定的URL作为标识符,要么作为现有资源的修改,要么作为一种新资源
DELETE:服务器删除给定URL所标识的资源。
OPTIONS:服务器提供给客户端能够应用到给定URL及其特定需求的方法列表
TRACE: 服务器返回请求的消息,用于诊断的目的。
第6章 间接通信
间接通信的本质是通过一个中介者通信,因此不存在发送者和一个或者多个接受者之间的直接耦合,还可以空间和时间解耦。
组通信,在组通信中,通信通过一个抽象的组进行,发送者并不知道接受者的身份。
发布-订阅系统,代表一类方法,这类方法的共同特点是通过中介者将事件分发给多个接受者。
消息队列系统,其中消息发送到队列中,接受者从这些队列中提取消息
基于共享内存的方法,包括分布式共享内存和元组空间两种方法,给编程人员提供一个抽象的全局共享内存抽象。
6.1 简介
在计算机科学中,所有问题都可以通过某个层次上的间接方式来解决。
空间解耦,发送者不知道也不需要知道接受者们的身份,反之亦然。因为空间解耦使得系统开发者有很大的自由度去处理改变:参与者可以被替换、更新、复制、或迁移。
时间解耦,发送者和接受者们可以有独立的生命周期。换句话来说,发送者和接受者们不需要同时存在才能通信。发送者和接受者们可以随时离开。
6.3 发布-订阅系统
发布-订阅系统(publish-subscribe system),有时也被称为基于事件的分布式系统(distributed event-based system)。发布者发布结构化的事件到事件事务,订阅者通过订阅表达对特定事务感兴趣,其中订阅可以是结构化时间之上的任意模式。发布-订阅系统的认识是把订阅与发布的时间进行匹配,保证事件通知(event notification)的正确传递。发布订阅本质上是一对多的通信范型。
发布订阅系统有两个主要特征:
异构性
异步性
6.4 消息队列
消息队列使用队列概念作为一种间接机制提供点对点的服务,从而实现所期望的时间和空间解耦。消息队列是点对点的,这是因为发送者将消息放置在队列中,此后由一个进程移走该消息。消息队列也称为面向消息的中间件。
第7章 操作系统支持
第8章 分布式对象和组件
第9章 Web服务
第10章 对等系统
第11章 安全性
第12章 分布式文件系统
第13章 名字服务
第14章时间和全局状态
第15章 协调和协定
第16章 事务和并发控制
16.4 锁
锁的实现 锁的授予通常是由服务器上的一个对象实现,称之为锁管理器(lock manager)。锁管理器把所拥有锁存放在诸如散列表之类的数据结构中。每个锁都是Lock类的一个实例,并与某个对象相关联。
16.5 乐观并发控制
16.6 时间戳排序
第17章 分布式事务
每个事务的服务器都包含一个恢复管理器,它的作用是出现故障之后服务器被替代时,用它来恢复服务器所管理的对象上的事务的效果。恢复管理器将对象、意图列表和每个事务的状态信息记录在持久性存储中。
17.1 简介
访问由多个服务器管理的对象的平面事务或嵌套事务称为分布式事务(distributed transaction)。
当分布式事务结束时,事务的原子特性要求所有参与该事务的服务器必须全部提交或全部放弃该事务。为了实现这一点,其中一个服务器承担了协调者(coordinator)的角色,由它来保证在所有的服务器上获得同样的结果,协调者的工作方式取决于它选用的协议。"两阶段提交协议"是最常用的协议。该协议允许服务器之间的相互通信,以便就提交或放弃共同做出决定。还有三阶段提交协议。
每个服务器对自己的对象应用本地的并发控制,以保证事务在本地是串行化的。分布式事务还需要保证全局串行化,如何实现这一点与是否使用加锁,时间戳排序或乐观锁并发控制相关。在某些情况下,事务在单个服务器上是串行化的,但同时,由于不同的服务器之间存在相互依赖循环,因此可能出现分布式死锁。
事务恢复用于保证事务所所涉及的所有对象都是可恢复的。除此之外,它还保证对象只反应已提交事务所做的更新,不反应被放弃事务所做的更新。