Motivation

FaaS 环境下存在大量短生命周期的函数，这些函数作为进程调度到 OS 上。同时创建数千个函数都是家常便饭。由于 Faas Function 生命周期通常很短，研究表明 99% 的 Azure Function 都在 224s 以内。因此，OS 调度策略会对 FaaS function 的周转时间（turnaround time）产生重大影响。然而，Linux CFS 在大量短生命周期任务的 FaaS 下表现并不好。

这个工作太神奇了，阅读 Understanding, detecting and localizing partial failures in large system software 的时候，在思考怎样检测 silent semantic violation，论文里说一个难点就是不知道正确的语义是什么，我想到也许可以用 LLM 推测。完全没想到可以用论文如此简洁的方式推测。

论文的思路很简单，从系统的 regression test 入手。尽管这些 test 通常是真的特定的 bug 的，但这些 test 仍然蕴含了系统的语义。论文要做的就是从 regression test 中推导出这些语义，并在运行时检测系统是否违背了语义。

本论文从最基本的单体数据库出发，一步步推导出目前主流的架构设计，并详细对这些设计进行性能分析。对于我这种新人而言，跟这作者的思路走，像是一场思想旅行，打开了一扇大门。

• 论文针对哪种类型的数据库？

  storage-disaggregated OLTP database

• 为什么 storage-disaggregated OLAP database 不使用 log-as-the-database 和 shared-storage 设计？

  OLAP 通常服务读密集型负载，这两个设计解决的是写密集型负载的痛点。

• log-as-the-database 的原理和效果？

  计算节点只发送 xlog，存储节点通过重放 xlog 得到数据。降低了网络负担，并且利用了存储节点的 CPU。

背景

partial failure 是区别于 fail-stop 模型 full failure 的另一种故障模式，简而言之，partial failure 指系统部分地故障，但不是完全故障而无法服务。论文给 partial failure 下了以下定义：

对于一个服务器进程 P，其中包含许多组件，提供一系列服务 R。如果进程 P 中发生了故障（fault），但这个故障没有让 P crash，但却破坏了 $R_f \notin R$ 安全性（safety）保证、活性（liveness）或性能问题，这样的故障就是 partial failure。

Motivation

目前分布式系统中的故障注入不够高效，主要是由于以下原因：

1. 许多故障是 partial failure。发生故障时，系统仍然在运行，只是系统的某个组件或服务受影响。
2. 故障的触发条件非常罕见。例如，某些故障只在特定时刻的特定网络故障下发生，并且只影响某个组件。
3. 成熟的分布式系统有比较好的容错性。许多混沌工程的实践随机注入故障，成熟的分布式系统可以容忍大部分故障，大量的注入是无效的，无法检测出新 bug。

故障注入的一大难点是“如何在无数中可能的故障注入点中找到最可能暴露 bug 的故障注入点”。论文认为，大多数的 bug 都发生在特殊情况下，因此故障注入框架也应该找到这些“特殊情况”，并在这些容易出错的地方注入故障。论文提出了一个新的故障注入框架 Legolas，Legolas 通过静态分析，找到程序的状态机，并在这些故障迁移时根据 bsrr（budgeted-state-round-robin）策略通过插入 hook 注入故障。

背景

Facebook 存储 2600 亿张照片，数据量超过 20 PB，且处于迅速增长中。Facebook 照片的工作流有以下特征：

• 单次写，多次读，很少删除。
• 长尾：用户会访问旧照片，这些照片不在 CDN 中。

Facebook 一开始直接将照片存储在文件系统中，并通过 NFS 导出，但存在以下问题：