Maths, CS AI CompendiumML 系统设计基石——从客户端-服务器到弹性模式的分布式系统全景指南【免费下载链接】maths-cs-ai-compendiumBecome a cracked AI/ML researcher/engineer with this unconventional textbook covering maths, computing, and ML with intuition.项目地址: https://gitcode.com/GitHub_Trending/mat/maths-cs-ai-compendium本篇文章是 Maths, CS AI Compendium 第 18 章《ML Systems Design》的第一讲系统讲解支撑生产级 ML 系统的分布式基础设施组件客户端-服务器架构、网络协议、DNS、代理与负载均衡、缓存、数据库、消息队列、一致性模型与韧性模式。读完本文你将掌握从训练出一个模型到构建一个产品之间缺失的系统设计能力并能独立分析推荐系统、LLM 推理服务等真实 ML 系统的组件划分与选型理由。为什么每个生产级 ML 系统本质上是分布式系统一个推荐引擎绝不是一个模型文件——它是 API 服务器、特征存储feature store、模型注册中心model registry、缓存层、消息队列与监控栈通过网络协作而成的整体。任何部署到生产环境的 ML 系统本质都是分布式系统。理解系统设计是区分我训练了一个模型与我构建了一个产品的关键能力。这也是顶级科技公司Google、Meta、Amazon、OpenAI系统设计面试考察的核心能否把一个需求拆解为可扩展、可维护、可故障恢复的组件架构。本仓库第 18 章按如下脉络展开本文件01. systems design fundamentals.md给出构件单元02. cloud computing.md 讲云基础设施03. large scale infrastructure.md 讲扩展模式04. ML systems design.md 讲 ML 专属设计05. ML design examples.md 给出完整案例。客户端-服务器架构最基础的分布式模式客户端发出请求服务器处理并返回响应。浏览器客户端向服务器发送 HTTP 请求服务器返回 HTML——这就是最基本的请求-响应循环。请求-响应模型是同步的客户端在等待响应期间处于空闲状态服务器必须先处理完当前请求才能处理下一个。简单直观但会形成瓶颈——客户端空转、服务器串行。无状态服务器服务器不记忆任何历史请求每个请求都携带处理所需的全部信息。其最大价值在于易扩展任意服务器都能处理任意请求因此可以在负载均衡器后面无限横向增加服务器。有状态服务器服务器在请求之间维护状态如用户会话。这会导致扩展困难——同一用户的请求必须路由到同一台服务器会话亲和性session affinity。现代系统普遍的做法是把服务端状态下沉到数据库或缓存如 Redis中让 Web 层保持无状态。从第 13 章操作系统知识看服务器端状态往往与 socket、进程模型强耦合将状态外置到 Redis 的本质是把内存中的会话转换为可被任意无状态实例读取的共享存储这正是 chapter 13 - computing and OS/03. operating systems.md 中进程通信与共享资源思想的工程化应用。网络协议应用层的五个主力第 13 章已覆盖 TCP/IP 分层与 socket 机制见 tcp_ip_layers.svg 与 chapter 13 - computing and OS/03. operating systems.md。系统设计层面真正需要掌握的是应用层协议HTTP/HTTPSWeb 与绝大多数 API 的基础协议。请求方法语义GET读、POST创建/推理预测、PUT更新、DELETE删除。HTTPS 在其上叠加 TLS 加密。REST API详见 chapter 15 - production software engineering/03. codebase design.md完全构建在 HTTP 之上。需要补充的一点HTTP/1.1 一个连接同时只能处理一个请求队头阻塞HTTP/2 通过多路复用解决而在现代推理服务中HTTP 长连接 流式响应已是标配。WebSockets持久化的双向连接。与 HTTP请求→响应→关闭连接不同WebSocket 保持连接常开用于实时流式传输。ML 场景中最典型的应用是LLM token 流式输出模型边生成边把 token 推送给前端用户无需等待完整响应此外也用于实时仪表盘与聊天应用。gRPCGoogle 出品的 RPC 框架基于Protocol Buffers二进制序列化体积与速度均优于 JSON 约 10 倍跑在 HTTP/2 之上。支持流式通信服务端流、客户端流、双向流。其最大价值场景是内部服务间通信——对性能敏感、且服务双方都能维护 .proto 契约的地方。仓库 chapter 15 - production software engineering/05. deployment and devops.md 指出Triton Inference Server 与 TensorFlow Serving 正是通过 gRPC 暴露推理接口的典型。Protocol Buffers契约先行用.proto文件定义消息结构编译后自动生成任意语言Python、C、Go、Java的客户端与服务端代码类型安全、向后兼容与高性能免费获得message PredictRequest { repeated float features 1; string model_version 2; } message PredictResponse { float prediction 1; float confidence 2; } service ModelService { rpc Predict(PredictRequest) returns (PredictResponse); }字段编号 1、 2是向后兼容的关键新增字段只能追加编号删除字段时保留编号不重用即可保证新老版本互不破坏——这比 JSON 的弱类型契约可靠得多。DNS分布式系统的第一道路由DNS 将人类可读域名翻译为 IP 地址。从系统设计角度DNS 还承担三种关键职责基于 DNS 的负载均衡同一域名轮换返回不同 IP将流量分散到多台服务器。实现简单但粒度很粗——DNS 结果会被缓存数分钟到数小时流量无法快速重新平衡。地理路由根据客户端位置返回最近数据中心的 IP。东京用户命中日本数据中心伦敦用户命中欧洲数据中心。故障切换某服务器宕机后DNS 停止返回其 IP新客户端流向健康服务器。但已被缓存的 DNS 记录会让部分旧客户端在TTL过期前持续访问死服务器——这就是著名的 TTL 问题也是故障切换延迟的根源。代理反向代理与 API 网关代理是客户端与服务器之间的中间层反向代理部署在服务器前端客户端只连代理由代理把请求转发给后端服务器客户端完全不知道实际处理者是哪台机器。Nginx与HAProxy是事实标准。它们统一提供负载均衡、SSL 终止在代理处解密 HTTPS向后端转发明文 HTTP、缓存、限流与压缩。API 网关是面向 API 的特化反向代理负责认证、限流、请求路由不同路径 → 不同服务与 API 版本管理。常见选择包括 Kong、AWS API Gateway、Envoy。ML 场景网关站在模型服务器前方认证 API Key、对免费层用户限流、把/v1/predict路由到模型服务器 A、/v2/predict路由到模型服务器 B并统一采集用量指标。这样模型服务本身只需关心推理把鉴权、计费、灰度等横切关注点全部上移给网关。负载均衡当后端有多个服务器时负载均衡器负责把进入的请求分发到各台机器上调度算法算法机制适用场景轮询Round robin按顺序 1, 2, 3, 1, 2, 3… 分发简单公平但不感知服务器真实负载最少连接Least connections分发给活跃连接数最少的服务器请求处理时间差异大的场景有的 LLM 请求只生成 10 个 token有的生成 1000 个加权轮询Weighted round robin容量大的服务器分到更多请求异构集群80 GB 显存的服务器承载 2 倍于 40 GB 的请求量一致性哈希Consistent hashing对请求键哈希同一键恒定命中同一服务器缓存亲和同一用户的请求命中同一缓存、会话亲和、LLM 前缀缓存一致性哈希与第 17 章直接相关相同 system prompt 的请求路由到已持有该 prompt KV-cache 的服务器可复用 前缀缓存/KV-cache省去重新计算 prefill 的算力开销。此外一致性哈希还解决了第 18 章数据库分片中增删节点引发大规模数据迁移的问题见下文分片一节。L4 与 L7 负载均衡L4传输层仅依据 IP 与端口路由。速度快但无法查看请求内容。L7应用层依据 HTTP 路径、头部或请求体内容路由能把/api/chat分流到聊天服务器、/api/embed分流到 embedding 服务器。更灵活但更慢。对 ML 服务L7 的价值在于按模型类型、租户、免费/付费层级分流而对海量 embedding 查询这类纯吞吐负载L4 足以胜任且开销更低。缓存用内存换延迟缓存把高频访问的数据放入快速存储层RAM避免重复计算或重复拉取三种缓存模式Cache-aside旁路缓存懒加载应用先查缓存未命中则从数据库取数、写回缓存、返回结果。最常见缓存只承载实际被访问的数据。Write-through写穿透每次写同时更新缓存与数据库保证缓存始终新鲜但拖慢写路径。Write-back写回只写缓存由缓存异步刷入数据库。写最快但缓存崩溃且未刷盘时会丢数据。驱逐策略缓存满时如何淘汰LRU最近最少使用淘汰最久未被访问的条目。最常用。LFU最不经常使用淘汰访问次数最少的条目。适合存在长期热门项的场景。TTL生存时间条目到期自动失效。适合天然会过期的数据——模型预测结果缓存 5 分钟、特征值缓存 1 小时。CDN 与 RedisCDN内容分发网络面向静态内容图片、JS、CSS的全球分布式缓存100 节点就近服务。ML 领域的一个直接用途把模型权重放到 CDN 上让全球客户端快速下载大体积 checkpoint。Redis业界标准的基于内存的缓存/数据库支持 string、list、set、sorted set、hash、stream亚毫秒延迟。ML 系统中的典型用途缓存模型预测结果、存储会话数据、限流计数统计每个用户每分钟请求数、实时特征在线服务。ML 实战价值对重复输入做预测缓存。大量用户问法国首都是什么时只需计算一次并返回缓存结果。聊天机器人类负载的缓存命中率通常可达 20–40%GPU 成本按比例下降——这是最便宜的扩容手段之一。数据库SQL关系型ACID 与结构化数据SQL 数据库PostgreSQL、MySQL用表、行、列存储数据外键表达表间关系SQL 查询。其核心竞争力是ACID保证原子性Atomicity事务要么全部完成要么全部回滚不存在部分更新。一致性Consistency数据库从一个合法状态迁移到另一个合法状态唯一键、外键等约束恒成立。隔离性Isolation并发事务互不干扰。持久性Durability已提交数据在崩溃后仍存在先落盘再应答。SQL 擅长有关系的结构化数据、复杂查询join、聚合、强一致需求与数据完整性要求高的场景。NoSQL用一致性换扩展性NoSQL 以牺牲部分 ACID 换取扩展性与灵活性键值存储Redis、DynamoDB最简单模型按键快速查找。用于缓存、会话存储、特征存储。文档存储MongoDB、Firestore存 JSON 风格文档schema 灵活每个文档字段可以不同。用于用户画像、商品目录、配置。列族存储Cassandra、HBase为写密集与时间序列数据优化。用于事件日志、指标、分析。图数据库Neo4j存节点与边遍历查询优化。用于社交网络、知识图谱、推荐系统。向量数据库Pinecone、Milvus、Weaviate、FAISS存高维 embedding 并支持近似最近邻ANN检索。是语义搜索、RAG、推荐系统的必需品。CAP 定理分布式数据库的三选二分布式数据库中一致性、可用性、分区容错性三者最多满足其二一致性Consistency每次读都返回最近一次写的结果。可用性Availability每个请求都得到响应即使部分节点宕机。分区容错性Partition tolerance网络分区节点间无法通信时系统仍能运行。由于分布式系统中网络分区不可避免真正的选择是CP分区期间保持一致但可能不可用如 PostgreSQLvsAP分区期间保持可用但可能返回旧数据如 Cassandra、DynamoDB。ML 系统的典型取舍特征存储通常选 AP——一个稍旧的特征值好过没有预测结果模型注册中心必须选 CP——服务错误版本的模型是灾难性事故。分片Sharding把一张表拆到多台机器每个分片持有部分数据哈希分片shard hash(user_id) % num_shards。分布均匀但无法做范围查询。范围分片每个分片持有一段键范围用户 A–G 在分片 1H–N 在分片 2。支持范围查询但可能产生热点比如大量用户名以 S 开头。重新分片问题新增分片会使哈希映射整体失效。一致性哈希把数据迁移量降到最低——加第 n 个分片时只需迁移约 1/n 的键。索引读快的代价是写慢索引是加速查询的数据结构代价是额外存储与更慢的写入。无索引时查询全表扫描为O(n)有索引时定位目标为O(log n)B-tree 索引默认平衡树每个节点含多个键与指针宽节点适配缓存行支持范围查询WHERE age BETWEEN 20 AND 30。多数 SQL 数据库使用 B-tree其树结构基础见 chapter 14 - data structures and algorithms/03. trees.md。哈希索引哈希函数映射键到行位置$O(1)$ 查找但不支持范围查询。适合精确匹配WHERE id 12345。复合索引多列索引CREATE INDEX ON users(country, city)加速按 country、或按 country city 的查询但不能加速只按 city 的查询最左前缀原则——查询必须包含最左列。核心权衡每个索引都加速读、拖慢写每次增删改都要更新索引并占用存储单索引约占表体积 10–30%。不要全列建索引只为高频查询列建。ML 落地特征存储的在线数据库要在实体键user_id、item_id上建索引以支撑毫秒级特征查询实验追踪数据库要在(experiment_id, metric_name)上建复合索引以支撑仪表盘聚合。API 设计REST 约定资源用名词/users、/models动作用 HTTP 方法GET 读、POST 建、PUT 更新、DELETE 删结果用状态码200 OK、201 已创建、400 请求错误、404 未找到、429 限流、500 服务器错误。分页返回列表的接口永远不要一次返回全部。游标分页GET /items?cursorabclimit50或偏移分页GET /items?offset100limit50。大数据集上游标分页更高效偏移分页需要跳过行。版本化路径前缀带版本号/v1/predict、/v2/predict在不破坏现有客户端的前提下演进 API客户端按自身节奏迁移到 v2v1 标记废弃、待流量下降后再下线。结构化错误响应返回足够调试的错误信息{ error: { code: INVALID_INPUT, message: Feature user_age must be a positive integer, details: {field: user_age, value: -5} } }消息队列解耦生产者与消费者消息队列将生产者生成工作的服务与消费者处理工作的服务解耦生产者把消息发进队列消费者就绪时再拉取。没有队列时消费者变慢或宕机会阻塞生产者有了队列生产者发了就跑fire-and-forget队列负责缓冲直到消费者恢复。Apache Kafka分布式、持久化、高吞吐的消息队列。消息按topic组织每个 topic 分区到多个 broker消费者从分区读取并记录自己的offset。Kafka 保证分区内有序且日志持久化后可重放消息。发布/订阅Pub/sub发布者向 topic 发消息所有订阅者各收到一份副本。事件驱动架构的基石新模型已部署这一事件可同时触发监控服务、A/B 测试服务与日志服务。ML 异步推理链路预测请求经 HTTP 进入 → 放入 Kafka 队列 → GPU worker 消费处理 → 结果通过回调或 WebSocket 返回。队列缓冲流量尖峰GPU worker 崩溃也不会丢失请求。一致性模型分布式系统中不同节点对同一数据的视图可能不同一致性模型定义了系统提供的保证层级强一致Strong consistency一次写之后任何节点的后续读都看到新值。推理简单但慢节点间需要协调。最终一致Eventual consistency写后短期内可能读到旧值但最终会读到新值。快无需协调但应用必须容忍脏读。因果一致Causal consistency若操作 A 因果先于 B如写 X 然后读 X系统保证 B 能看到 A 的结果无关操作则允许乱序。读己之写Read-your-writes用户总是立即看到自己的写即便其他用户读到旧值。这是绝大多数应用的最低要求。韧性模式让系统在故障中存活限流Rate limiting限制每用户每时间窗口的请求数防滥用并保证公平访问。常用 Redis 中的令牌桶token bucket或滑动窗口计数器实现。熔断Circuit breaker当下游服务错误率超过阈值时断开停止向其发请求并立即返回降级响应超时后半开发送一个测试请求成功则闭合恢复正常。熔断阻止级联故障特征存储宕机时模型服务器返回无特征的预测而不是每个请求都超时挂死。背压Backpressure系统过载时向上游发出减速信号尽早拒绝多余请求429 或 503客户端配合指数退避重试而不是一边接收一边失败。指数退避重试Retry with exponential backoff失败后等 1 秒重试再失败等 2 秒、4 秒、8 秒……并加入抖动jitter防止所有客户端同时重试形成惊群效应thundering herd。幂等性Idempotency同一操作执行两次与执行一次效果相同。PUT /user/123 {name: Alice}是幂等的把名字设两次没坏处POST /payments不是重复扣款是事故。让操作幂等重试才安全。本讲与第 18 章其他文件的衔接本文件是第 18 章的构件单元层。下一步按顺序展开cloud computing.mdIaaS/PaaS/SaaS/FaaS 分层、AWS/GCP 主力服务、容器与 Kubernetes、成本管理——把本讲的组件放到云上租赁与编排。large scale infrastructure.md一致性哈希、数据分区、弹性伸缩等规模化模式。ML systems design.mdML 生命周期、特征存储、模型注册中心、A/B 测试——把通用组件组装成 ML 专有架构。ML design examples.md推荐、搜索、广告、反欺诈等完整设计案例。同时本讲与仓库其他章节形成闭环网络细节可回看 chapter 13 - computing and OS/03. operating systems.mdTCP/IP、socket、TLSREST/gRPC 工程实践见 chapter 15 - production software engineering/03. codebase design.md模型服务部署与 Triton/TorchServe 见 chapter 15 - production software engineering/05. deployment and devops.md而负载均衡、缓存、KV-cache 与前缀缓存在 LLM 推理中的落地细节可在 chapter 17 - AI inference/03. serving and batching.md 与 chapter 17 - AI inference/01. quantisation.md 中继续深挖。【免费下载链接】maths-cs-ai-compendiumBecome a cracked AI/ML researcher/engineer with this unconventional textbook covering maths, computing, and ML with intuition.项目地址: https://gitcode.com/GitHub_Trending/mat/maths-cs-ai-compendium创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考
