【云计算】【总结及期末考试回忆】CMSC 5735 Cloud Computing

叼辣条闯天涯

已于 2023-09-28 14:19:34 修改

阅读量1k

点赞数 1

分类专栏：云计算文章标签：云计算 java 开发语言

于 2022-12-12 16:05:25 首次发布

本博客原创文章未经允许不可用于商业盈利（包括以引流盈利的网站），纯非盈利性网站可在未经博主允许的情况下转载、使用非收费类博客，但请标明来源出处。

本文链接：https://blog.csdn.net/weixin_43529394/article/details/128288657

版权

云计算专栏收录该内容

1 篇文章 0 订阅

订阅专栏

1. 知识点总结

虚拟化和数据中心
- 两种 Hypervisor：直接在硬件上和在操作系统上
- 两种 Hypervisor 实现方法：全虚拟化和半虚拟化
- 软件定义网络
- 两种RDMA：被授权后直接写和一方写一方收
高可用性背景
- 衡量分布式算法：为了保持复制副本需要发送的信息数和节点数的关系，越小越好
- 正确性
  - Safety
  - Liveness
时序
- Total Order: 服务端接收一致
- Linearizability: 遵守真实时间，平行系统并发数据结构锁
- FIFO Order: 客户端顺序不变，客户之间无关联
- Happen-Before Order
  - Lamport’s Logical clock a < b -> LC(a) < LC(b)
    - 只能辨别潜在因果，不能辨别因果
- Causal Order
  - Vector clock a < b <-> VC(a) < VC(b)
领导人选举
- 领导人选举和互斥锁
  - 互斥锁不处理死去的领导人
  - 互斥锁讨厌饥饿，但领导人可以一直获取锁
- Bully算法 - 寻找最大 ID 作为领导人
  - 复杂度 $O(n^2)$
错误
- Crash Failure
  - 异步不可检测，同步可检测
  - fail-stop 可检测错误，当发生错误时，变为一种能让人察觉到的状态
  - crash-stop 不可检测错误
- Byzantine Failure
  - 考虑所有可能的错误
  - 多数情况下用来应对不信任问题
- 错误检测
  - complete: 不会丢失任何错误通知
  - accurate: 不会有任何错误的判断
  - 异步系统下不能同时 complete 和 accurate
  - 分布式系统下偏向于 complete
  - 如何检测：Ping/HeartBeat
一致性
- 一致性问题
  - Crash Fault tolerant
  - 每个节点有自己的初始值
  - 所有节点最终达成一致意见（liveness）
  - 有效性：最终的决定必须是选举过程所能决定的
- 一致性问题的难点
  - 异步系统
    - 不可能在具有一个错误进程的系统中达到分布式一致性
  - 同步系统
    - 拜占庭错误：不可能在节点数小于等于3和有一个有害节点中达成一致性
- 拜占庭问题
  - OM algorithm
- PAXOS 不考虑拜占庭问题
- PBFT 考虑拜占庭问题
Raft
- Leader Election
- Log Replication
一致性模型
- CAP 理论
- 一致性模型
  - 线性一致性
  - 结果一致性 (total order)
  - 因果一致性
  - FIFO一致性
  - 最终一致性
- 保持一致性的花费是吞吐量和Scalability的瓶颈
CRDT
- Conflict-Free Replicated Data Type
- 最终一致性：可能看到暂时的不一致
- 问题解决：commutative 可交换的
- 两种：
  - CmRDT 基于操作：变化的状态一个一个发，丢失会引起故障
  - CvRDT 基于状态：可以直接发送最后的状态
ZooKeeper
- 目的：高性能，raft并不是为了高性能
- 妥协
  - 延迟同时返回多个Put请求的OK
  - 从任意跟随者处读取
    - 违反了 linearizability：改进，向leader写入后得到 commitIndex，只有当追随者的 commitIndex赶上了leader的commitIndex之后才可以返回用户的get请求
    - 改进之后不会再出现：第一次写入得到最新数据，第二次得到旧数据
    - 还会出现的问题：之前并没有写入任何信息的客户端，直接读取到旧信息
    - 如何解决：使用API的方式，看客户端是否需要在读取后被通知“Sorry！读取的数据是旧数据”
流和分布式快照
- 流系统
  - collect - log - analyze - serve & store
  - Exactly-once Consistency
    - 实现方式：分布式快照
  - 时间
    - Event Time: 创建时间
    - Processing Time: 被处理时间
    - group by processing time - > group by event time
- 分布式快照
  - cut: 每个进程至少一个事件
  - consistent cut: 每个进程的前驱节点也在其中
    - consistent cut 的边界是一个快照
  - Chandy-Lamport Snapshot 算法
    - Initiator: 记录自己状态 c_i, 并将 c_i 作为标记发送给所有的出通道
    - Peer: 第一次接收到 c_i, 记录自己的状态，转发给自己所有的出通道
    - 等待从所有入通道接收到 c_i，结束
键值存储
- Consistent Hashing 环状结构：顺时针选择最近节点
- Distributed Hash Table - Chrod
  - 搜索：寻找大于 h(K) 的最小节点
  - 添加节点
  - 节点离开
  - 节点失效：在节点的前驱和后继中做副本
链式复制
- Raft 不是为了高性能，而是为了高可用，要实现高性能但较低可用的
- 在头部写，在尾部读，只有更新从头部到达尾部，才能返回 ok
- Raft 维护心跳
- 发生crash
  - 头结点 crash，后一个节点成为头结点
  - 尾节点 crash，前一个节点成为尾节点
  - 中间节点 crash，前一个节点跳过他发给下一个节点
- 添加节点
  - 添加在尾部，开始复制尾节点信息，复制完之后，成为新的尾节点，原尾节点把消息发给新尾节点
- 优点：读写负载分开；线性；头结点发送负担小；实现简单
- 缺点：一个节点失效，客户端等待回复；写入延迟高
- 提高读取并发性：将数据流分为多个线路，不同节点担当不同的头尾节点，实现读取负载均衡和线性
- EBS 使用 Chain Replication
云数据库
- ACID on sigle node （Isolation）
  - 悲观锁
    - 2 Prase Locking (2PL)
      - 想要访问就要获取锁
      - 只要开始释放锁，就不能再获取锁
      - 确保线性
    - Fine grained lock
      - 读使用共享锁
      - 写使用排它锁
  - 乐观锁
    - 基于时间戳
    - 时间戳+多版本
    - 基于验证的（OCC）
      - 保存自己读取和写入涉及到的集合，验证是否与其他事务有重叠，无重叠则提交，有重叠则终止重启
- ACID （Durable）
  - WAL （write-ahead logging）
    - 数据写入硬盘之前，必须先将日志写入磁盘
- ACID （Atomic）on multi-node
  - 2 Phrase Commit
    - all or nothing
Aurora
- 历代
  - 第一代：MySQL部署在服务器上，不能容错硬盘宕机
  - 第二代：在一个数据中心上的多个硬盘上使用链式复制，不能容错数据中心挂掉
  - 第三代：在不同数据中心的多个硬盘上使用链式复制，慢
  - 第四代：不同数据中心多副本
- 区别
  - 传统数据库
    - 提交时将日志从缓存传给远程磁盘日志
    - 提交时将数据更新从缓存传给远程磁盘数据
  - Aurora
    - 提交时将日志从缓存传给远程磁盘日志
    - 从日志重建数据
    - Quorum-Based replication
- Qurum-Based replication
  - N个节点中，一个写数据需要 W 票，一个读数据需要 R 票
  - 需满足 W + R > N, W > N / 2
  - 写只在 W 票时成功，读从 R 个副本中找最新版本号数据
- 数据库复制模式
  - 同步：多节点，写入所有节点，读取任一节点；所有节点副本一致
  - 异步：主从模式，从节点只负责备份，主从节点达到最终一致性
  - Qurum-Based replication

术语缩写

FLP：三个人名的缩写，在网络可靠，但允许节点失效（即便只有一个）的最小化异步模型系统中，不存在一个可以解决一致性问题的确定性共识算法（No completely asynchronous consensus protocol can tolerate even a single unannounced process death）
CAP：Consistency、Availability、Partition
- 强一致性。强一致性意味着，当系统的更新操作成功并返回客户端完成后，所有节点在同一时间的数据完全一致。
- 分布式系统可以正常响应时间内提供相应的服务。
- 分布式系统在遇到某节点或网络分区故障的时候，仍然能够对外提供满足一致性和可用性的服务。

2. Lab 知识总结

Lab 1: Serverless Function

建立 Lambda 函数：选择环境，角色
添加代码到函数，设置 Handler 指向该函数名
部署、创建用例进行测试

练习

A serverless function:

(a) dose not run on any server machine (be it virtual/physical).

(b) has a start-up time faster than virtual machine.

© is stateful (i.e. you don’t need an external service to maintain its state across multiple invocations)

(d) must be written in Actor model

Lab 2: FaaS

创建步骤：

用 S3 创建桶（bucket），用于上传图片
在 DynamoDB 创建表，存储结果
在 Lambda 中为第三方库创建 Lambda 层，上传库文件
在 Lambda 中创建图像识别函数，写入代码
在 Lambda 中创建管道
- 触发器为桶
- 层选择建立的层
- 环境变量中添加数据库表名

习题

In AWS Lambda, we usually put our third party libraries in :
(a) Lambda function.
(b) Layers. √
© Triggers.
(d) Local client.
An AWS Lambda layer:

(a) contains alls ource code of your lambda function.

(b) contains all resources (such as image) as the input of the lambda function.

© contains all additional code such as the third party librarise. √

(d) contains the logs of the lambda function.

Lab 3: gRPC

创建步骤：

docker环境：Protobuf、Maven、Java/Go、Protoc gRPC GO plugin protoc-gen-go
编写 .proto 文件：包含 gRPC 定义、请求和响应类型信息
使用 Java 实现服务端和客户端
- 创建 pom.xml 引入依赖
- 生成两个java文件，是通过 .proto 文件生成的
  - CalculatorGrpc.java
  - CalculatorOuterClass.java
- 编写 CalculatorServer.java
  - 服务内部静态类继承了 CalculatorGrpc 类
  - 静态类的请求和响应类型对象来自 CalculatorOuterClass
  - main函数注册服务绑定端口
  - 生成 jar 包
- 编写 CalculatorClient.java 使用 java 实现客户端
  - 使用 stub 来调用 gRPC 服务
  - 生成 jar 包
使用 Go 实现客户端
- 利用 .proto 文件生成 Go 的 stub
- 编写 main.go
  - 创建 gRPC 连接
  - 利用 stub 调用 gRPC 服务
  - 编译

习题

In gRPC:
(a) a .proto file can be executed directly as a program.
(b) a .proto file is usually generated automatically from your source code by protobuf.
© clients in different programming languages can reuse the same client stubs.
(d) a .proto file is required to generate stubs using protobuf. √

Lab 7: CRDT

Conflict-Free Replicated Data Type

使用的开源库： Yjs

依赖	解释
Quill.js	API驱动的富文本编辑器
React-quilljs	Quill 的钩子包装，使得可以制作可协作协作文本框的React组件而不是ReactQuill
Yjs	CRDT框架
y-websocket	为 Yjs 提供 WebSocket 连接

步骤：

运行 docker 容器，到达 App 目录，为 Create-React-App 创建
- src/App.js: 三个 ClickToEdit 组件，分别包含一个 Yjs 提供的文档数据结构 Y.doc
- src/ClickToEdit.js: 使用了 React 的钩子，来建立 WebSocket 连接，实现了连接和断开连接的切换按钮
运行代码

习题：

Lab 8: Flink

Flink: Connector - flatMap() - keyBy() - sum() - PrintSink

flatMap() emits 0 or more records
keyBy(0) 按照第一个元素进行分组
sum(1) 对分组的第二个元素求和

练习

When using Flink:

(a) flatMap() emits 0 or more records (i.e., 1:n mapping). √

(b) In a Flink Cluster, there will be 1x JobManager and 1x TaskManager.

© JobManager will also execute tasks if TaskManager is too busy.

(d) User can only submit their program through WebUI.

3. 期末考回忆

DC 虚拟化
1. ……的技术有两种虚拟机，容器等，Function as a Service 的实现技术是什么
2. 没有CPU参与的RDMA技术是哪一种
3. 设计一个数据中心需要考虑什么
Clock
1. 按图给出 Lamport Clock
2. 按图给出 Vector Clock
3. 分别给出两种 Clock 的优点
Raft
1. 按题目写出每个 term 可能的 Leader
2. 3.2 有没有可能被提交
3. 如果xx成为 Leader，给出其他节点要 drop 的 log entries
4. ？
SnapShot
1. 图中两条线的 cut 是不是 consistent cut
2. 在图中画出每个节点至少有3个状态的最小的 consistent cut
3. 如果 channel 不按照 FIFO的顺序，Chandy Lamport 算法是否可行
Linearizability

给了一个图，图里边 4 个进程，有对同一个数据同时读写的操作，并且读写操作需要花费一定的时间才会 return，问这个系统是不是线性的。如果不是线性的，要尝试在图中用箭头画出一个 cycle 来反证。
Chrod key-value store
1. 写出一个节点的 finger table
2. H(x) = x mod 10，从N_12开始访问，写出 get(58) 访问的节点
3. ？
Aruora 原题（还是不会做，建议去读论文试试）
CRDT
1. 两个人同时对一个文档进行写入，一个人写“true ==”，另一个人写 “(一个单词)”，有没有可能出现结果为 “(一个单词) == true”，说明过程
2. ？
3. ？
Consistency
1. ？
2. 在 Partitioning 和异步的情况下，最好的一致性模型是
3. 在同步和？的情况下，最好的一致性模型是
选择，不少原题
1. Faas 是无状态的，那么状态是谁保存的（有疑惑的选项是 WebServer 和都不是，其他俩选项忘了）

叼辣条闯天涯

关注

1
点赞
踩
3

收藏

觉得还不错? 一键收藏
打赏
0
评论
【云计算】【总结及期末考试回忆】CMSC 5735 Cloud Computing

虚拟化和数据中心两种 Hypervisor：直接在硬件上和在操作系统上两种 Hypervisor 实现方法：全虚拟化和半虚拟化软件定义网络两种RDMA：被授权后直接写和一方写一方收高可用性背景衡量分布式算法：为了保持复制副本需要发送的信息数和节点数的关系，越小越好正确性SafetyLiveness时序Total Order: 服务端接收一致Linearizability: 遵守真实时间，平行系统并发数据结构锁。
复制链接

扫一扫