系统设计的典型分层和涉及的知识点

作为系统设计学习的一部分,不久前在梳理面试中典型的系统设计问题,发现大部分都可谓有套路可寻。我把思路梳理了一下,简单整理到下面这张图表里面:

系统设计的典型分层和涉及的知识点

对于其中的内容,稍微补充几句:

  • 系统设计需要经验的积累,但也确确实实有章可循。问的问题考察的类型很集中,比如同步、异步,消息push和pull,根据实际问题设计存储的数据结构,对于scalability、availability的认识等等。最喜欢被问到的问题,我在《系统设计典型问题的思考》这里列了几个。
  • pull on demand 和 push on change 是消息系统里两种极其典型的消息传播方式,基本上设计twitter、weibo,xx聊天系统等等,都要涉及到这个问题。这二者各有优劣,需要结合具体问题分析。
  • 复杂的系统的cache的设计和storage的设计一样,往往需要考虑分层。比如说,存储分成hot/warm/cold storage,读写性能和查询的灵活性依次降低,但是成本也依次降低。cache的设计有时还需要引入centralized cache来帮助提高hit ratio。
  • 缓存的常见design pattern:Read-Through, Write-Through, Write-Behind, and Refresh-Ahead Caching。
  • 服务端的设计最典型的就是分成三层(上图右):presentation layer,比如website的页面部分和service的request/response处理的部分,它可能叫做front-end layer更好一点;business logic layer,放置业务逻辑的地方;data access layer,也可以说infrastructure layer,数据访问层,花头最多,涉及的问题最多。
  • DB partition 和 sharding 的问题又是一个非常常见的典型。
  • 如果是性能问题,基本上都是围绕着throughput和latency展开的。
  • 一致性要出问题,一定要满足两个条件,一个是节点必须是有状态的,另一个是数据必须有冗余。而我们在讨论storage的时候,第一个条件一定满足;而对于第二个条件的满足,下一条目说明。
  • 一致性模型可以说是大数据系统问题的核心。而availability既包括服务的可用性,又包括数据的可靠性。二者关系紧密。比如说考虑到availability,对于有状态的节点需要有backup,那么这几个节点状态之间的同步就会成为问题,这就是consistency的问题;再比如说由于考虑到reliability,必然需要引入replication,而这时多个数据备份的consistency就会成为问题。
  • 数据库一致性的四个级别:Read uncommitted, Read committed, Repeatable read, Serializable。
  • 读写模型的问题往往是和存储数据结构的设计放在一起的,这样的问题很容易从算法问题衍伸过来,我在这篇文章中总结过。
  • 对于前端和部分CS或BS交互的要点和优化,这里没有列出来,几年前整理过,部分内容可以参考这篇文章
  • 最后,我在《资源链接》的“零散资源”部分,列出了系统设计很多我认为有价值的参考材料。

文章未经特殊标明皆为本人原创,未经许可不得用于任何商业用途,转载请保持完整性并注明来源链接《四火的唠叨》

分享到:

发表评论

电子邮件地址不会被公开。

您可以使用这些 HTML 标签和属性: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong>


Preview on Feedage: