作为系统设计学习的一部分，不久前在梳理面试中典型的系统设计问题，发现大部分都可谓有套路可寻。我把思路梳理了一下，简单整理到下面这张图表里面：
对于其中的内容，稍微补充几句：
- 系统设计需要经验的积累，但也确确实实有章可循。问的问题考察的类型很集中，比如同步、异步，消息 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 交互的要点和优化，这里没有列出来，几年前整理过，部分内容可以参考这篇文章。
- 最后，我在 《资源链接》的 “零散资源” 部分，列出了系统设计很多我认为有价值的参考材料。
文章未经特殊标明皆为本人原创，未经许可不得用于任何商业用途，转载请保持完整性并注明来源链接 《四火的唠叨》