系統(tǒng)設計在面試中一定是最讓面試者頭疼的事情之一。 因為系統(tǒng)設計相關的問題通常是開放式的，所以沒有標準答案。你在和面試官思想的交流碰撞中會慢慢優(yōu)化自己的系統(tǒng)設計方案。理論上來說，系統(tǒng)設計面試也是和面試官一起一步一步改進原有系統(tǒng)設計方案的過程。

系統(tǒng)設計題往往也非常能考察出面試者的綜合能力，回答好的話，很容易就能在面試中脫穎而出。不論是對于參加社招還是校招的小伙伴，都很有必要重視起來。

接下來，我會帶著小伙伴們從我的角度出發(fā)來談談：如何準備面試中的系統(tǒng)設計部分。

由于文章篇幅有限，就不列舉實際例子了，可能會在后面的文章中單獨提一些具體的例子。

個人能力有限。如果文章有任何需要改善和完善的地方，歡迎在評論區(qū)指出，共同進步！

系統(tǒng)設計面試一般怎么問？

我簡單總結了一下系統(tǒng)設計面試相關問題的問法：

1. 設計一個某某系統(tǒng)比如秒殺系統(tǒng)、微博系統(tǒng)、搶紅包系統(tǒng)、短網(wǎng)址系統(tǒng)。
2. 設計某某系統(tǒng)中的一個功能比如嗶哩嗶哩的點贊功能。
3. 設計一個框架比如 RPC 框架、消息隊列、緩存框架、分布式文件系統(tǒng)等等。
4. 某某系統(tǒng)的技術選型比如緩存用Redis 還是 Memcached、網(wǎng)關用 Spring Cloud Gateway 還是Netflix Zuul2 。

系統(tǒng)設計怎么做？

我們將步驟總結成了以下 4 步。

Step1:問清楚系統(tǒng)具體要求

當面試官給出了系統(tǒng)設計題目之后，一定不要立即開始設計解決方案。 你需要先理解系統(tǒng)設計的需求：功能性需求和非功能性需求。

為了避免自己曲解題目所想要解決的問題，你可以先簡要地給面試官說說自己的理解，

為啥要詢問清楚系統(tǒng)的功能性需求也就是說系統(tǒng)包含哪些功能呢？

畢竟，如果面試官冷不丁地直接讓你設計一個微博系統(tǒng)，你不可能把微博系統(tǒng)涵蓋的功能比如推薦信息流、會員機制等一個一個都列舉出來，然后再去設計吧！你需要篩選出系統(tǒng)所提供的核心功能（縮小邊界范圍）！

為啥要詢問清楚系統(tǒng)的非功能性需求或者說約束條件比如系統(tǒng)需要達到多少 QPS 呢？

讓你設計一個 1w 人用的微博系統(tǒng)和 100w 人用的微博系統(tǒng)能一樣么？不同的約束系統(tǒng)對應的系統(tǒng)設計方案肯定是不一樣的。

Step2:對系統(tǒng)進行抽象設計

我們需要在一個 High Level 的層面對系統(tǒng)進行設計。

你可以畫出系統(tǒng)的抽象架構圖，這個抽象架構圖中包含了系統(tǒng)的一些組件以及這些組件之間的連接。

Step3:考慮系統(tǒng)目前需要優(yōu)化的點

對系統(tǒng)進行抽象設計之后，你需要思考當前抽象的系統(tǒng)設計有哪些需要優(yōu)化的點，比如說：

1. 當前系統(tǒng)部署在一臺機器夠嗎？是否需要部署在多臺機器然后進行負載均衡呢？
2. 數(shù)據(jù)庫處理速度能否支撐業(yè)務需求？是否需要給指定字段加索引？是否需要讀寫分離？是否需要緩存？
3. 數(shù)據(jù)量是否大到需要分庫分表？
4. 是否存在安全隱患？
5. 系統(tǒng)是否需要分布式文件系統(tǒng)？
6. ......

Step4:優(yōu)化你的系統(tǒng)抽象設計

根據(jù) Step 3 中的“系統(tǒng)需要優(yōu)化的點” 對系統(tǒng)的抽象設計做進一步完善。

系統(tǒng)設計該如何準備？

知識儲備

系統(tǒng)設計面試非?？疾炷愕闹R儲備，系統(tǒng)設計能力的提高需要大量的理論知識儲備。比如說你要知道大型網(wǎng)站架構設計必備的三板斧：

1. 高性能架構設計：熟悉系統(tǒng)常見性能優(yōu)化手段比如引入 讀寫分離、緩存、負載均衡、異步 等等。
2. 高可用架構設計 ：CAP 理論和 BASE 理論、通過集群來提高系統(tǒng)整體穩(wěn)定性、超時和重試機制、應對接口級故障：降級、熔斷、限流、排隊。
3. 高擴展架構設計 ：說白了就是懂得如何拆分系統(tǒng)。你按照不同的思路來拆分軟件系統(tǒng)，就會得到不同的架構。

實戰(zhàn)

雖然懂得了理論，但是自己沒有進行實踐的話，很多東西是無法體會到的！

因此，你還要 不斷通過實戰(zhàn)項目鍛煉自己的系統(tǒng)設計能力。

保持好奇心

多思考自己經(jīng)常瀏覽的網(wǎng)站是怎么做的。比如：

1. 你刷微博的時候可以思考一下微博是如何記錄點贊數(shù)量的？
2. 你看嗶哩嗶哩的時候可以思考一下消息提醒系統(tǒng)是如何做的？
3. 你使用短鏈系統(tǒng)的時候可以考慮一下短鏈系統(tǒng)是如何做的？
4. ......

技術選型

實現(xiàn)同樣的功能，一般會有多種技術選擇方案，比如緩存用Redis 還是 Memcached、網(wǎng)關用 Spring Cloud Gateway 還是Netflix Zuul2 。很多時候，面試官在系統(tǒng)設計面過程中會具體到技術的選型，因而，你需要區(qū)分不同技術的優(yōu)缺點。

系統(tǒng)設計面試必知

系統(tǒng)設計的時候必然離不開描述性能相關的指標比如 QPS。

性能相關的指標

響應時間

響應時間 RT(Response-time)就是用戶發(fā)出請求到用戶收到系統(tǒng)處理結果所需要的時間。

RT 是一個非常重要且直觀的指標，RT 數(shù)值大小直接反應了系統(tǒng)處理用戶請求速度的快慢。

并發(fā)數(shù)

并發(fā)數(shù)可以簡單理解為系統(tǒng)能夠同時供多少人訪問使用也就是說系統(tǒng)同時能處理的請求數(shù)量。

并發(fā)數(shù)反應了系統(tǒng)的負載能力。

QPS 和 TPS

• QPS（Query Per Second） ：服務器每秒可以執(zhí)行的查詢次數(shù)；
• TPS（Transaction Per Second） ：服務器每秒處理的事務數(shù)（這里的一個事務可以理解為客戶發(fā)出請求到收到服務器的過程）；

書中是這樣描述 QPS 和 TPS 的區(qū)別的。

QPS vs TPS：QPS 基本類似于 TPS，但是不同的是，對于一個頁面的一次訪問，形成一個 TPS；但一次頁面請求，可能產(chǎn)生多次對服務器的請求，服務器對這些請求，就可計入“QPS”之中。如，訪問一個頁面會請求服務器 2 次，一次訪問，產(chǎn)生一個“T”，產(chǎn)生 2 個“Q”。

吞吐量

吞吐量指的是系統(tǒng)單位時間內(nèi)系統(tǒng)處理的請求數(shù)量。

一個系統(tǒng)的吞吐量與請求對系統(tǒng)的資源消耗等緊密關聯(lián)。請求對系統(tǒng)資源消耗越多，系統(tǒng)吞吐能力越低，反之則越高。

TPS、QPS 都是吞吐量的常用量化指標。

• QPS（TPS） = 并發(fā)數(shù)/平均響應時間(RT)
• 并發(fā)數(shù) = QPS * 平均響應時間(RT)

系統(tǒng)活躍度

介紹幾個描述系統(tǒng)活躍度的常見名詞，建議牢牢記住。你不光會在回答系統(tǒng)設計面試題的時候碰到，日常工作中你也會經(jīng)常碰到這些名詞。

PV(Page View)

訪問量, 即頁面瀏覽量或點擊量，衡量網(wǎng)站用戶訪問的網(wǎng)頁數(shù)量；在一定統(tǒng)計周期內(nèi)用戶每打開或刷新一個頁面就記錄 1 次，多次打開或刷新同一頁面則瀏覽量累計。UV 從網(wǎng)頁打開的數(shù)量/刷新的次數(shù)的角度來統(tǒng)計的。

UV(Unique Visitor)

獨立訪客，統(tǒng)計 1 天內(nèi)訪問某站點的用戶數(shù)。1 天內(nèi)相同訪客多次訪問網(wǎng)站，只計算為 1 個獨立訪客。UV 是從用戶個體的角度來統(tǒng)計的。

DAU(Daily Active User)

日活躍用戶數(shù)量。

MAU(monthly active users)

月活躍用戶人數(shù)。

舉例：某網(wǎng)站 DAU 為 1200w， 用戶日均使用時長 1 小時，RT 為 0.5s，求并發(fā)量和 QPS。

平均并發(fā)量 = DAU（1200w）* 日均使用時長（1 小時，3600 秒） /一天的秒數(shù)（86400）=1200w/24 = 50w

真實并發(fā)量（考慮到某些時間段使用人數(shù)比較少） = DAU（1200w）* 日均使用時長（1 小時，3600 秒） /一天的秒數(shù)-訪問量比較小的時間段假設為 8 小時（57600）=1200w/16 = 75w

峰值并發(fā)量 = 平均并發(fā)量 * 6 = 300w

QPS = 真實并發(fā)量/RT = 75W/0.5=100w/s

常用性能測試工具

后端常用

既然系統(tǒng)設計涉及到系統(tǒng)性能方面的問題，那在面試的時候，面試官就很可能會問：你是如何進行性能測試的？

推薦 4 個比較常用的性能測試工具：

1. Jmeter ：Apache JMeter 是 JAVA 開發(fā)的性能測試工具。
2. LoadRunner：一款商業(yè)的性能測試工具。
3. Galtling ：一款基于 Scala 開發(fā)的高性能服務器性能測試工具。
4. ab ：全稱為 Apache Bench 。Apache 旗下的一款測試工具，非常實用。

沒記錯的話，除了 LoadRunner 其他幾款性能測試工具都是開源免費的。

前端常用

1. Fiddler：抓包工具，它可以修改請求的數(shù)據(jù)，甚至可以修改服務器返回的數(shù)據(jù)，功能非常強大，是 Web 調(diào)試的利器。
2. HttpWatch: 可用于錄制 HTTP 請求信息的工具。

常見軟件的 QPS

這里給出的 QPS 僅供參考，實際項目需要進行壓測來計算。

• Nginx ：一般情況下，系統(tǒng)的性能瓶頸基本不會是 Nginx。單機 Nginx 可以達到 30w +。
• Redis: Redis 官方的性能測試報告：https://redis.io/topics/benchmarks 。從報告中，我們可以得出 Redis 的單機 QPS 可以達到 8w+（CPU 性能有關系，也和執(zhí)行的命令也有關系比如執(zhí)行 SET 命令甚至可以達到 10w+QPS）。
• MySQL: MySQL 單機的 QPS 為 大概在 4k 左右。
• Tomcat ：單機 Tomcat 的 QPS 在 2w 左右。這個和你的 Tomcat 配置有很大關系，舉個例子 Tomcat 支持的連接器有 NIO、NIO.2 和 APR。AprEndpoint 是通過 JNI 調(diào)用 APR 本地庫而實現(xiàn)非阻塞 I/O 的，性能更好，Tomcat 配置 APR 為 連接器的話，QPS 可以達到 3w 左右。更多相關內(nèi)容可以自行搜索 Tomcat 性能優(yōu)化。

系統(tǒng)設計原則

合適優(yōu)于先進 > 演化優(yōu)于一步到位 > 簡單優(yōu)于復雜

常見的性能優(yōu)化策略

性能優(yōu)化之前我們需要對請求經(jīng)歷的各個環(huán)節(jié)進行分析，排查出可能出現(xiàn)性能瓶頸的地方，定位問題。

下面是一些性能優(yōu)化時，我經(jīng)常拿來自問的一些問題：

1. 當前系統(tǒng)的 SQL 語句是否存在問題？
2. 當前系統(tǒng)是否需要升級硬件？
3. 系統(tǒng)是否需要緩存？
4. 系統(tǒng)架構本身是不是就有問題？
5. 系統(tǒng)是否存在死鎖的地方？
6. 數(shù)據(jù)庫索引使用是否合理？
7. 系統(tǒng)是否存在內(nèi)存泄漏？（Java 的自動回收內(nèi)存雖然很方便，但是，有時候代碼寫的不好真的會造成內(nèi)存泄漏）
8. 系統(tǒng)的耗時操作進行了異步處理？
9. ……

性能優(yōu)化必知法則

SQL 優(yōu)化，JVM、DB，Tomcat 參數(shù)調(diào)優(yōu) > 硬件性能優(yōu)化（內(nèi)存升級、CPU 核心數(shù)增加、機械硬盤—>固態(tài)硬盤等等）> 業(yè)務邏輯優(yōu)化/緩存 > 讀寫分離、集群等 > 分庫分表

系統(tǒng)設計面試的注意事項

想好再說

沒必要面試官剛問了問題之后，你沒準備好就開始回答。這樣不會給面試官帶來好印象的！系統(tǒng)設計本就需要面試者結合自己的以往的經(jīng)驗進行思考，這個過程是需要花費一些時間的。

沒有絕對的答案

系統(tǒng)設計沒有標準答案。重要的是你和面試官一起交流的過程。

一般情況下，你會在和面試官的交流過程中，一步一步完成系統(tǒng)設計。這個過程中，你會在面試官的引導下不斷完善自己的系統(tǒng)設計方案。

因此，你不必要在系統(tǒng)設計面試之前找很多題目，然后只是單純記住他們的答案。

勿要絕對

系統(tǒng)設計沒有最好的設計方案，只有最合適的設計方案。這就類比架構設計了：軟件開發(fā)沒有銀彈，架構設計的目的就是選擇合適的解決方案。 何為銀彈？ 狼人傳說中，只有銀彈(銀質子彈)才能制服這些猛獸。對應到軟件開發(fā)活動中，銀彈特指開發(fā)者們尋求的一種克服軟件開發(fā)這個難纏的猛獸的“萬能鑰匙 ?”。

權衡利弊

知道使用某個技術可能會為系統(tǒng)帶來的利弊。比如使用消息隊列的好處是解耦和削峰，但是，同樣也讓系統(tǒng)可用性降低、復雜性提高，同時還會存在一致性問題（消息丟失或者消息未被消費咋辦）。

慢慢優(yōu)化

剛開始設計的系統(tǒng)不需要太完美，可以慢慢優(yōu)化。

不追新技術

使用穩(wěn)定的、適合業(yè)務的技術，不必要過于追求新技術。

追簡避雜

系統(tǒng)設計應當追求簡單避免復雜。KISS（ Keep It Simple, Stupid）原則——保持簡單，易于理解。

總結

這篇文章簡單帶著小伙伴們分析了一下系統(tǒng)設計面試。如果你還想要深入學習的話，可以參考：https://github.com/donnemartin/system-design-primer 。

參考

1. https://github.com/donnemartin/system-design-primer
2. https://www.acecodeinterview.com/intro/
3. https://gist.github.com/vasanthk/485d1c25737e8e72759f