系统设计面试题思路综述

转自：http://www.jobcoding.com/basic-knowledge/system-designing/

在正式介绍基础知识之前，我先罗列几个常见的系统设计相关的笔试面试题。

(2) 有N台机器，M个文件，文件可以以任意方式存放到任意机器上，文件可任意分割成若干块。假设这N台机器的宕机率小于1/3，想在宕机时可以从其他未宕机的机器中完整导出这M个文件，求最好的存放与分割策略。

(4) 设计一个系统，要求写速度尽可能高，说明设计原理。

(6) 有25T的log(query->queryinfo)，log在不段的增长，设计一个方案，给出一个query能快速反回queryinfo

在google这些技术还未出现之前，企业界在设计大规模分布式系统时，采用的架构往往是database+sharding+cache，现在很多公司（比如taobao，weibo.com）仍采用这种架构。在这种架构中，仍有很多问题值得去探讨。如采用什么数据库，是SQL界的MySQL还是 NoSQL界的Redis/TFS，两者有何优劣？采用什么方式sharding（数据分片），是水平分片还是垂直分片？据网上资料显示，weibo.com和taobao图片存储中曾采用的架构是 Redis/MySQL/TFS+sharding+cache，该架构解释如下：前端cache是为了提高响应速度，后端数据库则用于数据永久存储，防止数据丢失，而sharding是为了在多台机器间分摊负载。最前端由大块大块的cache组成，要保证至少99%（该数据在weibo.com架构中的是自己猜的，而taobao图片存储模块是真实的）的访问数据落在cache中，这样可以保证用户访问速度，减少后端数据库的压力，此外，为了保证前端 cache中数据与后端数据库中数据一致，需要有一个中间件异步更新（为啥异步？理由简单：同步代价太高。异步有缺定，如何弥补？）数据，这个有些人可能比较清楚，新浪有个开源软件叫memcachedb（整合了Berkeley DB和Memcached），正是完成此功能。另外，为了分摊负载压力和海量数据，会将用户微博信息经过片后存放到不同节点上（称为 “sharding”）。

于是乎，新的架构便出现了。主要还是google的那一套东西，下面分别说一下：

MapReduce是针对分布式并行计算的一套编程模型。他最大的优点是：编程接口简单，自动备份（数据默认情况下会自动备三份），自动容错和隐藏跨机器间的通信。在Hadoop中，MapReduce作为分布计算框架，而HDFS作为底层的分布式存储系统，但 MapReduce不是与HDFS耦合在一起的，你完全可以使用自己的分布式文件系统替换掉HDFS。当前MapReduce有很多开源实现，如Java 实现Hadoop MapReduce，C++实现Sector/sphere等，甚至有些数据库厂商将MapReduce集成到数据库中了。

除了google的这三家马车，还有其他一些技术：

虚拟节点技术：该技术常用于分布式数据分片中。具体应用场景是：有一大坨数据（maybe TB级或者PB级），我们需按照某个字段（key）分片存储到几十（或者更多）台机器上，同时想尽量负载均衡且容易扩展。传统的做法是：Hash(key) mod N，这种方法最大缺点是不容易扩展，即：增加或者减少机器均会导致数据全部重分布，代价忒大。于是乎，新技术诞生了，其中一种是上面提到的DHT，现在已经被很多大型系统采用，还有一种是对“Hash(key) mod N”的改进：假设我们要将数据分不到20台机器上，传统做法是hash(key) mod 20，而改进后，N取值要远大于20，比如是20000000，然后我们采用额外一张表记录每个节点存储的key的模值，比如：

node2：1000001~2000000

这样，当添加一个新的节点时，只需将每个节点上部分数据移动给新节点，同时修改一下这个表即可。

文章最前面的几道题均可以映射到以上几个系统中的某个模块中，如：

（2）问题2涉及到现在通用的分布式文件系统的副本存放策略。一般是将大文件切分成小的block（如64MB）后，以block为单位存放三份到不同的节点上，这三份数据的位置需根据网络拓扑结构配置，一般而言，如果不考虑跨数据中心，可以这样存放：两个副本存放在同一个机架的不同节点上，而另外一个副本存放在另一个机架上，这样从效率和可靠性上，都是最优的（这个google公布的文档中有专门的证明，有兴趣的可参阅一下。）。如果考虑跨数据中心，可将两份存在一个数据中心的不同机架上，另一份放到另一个数据中心。

本文暂时写到这，读者如果有不清楚的地方，欢迎联系我，与我探讨。