1. 这份笔记不是“速成宝典”而是系统设计能力生长的土壤“system-design-notes”——光看这个标题很多人第一反应是又一份面试突击材料点开就背“三高架构”“CAP定理”“分库分表口诀”我见过太多人把这类笔记当通关秘籍刷完几十页PDF一到真实场景就卡壳用户量翻倍后服务雪崩了怎么定位瓶颈缓存穿透和缓存击穿到底该用布隆过滤器还是空值缓存为什么一致性哈希在节点增减时要加虚拟节点这些不是靠死记硬背能解决的。这份笔记真正的价值从来不在“抄答案”而在于它是一套可生长、可验证、可迭代的思维脚手架。它不告诉你“应该用Redis”而是逼你问自己“如果不用Redis用本地内存定时同步行不行瓶颈在哪数据不一致的容忍窗口是多少毫秒”它不罗列“限流算法有令牌桶、漏桶”而是让你亲手画出请求在网关层被拦截的完整链路标出每个环节的耗时、失败率、重试策略——直到你看见那个被忽略的线程池阻塞点。关键词里反复出现的“notes”不是指随手记下的碎片而是指经过真实压测、线上故障复盘、架构评审后沉淀下来的决策痕迹为什么选Kafka而不是RabbitMQ不是因为“Kafka更快”而是因为它的分区机制天然适配我们订单履约系统的事件溯源模型为什么放弃ZooKeeper做服务发现不是因为它过时了而是因为我们在灰度发布时发现其Session超时机制与我们的滚动更新节奏存在不可调和的抖动。这些细节不会出现在教科书里但会决定一个系统是能扛住双十一流量还是在促销开始前半小时就告警满屏。如果你正准备System Design Interview这份笔记能帮你避开“背题式回答”的陷阱如果你已是团队技术负责人它能帮你把模糊的“高可用”要求拆解成可落地的SLA指标、可观测性埋点、降级开关清单。它适合所有想把“设计”从玄学变成手艺的人——无论你是刚写完第一个CRUD接口的新人还是正在为千万级DAU系统做容量规划的架构师。2. 从“Rate Limiter”切入一个被严重低估的边界控制单元Rate Limiter限流器常被当作系统安全的“门卫”但在我经手的十几个中大型项目里它实际扮演的角色远比这复杂得多。它既是流量整形的执行器也是系统健康状态的晴雨表更是业务规则的隐形裁判。很多团队把它简单配置成“每秒1000次QPS”结果在大促期间下游支付服务因瞬时峰值被压垮而限流器本身却显示“一切正常”。问题出在哪根本原因在于限流策略的设计必须与业务语义、资源瓶颈、失败成本深度耦合而非孤立地看请求数。2.1 为什么“QPS”是最危险的限流维度QPSQueries Per Second看似直观但它掩盖了关键差异一次查询可能只读一条缓存也可能触发全量数据库扫描实时计算。我在某电商搜索服务中遇到过典型反例前端将“搜索关键词联想”和“商品详情页加载”共用同一个API入口限流器按QPS统一限制。结果是用户输入“手机”时联想接口返回50个词耗时30ms而点击某个商品后详情页需聚合库存、价格、评价、推荐等7个微服务平均耗时800ms。当QPS达到阈值时限流器粗暴拒绝所有请求导致用户看到的是“搜索无结果”而非“详情页加载慢”。这完全违背了用户体验优先原则。解决方案是按业务动作分层限流对联想接口设QPS上限对详情页接口则改用并发数Concurrency限制——因为它的瓶颈在于下游服务的连接池和CPU而非网络带宽。我们最终在网关层部署了两套独立限流规则并通过OpenTracing的Span Tag标记请求类型让限流器能精准识别。2.2 滑动窗口 vs 固定窗口不只是精度问题更是故障恢复逻辑的体现固定窗口Fixed Window实现简单但存在“窗口临界点突刺”问题假设窗口为1秒限流100次。若第0.999秒来了100次请求第1.001秒又来100次系统瞬间承受200次压力。滑动窗口Sliding Window通过维护时间戳队列解决此问题但代价是内存占用随QPS线性增长。这里的关键洞察是窗口选择本质是故障恢复策略的选择。固定窗口的突刺对应的是“允许短时过载但需快速恢复”的业务场景如社交平台点赞短暂延迟可接受而滑动窗口的平滑则服务于“零容忍抖动”的核心链路如金融交易下单。我们在支付网关采用滑动窗口但做了关键优化不存储每个请求时间戳而是按毫秒级分桶如[0-9ms]、[10-19ms]每个桶计数。这样内存占用从O(N)降至O(100)且精度满足业务需求支付请求间隔通常10ms。实测下来这套方案在百万级TPS下单节点内存仅增加12MB远低于原始滑动窗口的400MB。2.3 分布式限流的终极难题不是算法而是“谁来决策”单机限流容易分布式限流难。常见方案如RedisLua、Sentinel、自研Token Bucket集群但真正棘手的问题是当多个服务实例同时向中心限流器申请令牌时如何避免“脑裂”导致的总配额超发我们曾在线上遭遇过一次严重事故某次Redis主从切换期间两个从节点短暂认为自己是主节点各自发放令牌导致实际QPS突破设定值300%。根因不是算法缺陷而是缺乏强一致的决策仲裁机制。最终方案是引入Raft协议构建轻量级限流协调器Limiter Coordinator所有令牌申请必须经Raft日志复制达成共识后才生效。虽然增加了5-8ms延迟但换来的是100%的配额准确性。更重要的是我们把协调器的健康状态作为服务启动的前置检查项——如果协调器不可用服务自动降级为保守的单机限流模式并上报告警。这个设计让系统具备了“优雅退化”能力而非直接崩溃。3. 一致性哈希不是“负载均衡神器”而是数据亲和性的精密编排一致性哈希Consistent Hashing常被宣传为解决分布式缓存/数据库扩容的银弹。但在我参与的三个大规模缓存迁移项目中它暴露的最大问题是过度强调“节点增减时数据迁移最小化”却忽略了“数据访问局部性”这一更关键的业务约束。比如某社交App的Feed流服务用户关注列表存储在Redis Cluster中。按用户ID做一致性哈希理论上节点扩缩容时只有约1/N的数据需要迁移N为节点数。但实际运行中我们发现热点用户如明星账号的粉丝数据集中在少数几个节点导致这些节点CPU长期95%以上而其他节点闲置。问题根源在于一致性哈希保证了“数据分布均匀”但没保证“访问请求分布均匀”。粉丝读取操作天然具有强局部性——一个明星的粉丝往往同时在线刷Feed请求集中爆发。3.1 虚拟节点不是为了解决哈希环稀疏而是为了打破“热点固化”虚拟节点Virtual Nodes常被解释为“缓解哈希环稀疏导致的数据倾斜”。这没错但更深层的作用是它把“物理节点”和“数据分片”的映射关系解耦为动态调整提供了操作空间。我们不再把160个虚拟节点静态绑定到8台物理机器而是设计了一套权重驱动的虚拟节点分配算法。每台物理机根据其CPU、内存、网络带宽实时指标动态计算权重如CPU使用率30%时权重1.570%时权重0.5。调度器据此重新分配虚拟节点让高权重机器承载更多虚拟节点低权重机器减少承载。这个过程全自动每5分钟刷新一次。上线后热点节点CPU均值从92%降至65%且扩容新机器时旧节点无需手动迁移数据——调度器自动将部分虚拟节点迁移到新节点数据随之自然流动。这比传统的一致性哈希扩容方案需人工计算迁移范围、停写、同步、切流快10倍且零停机。3.2 哈希环的“断裂修复”当节点宕机时流量不该全砸向邻居标准一致性哈希中一个节点宕机其负责的哈希环区间会由顺时针下一个节点接管。这看似合理但实际会造成级联雪崩。例如节点C宕机其流量全涌向节点D若D本就接近容量上限可能立即触发OOM进而导致D也宕机流量再涌向E……形成多米诺骨牌。我们的解决方案是引入渐进式承接机制当监控发现节点C失联协调器不立即将其区间划给D而是先启动一个“影子副本”——在D上预热C的10%数据基于最近访问频次Top N并设置一个“承接系数”初始值为0.1。随后每30秒系数增加0.1直至1.0。同时所有客户端SDK内置“故障感知”逻辑当向C发起请求超时会按当前承接系数将相应比例的请求重定向到D其余请求直接返回降级响应如缓存旧数据或空列表。这确保了流量冲击被平滑吸收给了D足够的缓冲时间进行资源扩容。实测表明该机制使节点故障恢复时间从分钟级缩短至秒级且无任何下游服务告警。3.3 一致性哈希的边界它无法解决“跨分片JOIN”这才是真正的架构分水岭一致性哈希擅长解决“单Key路由”但现代业务中大量场景需要“多Key关联”。比如电商订单查询需关联用户信息、商品信息、物流信息而这些数据按不同Key用户ID、SKU、运单号分布在不同分片。此时一致性哈希反而成为障碍——它让数据物理隔离却放大了逻辑关联的复杂度。我们曾尝试用“复合Key哈希”如user_id:order_id强行路由结果导致数据分布极度不均一个用户可能有上千订单。最终转向分层架构核心交易链路坚持单Key路由保障性能而分析型查询如“某用户所有订单的物流状态”则通过CDCChange Data Capture将各分片数据实时同步至OLAP引擎如ClickHouse在分析层完成JOIN。这个决策不是技术妥协而是清醒认知一致性哈希是优秀的“数据分发协议”但不是万能的“业务建模工具”。它的适用边界必须由业务读写模式定义而非技术惯性驱动。4. System Design Interview的真相考的不是“画架构图”而是“拆解模糊需求”的能力System Design Interview常被误解为“现场画出Twitter或Uber的高可用架构”。但过去三年我作为多家一线公司面试官参与的200场面试中真正淘汰候选人的几乎都不是因为画不出“消息队列”或“CDN”而是在需求澄清阶段就暴露了致命缺陷。比如当题目是“设计一个短链接服务”90%的候选人立刻开始讨论“用Base62编码”“选MySQL还是MongoDB”却没人问“短链接的预期QPS是多少读写比例如何链接有效期是永久还是7天是否需要统计点击来源如微信/微博这些统计是实时还是T1”——这些看似琐碎的问题直接决定了技术选型的生死线。一个QPS 100的内部工具和QPS 10万的公共API架构复杂度天壤之别。4.1 需求拆解的“五问法”把模糊描述转化为可测量的约束我总结了一套需求拆解的“五问法”每次面试必用也写进了笔记的核心章节规模量级Scale不是笼统说“用户很多”而是明确数字。“支持1亿用户”毫无意义必须问“DAU多少峰值QPS单次请求平均数据量存储总量年增长多少TB”——这些数字决定是选单机Redis还是集群是用SSD还是HDD。质量属性Quality AttributesSLA不能只说“高可用”。必须量化“允许多少分钟宕机/年数据丢失容忍多少条读写延迟P99是多少毫秒一致性要求是强一致、最终一致还是可容忍1秒延迟”——这直接决定是否引入分布式事务、是否需要多活架构。功能边界Scope明确“做什么”和“不做什么”。例如“短链接服务”是否需要防刷是否支持自定义域名是否提供API供第三方调用——这些功能点会指数级增加复杂度必须在设计前锁定。演进路径Evolution问“未来6个月最可能的扩展方向是什么”——如果答案是“要接入微信小程序”那架构必须预留OAuth2.0集成点如果是“要支持视频上传”则存储层必须兼容对象存储。好的设计不是一步到位而是为已知演进留出最小改造成本。约束条件Constraints技术栈必须用Java、团队能力是否有K8s运维经验、合规要求GDPR金融等保——这些现实枷锁往往比技术理想更重要。我曾否决过一个“完美”架构方案只因团队没有Flink运维经验强行上实时风控会导致线上事故频发。4.2 白板上的“错误”才是最有价值的面试信号面试中我从不期待候选人给出“标准答案”。相反我刻意观察他们如何处理错误。比如当候选人自信满满地说“用ZooKeeper做分布式锁”我会追问“如果ZK集群网络分区客户端获取锁后长时间收不到心跳响应是该等待还是超时放弃”——这个问题没有唯一解但能看出他是否理解CAP权衡。另一个经典场景候选人设计了一个“用Redis缓存用户资料”的方案我问“如果用户头像更新了如何保证缓存及时失效”他答“更新DB后删缓存”我就接着问“如果删缓存失败怎么办DB更新成功但缓存残留用户看到旧头像这个风险你能接受吗有没有更可靠的方案”——这时真正有经验的人会提出“双删策略订阅Binlog异步清理”而新手往往卡壳。这些“卡壳时刻”恰恰是评估工程素养的黄金窗口。笔记里专门有一章记录了27个这类高频“陷阱问题”每个都附带真实线上事故案例和修复方案不是教你怎么答而是教你如何思考。4.3 从“面试题”到“生产代码”那个被忽略的“可观测性设计”几乎所有System Design Interview都止步于“画出组件框图”但真实系统上线后最大的挑战从来不是“能不能跑”而是“为什么跑得慢/错”。因此我的笔记强制要求每个设计方案必须包含可观测性Observability设计子项。例如设计一个订单服务除了API、DB、MQ还必须明确Metrics定义3个核心指标——订单创建成功率P99 99.99%、平均创建耗时P95 200ms、库存扣减失败率0.1%告警。指标采集点Service Mesh Sidecar or Agent、存储Prometheus or InfluxDB、告警阈值基于历史基线动态计算。Logging关键路径如“库存校验→扣减→生成订单”必须打结构化日志包含trace_id、span_id、business_id订单号、error_code。日志级别分级INFO记录流程WARN记录业务异常ERROR记录系统故障并规定日志保留周期审计类365天调试类7天。Tracing全链路追踪必须覆盖所有跨服务调用采样率按环境区分开发环境100%生产环境0.1%。特别标注“慢调用”判定逻辑如DB查询100msHTTP调用500ms。这套设计不是锦上添花而是生存必需。去年我们一个新上线的优惠券服务在灰度发布时P95延迟突然飙升至2秒。由于提前埋好了上述可观测性5分钟内就定位到是Redis Pipeline批量操作在特定数据量下出现阻塞而非盲目重启或扩容。这种能力无法靠背题获得只能在一次次真实故障中淬炼出来——而这正是笔记最珍贵的部分。5. “Notes”的本质对抗遗忘的工程实践而非知识堆砌“notes”这个词在标题里看似平淡却是整份材料的灵魂。它不是维基百科式的知识汇总也不是GitHub上star数过万的模板仓库而是一个持续对抗遗忘、沉淀决策上下文的工程实践。我见过太多团队架构评审会上激烈争论后拍板的方案三个月后就没人记得当初为何放弃方案B而选方案A线上故障复盘报告写得洋洋洒洒但同样的错误半年后再次发生。问题不在于不记录而在于记录的方式错了——它们被塞进Confluence的某个角落标题是“XX系统V2.0设计文档”内容是干瘪的架构图和接口定义唯独缺少最关键的“为什么”。5.1 决策日志Decision Log让每一次技术选型都有迹可循笔记的核心模块之一是“决策日志”。它不是简单的“选了什么”而是严格遵循RFC 863格式简化版每条记录包含日期与版本2023-10-15 v1.2决策主题选用Apache Kafka而非AWS Kinesis作为事件总线背景订单履约系统需支持跨区域数据同步现有SQS无法满足顺序性和回溯需求选项分析Kinesis托管服务运维成本低但跨区域复制需额外配置且Shard扩容有延迟5分钟Kafka自建运维复杂但通过MirrorMaker2可实现亚秒级跨区域同步且分区数量可实时调整决策依据业务SLA要求“订单状态变更1秒内同步至海外仓”Kinesis的扩容延迟不满足此要求未选选项的风险Kinesis方案需投入2人月开发定制化跨区域同步组件且无法保证1秒SLA后续验证指标上线后监控“跨区域事件延迟P99 800ms”连续7天达标则关闭此决策项这种记录方式让新人接手时不必重走一遍选型弯路也让架构师在季度复盘时能客观评估当初决策是否依然有效。我们甚至将决策日志与Git Commit关联——每次代码提交都需注明影响的决策编号如“#DL-23”形成技术决策与代码实现的双向追溯。5.2 故障复盘卡片Postmortem Card把“事故”变成“资产”另一核心模块是“故障复盘卡片”每张卡片严格遵循Blameless Postmortem原则聚焦系统而非个人。以一次著名的“支付超时”事故为例故障摘要2023-08-22 14:30-15:15支付成功率从99.98%骤降至82.3%影响订单量12,450笔时间线精确到秒14:29:47 监控发现Payment Service CPU达98%14:30:12 熔断器触发拒绝新请求14:32:05 运维手动扩容2个Pod但CPU未下降14:35:20 发现DB连接池耗尽连接数达2000上限200根因分析上游订单服务在促销活动开始时未按约定开启“削峰填谷”开关导致瞬时创建订单请求激增10倍Payment Service的DB连接池配置maxPoolSize200未随流量增长动态调整且无连接泄漏检测机制改进措施短期将连接池上限提升至1000并加入连接泄漏告警空闲连接5分钟未归还中期在订单服务接入流量控制网关强制执行削峰策略长期推动建立“容量基线”制度所有服务上线前必须提供QPS/TPS压测报告责任人与截止时间DBA组连接池优化- 2023-09-01SRE组流量网关- 2023-09-15这些卡片不是为了追责而是为了让“同样的坑永远只踩一次”。我们要求所有工程师每月至少阅读2张复盘卡片并在周会上分享启发。结果是同类DB连接池问题在后续12个月零复发。5.3 “Notes”的进化从静态文档到活的系统设计知识图谱最后这份笔记正在演变为一个活的知识图谱。我们用Neo4j图数据库存储所有实体服务Service、组件Component、决策Decision、故障Postmortem、指标Metric、负责人Owner。节点间的关系清晰定义Service-[USES]-ComponentDecision-[ADDRESSES]-RequirementPostmortem-[ROOT_CAUSE]-Component。当新工程师入职系统会自动推送与他负责服务相关的所有决策日志和故障卡片当某组件如Redis出现新漏洞公告系统会反向查询所有依赖它的服务并提醒相关负责人检查。这种动态关联让“notes”不再是尘封的PDF而成了团队集体记忆的神经中枢——它不告诉你答案但它确保你永远不会在同一个地方摔倒两次。这才是系统设计能力真正扎根的土壤。