资源介绍
视频数量：12个
总时长：1小时37分
课程介绍：
资深工程师的分布式系统设计评审课
想象一下这个场景：你坐在会议室里，隔壁团队的小王正在讲他的新架构。微服务、消息队列、读写分离，听起来很漂亮。然后他打开延迟指标——平均四十毫秒。不错啊。但你脑子里有个声音在问：p99是多少？扇出是多少？故障的时候这条链路还活着吗？
如果你能在别人看到PPT之前就嗅出哪里要出问题，那你需要的就是这门课教的东西。
这门课的主张很直接：评审设计和做出设计是两码事。设计者天然乐观，他们看不见自己假设里的裂缝。评审者要做的事恰恰相反——在灾难上线之前，把那些裂缝挖出来。课程一共十二讲，分成三个层次来训练这项能力。
一、评审者的底层思维
一开篇就讲清楚四种角色：提案者、评审者、决策者，以及那个隐藏在角落里、大家其实都在等他拍板的"影子决策者"。评审者最容易犯的错叫"共同作者失败模式"，就是忍不住帮别人改方案，结果把自己的偏见塞进去，反而漏掉了提案者真正的盲区。这一讲还把评审意见分成四个级别：Blocker意味着上线就会丢数据或宕机，Major是高负载或故障下会出问题，Advise是有更好的方案但由提案者决定，Nit只是个人偏好。区分这四种级别，比提出多少反对意见都重要。
二、数字与理论武器
一份设计稿拿在手里，光靠直觉是不够的。第二讲教你怎么用数字否决设计——吞吐量、延迟、容量预算，不是PPT上的装饰，而是评审的硬标准。第三讲是"一致性阶梯"，从强一致到最终一致之间的每一级都有适用场景，混用级别是设计评审里最常见的陷阱之一。紧接着是CAP和PACELC，讲清楚分布式系统那些不可能三角，而不是死记硬背定义。共识算法单独拿出一讲来讲Paxos和Raft，重点不是怎么实现，而是提案者在描述一致性保证时有没有说人话。时间、时钟和锁这一讲戳的是分布式系统里最隐蔽的那类bug——两个节点的时间漂移，租约过期了还在写数据。事务和隔离级别讲的是数据库那一层，评审者必须一眼看出提案者用的是读已提交还是可重复读，会不会出现幻读。复制和分区这一讲是数据分布的核心：主从、多主、无主、副本因子，读写落在哪里，谁来负责一致性边界。
三、把知识用在刀刃上
故障想象力这一讲专门训练一种习惯——打开方案之后先想"这个东西怎么挂"。网络分区、节点宕机、磁盘写满、回滚链路断了、依赖的下游超时，每一种都要在评审阶段想到而不是线上复现。性能、队列和并发那一讲用真实数据说话：平均值会骗人，中位数好看不代表尾部好看。课程给出一个反直觉的结论——你的页面有一半请求落在一个你以为是罕见边缘情况的延迟区间里，因为扇出是尾部的倍增器，而微服务架构本身就是扇出机器。对冲请求、负载削减这些防御手段，是评审者用来检验架构弹性的话术。
最后两讲是综合演练。完整评审那一讲把前面所有知识点串成一个完整流程，从开场提问到记录结论，每一步都有章法。压轴讲的是这门课最容易被忽略的部分——人的功夫。怎么提反对意见而不让提案者防御性反弹，怎么在政治高压下坚持专业判断，怎么区分"我不同意这个方案"和"我不喜欢这个人"，这些在真实团队里往往比技术细节更难。
学完这门课，你拿到一份设计稿不会只问"这个方案酷不酷"，而是会问：故障转移链路在哪？尾部延迟多少？一致性边界是什么？提案者自己测过什么、没测过什么？你会开始用一套更锋利的语言去提问，而这些问题的答案，决定了方案上线之后是平稳运行还是半夜被叫起来修故障。
适合谁来学呢？写了五年代码以上、开始参与架构评审的后端工程师，刚晋升的Tech Lead和Staff Engineer，以及那些在团队里扮演技术守门员但又苦于说不清楚哪里有问题的人。不需要你发明过Paxos，但需要你能在提案者说"我们的系统是最终一致的"时追问一句"多久最终"。