Junyi's Lab

Distributed System: Primary Backup Replication

junyi.h@comp.nus.edu.sg (Junyi Hou) — Tue, 12 Sep 2023 15:15:37 +0800

开胃菜来了！

你有一个硬盘，存了很多重要资料，你担心这个硬盘某天坏了，怎么办？

当然是多买点硬盘，把数据备份在不同的硬盘上。

保证可靠，就是通过多个一致的数据副本来实现的。

# 前提假设

我们假设所有的操作都是确定deterministic的

# 最简单的 primary & backup

clients 发送 operation (Put, Get, Append) 到 primary-server
primary-server 决定 operation 的执行顺序
primary-server 把 operation 的执行顺序发送给 backup-server
backup-server 按照 primary-server 发送的顺序执行 operation（hot-standby）
- 或者 backup-server 按照 primary-server 发送的顺序记录 operation 但不执行（cold-standby）
等 backup-server 成功结束，primary-server 给 client 发回复

问题是，怎么决定谁来当 primary-server？

怎么决定谁来当 backup-server？

client 怎么知道谁是 primary-server？

答案： 引入一台 view-server，让这个 view-server 来做决定，并且 client 去问 view-server 谁是 primary-server。为什么叫它 view-server？因为这涉及到一个重要概念「view」，后面会讲到，别着急！

知道了答案，我们可以这样设计整个系统：

我们让每台服务器发送心跳给 view-server，告诉 view-server 自己还活着。

问：有没有可能自己活着但是 view-server 认为自己死了？有可能因为网络问题，心跳没发出去，view-server 认为节点挂了，但其实节点还活着
我们 promote idle-server 成为 backup-server，但不越级 promote 成为 primary-server

问：除非有种情况？系统刚启动时（全都是 idle-server、需要一个 primary 的时候）
只有 backup-server 会被 promote 成 primary-server

Fig.1 - One View Server and Two Nodes

# 什么是 view-server 里的 view

一个 view 是一个 primary-server 和一个 backup-server 的集合，描述了当前状态谁是 primary 谁是 backup。

注意，一个 view 里，只有一个 primary 和一个 backup，其它的 server 标记为 idle。（想想看为什么这样设计？）

view 由 view-server 进行管理，其他节点可以获取到当前系统的 view。

Fig.2 - Example of three different views, denotes three different states of the system

看了上面的描述，感觉自己又行了，于是我设计出了下面的流程

系统刚开始，挑一个 primary-server，然后挑一个 backup-server，其它的都是 idle-server，然后开始工作。

primary 立马让 backup 成为新的 primary，从 idle 里面挑一个成为 backup，然后让这个新的 primary 把状态都发送给 backup

很简单嘛！这能有什么问题？

话音刚落，问题就来了。

请看下面这个情况：

`View 1, primary=A, backup=B;` 这时候 A 挂了，B 成为 primary，从 idle 里面挑一个 C 成为 backup，然后 B 发送状态给 C。

`View 2, primary=B, backup=C;` B 发状态的时候挂了，C 成为 primary，idle 里面没机器了

`View 3, primary=C, backup=_;` C：😅？（此时 C 根本不知道系统的状态是什么）

所以我们刚刚对整个系统的描述，是有缺陷的。

怎么改呢，我们让 view-server 必须等待 primary-server 确认ACK 当前的 view。

就算 primary-server 挂了，view-server 也要等 ACK。

（直觉告诉我们，这种等待 ACK 的行为可能导致系统卡住）

# 总结一下所有的规则

在 view i+1 的 primary 必须是 view i 的 backup

如果没有这个规则会怎样？Split brain: primary A, backup B, but can’t reach view-server. C,D are promoted to primary and backup, C doesn’t know previous state.
primary 必须等 backup 执行完，才可以回复 client

如果没有这个规则会怎样？Missing write: client writes to A，A crashes before writing to B, clients read from B

一定要转发 read() 给 backup 吗？（这是一个常见的优化操作）必须转发。不然可能出现 Stale read: at view 1, A,B are primary and backup, but A cannot reach view-server. now view 2, B,C are primary backup. client 1 writes to B, client 2 reads from A. A returns outdated data（不过 stale read 依然符合 sequential consistency）
如果 view 是正确的，backup 必须接受转发的请求Forwarded Request，并且执行

如果没有这个规则会怎样？Partially Split Brain
non-primary 节点必须拒绝 client 的请求

如果没有这个规则会怎样？Inconsistencies: client’s view may outdated, send request to old primary server.
state-transfer 的时候不能有操作。（Atomic State Transfer）

如果没有这个规则会怎样？

# 脑裂 (Split-brain)

这个词有点吓人。。。其实是在说：在网络故障时，两个及以上的节点都认为自己是 Leader (primary-server)。

View 1, primary=A, backup=B; 这时候 A 网络出故障无法连接到 view-server，B 成为新的 primary。 View 2, primary=B, backup=_; B 是新的 primary，但 A 也认为自己是 primary

在我们之前的规定里，只有 primary-server 会回复 client，但是脑裂的时候，两个节点都会回复 client，这就可能导致 client 收到的数据不一致。（破坏了 Linearzability）

# 系统卡住

有哪些可能导致系统卡住（处理不了 client 的请求）的情况？

view-server 挂了
整个网络挂了
client 只能练到 view-server，不能连接到 primary-server
backup server 没有了（因为 primary 转移状态给 backup，转移完了回复 view-server 一个 ACK）
状态转移之前 primary 挂了

# 重复写入

# 为什么 Primary Backup 比较难

primary 可能挂掉
backup 可能挂掉
通讯可能临时/永久挂掉
参与者的决策可能存在延迟：
- view server 不知道 primary 挂了
- primary 挂了吗？挂了之后恢复，还需要回复 client 吗？
- backup 挂了吗？state transfer 结束了吗？
- client 不知道 view 有没有切换

# 总结一下 view-server 的缺点

view-server 自己存在单点故障问题
view-server 必须等待 primary 的 ack，即使 primary 可能挂了也要等

# 状态机复制State Machine Replication

状态机有一个特性： 任何初始状态一样的状态机，如果执行的命令序列一样，则最终达到的状态也一样。

如果将此特性应用在多参与者进行协商共识上，可以理解为系统中存在多个具有完全相同的状态机（参与者），这些状态机能最终保持一致的关键就是起始状态完全一致和执行命令序列完全一致。

根据状态机的特性，要让多台机器的最终状态一致，只要确保它们的初始状态是一致的，并且接收到的操作指令序列也是一致的即可，无论这个操作指令是新增、修改、删除抑或是其他任何可能的程序行为，都可以理解为要将一连串的操作日志正确地广播给各个分布式节点。

我们并不要求所有节点的每一条指令都是同时开始、同步完成的，只要求在此期间的内部状态不能被外部观察到，且当操作指令序列执行完毕时，所有节点的最终的状态是一致的，这种模型就被称为状态机复制（State Machine Replication）。

# Tips

实现 Paxos 的注意事项可以参考 Junhui 的 Cheatsheet¹

# Reference

https://jzhu.xyz/posts/paxos (Cheatsheet of MultiPaxos Impl) ↩︎

Distributed System: Consistency

junyi.h@comp.nus.edu.sg (Junyi Hou) — Tue, 12 Sep 2023 14:06:01 +0800

这篇文章主要是对分布式系统中的一致性Consistency进行区分

弱一致性Weak Consistency：允许系统的行为与单一系统的行为不一致。

强一致性Strong Consistency：整个系统表现得像是一个单一的、无并发的实体。

下面的一致性，由弱到强

# 最终一致性Eventual Consistency

系统最终会达到一致的状态。

# 因果一致性Causal Consistency

比 Sequential Consistency 更弱。如果操作 A 依赖于操作 B，那么操作 B 发生在操作 A 之前，但是如果操作 A 和操作 B 之间没有因果关系，那么操作 A 和操作 B 的顺序是不确定的。

有因才有果，因在果之前

先看见因，再看见果

如果一个问题被回答，显然问题本身得先在那里，因为给出答案的人必须已经看到这个问题，我们认为在问题和答案之间存在因果依赖。

比如微信朋友圈需要服务器之间采用因果一致性，来保证用户刷朋友圈时不会看到评论所对应的答复而看不到对应的评论。

延伸阅读：怎么生成唯一且递增的 ID？微信序列号生成器架构设计及演变雪花算法

# 序列一致性Sequential Consistency

不管系统怎么运行，得到的结果就好像把所有节点的所有操作按照某个 sequential order 排序后运行，但是在这个 sequential order 中，来自同一个节点的操作仍然保持着它们在节点中被指定的顺序。

换句话说，物理意义上的时间，不能决定操作operations的执行顺序

用作 Transaction 时我们称之为 Serializability

常用在银行、金融数据库、事务

# 线性一致性Linearizable Consistency

也叫 Linearizability

是【顺序一致性 + 按照物理时间顺序执行】。

满足线性一致性的数据结构，表现得像是一个单一的、无并发的实体。是最强的保证

比如 Google Spanner

介绍到这里，基本上对 Consistency 有了大致的了解，接下来可以看 Primary Backup Replication 了。

# Lab 2

实现 Primary-backup replication：

client 发送请求给 primary-server
由一个中央 view-server 决定谁是 primary 谁是 backup
primary 挂了，backup 顶上来

Distributed System: Ordering of events

junyi.h@comp.nus.edu.sg (Junyi Hou) — Tue, 12 Sep 2023 11:32:04 +0800

上个学期的 CS5223 Distributed Systems ，Prof. Li 讲的蛮好，尽管实现了 Basic Paxos 和 Multi Paxos（多亏了 Junhui 的 cheatsheet¹），但是耐不住时间的拷打，写的 Paxos 都快忘光了…

所以，赶紧开一篇博客把想法都记录下来，以便之后的复习。

首先简单过一下这些基础概念

# Happens-before relationship

Within a process, A comes before B then A→B, it also means

B could have been influenced by A
If a → b, then b !→ a

What about a!→b, does that mean b→a? NO
If a → b, and b → c, then a → c (transitivity)
a !→ b and b !→ a, means a and b are concurrent

no one can tell whether a or b happened first!

# Lamport clock

We can use clocks to implement a lock.

Our goals are:

Only one process can hold the lock at a time.
Grant the lock in request order.
Requesting processes eventually get the lock.

Our assumptions are:

In order point-to-point message delivery.
No failures.

Implementation:

Each message carries a timestamp $T_m$
Three message types:
- request
- release
- acknowledge
Each node’s state:
- A queue of requested messaged, ordered by $T_m$.
- The latest timestamp it received from each node.

On receiving

receiving a request
- record the timestamp
- add the request to the queue
- send an acknowledge
receiving a release
- record the timestamp
- remove the request from the queue
receiving an acknowledge
- record the timestamp

To perform

To acquire a lock
- send request to every node, including itself
To release a lock
- send release to every node, including itself

The lock is acquired when

My request is at the head of the queue.
I’ve received higher timestamp from every node.
So my request must be the earliest.

# Vector clock

Clock is a vector C, length = # of nodes.

(0, 0, 0) for a 3-node system

On node i, increment C[i] on each event.

node 0 (3,5,2), after event: (4,5,2)

On node i, received a message, increment C[i], and take the max of each element.

node 0 (4,5,2), received message (2,7,0): (4,7,2)

If Cx[i] < Cy[i] and Cx[j] > Cy[j] for some i, j

Cx and Cy are concurrent

if Cx[i] <= Cy[i] for all i, and there exist j such that Cx[j] < Cy[j]

Cx happens before Cy

# Lab 1

实现一个 at-most-once 的 KV Store

RPC 要么最多执行一次，要么不执行

# Reference

https://jzhu.xyz/posts/paxos (Cheatsheet of MultiPaxos Impl) ↩︎

垂直联邦学习Vertical Federated Learning (VFL)

junyi.h@comp.nus.edu.sg (Junyi Hou) — Sat, 26 Aug 2023 19:32:24 +0800

这是一个科普性质的文章

之前很抗拒做 VFL，因为我认为 VFL 只是一个训练模型的工作。

但是，我刚刚意识到 VFL 不只是深度学习。（一种突然开窍的感觉）

实际上，垂直联邦学习Vertical Federated Learning 在联邦学习Federated Learning 领域里，研究的核心是 Record Linkage / Data Integration。

这玩意被深度学习包装一下就变成了 VFL。

研究 HFL 的人比研究 VFL 的人多。因为 VFL 的数据太难获得了！

图 1 - HFL 和 VFL 的区别在于如何对待数据的 Column(Feature)

想想看，什么样的场景需要用到 VFL 呢？

比如银行和医院可以合作训练一个模型，预测用户的健康状态 / 还款能力。

训练这样一个模型之前，我们应该先把银行和医院的数据对齐一下（做一下 Record Linkage）。

Record Linkage: the process of identifying and linking records that correspond to the same individual across different databases.

图 2 - 经过 Record Linkage 过程，我们找到了银行和医院中的 Junyi Hou。

图 3 - 在 Privacy Preserving (保护隐私) 的情况下，Record Linkage 变得困难。

在 Privacy Preserving 的情况下，如何做 Record Linkage 呢？

一个方法是 FedSim (NeurIPS2022)，取 TopK 个最相关的 record 做 linkage ….

VFL 数据不够的情况下，我们怎么广泛评估算法好坏呢？

大部分研究者手动切分数据集，要么随机切，要么平均切，要么看心情切。

比如数据集有 16 个 feature，我分成 2 个 party，partyA 有 9 个 feature，partyB 有 7 个 feature。

直到 VertiBench (ICLR2024) 这篇工作，我们才有一个切分数据集的指导纲领（两个指标）。