Scott Shi指分布式时钟与Redlock存致命缺陷 易致数据覆盖

Scott Shi指分布式时钟与Redlock存致命缺陷 易致数据覆盖 CAP定理中的网络分区是无法规避的客观物理现实，系统若盲目信任不可靠时钟或在分布式锁中缺失防护令牌，在进程停顿冲击下必然导致致命的数据覆盖与脑裂。 主讲人 Scott 结合自身在工业界主导系统及面试逾百人的丰富阅历，剖析了面向对象建模与分布式系统设计的侧重点差异、各职级的考核信号与致命设计红线。随后，内容深入经典著作《DDIA》第八章的核心命题，系统性拆解了分布式现实中的暗礁——包括网络丢包与分区、不可靠的时钟漂移、LWW 数据覆盖陷阱以及 GC 停顿对分布式锁造成的破坏。讲座最终梳理了半同步模型与崩溃恢复模型等关键假设，强调以共识机制、防护令牌与大道至简的工程哲学应对不可靠组件。 系统设计面试的核心在于业务语境与工程权衡（Trade-off），高级别技术岗位具备一票否决权，重点排查常识性设计红线（如密码明文存储、关系型数据库存大视频或用最终一致性组件处理金融交易）。 (10:30) 网络分区（P）在分布式系统属于客观物理故障而非可选方案，业界对 CAP 定理的“选 CA”属常见误读，架构师必须在分区必然发生的前提下在可用性（A）与一致性（C）之间做出妥协。 (50:00) 物理日历时钟存在不可控漂移与时间回跳，简单依赖 LWW（最后写入为准）会导致业务数据严重损坏；因进程停顿（如 GC）威胁，基于租约的锁机制（如 Redlock）必须引入单调递增的 Fencing Token 才能保证数据安全性。 (70:00) 工业级商用数据中心的核心哲学在于“利用不可靠的廉价硬件构建高可靠系统”，现实工程系统设计普遍建立在“半同步时序模型”与“崩溃恢复（Crash-Recovery）模型”两大基准假设之上。 (97:15)

讲师 Scott Shi 指出，现代分布式系统架构的核心在于业务权衡与面向不可靠现实的容错设计，工程师必须破除单一工具思维，以简洁优雅的模型和严谨的系统假设来应对现实缺陷。 架构选型的业务权衡与职级考察核心 (3:00) 系统设计并不存在万能的标准答案，其本质全在于权衡取舍（Trade-off），且强力受业务逻辑驱动。例如 Amazon DynamoDB 的架构设计选择针对 P99/P99.9 延迟极限优化，并在购物车冲突时宁可容忍重复项也绝不丢弃商品，完全是由电商商业场景决定的。现代互联网巨头重点考察支持海量并发与高可用容灾的分布式应用，而非单机面向对象建模。 在面试评估中，初级工程师主要考察计算机基础与潜质，中级工程师要求掌握架构拆解与基础权衡，而高级工程师及以上级别则要求端到端把控与商业理解。高级面试中系统设计具备一票否决权，踩中常识性红线（如密码存明文、关系型数据库强塞大媒体文件、在金融转账中错用 Cassandra 或 Redis 这类弱一致性组件）或在团队协作与沟通表达上表现狂妄，都会导致直接被拒。 不可靠现实与商用分布式系统的构建哲学 (40:00) 科研超算依赖造价高昂的高可靠硬件与强依赖检查点，节点损坏即中断；而商用数据中心则完全基于廉价通用硬件构建。在万台机器的扩展规模下，基于生日悖论的概率效应，节点或硬件故障已成为常态。因此商用系统的核心哲学是在不可靠组件之上构建可靠系统。 现实中客户端无法区分超时是源于请求丢包、节点崩溃、响应丢失还是几分钟的垃圾回收（GC）停顿。系统不能消除网络分区，CAP 定理中的分区是客观物理事实而非可选项，架构只能在一致性与可用性间妥协并设计冲突解决机制。此外，现代网络为了突发流量和极致吞吐主动牺牲了延迟确定性，自动驾驶等对毫秒级确定延迟有刚性要求的领域，必须依赖本地实时操作系统（RTOS）而非云端远程控制。 时钟漂移风险与基于多数派的共识裁决 (65:00) 依赖本地时钟是分布式系统中最危险的假设。日历时钟易受 NTP 调整而发生跳跃和无上限漂移，直接采用“最后写入为准”（LWW）机制极易导致新写入数据被旧数据静默覆盖。为此，Google Spanner 耗费数年通过机房多组原子钟、GPS 硬件及 TrueTime API 将时钟误差窗口压缩在 7 毫秒内来解决因果时序。在普通分布式锁场景中，仅凭本地时间租约会因进程暂停而失效，必须依赖 ZooKeeper 等单调递增的防护令牌（Fencing Token）并在存储层做版本拦截。 在面对网络分区与不可靠节点时，系统无法确信孤岛状态，必须依赖共识算法（如 Raft、Paxos、ZooKeeper），通过 Quorum 多数派投票仲裁来定义唯一的“真相”，以避免脑裂发生。若网络中混入恶意伪造数据的叛徒或遭遇辐射位翻转，则需引入高通信开销的拜占庭容错机制，或类似区块链工作量证明的去中心化共识手段。 工程基准模型与大道至简的设计理念 (93:30) 在系统时序与崩溃模型中，完全同步模型脱离现实，纯异步模型限制过大以至于无法实现可串行化事务。现代工程普遍采用“半同步模型”（平时表现良好但承认偶发延迟超标）与“崩溃恢复模型”（假定节点故障后会携带可靠持久化数据重新上线）的黄金组合作为底线。 在数据中心内部，随机独立的硬件故障容易通过冗余替换解决，而具有强相关性的软件共因故障（如驱动程序 Bug 或全量发布事故）才是引发集群雪崩的致命隐患，必须依靠灰度金丝雀发布来切断扩散。正如 Linux 的管道组合与 Git 简洁的提交 DAG 架构，顶尖的系统设计遵循 KISS 原则，注重关注点分离，避免陷入“手里拿着锤子看什么都是钉子”的狭隘思维。 系统设计无法依靠突击速成，而需通过螺旋上升式复习并深挖代表性组件。针对不可抗力造成的数据中心级物理摧毁等极端场景，现存工程模型依然存在假设边界与恢复局限。

[0:00] Scott Shi: 从广义上来说，我不觉得任何人是 System Design 的 Expert，我自己也绝对不是什么 Guru 或 Expert。 [0:00] Scott Shi: He is very honest about things he doesn't know. [5:00] Scott Shi: It's all about trade-off. [7:30] Scott Shi: It's very okay to not know something, just be honest. [20:00] Scott Shi: If you only hold a hammer, everything looks like a nail. [20:00] Scott Shi: It works now, does not mean it works forever. [30:00] Scott Shi: 做最坏的打算，抱最好的希望 [40:00] Scott Shi: Always something is broken at any single point [40:00] Scott Shi: Build a reliable system from unreliable components [50:00] Scott Shi: 很多人去背 CAP，说什么三者不能兼得，所以你可以选 CA、不能选 P，这是从根本上就理解错了。CAP 里的 P（Network Partition）是一个物理客观条件（Condition），根本不是一个选项！你不能说‘如果我不得心脏病，我就能活到 140 岁’——心脏病是一个可能会降临的客观故障。当网络分区必然发生时，你只能做妥协：你到底是要偏向可用性（A），还是要偏向一致性（C）？ [65:00] Scott Shi: Clock is one single most dangerous component you can assume in the distributed system [90:00] Scott Shi: The majority is defined truth

[0:00] 现在应该开始录音了好开始录音了好呃然后呃我们再说一下就是如果我讲太快的话我能看到一个group chat如果讲太快的话你可以说就是打一些问号表示你这块不理解然后如果你觉得这块有问题的话直接在这块直接打问题或者是直接打一个数字然后这样的话你就先是声明了一个位置然后会在合适的时候停下来然后解答问题然后就是这样子好Systems and Interview Tips,我自己是在Safety Data Team,我之前的Conduct大概120个150个Interview,有些的话是有点像Speed Data Interview,所以太小了,我也很难记住,就是20分钟飞快的Interview一下一个Candidate,然后大概有40个System Design Interview,然后Safety Report 我是Funding Engineer 或Safety Report 是我Deliver的嗯就是general speaking 我不觉得任何人是system design 的 expert 我definitely not a system design expert 但是我觉得已有的材料都很糟糕,市面上已有的材料相对来说比较糟糕一点,有的误导性很强,并且Distribute System没有很好的教材,教材Design Data Intensive Application是一个非常不错的教材,我是二月份开始读,大概就是到现在基本读完了,然后花了很多时间,可能花了近250个小时以上读完了,然后读的相对比较细一点,我觉得是非常好的一个入门教材,但是如果说你说问一下System Design怎么读的话,我觉得首先要可以可以把这个教材作为入门,然后我个人的话会读一些paper,比如说,比如说读那个Spider的paper,DynamoDB的paper,然后我自己也读Hacker News,Hacker News上有一些东西讲的很不错,就是其他的developer写的有时候很不错,但是它上面质量比较参差不齐一点。这个是我的观点,然后并且我observ'd到,就是说我觉得很,就是我从来没有见人说他自己是system design 的 guru 和 expert,即使是我之前在 Southforce 的时候,我有一个就是我们同时有个 Distinguished Engineer,Southwell只有两个Distinguished engineer,他有35年的业界经验加一个PhD。他之前讲过很多很有趣的地方,比如说他怎么建那个Gym Grade,就是那个Missing the Jim Grade,Legend missing the Jim Grade,和那个说写DB paper,stone breaker,他讲过很多很有趣的细节。然后我从他身上能学到很多东西,但是其中有一点就是非常humble,然后他honest about things he don't know,他其实不知道很多问题,很多东西他不知道,但是他会说不知道什么,并且一些high level philosophy有很有趣的地方。就是我从那个就是比较一个distinguished engineer,就非他们distinguished engineer,其实我觉得他圈子也比较小,就比较有趣的一点,学到的东西。所以我觉得这个其实很难,我觉得可能很牛的人的话,可能时间更忙一点,可能花的时间比较少一点,在这个上面。我觉得西面没有很好教材,所以我愿意花点时间去来立的这个effort。会有很多问题我会有很多地方理解不够深入所以如果大家觉得这块理解有问题的话就直接提出来直接不会提出来然后我会尽量的尽量的花时间改造,然后自己也 improve,因为我觉得这个,我觉得 one of the most incentive for myself is,就是发现我知识的短板和错误的理解,然后把它改造。然后同时的话,我committed 10个小时,比如说committed 10个小时,20个小时,去 delve deep into one of the technology and learn.所以System Design是一个open question,有Design Slack这种distribute system application类型,有Design Parking Lot这种有点OOP的感觉,没有绝对的好与坏,我觉得这个没有绝对好与坏,但是从我的observation来说,我过去也面试过大概40家公司,从我的observation来说,Design Parking Lot的话,我感觉更像是一些传统的公司面试的,就不是那种互联网,互联网公司常见的面试就是Design, Slack, Uber,然后还有的人喜欢就是就是Parkerlot OOP这块其实也非常复杂,API这块有的这个model design非常复杂,不是一个很简单的问题,但是我们这块的话focus上的是design,Uber, Slack这种distributed system application 可能会不服务上parking lot 但是那块也会比较好奇 如果你对那块感兴起来你可以从其他地方学的然后如果我们说design distributed system application的话 [5:00] 一种share nothing architecture这个和Mateframe computer是不一样的比如说Mateframe computer是现在很多那种就是bank transaction它是用COBO所以这一次新冠疫情以后呢就是新冠疫情以后呢就发生了一件很有趣的事情就是File那个失业人数的人太多了但是那个失业人数的系统是用COBO写的导致他们找不见COBO programmer据说average pro-COBO programmer大概59岁了他们早不见这个Cobo Programmer并且也没有新的人愿意学因为Cobo Programmer的Average的位置只有好像不到9万还是8万就是他们平均industrial experience是more than 30 years但是位置不到9万所以就出现了一个很大的人才缺口所以这个就是有趣的话就是有趣的一些信息然后System Design是没有standard answer的It's all about trade-off这块nongo和go非常重要然后你的assumption也非常重要因为你所有system design都是trade off你可能需要a的时候你就没有b要瓜得瓜要豆得豆你不可能几个兼顾然后system design是非常reflect那个candidate experience的它是reflect understanding industry所以很难说你通过lead coding这种就是自己一个人独自practice下功夫就可以学会了比较难你需要很多时候就是好的system design你需要去不同的discuss然后不同的就不停的去参加discussion其他reading和conferencebringstone然后practice然后这个的话其实需要聪明人一起练习,一起practice我觉得从过去来说,我觉得读书是你补充知识短板的一方面但是我觉得你和你非常passionate,smart people discuss的时候可以让你非常醍醐那种感觉,学到很多东西然后就是理解到非常听过观点那种就是能理解到很多东西能打开了一个新的世界的感觉非常有趣这不是我一个人的感觉如果看历史上很多科学家发明了新的东西然后他们也是也是这样子这个不是说 individual experience这个是 a proven way to innovation然后 system design 因为它是 en question所以你需要theoretical study和unpractical experiments你单读study theory是很难够的你实际上还需要更多的实验然后system design 如果从interview的角度来讲的话包括正常的system designit's all about business sense如果你读dynamoDB的话你发现dynamoDB我觉得是近几年相对来说system design非常好的一个paper了但是也其实有十几年以上了你看它的话它其实很大的篇幅它System Design就是Oriented Business比如它一直花了很多时间解释什么是P99P99.9然后为什么要优化在P99.9为什么它这个DenmoDB它的优化是我可以在这个Shopping Cart里面有Duplicate Item但我不可以无缘无故的Remove Item所以就是这个它解释了很多这个方面它其实整个DB设计是跟Business Sense相关的然后在System Design Interview包括你System Design的那个Meeting你比如说你要设计一个新的System你怎么样articulate problem matters你怎么样描述这个问题你怎么样描述给你的同事你怎么样articulate problem非常重要的如果你没办法去articu the problem那你就没办法把你的system design解释给别人从历史上的商业来讲好的system design不一定活到了最后不好的system design它可能通过更好的商业宣传可以回到最后所以说总体来说你system design的成功一方面是你的decision rightdecision right然后另一方面的话你也需要有一个非常好的articulate problem的能力也有非常好的business sense好的system design没有活到最后的例子很多我记得intel还有什么芯片有几个例子我具体忘了细节 反正这个有很多所以你其实system design是关乎你的technical skill但是也关乎你怎样解释你的问题怎样解释这个问题 还有business sense然后如果在System Interview的时候,包括你日常discussion的时候,It's very okay to not know something, just be honest, right?因为System Design这个范围太广了,很多时候你不知道,比如说你不知道什么是long polling,或者你比如不知道System Notification怎么做的,你就说我不知道。每个人都是有长处和短处,并且每个人时间都是有限的。 [10:00] 并且有我觉得每个大家在这个computer sense的时间也是相对来说也是有限的,只是生活中一部分。所以如果不知道的时候,就是就是就是包括在design或者是在discussion,说I don't know,然后你可以花点时间去去理解,花点时间去学习得更深入一点,然后然后从System Design Interview的角度来说, it's not okay to argue with your interviewer,如果他的interview的question或interview solution是这样的话,你最好可以通过维万的方式 list the pros and cons,然后do not try to outsmart your interviewer,这个的话我觉得System Design不是比谁聪明啊,这个和聪明也没有任何直接相关的地方,就是觉得有时候有非常genius的想法的时候可以分享一下,然后觉得对所以说,就是interview tips,就是try not to argue with the interviewer.然后我personally说一下,就是我见过,我interview system design 的时候,我见过,嗯,有一些人,System Design是非常strong的,我见过一个最strong的engineer来自Netflix,然后他花了大概20分钟把所有一个非常复杂的design flag题从头到尾解释清了,没有任何red flag,但他最后没有被录取,他面的是senior tool没有被录取,为什么?因为他所有的那个Behaviour question run 全 broke 了,全 fill 掉了,然后当时 debrief 的时候, hiring manager 说,问他当时说为什么如果你和你对有conflict的时候怎么办?他说没有conflict,所有的decision都是他做决定。然后他这个interview就挂掉了。所以说这个System Design只是生活中一部分,但是它是一个非常technical oriented coding和这种behavior question之间的一个结合体。它也是比较考量就是Senior Engineer的一种能力。stuff engineer 我知道可能有stuff engineer在这块一种能力然后就是你你职业生涯时间越久一点就会发现Pure technical part 其实变得越来越不重要,然后你的personal influence 会变得很重要,然后你的behavior不是behavior,你的how you articulate problem,how you perceive problem,这块变越来越重要的。然后因为大家就是能力都会提升上去,然后理解的话都会提升上去,然后就是你能力理解提升,就是没有提升上去的人就会被淘汰掉。所以这时候你就是personal skill 有时候会很重要,在system体栏中,这个也是一种体现。包含你怎么样说服你的teammates,你用这个architecture不用那个architecture,也是一种能,就是Personal skill 的期限好,System Design是你能在面试过程中学习和掌握的最重要的一个skillCoding skill 我现在没写过一个recursion 我现在在production中从来没有写过recursion尽管是coding skill 你不得不基本一定会要的东西但是system design 你在所有的在这学到system design在现实生活中很快能找到一些实用的例子所以它是most useful skill you could learn 然后system design is all about signals 这个和说的interview是一样的作为一个interviewer 我不会看interviewee的具体的问题 我会看他怎么解决包括你做interview training 是这样子,就是你会看他具体怎么样理解这个问题,然后怎么样解决这个问题。有些地方比如说一写成二,这 doesn't matter,就看这个signal,他的approach是不是正确的。然后System Design呢是不那个require for new grades 的。New grades 其实基本上是不看CCC的情况,但是它是一个非常good way to discover rocket star, rockstar new grads。所以作为 new grads,或者你工作经验比较少,三年之内,你更多应该focus上一些fundamentals,比如说SQL, non-SQL, ASA怎么样, concurrency model,如果那个database的话,B-trade什么样子的,为什么有的能实践,有的不实践,然后这些fundamentals,你需要understand the fundamentals,也能为你之后的,System Design打下一个好的基础然后如果你是SD2的话, 总之的话, 它是OK的要求他。词: 张宇宙: 美女的亵虾,C-BAN,S-T2都是可以PASS-Interview的。所以说,比如说, it's okay not to know rainbow table, but you shouldn't install the password in plaintext.Rimbo Table 是一些 tricky way to crack 那个 password 就是把 hash的 password crack 上 Plantex 但是如果你设计的时候把 password 全成 Plantex 这就是基本上就是一个非常 major 的 red flag 一般interview 被 reject 了 [15:00] 大的直接原因可能是你articulate 没有articulate好 或者是别人觉得不honest或者是一些常见的 red flag然后但是直接说直接 reject 的原因一般都是 red flag一般都是 major red flag 比如说 password in plain text然后Senior above的话是一种wide vote vital的就是一票否决权的你如果system design有 Red Flags 的话你是一票否决的有少量的例子不是一票手球,我会说一下在database里面去存一个multimedia data file,这个会一票否决的,就是一般来说都是object的database,比如说amlons3这种。用Cassandra和Redis用来做bank transaction,这个基本上一票否决的,但Cassandra做bank transaction这块还是有一些问题的,因为它这个有一些细节问题啊,但是Redis做bank transaction的话,也是问题就比较大了相对来说。嗯然后, system design is about building block and modules.系统设计的像搭积木你会有很多错 你会有很多寂寞它每个积木 shape 不一样它有的 shape 是从 API 角度就可以看到的比如说 DynamoDB 里面有 partition key有Sought Key,然后有各种的Column,这是从API角度就看到的。包括像Schemeless里面,它Convention用法就是说它那个Key是UID,就是从那个非常表象的一种一种一种。其他一种feature,就是积木的一种feature。另一种feature呢,这个积木的 feature 就是这个 tool 的 feature 是你看不出来的你比如说比如说DenimalDB,那是我们叫做一种Best Effort Database,为什么DenimalDB或者Cassandra是Best Effort Database?这是积木的API什么的看不出来的就有点像这个积木的积木的API这个就有点像积木的形状,你看到这个积木的形状,你说我可以把它放在这个形状,这个契合的很好。然后database深处的那块有点像这个积木的组成,它到底是铁的组成的部分,还是木头的组成部分,还是塑料的组成部分。这个是很重要的,为什么呢?因为你看到一个形状很合适,但是它实际上是塑料的,你放在一个钢筋卷凝土的结构下,一下就压垮了,这是一种啊,这是一种。fundamentally errors right?就是fundamentally errors,所以说这个是很难很难说是quickly run by button,所以我看到很多同学最常见的一个问题是怎么样竖层,怎么样竖层很难很难竖层。我觉得如果你是有很urgent interview 的 requirement 的话,我推荐你做两件事情第一件事就是你懂得在你过去的工作中,你对过去工作的project理解非常深入啊也没有quad start transaction那么处理啊,那其实我们就必须从DataModel的角度来处理是吧就是这些问题,你需要去理解更多。如果你花时间的话,作为有紧急的interview的timeline的话,你要花时间理解自己之前工作的系统是什么样子的。然后这是第一点。然后第二点的话,如果你有额外的时间去尝试理解DB,然后可以从Seql开始。可以从 Sequel 开始,然后我常见的推荐就是 Sequel,然后 Sharded Sequel Database,比如说像Uber的那个Schemeless或者是Facebook的Tao,这两个是非常相像的,ShardedMulti-leader SQL Database,这个非常相像的,他们虽然是在MySQL上面build的,但是它整个的使用方法和它那个assumption已经不一样了。然后读一下,可以读一下Dynamo,MongoDB我觉得没有必要,读一下Dynamo,大概Noseql了解一个Dynamo其实就足够了。很多时候面数足够了,但有很多其他有趣的NoSQL,比如说Neo4J啊,然后In memory database 可以简单了解一下Redis一些细节然后其实你当做schema-less的时候,它已经算是noSQL一种了,并且这个现在还是比较在,不管是在Uber还是在Facebook是比较主流的一个database,所以可以花点时间在这个上面,然后最重要的System Design是它不注重于数量它注重于质量这个和Learn Your How [20:00] 各人相关 就是有一门课叫Learn how to learn,非常有趣,这块讲这块,我想讲一下我大学时候,我大学时候就非常喜欢翘课,我翘课率高达90%。就是经常上课的时候,这个第一节课我去了,然后我也没见过老师子弄什么样,说面试的时候,就是考试的时候经常见不到老师子弄什么样。然后我经常最后一节课,然后还有一天考试来,我就开始把课本全部复习一遍,比如什么藏微分,然后24小时学完藏微分,然后去考试,所以考试层就比较极端一点,有时候60分,有时候是90分,95分。参与比较极端一点然后呢我这个其实是Absolutely wrong way to learn how to learn的东西,就是去学习一个东西的方式。然后我会发现,这是我个人的例子,我会发现过了没多久以后,甚至不超过一周我所学的东西就全部忘掉了然后那怎么是一个正确的Learn方式呢?正确的Learn方式是一个螺旋型的,你会开始学到一个东西,然后你会学得很深然后过一周后你会忘掉忘掉很多50%然后你会再学这个东西然后你这次学呢会在之前的基础上学所以你像一个螺旋旋梯一样你会学的比之前更深一点然后是这么一个过程所以说我觉得这个System Design这块也是一样的会一开始的时候很比较累然后会学的相对轻松一点但是它不管怎么说都学是一个螺旋形的过程你会先积累一点然后会忘掉一部分然后再积累一点然后再忘掉一部分然后不停的学的深入一点嗯然后System Design呢如果是你从来没有接触过的话是非常overwarming的,你需要一个非常discipline的methodology,这个我会主要在周三时候讲就是你怎么样把一个System Design的问题break成更小的细节。周六的就是周六,今天的课的话就是主要讨论的呢都是就是一些long term,就比如说讨论下这个积木的属性啊,讨论下这个积木的形状啊,讨论一些fundamental assumptions in distributed system 这些东西,就是讲的非常非常 fundamental 的东西,非常简单的东西。所以System Design一般来说也是hardest part of interview,它一般是interviewed by most senior team members,所以如果你System Design轮表现得很好,你其他轮表现得不好的话,你是有很大的机会什么呢?你是有很大的机会 sorry你是有很大的机会去就是一轮就是表示因为你是MOS senior member 所以你System Design表现的话 你很有可能是overwrite overrule一些一些那个coding的问题并且是比如说你面试Google的话 有的就是L6级以上的话 你可以选择全System Design轮 但是L6以上你不可能选择全coding轮就是整个四轮还是五轮System Design,它是有这种面试的。然后System Design是Impossible to Bushit,如果你不知道的话就不知道,你Bushit的时候反而会导致更多的问题。然后, system design is about systems.很多 system design的问题,它不只是System Design的问题,它也是人生哲学的问题,非常有趣的一个人生哲学的问题。甚至是跨行业的一个问题整个Engineering通用的比如说波音73G MAX,它当时有个 failure,然后有个非常长的 failure report,我当时看那个 failure report 的时候我就发现它其中在系统判断出它这个系统有这个飞机有坠机风险的时候它是有一个single machine去control的,然后这个single machine呢它这个Machine会根据它的perception,有一大堆sensor然后所有的 sensor 也是没有 backup,就是 single point failure 的。所以整个 737 设计就是 single point failure 的。并且它这种情况下是overwrite human operation的,就是single-party failure,你不需要go-fired a job, it's fundamentally something around there,谢谢大家然后另一种说法就是 if you holding a hammer, everything looks like a nail. 这也是非常有哲学的一个结论,这是一个德国谚语。这个你会看到在很多地方说过,查理蒙哥说过,他在自己的那个书里面说过这个,提到过这个,很多地方也看到过。这个说法是什么呢?如果你的思维是固定的,查理蒙格尔不是推荐那种多元化思维,如果你思维是固定的你拿着一个垂头你看见什么都是钉子都想来一垂头都可以解决在System Design里就是说如果你只知道一个database,比如说Denmo,看见什么问题都可以用Denmo来解决这个是fundamentally错的,因为这个世界是多元化的,是吧?然后其次的话,很多时候, it works, works not, that means it works forever. And很多时候根本fundamentally,其实就不work。所以说这个,我觉得System Design非常注重Avoid的一个地方就是,如果,就是说你要尝试培养这种多元化的 [25:00] 王格说多样化思维就是不是看到什么都是钉子,然后你自己拿那个锤头看什么都是钉子。然后还有一些Linux设计,Linux设计就是非常简单它就是build了一大堆small非常reliable,非常scalable的一个小tool,这块的scalable是指你比如说你这个salt你可以非常快的把一个file salt好,它会自动帮你handle哪一块把那个放到memory,它甚至saltfile可以大于memory的capacity所以它非常simple,非常reliable,小tour,然后这几个tour,你可以通过一个interface,来把它用一个pipe,然后相连,它实际上是把Linux里面的program,实际上是把business logic,把logical logic和input和output是separate了,separate concern。所以input/output他写的时候都是来自于standard in,standard out,然后可以用PyPyPy连起来,就这么简单的一个思维,然后其实是fundamentally revolutionary,changes how the computer world works包括你在往前追溯的话,你看图灵机,图灵机的设计也非常简单。现在所有的系统都是图灵机,图灵机设计非常简单非常非常simple的。这个Keep it still simple,我记得是来自于Kelley我忘了看你的 last name 什么了,他是来自于这个工程师呢,是一个是Lockhue的一个工程师,他设计的是历史上最快的飞机。这个历史上最快的飞机呢,是达到3.5赫兹的因素,3.5岁的因素。然后他飞得如此之快,以至于这个飞机呢,因为它是金属,它会热脏冷缩。它飞得很快的时候它金属膨胀为了保证它进入膨胀的时候把那个飞机自己给蹭爆了,所以它静止的时候这个飞机会漏油是这个叫 Blackbird 好像Mask的那个小孩,前两年刚生的小孩也是这个 Blackbird 这个飞机的那个型号秘密的非常有趣啊这个飞机。其实它的理念就是 Keep it still being simple 。这是一个非常有就是。我觉得是revolutionary,在飞机上revolutionary的一个先驱然后除了System Design 除了这个以外你会看到很多其他很有趣的地方你比如说我们美国这边不是我们美国这边1976几年登月50多年了我记得1969年了,登月50多年了,但是现在突然没有登月能力了,然后然后你比如说Blackbird这块就是Blackbird是50年前发明的,但是它是一样最快的飞机。之后就没有人超越,当然Blackbird主要是cost efficient,就是跟那个性价比来的,包括登月都是性价比来的。但是这个其实fundamentally是一个非常有趣的现象。就是AllenK,AllenK是OOP的一个,发明者,他在斯坦福给了一门课讲的是为什么我们要invent future from future, why we need to invent future from future,讲得非常有趣,说这个其实如果你不invent future from future的话,你不做revolutionary change的话,你的invention其实是backward的你的invention不是那种像一个正曲线一样 forward的,很多时候你的invention像backward,比如说apple是吧比如iPhone的时候,我觉得iPhone3,iPhone4后面就越来越烂了。这是其实是非常确的,非常非常man blowing 非常 true 的一个观点就是你的 invention 如果你不 invent future from future 的话你的invention是backward这都是一些design的哲理,然后我觉得非常有趣的哲理,他们其实从engineer讲就是相通的我觉得比较有趣,所以这是非常有趣的一点,就是System Design一点。然后System Design呢,不只是Engineering需要,其实很多时候是Engineering和Pract Manager都很需要的。嗯我个人的 my honest opinion就是 system designPRD就是Product Design和ERD区别就是Pilot Design不需要考虑Implementation但是这两个其实有本质相同性的,所以什么product manager 有时候他们也会面system design 人,但是他那个focus 更多是要那个requirements,那种prd 这种 design 人。然后engineering manager 也是面system design 的。我面试过几个engineering manager,system design 是有一票否决权的,在engineering manager 面试里面是一票否决权的,我当时面试的三个Engineer Manager基本上有两个都是System Design没过的,其中有一个是被System Design fill掉的全是被System Design fill掉的,因为它这个本身的background非常非常accellent然后在Apple工作 非常非常strong的一个candidate [30:00] 就是system design 我们那轮是no strong no 然后就没下满了所以说,System Design,如果你以后继续转型的话,其实非常重要,包括我们我们就记得Pyush,就是我们这个新的VP,就是加入Uber一年就前的新的VP,他之前是Amazon Alexa的头,然后面试Uber,他面了14轮,他们当时跟我们All Hands的时候,就是Q&A的时候说他面了14轮,其中有至少一到两轮的System Design,他Honest speaking,他自己说它是System Design面的很糟糕,因为他很多织织都非常RUS的了。但你也看到即使你达到VP甚至CTO这种level,你可能也要面System Design,但你不可能去问算法了,你不可能去写个recursion。好,我这块呢,我先暂停一下,我看一下大家有没有问题。好,现在有没有问题,大家有问题的话可以问一下。我看一下多少人,如果人不多的话可以直接问trying to figure out how it works74个人还是74个人 好 有问题的话可以直接onmute然后问一下好的,如果没有问题的话,我们就接着下一步。然后我再提一下Incase有些同学刚才不在,请今有空的话把这个System Design Study Community这个信息填一下,我到时候可能会找一些愿意帮助别人mark in to order,分成几个smart group,然后其次的话比如说有的人想做一些更小的,比如说Design Data Intensive Application这种Reading group,也可以在这里面,我可能会建一个Google group,然后到时候可以相互连接一下,然后读一下。向后联系一下读一下,然后System Design,然后我今天讲的是另一个谢谢大家叫Truth Knowledge and Lies这个其实是Design Data Intensive Application中的一个章解是第八章,如果没有记错,第八章我为什么从这一章开始讲呢?因为这一章是就是你有点整个knowledge有点像一个就是DAJ一样,就是你有starting node,然后有ending node,然后你有一个node有很多dependency,我仔细想了一下,我觉得这个node的dependency是最小的,这个是基本上你不需要知道很多其他东西的,你就可以开始读这个的,所以我就打算从这章开始讲,就是关于system design的,就是关于distribute system的truth knowledge analyze,然后就是如果你看的话,这个图非常有趣,DistributeSystem里面其实就像一个monster一样。它有各种问题,你如果ideally看的话,你把它想成一个single machine, nothing, no problem at all.但是你其实看的话,它其实有各种问题,比如说,System Design里面可能有clock error, clock error,然后可能有Process Pause然后可能有unbounded network delay,这都是一些常见的问题。如果你设计的时候没有把这个问题想尽的话,就是现实的那个,理想很丰满,现实很骨感,这个骨感的现实会导致翻船。这个船就翻掉了,所以这个System Design呢,我觉得Darker and I'll Think,Darker and I'll Think是之前的一个科幻小说,我很喜欢读,比你想象中的更黑啊,比你想象中的更黑啊,然后所以在System Design里面你需要什么呢?你需要Plan for the worst but hope for the best你需要为最坏的做打算但是你希望的是最好任何一个system design任何一个system design,它都可能会fill掉,所以你可能需要的是Planful of worth 你需要理解那你Planful of worth 那什么是passful of worth scenario呢 就主要在这张讲然后在这个之后呢你会明白 which design doesn't work fundamentally.这个 focus 是哪些 doesn't work fundamentally,而不是哪些 work fundamentally.这个的话,可能没办法能短时间短时间交手,其实这个周六的,我想周六自己讲的话可能更多focus on monumental,可以很慢一点啊可能没办法短时间内说什么work但是您可以短时间内理解什么不work然后这个也非常重要,就是什么不 work 很重要,如果你理解什么不 work 的话,可能就不会发生波音737 MAX 的最近事件,如果理解什么不 work 的话,可能就很多 fundamental 性, fundamental 性, fundamental 性可以 prevent it. [35:00] Thank you. So this is a quote that is interesting. In his experience, he has dealt with a long-lived network partition in a single data center. Long live partition, I read notes, it has been over a few hours, even over a few days. The whole network has been divided into two parts, one of the clusters and one of the clusters. And I think that they don't exist. "Bullet people don't exist" and "Solid world" is a solid world. You can imagine that it is like a different kind of world. And then all of the people are small groups. And this group is because the world is destroyed. and try to do some things to restore human beings. The same thing is the new network protection. Every cluster thinks it's only serving service. and try to do some things. This is Split Brain. This is not speed brain, it's not speed brain. PDO is the data center in the data center. And network switch is worse And then the power cycle of whole rack is broken. The whole data center backbone has changed. Even the data center power of failures has changed. I've seen a car, a driver, and he just drank the drink. It's going to be in the data center, the temperature of the heat. It was a system of a system of a system, and it was a system of the data center broke. One more interesting thing is that in 2014, Google's海底 network was a shark bite. It was a shark bite. It was a shark bite. And for NASA, the outer space of the Alborot, the CPU in the cache memory because it was a lot of damage from the size of the size, from 0 to 1 to 1 to 0. This is a very interesting thing. Let's think about it. If you were to go back to 30 years ago, 20 years ago, or 10 years ago, And when you use Windows, For Windows, it's a game for a game, or a game for a game, or something like that. It's just two different ways. One is you use normal use. Since we are at a deterministic, The device is a computer, so it is a computer. You can use a computer method, but it is a computer. So it is a computer. So it is a computer. If you have hardware connection problems, like memory claptions or loose connectors, you will create a "file" Blue screen on dice, failure to start up, or current panic. You only have two results you'll get a completely right result. Or you get a kernel failure, the node is off-line, the system is off-line. This is a computer program. This is a very... Very smart one. Now, if you found an internal fault, You don't want to push your user, you want to crush completely. rather than return a wrong result. Because if you return a wrong result, then you'll be very difficult and confused to deal with. Wrong result will cause a very very complicated thing. If you're assuming that computer could return wrong results, we will get more清楚. So you can see, in the traditional mode of the "单-机" mode, You have two assumptions. You can return a cracked result, you can crash. This is a very good design T-shirt. System design, scientific computing, also add to my understanding. The science of计算 is the total compute center. I studied at UIUC, and it is called NCSA. National Supercomputing Center. And it has gained the UIOC of the 20% of the UIOC. And then it's done the process. And then the process is called Blue Water. There is a super computer called Blue Water. I used laptop to calculate the flop per second, it was blue water of one second, it was about 167 days. Supercomputer. Supercomputer, it's a little like... Um, Taurus Topology. It's like a little bit of a tiny thing. One loop, one loop, one loop. And then this is the one. Okay. And so this supercomputer is like a computer. It was one of the few fails [40:00] 整个process又废掉了其中一环filda,比如说这个computerfilda,整个supercomputer已经终止了,你必须把这个fixed 了以后它能继续。所以他整个他为什么做这个 assumption 因为他说的 hardware 非常 expensive 也变得非常 reliable常见的这个好像只有几个,现在只有几个clay啊这种这种Clay,然后好像IBM还在做,就是做这个supercomputer,这个hardware,非常贵,非常贵。不会有个人会尝试买的,所以这个这个是,就是他们的Centific Computing的逻辑如果Field要怎么办?他们所有的MPP,Multiprocess Programming,或者说High Performance Computing,都是都是有个fault,就是节点的存点的,比如说他计算从A计算到B存点,从B计算到C存点,从C计算到D存点,非常有趣High performance computing 非常有情物,研究生的时候也和我同学景祥一起做过一个类似的,当然主要成绩都是他写的,因为我老在逃课然后Commercial DC的话是现在的这种,所以它是这种Cloth Topology你比如说这块的话,这个可能就是一个load balancer,然后这可能就是一个Application Server,然后一大堆Application Server,然后这个就是一个Data Center,可以用这么来想它是叫Clouds Topology这个里面它的 cost efficiency matters,那为什么 Google 它当时就是1999年 2000年的时候它 fundamentally 比其他的那个其他的那个巨头,它怎么在巨头的搜索中成长出来,就是它用的是非常chip的comedy hardware,就是它整个hardware用那种最便宜的性价比最高的hardware,然后呢,它开创了share nothing architecture,它开创了distributed system的那个design的那个最早的他是最早的PINIA所以很多最早的distribute system,比如说MapReduce,Bigtable,都是Google的,包括后面的Spanner,它也是有很多额外的创新。但是总体来说,这个commercial DC,像Uber的commercial DC,AWS是commercial DC,它focus上是盈利,盈利的话一定要用性价比最高的。因为它用性价比最高的,所以它Hover是最便宜的,相对来说,同等性价比最便宜的。所以,Always something is broken, something is always broken at any single point.你有一万台基地总有机器在broken的这种话有个叫birthday paradox我不知道你们知道就是birthday paradox是说你在一组人里面多少个人就可以找见两个生日相同的直观的感觉的话,有366个人的话,肯定有两个人生日相同的。但是有多少50%概率你有生日相同呢?你只要有23个人,就有50%概率生日相同了。你如果有70个人,你有99%的概率会生日相同了所以这个就是birthday paradox,非常有趣的一点。所以说,这个生日相同,生日conflict,您可以认为,相应的您可以认为是那个,就是有一个component的crush了,有一个hardwarecrush了。这个crush rate,你如果是比如说万分之一,但你有一万台机器的时候,其实很快就crush掉了。就由于它机器就crush掉所以说这个系统呢,实际上一个 philosophy 就是谢谢大家你整个module是less reliable, less powerful,但你要build a reliable system from unreliable components,这也是TCP在unreliable network build的一些基础比如说你还需要一些correcting code for crafted data然后这种设计呢就不能用在那个为什么不能用Centific Computing这个呢?如果你有一个block的话,有一个node fill的话你就不继续了,然后直到fix那个node,如果你用了这个commercial data center里面,nothing can be done这块举了一个例子这就是开始讲你unrelatable network了,这是networkunrelatable。我有的就是时间准备的时候比较仓促一点,可能就copy到这边了,但是我觉得大家理解到意思就可以,如果不理解的话可以问一下,提下问题。比如说我们做一个Client,我们开始Request 事情,Request 一个Service,比如说Get Username,你这个侧客的侧客可能在级续的输入你可能network为什么lost呢?因为network的话它是很多时候它是有个buffer和cacher的当你当你说的东西request得到一个那个port的话它超过它的buffer的话,它新的request就直接drop掉了,就是network可能掉了,或者整个network就broken了,整个network就loss了是吧,你可能整个datacenter被垂冲了,我们也有见过datacenter被垂冲了, [45:00] 或者突然发生了一个地震,然后整个data center被埋了,也是有可能的所以它可以network and lost它也可以说这个network成功,但是这个node是不responsive也可能network成功了,node response了,但是你返回的时候失败了那你作为client,你其实没法区分这三种情况这三种情况是没法区分的甚至有一种情况是它其实已经就是正常的那个,就是正常的返回,但是呢你这个它中间这个system它中间出现了很长时间的进程pauseprocess pause它两分钟后才返回那你client在这两分钟之内也不知道它system到底是down了还是没有到所以说你根本不可能区分到底是network down了还是node down了还是其实都没有到只是simply delay了就是你根本不可能去fundamentally不可能区分的那所以说呢如果你不能区分的话,那你就不能知道哪一个系统出问题了你实际上是哪一个系统出问题,你就不知道,就是你没有一个reliable fault detector你不知道这个node是不是真的出问题了只有node,甚至node自己也不知道是不是真的出问题了只有oracle node,这个node是不是出问题了只有node甚至node自己也不知道是不是真的出问题了只有oracle nodeoracle node这个node是不是出问题了oracle我们在学computer science知道很多事情比如说如果oracle的话比特币就一文不值这种就是只有oracle node基本上是impossible to nodeoracle node就是impossible to node然后同时呢现在最常见的indicator是timeout所以说所有的那个distribute service或者所有的那个micro service都讲就用timeout你必须remote procedure call你必须有timeout够的话是比较好的就可以在context里面settimeout然后scala的话有个Arca它是一个actor framework也是非常有趣的一点它那个设计和其他Arca不是framework是library它是有framework library区别Arca是library它有一个ACTOR还是Framar它有个ARCHA的设计它这个设计呢其实这个执行是可以在多个Node上执行的然后它也是用Timeout的然后如果你这个Request Timeout了实际上你是不能区分它是Node failure还是Network failure所以你能做的就是retry few times when possible但是你retry是要wait how long比如说你现在timeout了你是500毫秒时timeout还是100毫秒时timeout这是非常好讲究的如果你timeout的过早比如说你200毫秒timeout然后正好那个node在做garbage collection然后300毫秒才返回那你有很有可能是你以为这个node已经死掉了但是这个node其实come back了就是会造成一些disastrous result那常见的话就是需要做一些experiment可以手动的舔这个timeout然后也可以什么呢也可以就是用一些EU的algorithm比如说Cassandra是用automatic的一个algorithm有一个automatic library来detect timeout的然后在那个database里面这个timeout很重要为什么Timeout很重要 因为你database里面当你做replication的时候single master replication的时候 你有一个master有slave如果别人都觉得就是说的slave都觉得你这个master timeout了然后你就被falsefully declared dead然后就promote another slave as a master当这个master突然活了的时候你就突然就发现你已经不是老大了就有点像香港黑社会一样以为这个老大已经死掉了过了两年后这个老大突然跳出来说我才是老大然后现在有老大也很尴尬所以这个就是就造成了一个split spring这种现象就是两方就产生冲突然后就是你有一个新的master还有一个之前被declared dead的falsely declared dead的master这样就造成SpringBrain然后这种情况下如果你是没有设计好的话你很有可能会造成Arrow你比如说你request谁是Sourceful Truth那是之前死掉的那个老大呢又死掉回过来老大呢还是现在的新的老大是吧然后其次一点的话就是一个request因为你Timeout了你可能会retry所以你可能会call several times就是同一个request那你如果这个系统设计的没有ItemPotent的话你就造成disastrous result什么是idempotent呢idempotent是你同一个requestrequest several times你没有disastrous outcome就是你没有side effect其实idempotent在我们现实生活中用了很多比如schemalist里面你靠同一个reference的start的时候当你start同一个就是一个key和一个reference number的时候如果他是看到这个reference number [50:00] 已经被存储过了,直接把新的update就discard掉了这是 Adam Potent 在distribute system中一定要考虑到怎么样涉及 Adam Potent 的这一块就是你怎么样能把series设计成 Adam Potent 如果你没有 Adam Potent 的话那你如果相同的request repeated several times 你会造成 incorrect result 所以这个 Adam Potent 很重要的然后Network Failure其实非常常见的,一个Medium Science,他们有人就是有写PayPal统计,一个Medium Science Advice Center差不多每个月有12个Network Faults还有很多Network Partition,我们现在讨论过Network Partition就是整个Network在Data Center里面,Network被分开了导致一部分以为它是唯一的,比如说你有个Service叫User Service,然后有个Network partition,然后把其中一部分node和另一部分node分开有一份小cluster觉得它自己是user service 唯一的处理处理的那个cluster,就是这个我是,只有我在serve use the service,然后另一部分也是这么觉得的,然后你data存的时候,如果你save data存到A了,你读data存到从B读的,那你其实就没有Linearability Guarantee了,你就读的是你刚传进去一个纸,然后读不出来了。这就是Network Partition造成很麻烦的地方。如果没有Testing的话,很多时候这个Network failure会break fundamental assumption and result in surprising result.常见的比如说就是如果你的那个系统的逻辑是Depends on data的Linearability的话,你可能有Deadlog,并且你这个是重启没用的,因为你的Deadlog在你的系统,在你的Data里面。在你的Data里面是有Deadlog的,你比如说你设计程序是个有限状态机,你会读A,然后处理B,然后但是你虽我们写进A了,但是你实际上从另一个Data Center里面,另一个Cluster里面没有读出来A,然后就导入Deadlog。Uber 其实是有专业的Tool,Uber 有个HellStump是做Node failure test的,它整个就假设这个Service弄得Done了, test你这个系统会怎么样perform还有一个是Data Center Fillover但是这个Data Center是Data Center Level的Fillover,它可没有处理Data Center内的在这个系统中的系统中像他Observer的Data Center内的Network Curation,其实Uber内部是没有测的。这个其实不是Uber不够先进,业界都没有测。所以说整个这个Network failure是fundamentally hard to test,经常在HackerNearth上见过一个文章说一个bug在之前前40年都没有发现过,然后突然有的人发现了一个40多年的一个常用的bug,这个不只是一些不常用的software,常用的Linux command,非常常用的Linux command也经常发现过这种问题。所以这个是这个其实是经常出现的一个问题好,我看一下大家有没有问题谢谢大家好Network Partition在Uber怎么解决呢?Sticking in Roads?不是,Network Partition,其实你思考一下Network Cartation当你做Multi-Leader的时候,Uber其实是Multi-Leader,你其实是有一个Primary Data Center和Secondary Data Center,比如说有时候在Phoenix,有时候在DCA,那你是个Multi-Leader的Data Center,那你有时候你写的是Phoenix,当你Fill Over的时候写到DCA,或者是Phoenix不Responding的写到DCA,那你其实就会本身就会产生了Conflict你需要去 reserve the conflictNetwork partition它是一个fault,它是naturally会happen的它是没法被解决的你只能解决说 当Network Cartation Happens 的时候 你怎么样解决它的conflict 是这一部分所以 我们知道很多人知道有一个叫CAP 理论CAP理论是什么呢?C系划指的是 Linearability, Linearability就是当你写去一个值,你要读这个值的时候,你能读得相同的值,或者读得刚写进的值然后A是指available,就是在任何时候你进行request的时候总有datacenter availableP是Network Partition,很多地方解释,包括你去Glocking System Interview,上面写CAP,CAP三个不能兼顾,你只能有C和A,不能有P什么的,这个是fundamentally不对的。为什么呢?因为CAP的P它是一个condition,它不是你能选择的Network partition不是你能选择的,它是一个会发生的现象,就像你不能说如果我没有心脏病的话我能活到140岁,这种心脏病可能是它是一个fault,它是一个可能会在生命中会发生的,你只能说如果我有心脏病的话,我怎么样可能会延长我的生命,会解决我的心脏出问题是吧?所以这个Network Partition,这个CAP里面这个P Network Partition是不能被解决的它是自然会发生的一个事情你别没办法预测 [55:00] 未来也没办法阻止它发烧,所以这个是不能被解决的你只能解决,当Network发生Parkation的时候,你到底是优先考虑Availability,还是优先考虑Consistency,或者Lineability,这是你能考虑的。懂了吧,Network Partition,它不是一个你能解决的东西,它是naturally会发生的东西,你只是说它发生以后,能兼顾哪些,因为System Design about trade-off好好最后再讲一点的话,这个Network,比如说这个Network Delay和Network Loss,就是我们在说这个Network可以Delay和Loss,这个是其实是Choose by Design这块我要改一下,只有delay是choose by design,loss不是choose by design,比如说你如果用传统的电话线的话,那你就almost guarantee no delay,因为传统连号线它会fix一个fix share的bandwidth 然后downconnected你就会用这个fixer的去使用但是network不一样Network 实际上使用的时候是一个 Burst Mode 比如说你想你 Open 一个 Website你open 一个 website 你send 一个 email 你看一个 video或者是你听一个music,它都是burst mode,你短时间内传出大量的信息短时间内传输大量的data所以它这块design呢就是当时的工程师在focus是什么呢?是最大化throughput或者resource utilization rate当它最大哈斯鲁普的resource utilization rate的话相同cost下,它能传输的data越多,所以它也会drip down它那个cost你的 cost per transfer unit, 用的 用的 用的 用的TCP也是这么做的决定的,它都是为了这个BURST这个Burst的这个Mode来进行Transfer之前有mix,就是之前在历史的场合中有人是做一个mix的,就是有一部分是fixed bandwidth的有部分是这种就是maximum resource utilization rate 的,有人这么混合做的,但是他最后没有成功,就是商业的角度没有成功,所以他就就淹没在历史的长河中了。现在还有新的人在这么做。好这个其实这个Network Delay Choose by Design呢,这个Focus上这个Maximum Resource Utilization Rate呢,这个不是只有Network怎么做很多都这么做,比如说你的 generic operating system,也其实是就是你是 maximize the resource utilization rate但是real-time operating system是没有focus on utilization rates的real-time operating system 它是每一个operation 每一个system call instruction call包括每一个library call,你都必须写明他最大时间花的人,比如说你说你最多花500毫秒那么我就可以靠他那我就guarantee这个500毫秒后我一定有响应所以realtime system operating system就用在哪一块呢?比如说你的汽车那个汽车安全气囊,你不能说汽车安全气囊在做memory collection,然后突然发生车祸了,然后一秒也没发现,那会造成人的伤亡是吧?然后所以这个real-time operating system,它不是focus on resource utilization rate,它是focus on response time, response latency delay的所以它这个处理能力,其实它的单位时间内处理能力是远低于generic operating system很多real-time operating system是可以用unix是有那个Ubonto是有那个Real Time Operating System的Mode的,它其实从Operating System讲的,Operating System是个管家嘛,是个大管家。所以你从Operating System讲的,其实就是它和那个它underline的library打算一种协议,然后决定我在靠A的时候,我最多有3毫秒不响应,那我先靠完A,然后靠完A以后再回来看有没有其他urgent request,然后再靠B,7毫秒不响应,它是这个的。然后我之前做过一些research on autonomous driving,我觉得非常有趣。就是fundamentally,我觉得autonomous driving很难work的一个原因就是就是他必须用real-time operating system,然后他不能remote control,你的operating,你的那个autonomous driving,你的那个卡,你是不能,我这句话有一些ATG的同事,有些ATG的同事,我也欢迎举重批评。我的理解是,我觉得它这个短时间内很难work,因为这个我是调查了Wemo Cruise,我没有ATJ,我没有看APJ这种型,我就看Wemo Cruise和Bidu的Apollo像比如说我们就拿Badu的Apollo Project的话,它是有一个128LiDAR,然后有4个312LiDAR,然后加RADA然后再加上再加上那个操声波我记得,操声波radar,然后还有一个什么,我瞎忘了就这几个来进行进行Ctrl的,这是它Ctrl装置,它不能把这个 [60:00] uh, data send over network, because we talked about network, now we have network, maximum resource utilization rate, it can delay for a few seconds. If you email it, you can send it over to the network. How do you do this? You must have an operating system. You have an operating system. The operating system is a Supercomputer, like Apollo, it's about 180 MB/s. That's just 128 LIDA. You need to fix the clock for a minute. The number of people are 180. and you must use real-time operating system to make a decision. Thank you. So it's a device itself very heavy. Like Apollo, it has a very big supercomputer. It has a lot of equipment. It's a total of 20 million dollars. It's a deprecation rate. There are many problems. We can see the next one. Thank you. kind of instrument. Thank you. Now, system of atom potent have any other way? In the API, if it's the same request, it's a no-op. How image each fusion? What's the question? Thank you. Oh This is the network delay. So, why is this network delay? It's fundamental issue. You can't But the network delay is chosen by design, it is to be able to make the most powerful. The cost efficiency is to reduce cost. Choose by design. You can set the network as a phone line, but in the history of the time, this is not. Because there is a network delay, so autonomous driving is not able to send to remote. You can send to remote supercomputer and remote supercomputer. Autonomous driving is now all about and put a very powerful machine in the machine. And then there are problems. And then you actually have an offline system. You have no network request. You can... I remember from where I read the data. You have an autonomous driving. You have to go 2 hours and you have to keep up in terabytes data. How many TB data can you calculate? Like 128 line, 180 MB/s. So you can run 2 hours, local disk is written. You just need to stop and fix the data and train the offline model. Thank you. Unreliable clock. Now, clock, actually, is a fundamental component in the operating system or distributed system. For example, we常 use the request, the timeout, and the service is P99 response time. Now, you have a query per second, and how long does the user spend on our site. And then, when was it published? A daytime reminder your email to be sent and have expiration, or time stamp or error message in the logs file. Now, this part actually is two types. One is focus on duration, and the other is focus on time of day. The most famous mechanism is using NTP to sync data. That is to allow The time clock is based on the time, and the time clock is based on the NTP server. Then the server will be able to read the accurate time resources. If you want to learn more, you can use GPS receiver to read. The NTP is also from GPS receiver to read. But individual NTP is not reliable. They found that before there were NTP, there are NTP servers that have been a few hours. So if you read NTP, if it's more reliable, you can read several NTP servers. In system, there are two clocks. One clock is time of day, which is time of day. There is another clock called monotonic clock. This is the mirror duration. We will say from time of day clock. When you call system get current time of milliseconds, then you call time of day. Or you call clock get time of day. This is a very highly unreliable clock. You can jump forward. You can jump backwards. You can say you are 10:15. You can go through a minute. You can go through a minute. It's 9:15. This is Passport. It's a system. And this clock drift is unbounded, it can be a single drift In Google Spanner, the assumption is based on this class. [65:00] 它是assume是24小时能jift的30秒那我们个人的computer肯定这个drift的时间可能要比这个更多当你不进行network sync 的时候它drift的时间可能更多这是MetroTimerData的那还有一种Clark是MonoticProc它实际上就是MetroDuration的这个Duration Relatively 是可以比较 Relatively Accurate Measure 的, 您可以用这个Duration Clock你可以用这个Melatonic clock进行Emerge Duration, 净是比较trustworthy的, 比较reliable的为什么在clock上面的assumption非常dangerous的 sorry为什么在Clock Assumption非常Dangerous?就是我觉得Clock是 one single most dangerous component you can assume in the distributed system因为像我们之前讨论的GCIO System跟一个单机系统一样你只有两种结果你要不就 provide accurateDeterminated result put in crash但是不是Club,Club是不是这样子clock 你是永远要给一个时间的即使它的时间非常 inaccurate 你要给个时间你不会说这个clock 我不知道自己 inaccurate inaccurate inaccurate就crush掉了不会这样子 clock 不是这样子所以说,clock就是说,你clock可能是unintentionally lie了,就是clock我没有打算去来,但我就实际上clock就撒谎了。那这个clock撒谎呢,比如说可能常见原因是什么,比如说你connection to NTP被firework block掉了,那这个ARRO,这个Clock Drift,每天drift30秒,这个可以积累,预计一页累,你因为没法连接到NTP,所以你就没办法去Sync。那Clock Drift还有什么可能发生呢?你因为你的那个,你比如说我去NTP server,问我现在几点,现在Clock是3.08分9秒。那我就会把我的local clock赛造3:089秒这个它是跟Time Work Delay Network Delay相关的那我如果NetworkDelete了3秒钟,那我回来以后还是Side成3.08分9秒。那他们有人做过research说,minimum error network delay internet是35毫秒,所以你的clock至少是有35毫秒的 error因为Clock是如此的不reliable,所以Google呢有一个之前是一个side project,他们要把它做成一个很好的一个database project,但是他后来发现在database的时候,你没办法做time,就对Clock进行assumption,所以他把这个他在六七年后还是五六年后才把这个spanner做成了一个official database这个spanner其实它只有一点不同,就是我们之前说过的spanner就是distribute system里面的一个基因物这个积木从它的表象来讲呢,它是提供了一个True Time API,就是这个形状是个三角形,是吧,True Time API,你可以从这个spanner上得到一个time-mashing-turval,T1到T2,意思是现在的时间可能是T1到T2之间这是它的那个表象,它的理项呢,是spanner呢,它的那个材质呢,这筋木的材质呢,是这个Spanner呢,是用Atomic Clock和GPS Clock做成的。原子中和GPS中原子中是根据物理特质来做成的,所以它那个时间高度准确这个原子钟时间高度准确,原子钟很贵,一个原子钟我前两天才可能差不多2000美元,非常贵的一个 device。它这个Google Cloud在它自己的Data Center里面,set了大概很多原子钟,并且它是在Data Center角落里面set的原子钟,中间也set的原子钟。它为了保持它没有那个时间的偏差,在四周set了好几个原子钟。所以在这个Spanner的Server,在这个Spanner Service里面的Server呢,它会首先cos就是周围的所有的源自中然后看到它准确的时间,然后它同时也会靠GPS中,因为这两个中机体不完全一样,所以它会有一些偏差,然后它用这个时间计算一个最有可能的时间。它就算是最有可能的时间,并且它Sync非常frequent,它Sync的是30秒Sync一次,这样的话这个frequency drift不会too much可能是个几毫秒吧然后再加NetworkDelay 所以它导证clock sync在7毫秒之内就是说我现在带的时间我是T1和T2这个T1和T2这个监插除下来是7毫秒之内就是他这个highly confident 不能100% confident 但是highly confident 这个时间是在绝对时间这是计算了一个绝对时间在这个之间的所以这样的话,他用这个做什么呢?用这个做 casualty events谢谢大家什么叫carity events 我们稍后再说 最后有个example就是说这个carity event 说白了就是你它能分清事件的event的先后顺序他用这个spanner,通过用spanner service, rely on原子中atomic clock来判断event的坚后顺序那为什么这个 [70:00] stamp会造成disastrous result呢我们看一下 last right win像那个Casandra是用Last Threat Window的然后我记得我记得Cassandra是用last right thing的还有什么的Darkstal好像也是用last right thing的我当时做Docstar的时候他也是用LastThreatVind的Schemeless 可能也是用Loss Threatment的他们用的可能都是相似的那Last-RHand-Win有一个非常大的缺点其实fundamentally不能改变的缺点是什么呢比如说我们看这个例子在这个ClientA,set,在这个先前就是绝对时间,就是假设绝对时间,在之前setX等于1。cant b把x加了1,所以这两个,这两个event是有casualty的。就是这个x=1发生在前,x+=1发生在后,这是有carat的两个event这是有先后顺序的一文字他当设置X=1的时候他读他Local的一个clock,他这个Master是NodeE他去Node1说Node1的Clush是42分04秒是吧或者42秒-004那它就是set了 然后这个asynchronized呢写到node2和node3上,然后return就是ok了那你从clientB呢,说我x+1,那就x=2了,是吧?它的timestamp是42.002,因为它这个timedrift是比它,他们有timedrift的时间相差,所以这个后来设置的,它时间反而更早。当它写进去的时候,实际上来说,第二台Machine,它先写的是42.002,没问题,他所以就把这个x等于2写进去了然后这个node1的request combinator变成42.0,就变成x等于1那就把 x等于r overwrite了这就是实际上,当你读的时候,假设它这个Cassandra的话,你读的时候,你会发现,比如说你只从1和2读的话,因为你那个Cassandra的话,你是可以读就是Corum,就是你只要读三个钟的两个就可以了,那你就变成X等于1了,尽管X应该是等于2的。好这就是一个last right thing 什么意思? 什么意思?Last Threat mean is "Fundamentally cannot guarantee crack"Fundamentally last right wing可能是 lost data的因为 last thread win 一定要 based on time clock, time clock一定是 local time clock,你有可能一个后来的request但是它time clock比其他的慢,所以你后来这个request就没有覆盖掉,被之前的request就覆盖掉了,那你这相当于data loss。比如说你这个是挣钱,比如说这个钱,你开始有一块钱,你通过努力变成两块钱。你到最后的结果还是一块钱就是fundamental的一个data loss所以 last thread ring 是是有一个coverit的就是你会造成 data loss 并且这个 data loss 是不能任何东西都不能解决的然后我看到就是我们我看到昨天前天有一个讨论问题说另一个问题很久起来就是 Unicode ID Generation 我们在群里面讨论了好久 Unicode ID Generation这个问题是这样子的面试官说那有没有一种distributed way to generate ID 呢导致的ID是有TimeStamp的是有先后顺序的然后这个ID是不重复的然后这个ID呢根据这个ID的数量呢是可以判断它在哪一个machine上的对吧?这个是很难的,为什么很难呢?你可以很简单的判断在哪个 machine 上,比如说你可以做这个,比如说100台 machine,把那个 machine 的那个 mac id 变成那个 id 的一部分,当你读到这个 id 的时候,你读它前128位 mac id,你就知道它在哪个 machine 上,这个比较容易。然后你可以来说,进 best effort 说,它这个 time stand 先后顺序,你可以用这个 machine 的这个时间,就是 mac id 加 machine 的 local time然后把它做成一个ID,比如说Mac ID是unically identify all the machine in the world, Mac ID就是作为前的多少位然后后面加一个比如说mesecond和nanosecond的时间那这个machine通过前多少位是mac id呢unicode identify the machine然后后面的时间你可以unicode identify the time似乎满足这个要求但这个Design还是错的为什么是错的因为这个Design为什么是错的因为这个Time O'clock你不同机器间的time clock没有相对比性的你这台机器显示15.16分,那台机器可能显示16.17分所以这个还是fundamentally错的你不能把机器,如果你说这个time o'clock requirement 是strictly [75:00] 可以inforce的话那你只能用一个 consensus algorithm只能用 rootkeeper 这种或者是那种是pexels 或者是用那种RAFT, so a consensus algorithm, like Sante.因为你fundamentally没法greed on谁发生在前谁发生在后所以这个要求如果你是distributed的就是通过一个ID知道你是哪个事情哪个时间发生的你只能用就是fundamentally 你只能用consensus 二规则来解决就是因为System就是Operian System哦Distribal System may far agree on什么时间发生在前,什么时间发生在后我估计大家会有问题如果4到先到2的话,它会被drop吗?他会被jump吗这个看你怎么设计的,如果你按request来说,这个不能job,这个为什么不能job?因为这个Network很Delay,如果你是正常一个Request的人,比如说假设这个Clog全部是Sync的话假设你这个clock time sync 的时间都是一致的Network delay可以delay掉,所以你的后来的request其实后来的request可能是之前的,所以这种情况下,就比timestamp你应该被drop掉。所以会照不掉,对。好LD 里面 Timestamp 只要保证 Unique 就够了,Snowflake 好, 反正产生 Timestamp 前一个商场就会等一会儿这Snowflake 不是一个很好的 ID 我之前很久之前读过一个什么,Snowflake 不是一个很好的一个 UO ID我之前说的就是刚才说的那个Mac ID+Time stamp,其实就是V1的UO ID如果你搜一下 v1 uuid 的 mechanin论就是 mac id 加一个 timestampSnowflake 是有问题的 它设计fundamentally有问题UOID 是一个更好 如果你只guarantee uniqueness 的话 用UOIDUOID 的V4 是就是Universal, Unic,它是通过数学证明来证明它是不会conflict的的所以你不管在哪台机器,你不需要跟其他机器的Sync和Generate就可以了Snowflake,其实它那个idea是比UI的V1还要糟糕,它那个idea其实不能盖人体验,就是他有一些自己的问题如果Guarantee Uniqueness的话有UID V1 或UID V4 就可以同一个node上能保证先后关系吗?不可以,记得我们之前讨论过,这个clock是可以jump backwards的。我们之前讨论过Clock是可以jump backwards的你这个clock之前是12分04秒,然后突然变成12分03秒了,这是可能的。所以你不能保证间后关系Cassandra和DynamoDB有解决方案吗?Cassandra是用LastWriteWin的,DynamoDB不是。DenimalDB 你看DenimalDB paper的话,DenimalDB是让你自己来,他很多时候有Default,Default好像是Lost Threat Thing,但是如果不是Default的话,因为他知道这个问题,所以DenimalDB说你可以作为Client,你可以自己写Conflict Resolution Logic,你比如说如果他是个Amazon Card Shopper的话,你的Conflict Resolution Logic就是指甲不减,在你的Card里面指甲新的Item不减Item,这是DynamoDB提供的,你可以自己写的那个Client resolution, Configure resolution logic,发生概率高不高不高,这个概率不高,但是这个不高也很麻烦,你不能拿这个做transaction,bank transaction这就是为什么Cassandra不能做bank transaction的原因之一,还有其他原因。你用Cassandra bank transaction fundamentally,你突然移了15万块钱,然后突然就没了,就突然净损失15万。然后我们再说那个对其实这个其实 assumption 非常简单你会发现你就知道这几个knowledge 发现其中 fundamentally 很多东西不work你比如说你怎么样怎么样设计就是generate UID,然后generate ID,然后distinguish ID在哪个Machine上,然后先后顺序,这个你如果没有consensus algorithm,fundamentally不work然后比如说这个为什么这 Cassandra 里面基本从 fundamental 的角度它会找到 data loss 这是 fundamental 角度它一定会出现 data loss好,我再看一下大家有没有其他问题然后我忘了Slow Flake是什么,那片有张记本,但大家就是,如果你是guarantee uniqueness,的话有UID,UID是现在已有的State of Art或者是那个Cutting Edge Uniqueness Guarantee IDSnowflake是被淘汰的一个东西,我好像推特上不用它了 [80:00] 然后然后有另一个ID叫ULID啊,就是我前两天刚知道有一个ULID这个是Guarantee,它有点像Machine,加上timestamp它是guarantee前后顺序的你之前发生的同一time 身上之前发生的一般它的id是向前的但是这也fundamentally它有个assumption就是这个clock递增了但是Clock不是递增的所以它只是best effort感人气Best Effort Guarantee 这个是每方绝对的 Guarantee 的谢谢大家谢谢Clock 时间 jump forward backward 是比真正时间快和慢的意思?不是,它是比真正时间快和慢,所以它 jump backward 和 forward 比如说你有一台 machine不停的drift,drift,drift,drift,现在已经跑到今天是5月23号,已经跑到5月24号了,那他跟那个NTP server sync 可能就 jump backward 了或者是你有一个Time Machine,现在就跑到5月22号,那你跟NTP Server一行就跑到5月23号了,这才要jump forward好谢谢大家好谢谢大家谢谢大家好,我继续了,就是,嗯,你会发现这个其实知道一些fundamentally,你可能还没有想到一个什么solution能让fundamentally work但是你通过理解一些distribute system的一些condition,你知道哪些东西fundamentally don't work,所以这个是很重要的一点好然后再讲的一点是 Process Pause很多的program language 比如说Java的话 它有garbage collection 它occasional需要去stop去run process,所以叫 stop world garbage collection.我记得Uber去年还是前年的时候有一个go的那个一个够的Programmer我忘了是哪一位了Code programmer 过来讲他那个stopper word garbage collection optimization他说什么是stopware的garbage collection,就是什么东西都不work了,什么东西都不work了,什么东西都放一边,他开始进行garbage collecting了。当时Goal是从我忘了哪个version到哪个version,反正它把那个garbage collection,stop word,garbage collection,reduce了40%以上但是当时他observe 最长的一个garbage collection 时间高达500毫秒,已经很强了,我觉得已经很强了,但是这不是最长的,加网加码常见的就是garbage collection,stop word,有时候持续几分钟所以你整个这个process没有任何东西在run,整个这个java没有任何东西在run,它一直在做garbage collection并且这个garbage collection有一点非常不好的点是什么呢如果你 depend on your code, how to write and how to write the resources, you may say that the code run garbage collection time, stop the word garbage collection, is far from your logic to any logic.这是Dependent in Garbage Collection 怎么做的所以Stop the War garbage collection是必须写成一种必须在distribute system 必须考虑的因素单击的时候不需要考虑 因为你反正你睡五分钟起来以后你进入能处理要request 也可以了但在distribute system里面这是必须考虑的一个东西然后其次发生process path,比如说你operating system进行contact switch了或者是你在Vertual Machine里面有Supervisor switch东西了,那从当前的Thread来说,你就暂停了,然后你可能过了一段时间以后才会恢复。然后另一方面,如果你进行Synchronize Disk Access的话,那可能会pause,在wait这个Slow I/O Operation。这个常见的是Java Class Loader,Java Class Loader会Lazy Load的那个class,如果你之前没有Initialize,还有Lazy Load Class。在楼上然后就 run 程序 run 了一半,然后它突然就卡住了,因为它要去 synchronize,去 load a class.还有这个发生也在stretching 什么意思你配着memory disk swiping 这个也是常见的 我就不普及了就是operative system中的一个概念就是你memory不够大了 你要不停的把memory的pages写到disk上然后如果这个太平常的话,整个system就已经pause到那里了。所以因为这些 generic operating system的原因,说realtime operating system,说的library card是有worst time guaranteed的保证你几百毫秒内一定会响应我们看一个real case,这是一个real case,这块有个reading很好,我想highlight一下这块有个reading很好。计划有个reading 写得很好,是那个Martin Klepsman 写的这个写了一个就是Redis的Redlock的问题 [85:00] 如果你积累了足够的经验的话你会发现Operating System中distribute system有很多新的tools,比如说有新的tools不是越新了越好越新的往往保持它坑越多,所以当你设计设计系统的时候,你经常会有人说我hesit to use 这个新的tool,因为它是uncharted water,Uncharted Water就很有可能会出现各种各样的问题,包括一些UNIX最常见的错,47年后还能找见bug,你就知道他这个所有的东西都可能在distribute system中出问题了。然后他这块的话就是Redis新执建的一个Redlock,叫Fault Tolerant Distributed Lock,但是他这个本质问题就没有fancing token,这是fundamentally wrong的,他不是第一个run的,他不是第一个出问题的。再来充满地你有两个client,你想写到一个data,一个storage,比如说你的userfile,或者是叫我这个 account 有多少钱,account里面有多少钱,这个 corporation bank account 有多少钱你看他去那个 lock service 说我要拿到一个 lease在这个List这个时间内,我拥有这个Count的所有权有点像lock嘛,就有点像你写coding里面那个一个Single,就是Modg-Sign coding一个lock,那你就拿到List了,然后这时候呢拿到这个类似的同时你发生了Stop the World garbage collection post我们注意刚才聊到这个garbage collection post可能持续几分钟,worst case情况下。当你持续了几分钟的时候,你醒来的时候你接着写data,你以为什么事情都没有发生。但是因为你在这个garbage collection post的时候,你实际上你的lease已经expire了,Client2已经get the lease,然后再写了data,这时候你的old data,比如说你bank count只有10块钱,然后Client2给你deposit了50万,写完以后还要只有10块钱,你就损失了50万。这个是真实发生的,有的同学会问说,我能不能加一个timers,是吧?当我在write data之前我写个timers,就是if当前的clock.time now within the least expired,然后写就write data,这个是不work的,为什么不work?因为你可以check那个lease expire可能发生在这儿就是你这会儿check的时候,你lease还没有expire但是当你garbage collection pause 以后,你以为你紧接着实现第二个了,但实际上不是,你已经过了10分钟了,你10分钟前立死不 expire,不代表你10分钟后立死不 expire。所以你这个check time和write data中间可能有10分钟的间隔,当你check list的时候你还是valid,但当你起入 data的时候就造成correction了。这是常见的一个,这是HBase出现过这个问题,Redis也出现过这个问题,就是他们就是smartest people也会犯的一个问题。所以说这个是一个fundamental的一个问题,那怎么样解决这个问题呢?要有分清Token我们之前说过用Rootkeeper去拿到一个Rootkeeper transaction ID,那Rootkeeper transaction ID可以是increasing的,所以当你ClientA拿到List的时候,你同时也拿到这个LogService可以是Rootkeeper提供的,你Rootkeeper也可以提供一个Transaction ID,比如说这个ID是1,然后你Client2在拿ID的时候拿到ID是2,你把2写进去的时候,你再写1的时候,发现这个ID backward,你就reject了,这样的话就可以了,所以叫fancing token可以解决这个问题。好,然后,所以在distributed system里面有很多truth猝死的是什么呢?一个node在network里面不能知道anything for sure,只能是make guesses based on messages you receive,其实任何东西你都不是很确定的你知呢就说你只能用你的best effort去 guess什么事情发生了然后出此还有什么呢Node只能知道另一个Node在什么状态下,跟它在Extchange Message。比如说我想知道node2在什么地方下,我只能exchange message了,我才能知道node2在什么地方下。如果node2没有响应,那我不知道到底是我不知道nodei在什么情况下,不知道什么state下同时我不知道是Node2出问题了还是Network出问题了,其实都没有出问题,但是最后处理返回的时候出问题了。然后distribute system另一个truth是什么呢?truth是defined by majority 的缸多半当disgrade的时候你需要去consensus就是在majority里面disagreed的时候,你是要去consensus,但是truth是defined by majority,比如说我们之前讨论过network和partition你Network Function 了以后,你会分成两个partition,一个大的partition,most likely一个大的partition,一个小的partition谁是有主动的,比如说谁的partition nodes多,那谁就是那个谁就是winger 谁就是 [90:00] All. which is Truth. So this is the network from partition. How do you decide to decide the partitions in the same part? You need consensus service, like rootkeeper or other roughed or pexels, you need to get consensus. The majority is defined truth. The majority is defined truth. Let me see if there's no problem. you know. Okay, that's when we talk about truth, we will talk about lies Lines in distributed systems, there are a nice binocular failure. What is the meaning of the "bite-zantine failure"? If you have a "bite-zantine" to the "bite-zantine" question, you have three "bite-zantine" They are in three places to attack the military. Istanbul, like Istanbul, Istanbul, Constantinople. Then you can攻占 it, you must be together, you can攻占 it. So you must decide go or not go, you must decide to go or not go. You must decide to go or not go. You must be able to go. If you have a person who says I don't want to go, then you should say about it. If you have three people who are in the air, you can carry out the air. If there are three soldiers in the three soldiers, one is the "pant主" If he said to the one person, and the other person said to the other person, this is a "fail" that. If he said to the other person, he said to the other person, he said to the other person, he said to the other person, he said to the other person. He said to the other person is a confused state. You can say that a part of the team is not in the air, and a part of the team is not in the air. This is a real-reliable note. Malicious node. You can't be a compromise. You can't be a messenger. You can't be a compromise. You can't be a messenger. You can't be a messenger. You said that we don't have to do it, and the message is that we have to do it. And it may cause problems. So this is the unreliable network or malicious network. This is a bit of a problem. This is a bit of a problem. It is used to use for example, if you have a aerospace, CPU register and memory is corrupted. And then you need to use Tolerant Band-Zen-Thing failure. Finanting failure is to tolerate the algorithm, but it is very expensive I remember that the President of the Li永乐, he talked about 40 minutes about failure and algorithm. I think he was pretty good. If you're interested, you can quickly read it and hear it. 拜暂停将军问题。 In some cases, you must consider the "bind-zantine failure" If you are peer-to-peer, you can assume that node is well-behaved, you must consider the "bind-zantine failure" Or, you also need to consider a failure. But it uses different ways to consider it. For example, it is a computational hard. And when you calculate it, you have a short-lived authority. And you can resolve conflict. And this is the blockchain design of Bitcoin. Thank you. That's the last thing, distribution system in different models. These visual systems have different models. Synchronized model is You know, we showed a network deleter bounded, showed a process positive bounded. So the clock error is bounded, this is like we discussed earlier. This is not a realistic model. It's not trustable. If you have this assumption, most likely your design will end up badly. So synchronized model cannot be a realistic model. There is another model called Asynchronized Model. Asynchronized model is what? You can't use any timing assumptions. You can't use clock, timeout, any other thing is not used. With clock, it's not used to use. That is asynchronous model. If you have asynchronous model, many things are fundamentally not able to do. There are many things fundamentally made to be found. It seems like serialized ball is fundamentally not able to do it. In the database concurrency control, there is a serializable. Serialize for, uh, uh, transaction, how are fundamentally cannot be implemented in asynchronous model, 它还是有一定的 timing assumption,然后 partial synchronized model 为什么呢? Most of the time is synchronized. [95:00] 但是有时候,occasional是 exceeded bound network layer或者是可惜这个是 realistic model这也是所有的design常见的一个model,就是你的model,你的design应该based on partially synchronized modelAsynchronized model,太 restrictive,很容易的不 workSynchronized model 就是 fundamentallyfundamentally, it will feel horrible.然后model还有另一种就crash stopCrush recovery and Byzantine failure. Byzantine failure是任何东西,任何 node都可能是 malicious node这个呢是不可能,这个是在我们这个Data Center里面是不存在的,因为我们Data Center的机器都是用,比如说Uber Data Center或者AWS Data Center,都是员工专门维护的。你不可能说整个这个机器就是一个 malicious fault,但是有另一种 fault,就是有三种 fault,如果你考虑false的话有三种false,就是一种是hardwarefalse,就是randomly occur,你比如说一万分钟一的概率,其实我看Santa写的那个有人做Centadisk的Fault Survey差不多就是十万分之一的Fill概率这就是Hardware Faults还有一种是Software Faults比如说你这个Software写了一个问题或者你可能是Hardware Drive的问题Hardware Drive的问题然后这个Hardware Drive也是一个Software然后你这个问题出问题来当你更新这个Hardware的时候突然trigger了问题你整个这个Hardware就全部同时挂掉了因为你都是用同一个Hardware Drive version同时怪党 这是比较严重的一个在datacenter里能出现的比较严重的问题单独的hardware faults 因为它是不相关的所以这个问题出现的不严重最多换一个hardware 而 software faults是就是出现的时候是大规模就是连续出现的那这个会导致fundamental error这个software force也包含比如说我们写个client写个client code 然后你deploy的时候一下deploy一坨然后就全挂了 这也是一个常见的software force所以说这个软件写的时候就是AB test,然后partially incrementally robot是非常有它那个就是有必要性的Bizzen-ting-Fox我们是不在Data Center考论的,你正常通过程也不会预见除非你设计一个 peer-to-peer system。然后在这个Data Center里面,所有的Crash Model里面,又有Crash Stop Model和Crash Recover Model。Quest stop model就是说假设一个node fill掉的话,那么它会终止掉,就是这个node fill就 gone forever了,never come backCross Recover Model是什么呢?就是假设这个Field终止掉了以后它会在 some unknown time in the future,它会 recover, 然后变成一个 reliable storage, 比如说这个也是常见的一个, 就是你作为一个 engineering 设计的时候常见的一个 assumption, 就是crushes, recover faults,就是说我这个node我可以知道它杠掉比如database这个database有可能就是突然off 来了但是我知道它一定会go back online因为它如果不go back online的话,那我这个data就loss了所以你的assumption就是这个database有可能go up online它一定会go up online吗?不一定你比如说你突然来一个龙简峰,把整个datacenter drag down的话,那你这个data nodes你有可能不go back on line 但是作为一个 engineer 你始终要有一些 assumption right?所以这个 assumption 经常正常的 combination 就是 partial synchronized model意思是大部分时候 nodes 都是 well-behaved,只有转些时候会 exceeded itsExceeded is guaranteed,然后crush recovery,大部分时候这个nodes,就是这个nodes它可能会crush,但是它crush以后在上future time一定会go up online这是大部分软件设计的 assumption对,这大部分要是两件设计的assumption。好,我现在呢,就是,这是我今天想讲的所有内容了。我stop sharing 一下。我现在呢就是想聊一下大家就是还是想让大家花点时间呢就是把那个一个是那个联系的这个方式提一下,然后我们到时候可以分成小的group然后我想知道一下有什么feedback可以跟我提一下,然后有什么question给我提一下然后谢谢大家然后大家叫Scott就好 我不喜欢叫Scott大神 我自己玩心比较重 叫Scott就好也不要叫老师啊我不想叫老师啊下次告的就好好然后然后我想就是就是就是就是简单聊一下就是现在就比如说呃有非常非常 [100:00] 有什么问题,QNIO想我们还有6分钟时间总体来说我希望就是organize一些这些就是讲的比较简单一点,比较简单,因为我觉得MOSA brilliant idea从历史上来看,Mossi Brilliant Idea其实都非常简单我这两天在我看有一个人Blog写了一个Gate 就是那个Git也是Linux设计的我看下Git的Design,我觉得也是非常简单的一个Design,没有很复杂的东西但是它其实fundamentally revolutionary changed了SVN之前是怎么工作的所以我觉得很多很好的设计其实Design fundamentally非常简单没有很死达的地方 所以我觉得然后也是比较简单的比较好,然后我还是希望就是就是有一些有趣的讨论, 这个周六可能更多focus on knowledge sharing, 然后到时候周三的话是focus on system design,我会稍微把它upload上去,upload到一个在 folder里面吧好,还有问题吗?大家有什么问题吗?没有什么问题的话就今天就到这吧请不吝点赞 订阅 转发 打赏支持明镜与点点栏目好的好的好的有什么问题的话可以写了Q&A然后也希望大家提供了点feedback好 谢谢大家谢谢大家好