如何巧妙地回答面試官的問題？

本文摘自《PHP程序員面試筆試寶典》

應屆生在面試時，偶爾也會遇到一些系統設計題，而這些題目往往只是測試求職者的知識面，或者測試求職者對系統架構方面的了解，一般不會涉及具體的編碼工作。雖然如此，對於此類問題，很多人還是感覺難以應對，也不知道從何處答題。

如何應對此類題目呢？在正式介紹基礎知識之前，首先列舉幾個常見的系統設計相關的面試、筆試題。

題目1：設計一個DNS的Cache結構，要求能夠滿足5000次/s以上的查詢，滿足IP數據的快速插入，查詢的速度要快（題目還給出了一系列的數據，比如站點數總共為5000萬、IP地址有1000萬等）。

題目2：有N臺機器，M個文件，文件可以以任意方式存放到任意機器上，文件可任意分割成若幹塊。假設這N臺機器的宕機率小於

題目3：假設有30臺服務器，每臺服務器上面都存有上百億條數據（有可能重復），如何找出這30臺機器中，根據某關鍵字重復出現次數最多的前100條？要求使用Hadoop來實現。

題目4：設計一個系統，要求寫速度盡可能快，並說明設計原理。

題目5：設計一個高並發系統，說明架構和關鍵技術要點。

題目6：有25TB的log(query->queryinfo)，log在不斷地增長，設計一個方案，給出一個query能快速返回queryinfo。

以上所有問題中凡是不涉及高並發的，基本可以采用Google的三個技術解決，即GFS、MapReduce和Bigtable，這三個技術被稱為

在Google這些技術還未出現之前，企業界在設計大規模分布式系統時，采用的架構往往是DataBase+Sharding+Cache，現在很多網站（比如淘寶網、新浪微博）仍采用這種架構。在這種架構中，仍有很多問題值得去探討，如采用哪種數據庫，是SQL界的MySQL還是NoSQL界的Redis/TFS，兩者有何優劣？采用什麽方式sharding（數據分片），是水平分片還是垂直分片？據網上資料顯示，淘寶網、新浪微博圖片存儲中曾采用的架構是Redis/MySQL/ TFS+Sharding+Cache，該架構解釋如下：前端Cache是為了提高響應速度，後端數據庫則用於數據永久存儲，防止數據丟失，而Sharding是為了在多臺機器間分攤負載。最前端由大塊的Cache組成，要保證至少99%（淘寶網圖片存儲模塊是真實的）的訪問數據落在Cache中，這樣可以保證用戶訪問速度，減少後端數據庫的壓力。此外，為了保證前端Cache中的數據與後端數據庫中的數據一致，需要有一個中間件異步更新（為什麽使用異步？理由是，同步代價太高）數據。新浪有個開源軟件叫Memcachedb（整合了Berkeley DB和Memcached），正是用於完成此功能。另外，為了分攤負載壓力和海量數據，會將用戶微博信息經過分片後存放到不同節點上（稱為

這種架構優點非常明顯—簡單，在數據量和用戶量較小時完全可以勝任。但缺點是擴展性和容錯性太差，維護成本非常高，尤其是數據量和用戶量暴增之後，系統不能通過簡單地增加機器解決該問題。

鑒於此，新的架構應運而生。新的架構仍然采用Google公司的架構模式與設計思想，以下將分別就此內容進行分析。

GFS 是一個可擴展的分布式文件系統，用於大型的、分布式的、對大量數據進行訪問的應用。它運行於廉價的普通硬件上，提供容錯功能。現在開源界有HDFS（Hadoop Distributed File System），該文件系統雖然彌補了數據庫+Sharding的很多缺點，但自身仍存在一些問題，比如由於采用master/slave架構，因此存在單點故障問題；元數據信息全部存放在master端的內存中，因而不適合存儲小文件，或者說如果存儲大量小文件，那麽存儲的總數據量不會太大。

MapReduce 是針對分布式並行計算的一套編程模型。其最大的優點是，編程接口簡單，自動備份（數據默認情況下會自動備三份），自動容錯和隱藏跨機器間的通信。在Hadoop中，MapReduce作為分布計算框架，而HDFS作為底層的分布式存儲系統，但MapReduce不是與HDFS耦合在一起的，完全可以使用自己的分布式文件系統替換HDFS。當前MapReduce有很多開源實現，如Java實現Hadoop MapReduce、C++實現Sector/sphere等，甚至有些數據庫廠商將MapReduce集成到數據庫中了。

BigTable 俗稱“大表”，是用來存儲結構化數據的。編者認為，BigTable開源實現最多，包括HBase、Cassandra和levelDB等，使用也非常廣泛。

除了Google的這“三駕馬車”以外，還有其他一些技術可供學習與使用。

Dynamo 亞馬遜的key-value模式的存儲平臺，可用性和擴展性都很好，采用DHT（Distributed Hash Table）對數據分片，解決單點故障問題，在Cassandra中也借鑒了該技術，在BT和電驢這兩種下載引擎中，也采用了類似算法。

虛擬節點技術 該技術常用於分布式數據分片中。具體應用場景：有一大塊數據（可能TB級或者PB級），需按照某個字段（key）分片存儲到幾十（或者更多）臺機器上，同時想盡量負載均衡且容易擴展。傳統做法是：Hash(key) mod N，這種方法最大的缺點是不容易擴展，即增加或者減少機器均會導致數據全部重分布，代價太大。於是新技術誕生了，其中一種是上面提到的DHT，現在已經被很多大型系統采用，還有一種是對“Hash(key) mod N”的改進：假設要將數據分布到20臺機器上，傳統做法是Hash(key) mod 20，而改進後，N取值要遠大於20，比如是20000000，然後采用額外一張表記錄每個節點存儲的key的模值，比如：

node1：0～1000000

node2：1000001～2000000

……

這樣，當添加一個新的節點時，只需將每個節點上部分數據移動給新節點，同時修改一下該表即可。

Thrift Thrift是一個跨語言的RPC框架，分別解釋“RPC”和“跨語言”如下：RPC是遠程過程調用，其使用方式與調用一個普通函數一樣，但執行體發生在遠程機器上；跨語言是指不同語言之間進行通信，比如C/S架構中，Server端采用C++編寫，Client端采用PHP編寫，怎樣讓兩者之間通信，Thrift是一種很好的方式。

本篇最前面的幾道題均可以映射到以上幾個系統的某個模塊中。

1）關於高並發系統設計，主要有以下幾個關鍵技術點：緩存、索引、數據分片及鎖粒度盡可能小。

2）題目2涉及現在通用的分布式文件系統的副本存放策略。一般是將大文件切分成小的block（如64MB）後，以block為單位存放三份到不同的節點上，這三份數據的位置需根據網絡拓撲結構配置，一般而言，如果不考慮跨數據中心，可以這樣存放：兩個副本存放在同一個機架的不同節點上，而另外一個副本存放在另一個機架上，這樣從效率和可靠性上，都是最優的（這個Google公布的文檔中有專門的證明，有興趣的讀者可參閱一下）。如果考慮跨數據中心，可將兩份存在一個數據中心的不同機架上，另一份放到另一個數據中心。

3）題目4涉及BigTable的模型。主要思想：將隨機寫轉化為順序寫，進而大大提高寫速度。具體方法：由於磁盤物理結構的獨特設計，其並發的隨機寫（主要是因為磁盤尋道時間長）非常慢，考慮到這一點，在BigTable模型中，首先會將並發寫的大批數據放到一個內存表（稱為“memtable”）中，當該表大到一定程度後，會順序寫到一個磁盤表（稱為“SSTable”）中，這種寫是順序寫，效率極高。此時，隨機讀可不可以這樣優化？答案是：看情況。通常而言，如果讀並發度不高，則不可以這麽做，因為如果將多個讀重新排列組合後再執行，系統的響應時間太慢，用戶可能接受不了，而如果讀並發度極高，也許可以采用類似機制。

更多有趣有料的PHP面試筆試資料可以關註：“琉憶編程庫”

或者瀏覽：www.shuaiqi100.com 獲取。

PHP程序員面試筆試寶典下載：https://pan.baidu.com/s/1-ES2ZI3z5Lhv-zTKFmJDSQ

《PHP程序員面試筆試寶典》——如何回答系統設計題？