Distributed Systems and Cloud Computing: Review 1

This is the self-review pack of Distributed Systems and Cloud Computing. We have lesson 1-5.

Lesson 1

Presentation – Effective communication of information rather than of data
– Code and number conversion
– Transmission of sophisticated data structures
– Data compression
• Application
– Electronic mail
– File transfer protocols (ftp)
– virtual terminal protocols (telnet)
– Distributed system (distributed database)
– Client-server

Lesson 2

什么是中间件！

C/S

proxy server

“可移动代理（mobile proxy / downloadable proxy）”，本质是 RMI + mobile code

“我想调用这个远程对象，但我本地没有它的 proxy”

2️⃣ 系统从 另一个服务器（不是目标服务本身）
👉 把 proxy（stub）代码发给 client

• proxy 是：
  • Java class / bytecode
  • 或其他可执行中间代码
• 属于 mobile code

3️⃣ Client 本地 加载并执行 proxy

4️⃣ Client 调用 proxy 的方法

“Example mobile code: Applets” 指的就是运行在 client 端的代码，更准确地说，是从服务器下载到客户端、并在客户端 JVM 中执行的移动代码（mobile code）。

• Best-effort：大家一起抢资源，谁快谁用
• QoS：我保证你至少 / 至多 / 大概用到多少资源

指标	含义	例子
Latency（延迟）	多久能响应	RPC < 10ms
Throughput（吞吐）	单位时间处理多少	1000 req/s
Bandwidth（带宽）	传输速率	1 Gbps
Jitter（抖动）	延迟是否稳定	实时音视频

常见手段：

• 流量分类（traffic classification）
• 优先级队列（priority queue）
• 带宽预留（bandwidth reservation）
• Rate limiting / shaping

目标：多租户下的 SLA 保证

• 一个用户卡了，不能拖垮其他人
• 云厂商要“卖承诺”

常见说法：

• SLA（Service Level Agreement）
• QoS violation（服务质量违约）

典型 QoS 目标

• Prefill latency < X ms
• Decode TPS ≥ Y
• P99 latency ≤ Z
• 不因其他请求导致 OOM 或长尾爆炸

概念	区别
QoS	系统内部的资源/性能保证机制
SLA	对外承诺（合同级）
Performance	实际跑得快不快
Fairness	是否公平，不一定有保证
Best-effort	没有 QoS

System models

What are the main entities in the system?
👉 系统里“有什么东西”？

• 进程 / 线程
• 节点 / 机器
• 用户 / 请求
• 数据对象 / 状态

How do they interact?
👉 它们“怎么交流”？

• 消息传递 or 共享内存
• 同步 / 异步
• RPC / 流 / 事件
• 一对一 / 广播 / 组通信

What are the characteristics that affect their behaviour?
👉 哪些因素影响行为？

• 时钟是否同步？
• 网络是否可靠？
• 是否会失败？
• 是否存在恶意行为？

Interaction, Failure, Security 是“三大基础模型”

1️⃣ Interaction Model（交互模型）

回答问题：

系统组件如何通信？时间和顺序是否可预测？

典型分类：

• 同步 / 异步
• 有界延迟 / 无界延迟
• 消息是否会丢 / 乱序

📌 影响：

• 能否实现共识
• 是否能设定超时
• 是否能用锁 / barrier

---

2️⃣ Failure Model（失败模型）

回答问题：

系统中“坏事”会坏到什么程度？

常见失败模型：

• Crash failure（宕机）
• Omission（消息丢失）
• Timing failure（超时）
• Byzantine failure（恶意行为）

📌 不同失败模型 ⇒ 完全不同的算法复杂度
（比如 Paxos vs PBFT）

---

3️⃣ Security Model（安全模型）

回答问题：

系统是否面对攻击者？攻击能力有多强？

包括：

• 是否有恶意节点
• 是否能伪造消息
• 是否窃听 / 篡改
• 是否支持认证 / 加密

📌 决定：

• 是否需要签名
• 是否需要 PKI
• 是否需要拜占庭容错

---

Lesson 3

The functionality encapsulated within each layer is called Protocol.

OSI

一种最基本、最通用的分布式交互协议模式（interaction pattern）

👉 Client（请求方） 和 Server（应答方）

哪些模型/协议？

实例	说明
RPC	远程过程调用，本质就是 request–reply
HTTP	请求–响应模型
gRPC	带强类型的 request–reply
数据库查询	Query → Result
LLM API	Prompt → Response

IP multicast 是一种 网络层的一对多（one-to-many）通信机制：

发送方只发送一份数据，网络负责把它复制并分发给所有加入该组的接收方。

• Unicast：一对一（发 N 份给 N 个接收者）
• Broadcast：一对所有（全网都收到）
• Multicast：一对一组（只给订阅者） ← IP multicast

---

IP multicast 在“哪一层”？

• 网络层（IP 层）
• 通过 多播地址 表示“接收者集合”
• 网络设备（路由器）在必要的分叉点复制数据

Lesson 4

Distributed Objects and Remote Invocation

RMI（Remote Method Invocation，远程方法调用） 是一种分布式系统机制，它允许一个进程像调用本地对象的方法一样，调用运行在另一台机器上的对象方法。RMI 在底层通过 request–reply 的通信模式，将方法名和参数序列化后发送到远端，由远端对象执行并把返回结果或异常再传回调用方，从而对程序员隐藏网络通信、数据传输和位置差异等细节。

“调用语义（invocation semantics）”与“容错机制（fault tolerance）

在存在网络与节点故障的情况下，一个远程方法“到底被执行了几次”？

1️⃣ Maybe（可能执行，也可能没执行）

• 不重传请求
• 出错就直接失败
• 调用方不知道远端是否真的执行过

📌 特点：

• 最弱保证
• 实现最简单
• 语义最不安全

👉 本地 ≠ 远程 的根本原因就在这里

2️⃣ At-least-once（至少执行一次）

• 请求丢了 → 重传
• 可能 执行多次
• 但调用方一定会收到：
  • 结果，或
  • 异常

📌 风险：

• 副作用操作会出问题
  • 比如 withdraw(100) 可能扣两次钱

📌 PPT 中的例子：

• Sun RPC

3️⃣ At-most-once（至多执行一次）

• 请求可以重传
• 服务器做重复检测
• 已执行过的请求：
  • 不再重新执行
  • 直接重发上次的 reply

📌 这是最接近“本地调用”的语义
📌 PPT 中的例子：

• Java RMI
• CORBA

列	在问什么
Retransmit request message	请求丢了要不要重发？
Duplicate filtering	服务器要不要检测重复请求？
Re-execute / retransmit reply	重复请求怎么处理？
Invocation semantics	最终语义保证

how different fault-tolerance mechanisms in RMI (request retransmission, duplicate filtering, and reply retransmission) lead to different invocation semantics: maybe, at-least-once, and at-most-once.

Proxy

proxy 不是缓存（cache），而是“远程对象的本地代理（stub / proxy object）”。

result = remoteObj.foo(x);

实际发生的是：

1. 调用的是 proxy 的 foo()
2. proxy：
   • 序列化方法名 + 参数
   • 通过网络发送 request
3. server 执行真正的 foo()
4. 返回结果
5. proxy 反序列化并返回

👉 这就是 “Instead of executing an invocation, it sends a message” 的含义

维度	Proxy (RMI)	Cache
是否执行逻辑	❌ 不执行	❌/✅
是否存结果	❌（默认）	✅
是否减少网络通信	❌	✅
目的	透明性	性能
语义	远程调用	本地副本

一次“看起来像本地方法调用”的 RMI，在系统内部到底是怎么被拆解和执行的。

RMI 通过 proxy（stub）、remote reference module、communication module 和 server 端的 skeleton/servant，把本地方法调用转化为网络请求并在远端对象上执行。

它干三件事：

1. 区分本地对象引用 vs 远程对象引用
2. 生成 remote object reference
   • 包含：对象 ID、服务器地址、端口等
3. 创建 proxy（stub）

📌 你可以把它理解为：

“RMI 的对象地址管理 + proxy 工厂”

Remote object table

• 保存：
  • 本进程拥有的远程对象
  • 本地 proxy 对应的远程对象引用
• 用来做：
  • 查找
  • 去重
  • 生命周期管理

1️⃣ RMI ≠ 魔法

• 本地调用只是“表象
• 实际是 消息传递 + 对象管理

2️⃣ 清晰的职责分离

• proxy：接口透明
• remote reference module：对象定位
• communication module：网络
• skeleton：方法分派
• servant：业务逻辑

3️⃣ 为后续问题做铺垫

• at-most-once 语义
• failure handling
• garbage collection（分布式）

---

RMI 是建立在 RPC 之上的、更高层的抽象；RPC 是机制，RMI 是面向对象语义的封装。

• 没有对象、没有状态
• 调用的是“某台机器上的某个过程”
• 更贴近 C / 系统编程

📌 RPC：调用一次就完
📌 RMI：对象长期存在

RMI = RPC + 对象模型 + 远程引用管理

• RPC：
  • 无状态（stateless）
• RMI：
  • 对象有 identity
  • 多次调用作用在同一个远程对象

RPC	RMI
实现复杂度	低	高
语义强度	弱	强
分布式 GC	❌	✅
动态 proxy	❌	✅

现实系统	更像谁
gRPC	RPC
Thrift	RPC
Java RMI	RMI
CORBA	RMI
REST	RPC（弱形式）
LLM API	RPC

RMI code

Lesson 5

indirect communication

在讲 分布式系统中的“空间耦合（space coupling）”和“时间耦合（time coupling）”，用一个 2×2 的分类表 来系统地理解通信方式之间的本质差异。

1️⃣ 空间耦合（Space coupling）

关注的是：

发送方是否需要“知道”接收方是谁/在哪里

• 空间耦合（Space-coupled）
  • 发送方知道明确的接收者（地址、对象、进程）
• 空间解耦（Space-uncoupled）
  • 发送方不知道具体接收者，只是“发出去”
  • 谁接收由系统/中介决定

---

2️⃣ 时间耦合（Time coupling）

关注的是：

发送方和接收方是否必须在同一时间存在

• 时间耦合（Time-coupled）
  • 发送消息时，接收方必须“在线”
• 时间解耦（Time-uncoupled）
  • 发送和接收可以发生在不同时间
  • 接收方可以晚点再出现

④ 空间解耦 + 时间解耦（右下）

最解耦、最灵活的通信方式

特性

• 不知道接收者是谁

• 不要求接收者立即存在

• 双方生命周期完全独立

例子

• Publish / Subscribe

• Message Queue

• Tuple Space（Linda）

• 大多数间接通信模型

👉 本质：

“我只管发，谁来、什么时候收都无所谓”

---

JGroups 是一个 用于构建可靠组通信（group communication）的 Java 中间件库，常用于 集群、分布式系统的一致性与成员管理。
一个让多台节点像“一个组”一样可靠通信的 Java 库，提供 成员发现、可靠消息广播、顺序保证、故障检测 等能力。

在分布式系统里，你经常需要：

• 向一组节点发送消息（不是点对点）
• 知道谁在线、谁宕机
• 保证消息 不丢、不乱序（可选）
• 在节点 动态加入/离开 时系统还能正常工作

👉 JGroups 把这些通用而复杂的机制都封装好了。

---

实际中谁在用 jgroup？

• JBoss / WildFly：集群通信

• Infinispan：分布式缓存复制

• Hazelcast（早期/类似思想）

• IP Multicast：只负责“发”

• JGroups：在 multicast 之上 补齐可靠性、顺序、成员管理

服务发现（Service Discovery） 是分布式系统中的一种基础机制，用来解决：

在一个节点数量、地址、状态都不断变化的系统里，客户端如何找到“当前可用”的服务实例？

服务发现 = 自动维护“服务名 → 可用实例地址”的映射机制
让调用方 不用关心 IP / 端口变化，只按服务名访问。

核心组成（3 个角色）

1️⃣ 服务注册（Service Registration）

服务启动时：

• 向“注册中心”报告：

  我是谁 + 我在哪 + 我还活着

例如：

service = "user-service" address = 10.0.0.12:8080

---

2️⃣ 服务发现（Service Lookup）

客户端需要调用服务时：

• 向注册中心查询：

  “user-service 现在有哪些可用实例？”

---

3️⃣ 健康检查（Health Check）

注册中心持续确认：

• 服务是否存活
• 宕机实例会被自动剔除

两种主流服务发现模式

🅐 客户端发现（Client-side Discovery）

客户端：

1. 查询注册中心
2. 自己做负载均衡
3. 直接调用实例

📌 常见于微服务 / RPC 框架

优点

• 灵活
• 少一跳

缺点

• 客户端逻辑复杂

---

🅑 服务端发现（Server-side Discovery）

客户端：

1. 请求一个固定入口
2. 由网关 / LB 转发到真实服务

📌 常见于云原生架构

优点

• 客户端简单

缺点

• 多一跳

下面这些都是分布式系统里非常经典的组件：

• ZooKeeper

• etcd

• Consul

• Kubernetes（内置 Service / DNS）****

• RPC / RMI
  👉 常常依赖服务发现来拿到目标地址

• JGroups
  👉 偏向“组通信”，不是典型服务发现

• 消息队列 / Pub-Sub
  👉 更进一步，连“找服务”都不需要