Yuchen You

1. TL;DR [!TL;DR] 用一句话说清：这篇论文在什么场景下，用什么关键方法，解决了什么问题。 2. Problem 问题： 为什么重要： 已有方法为什么不够： 3. Core Idea 核心 insight： 作者真正的新东西： 4. Design 系统/方法框架： 关键机制 1： 5. Evaluation 作者想证明什么： 最关键结果： baseline 是否合理： 实验是否足够支撑 claim： 6. Limits 最强假设： 最大局限： 什么场景下可能失效： 7. My Take 我学到的点： 和我研究的关系： 可 follow-up 的问题： 8. 5-Line Recall 问题： 方法： 亮点： 缺点： 启发：

Data-Level Parallelism (DLP) 在前面的工作中我们主要学习的 并行架构 就是 pipelining 简单的做法就是并行使用多个 核 core 或者使用多个硬件结构实现并行, 但是这里要讨论的是 数据层面的并行 在固有的处理器中, 我们计算如下公式 12for(i = 0; i < 100; i++) z[i] = A * x[i] + y[i]; 很显然这一步可以用矩阵和向量等式进行优化 即表达式 z⃗=A⋅x⃗+y⃗\vec z = A\cdot \vec x + \vec yz=A⋅x+y​ 那么接下来的问题就是如何用硬件快速计算向量 SIMD 方法论 基础方法称为 single insturction single data 处理, 即每个指令获取一个对应的 data 部分, 但是事实上我们可以从一个指令调用多个 变量(来自一个 vector 的多个相关变量) 这就是 simd (可以在单核处理器上面有出色表现) 当然也可以 多个指令调用多个变量, 这个取决于多核同时工作 对比 cpu 和 gpu, 我们会发现当我们要处理大量相同类型的数据的时候 ...

平衡的背景 利用冗余(replicas)来降低尾延迟(tail latency), 以及它和 Paxos 共识, load / sharding 之间的关系; 核心是: 复制本来是为了容错/可用性, 但你也可以把它当成"多条独立路径/多台机器"的并行机会, 用来对抗偶发慢请求; 一个 key 有多个副本(N replicas); - 正常读: 只读一个副本 - 好处: 负载低, 便宜 - 风险: 这一次刚好遇到这个副本慢(GC, 排队, 抖动), 尾延迟就被拖垮 First idea: read from all in parallel(最直接: 全部并行读, 取最快) 做法: 同时向所有副本发 GET, 拿到第一个返回就用(其他请求丢掉/忽略); 优点: 尾延迟会显著下降(你拿的是 min(response times)) 问题(slide 点出的): 系统负载和成本暴涨 每次读都变成 N 倍 RPC 平均延迟可能更好, 但整体排队更严重, 反而把系统推到更拥塞, 导致更差的 tail 所以"全并行"通常太贵, 只能在极少数场景用; Sec ...

分片 (Sharding) 分片是分布式系统设计中的一个关键概念, 它与复制(Replication)一起, 构成了构建大规模系统的基础; 分片的本质与目标 分片的本质在于解决单一机器的限制和不可靠性问题,; 复制(Replication): 通过复制数据来使机器可靠(reliable), 提高容错性; 分片(Sharding): 通过分割数据来提高机器的容量限制 (raise the machine’s limits); 分片适用于任何存储系统, 通常是通过将 键空间(key space) 分割到多个复制对(例如主/备份对)来实现; Facebook 架构中的分片应用 复制存储: 数据库在所有数据中心之间进行复制(replicated), 可以想象每个数据中心都包含一份完整的数据拷贝,; 数据库分割: 数据库被分割成多个分片(shards), 每个数据元素都属于一个特定的分片,;     - 领导者/跟随者: 每个分片都有一个数据中心作为其领导者(leader), 其余的中心是跟随者(followers);     - 数量: 分片的数量通常远多于(many more)数 ...

简单介绍 最终一致性位于一致性谱系的末端, 比线性一致性(Linearizability), 顺序一致性和因果一致性都要弱; 如果对某一数据项不再有新的更新写入, 那么在经过一段时间后, 所有未来的读取操作都将反映最新的写入结果 没有时间限制: 系统对收敛到一致状态所需的时间没有界限,;这个时间长短取决于通信模式的可用性(例如, 如果节点长期不通信, 收敛时间就会很长); 保证最终顺序: EC 仍然要求更新最终以相同的顺序应用到所有副本上,;这通常是通过逻辑时钟等机制来实现的, 允许更新先作为临时更新本地应用, 然后在同步时根据逻辑时间戳进行回滚和重放,; Bayou 模型 (SOSP 1995) 没有中心化存储: 所有的节点都被视为客户端,; 始终接受更新: 客户端总是接受用户发出的更新操作, 这保证了高可用性和活性; 日志记录: 所有更新都会被记录在本地日志中; 点对点同步: 客户端之间会定期进行 成对(pair-wise) 的更新交换; 临时更新: 更新通常是暂时的(tentative), 可以解决它们之间的冲突; 举例说明最终一致性 假设有一个房间日程安排应用程序(Ro ...

分布式系统的不稳定性 综合我们前几个章节的内容, 我们可以总结出分布式系统中的不稳定性主要源于以下几个方面: 故障模型 (Failure Model) 在这个模型中, 对节点和网络特性的定义如下: 节点(Nodes): 它们可以无限期地失败; 它们在恢复时不会丢失持久状态; 对任何特定的计算, 它们都没有时间限制; 网络(Network): 网络可以丢弃 drop 或延迟 latency 消息; 消息可能被无限期地延迟; 网络也可能对消息进行重新排序; 异步模型 (Asynchronous Model) 上述的故障模型被称为异步模型; 在该模型下, 核心挑战在于: 无法区分 Failure 与 Slow: 在一个异步模型中, 你通常无法区分失败(例如, 请求被丢弃或远程节点死亡)和极度缓慢(例如, 网络或节点速度很慢, 响应只是尚未到达); No response 的含义: 缺少响应可能意味着请求被丢弃, 远程节点已死, 或响应被丢弃;但这也可能仅仅意味着网络或节点非常慢, 并且响应仍在路上; 也就是这些都 Not Distinguishable (无法区分); F ...

分布式事务系统 Distributed Transaction 根据分布式数据库系统的类似要求, 我们设计的分布式系统要支持 ACID 准则: Atomicity (原子性): 事务要么全部完成, 要么全部不做; Consistency (一致性): 事务执行前后, 数据库必须处于一致状态; Isolation (隔离性): 并发执行的事务彼此隔离, 互不干扰; Durability (持久性): 一旦事务提交, 其结果是永久性的, 即使系统崩溃也不会丢失; 如何区分 Linearizability 和 Serializability? Linearizability (线性一致性): 每个操作看起来像是瞬间发生的, 并且所有的 read 都会反映已经发生的所有 write 的结果 Serializability (可串行化): 并发执行的事务的结果与某个串行执行的顺序相同 Strict Serializability: 结合了线性一致性和可串行化的概念 也就是外界看到的顺序和实际执行的顺序是一致的 Isolation 问题与二相锁 (2PL) 一个常见的 i ...

ACID 准则 在讨论支持并发的文件系统 (包括 482 p4 NFS, DBMS 等) 的时候, 我们往往会提到一个非常核心的准则: ACID 准则. Atomicity (原子性): 事务是一个不可分割的工作单位, 要么全部完成, 要么全部不做; Consistency (一致性): 事务的执行必须使数据库从一个一致性状态转变到另一个一致性状态; Isolation (隔离性): 并发执行的事务彼此之间是隔离的, 一个事务的中间状态对其他事务不可见; 两个事务并发的时候不能互相冲突 Durability (持久性): 一旦事务提交, 它对数据库的修改就是永久性的, 即使系统崩溃也不会丢失. 更多是从 recovery 恢复角度来讲的, 也就是尽量能在任何崩溃情况下都不丢数据;具体看 [Logging](#Log 日志结构) 章节和 Recovery 章节 并发控制的数据库系统 并发控制与隔离性的基础 事务 (Transaction): 事务是 DBMS 中变化的基本单位;它是在数据库上执行的一系列操作(如 SQL 查询), 以完成某种高级功能; 事务的抽象视图 ...

Database Storage Disk-Based Architecture(磁盘架构) DBMS 假定数据库的主存储位置在非易失性磁盘 (Disk / SSD); 系统组件负责在 volatile memory(主存) 与 non-volatile storage(磁盘) 之间移动数据; Storage Hierarchy(存储层次) CPU Registers < CPU Cache < DRAM < SSD < HDD < Network Storage 越靠上速度越快, 容量越小, 成本越高; DBMS 设计目标: 最大化利用高速层, 最小化慢速访问; 为什么不直接用 OS 管理存储 虽然可以用 mmap() 将文件映射到内存, 但: DBMS 无法控制 page replacement 策略; OS 不保证 flush 顺序; 并发写入下可能引发不可控的 page fault; 因此 DBMS 自己实现 Buffer Pool, Page Replacement 与 Flush 策略更可控; 常见 OS 辅助机制: madvise: 告 ...