avatar
Articles
119
Tags
61
Categories
8

Home
Archives
Tags
Categories
About
Yuchen You
Search
Home
Archives
Tags
Categories
About

Yuchen You

5. Docker 网络栈协议
Updated2026-04-26|network•container•docker
📝 术语别名 NIC: Network Interface Card, 物理网卡, 真正的硬件; net_device: Linux 内核里描述"一张网卡"的统一抽象, 虚拟和物理共用同一个数据结构; 虚拟网卡: 没有对应物理硬件、纯软件模拟的 net_device, 例如 lo / veth / tap / tun / bridge; tap / tun: 给用户态进程收发包用的虚拟网卡, VM 和 VPN 的标配; netns: Linux network namespace, 内核提供的网络栈隔离机制; veth pair: virtual ethernet pair, 一对虚拟网卡, 一端发, 另一端收, 是连接两个 netns 的通道; bridge: 内核虚拟二层交换机, 把若干网卡拉到同一广播域; DNAT / SNAT: destination / source NAT, iptables 用来改包的 dst/src IP, 是端口映射和"出口走主机 IP"的核心; 前置 A: 物理网卡 (NIC ...
kubernetes
Updated2026-03-30
Load Balance
1. Distributed Data Parallel
Updated2026-03-26|mlsys|mlsys•gpu•cuda
DDP 是什么 DDP(Distributed Data Parallel)是 PyTorch 官方提供的分布式数据并行训练机制; 它的核心思想是: 让多个训练进程各自持有同一个模型的副本, 分别处理不同的数据子集, 并在反向传播阶段自动同步梯度, 从而保持所有模型副本的一致更新; DDP 要解决什么问题 深度学习训练通常面临两个核心限制: 单张 GPU 的计算吞吐有限 单张 GPU 每一步能处理的数据量有限 如果只用单卡训练, 随着模型和数据规模变大, 训练速度会越来越慢; DDP 的目标是: 利用多张 GPU 并行处理更多数据 在提高吞吐的同时, 仍然保持"训练的是同一个模型" 让多卡训练的优化语义尽量接近单卡上的大 batch 训练 因此, DDP 本质上是在解决: 如何让多个 GPU 高效, 稳定地共同训练同一个模型; DDP 的设计理念 DDP 的设计建立在一个基本前提上: 如果 单张 GPU 能放下完整模型, 那么最自然的数据并行方式不是切模型, 而是复制模型; 所以 DDP 的基本设计不是"拆模型", 而是: 每个进程 ...
0. 基本 GPU 架构
Updated2026-03-26|mlsys|mlsys•gpu•cuda
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, 我们会发现当我们要处理大量相同类型的数据的时候 ...
10. Tradeoffs btw
Updated2026-03-26|distributed_sys•Consensus
平衡的背景 利用冗余(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 ...
8. Sharding, Facebook and Implementation
Updated2026-03-26|distributed_sys
分片 (Sharding) 分片是分布式系统设计中的一个关键概念, 它与复制(Replication)一起, 构成了构建大规模系统的基础; 分片的本质与目标 分片的本质在于解决单一机器的限制和不可靠性问题,; 复制(Replication): 通过复制数据来使机器可靠(reliable), 提高容错性; 分片(Sharding): 通过分割数据来提高机器的容量限制 (raise the machine’s limits); 分片适用于任何存储系统, 通常是通过将 键空间(key space) 分割到多个复制对(例如主/备份对)来实现; Facebook 架构中的分片应用 复制存储: 数据库在所有数据中心之间进行复制(replicated), 可以想象每个数据中心都包含一份完整的数据拷贝,; 数据库分割: 数据库被分割成多个分片(shards), 每个数据元素都属于一个特定的分片,;     - 领导者/跟随者: 每个分片都有一个数据中心作为其领导者(leader), 其余的中心是跟随者(followers);     - 数量: 分片的数量通常远多于(many more)数 ...
7. Eventual Consistency
Updated2026-03-26|distributed_sys•Consensus
简单介绍 最终一致性位于一致性谱系的末端, 比线性一致性(Linearizability), 顺序一致性和因果一致性都要弱; 如果对某一数据项不再有新的更新写入, 那么在经过一段时间后, 所有未来的读取操作都将反映最新的写入结果 没有时间限制: 系统对收敛到一致状态所需的时间没有界限,;这个时间长短取决于通信模式的可用性(例如, 如果节点长期不通信, 收敛时间就会很长); 保证最终顺序: EC 仍然要求更新最终以相同的顺序应用到所有副本上,;这通常是通过逻辑时钟等机制来实现的, 允许更新先作为临时更新本地应用, 然后在同步时根据逻辑时间戳进行回滚和重放,; Bayou 模型 (SOSP 1995) 没有中心化存储: 所有的节点都被视为客户端,; 始终接受更新: 客户端总是接受用户发出的更新操作, 这保证了高可用性和活性; 日志记录: 所有更新都会被记录在本地日志中; 点对点同步: 客户端之间会定期进行 成对(pair-wise) 的更新交换; 临时更新: 更新通常是暂时的(tentative), 可以解决它们之间的冲突; 举例说明最终一致性 假设有一个房间日程安排应用程序(Ro ...
6. 从 FLP 不可能到 CAP 和 PACELC
Updated2026-03-26|distributed_sys•Consensus
分布式系统的不稳定性 综合我们前几个章节的内容, 我们可以总结出分布式系统中的不稳定性主要源于以下几个方面: 故障模型 (Failure Model) 在这个模型中, 对节点和网络特性的定义如下: 节点(Nodes): 它们可以无限期地失败; 它们在恢复时不会丢失持久状态; 对任何特定的计算, 它们都没有时间限制; 网络(Network): 网络可以丢弃 drop 或延迟 latency 消息; 消息可能被无限期地延迟; 网络也可能对消息进行重新排序; 异步模型 (Asynchronous Model) 上述的故障模型被称为异步模型; 在该模型下, 核心挑战在于: 无法区分 Failure 与 Slow: 在一个异步模型中, 你通常无法区分失败(例如, 请求被丢弃或远程节点死亡)和极度缓慢(例如, 网络或节点速度很慢, 响应只是尚未到达); No response 的含义: 缺少响应可能意味着请求被丢弃, 远程节点已死, 或响应被丢弃;但这也可能仅仅意味着网络或节点非常慢, 并且响应仍在路上; 也就是这些都 Not Distinguishable (无法区分); F ...
9. 分布式事务系统与 Spanner
Updated2026-03-26|distributed_sys
分布式事务系统 Distributed Transaction 根据分布式数据库系统的类似要求, 我们设计的分布式系统要支持 ACID 准则: Atomicity (原子性): 事务要么全部完成, 要么全部不做; Consistency (一致性): 事务执行前后, 数据库必须处于一致状态; Isolation (隔离性): 并发执行的事务彼此隔离, 互不干扰; Durability (持久性): 一旦事务提交, 其结果是永久性的, 即使系统崩溃也不会丢失; 如何区分 Linearizability 和 Serializability? Linearizability (线性一致性): 每个操作看起来像是瞬间发生的, 并且所有的 read 都会反映已经发生的所有 write 的结果 Serializability (可串行化): 并发执行的事务的结果与某个串行执行的顺序相同 Strict Serializability: 结合了线性一致性和可串行化的概念 也就是外界看到的顺序和实际执行的顺序是一致的 Isolation 问题与二相锁 (2PL) 一个常见的 i ...
5. Transaction and ACID DB
Updated2026-03-26|database•distributed_sys
ACID 准则 在讨论支持并发的文件系统 (包括 482 p4 NFS, DBMS 等) 的时候, 我们往往会提到一个非常核心的准则: ACID 准则. Atomicity (原子性): 事务是一个不可分割的工作单位, 要么全部完成, 要么全部不做; Consistency (一致性): 事务的执行必须使数据库从一个一致性状态转变到另一个一致性状态; Isolation (隔离性): 并发执行的事务彼此之间是隔离的, 一个事务的中间状态对其他事务不可见; 两个事务并发的时候不能互相冲突 Durability (持久性): 一旦事务提交, 它对数据库的修改就是永久性的, 即使系统崩溃也不会丢失. 更多是从 recovery 恢复角度来讲的, 也就是尽量能在任何崩溃情况下都不丢数据;具体看 [Logging](#Log 日志结构) 章节和 Recovery 章节 并发控制的数据库系统 并发控制与隔离性的基础 事务 (Transaction): 事务是 DBMS 中变化的基本单位;它是在数据库上执行的一系列操作(如 SQL 查询), 以完成某种高级功能; 事务的抽象视图 ...
1234…12
avatar
Yuchen You (Wesley)
Articles
119
Tags
61
Categories
8
Follow Me
Announcement
This is my Blog
Recent Post
Mem0 - Building Production-Ready AI Agents with Scalable Long-Term Memory2026-06-26
ZooKeeper: 不发钥匙, 改立公告板的协调服务2026-06-20
Effective context engineering for AI agents2026-06-16
0. 分布式系统编年史: 2000-20202026-06-11
Google Chubby: 解耦控制数据平面的分布式锁系统2026-06-10
Categories
  • agentsys8
  • cs_basic25
  • cybersecurity12
  • eecs2817
  • math9
  • mlsys4
  • network1
  • os1
Tags
reinforcement_learning gc mcts search cyber_security Chubby ml_training context_engineering go history kubernetes algorithm llm_agent agentsys mlsys container system_failure tool_use Consensus gpu pl database prompt_engineering etcd rca structure icmp cloud_native computer_composition os distributed_sys reflection unix self_improvement chaos_system kernel agentic_search operating_system docker planning
Archives
  • June 20266
  • May 202612
  • April 20263
  • March 20262
  • January 20261
  • December 20254
  • November 20253
  • October 20255
Info
Article :
119
UV :
PV :
Last Update :
©2020 - 2026 By Yuchen You (Wesley)
Framework Hexo|Theme Butterfly
welcome to my blog!
Search
Loading the Database