【面試必看，2021最新京東Java面試題目

所以，你還要不斷經過實戰項目鍛鍊本身的系統設計能力。

保持好奇心

多思考本身常常瀏覽的網站是怎麼作的。好比：

• 你刷微博的時候能夠思考一下微博是如何記錄點贊數量的？

• 你看嗶哩嗶哩的時候能夠思考一下消息提醒系統是如何作的？

• 你使用短鏈系統的時候能夠考慮一下短鏈系統是如何作的？

• …

技術選型

實現一樣的功能，通常會有多種技術選擇方案，好比緩存用Redis 仍是Memcached、網關用 Spring Cloud Gateway仍是Netflix Zuul2 。 不少時候，面試官在系統設計面過程當中會具體到技術的選型，於是，你須要區分不一樣技術的優缺點。

系統設計面試必知

---

系統設計的時候必然離不開描述性能相關的指標好比 QPS。

性能相關的指標

響應時間

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

RT是一個很是重要且直觀的指標，RT數值大小直接反應了系統處理用戶請求速度的快慢。

併發數

併發數能夠簡單理解爲系統可以同時供多少人訪問使用也就是說系統同時能處理的請求數量。

併發數反應了系統的負載能力。

QPS 和 TPS

• QPS（Query Per Second） ：服務器每秒能夠執行的查詢次數；

• TPS（Transaction Per Second） ：服務器每秒處理的事務數（這裏的一個事務能夠理解爲客戶發出請求到收到服務器的過程）；

書中是這樣描述 QPS 和 TPS 的區別的。

QPS vs TPS：QPS 基本相似於

TPS，可是不一樣的是，對於一個頁面的一次訪問，造成一個TPS；但一次頁面請求，可能產生屢次對服務器的請求，服務器對這些請求，就可計入「QPS」之中。如，訪問一個頁面會請求服務器2次，一次訪問，產生一個「T」，產生2個「Q」。

吞吐量

吞吐量指的是系統單位時間內系統處理的請求數量。

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

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

• QPS（TPS） = 併發數/平均響應時間(RT)

• 併發數 = QPS * 平均響應時間(RT)

系統活躍度

介紹幾個描述系統活躍度的常見名詞，建議緊緊記住。你不光會在回答系統設計面試題的時候碰到，平常工做中你也會常常碰到這些名詞。

PV(Page View)

訪問量, 即頁面瀏覽量或點擊量，衡量網站用戶訪問的網頁數量；在必定統計週期內用戶每打開或刷新一個頁面就記錄1次，屢次打開或刷新同一頁面則瀏覽量累計。UV 從網頁打開的數量/刷新的次數的角度來統計的。

UV(Unique Visitor)

獨立訪客，統計1天內訪問某站點的用戶數。1天內相同訪客屢次訪問網站，只計算爲1個獨立訪客。UV 是從用戶個體的角度來統計的。

DAU(Daily Active User)

日活躍用戶數量。

MAU(monthly active users)

月活躍用戶人數。

舉例：某網站 DAU爲 1200w， 用戶日均使用時長 1 小時，RT爲0.5s，求併發量和QPS。

平均併發量 = DAU（1200w）* 日均使用時長（1 小時，3600秒） /一天的秒數（86400）=1200w/24 = 50w

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

峯值併發量 = 平均併發量 * 6 = 300w

QPS = 真實併發量/RT = 75W/0.5=100w/s

經常使用性能測試工具

後端經常使用

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

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

1. Jmeter：Apache JMeter 是 JAVA 開發的性能測試工具。

2. LoadRunner：一款商業的性能測試工具。

3. Galtling：一款基於Scala 開發的高性能服務器性能測試工具。

4. ab：全稱爲 Apache Bench 。Apache 旗下的一款測試工具，很是實用。

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

前端經常使用

1. Fiddler：抓包工具，它能夠修改請求的數據，甚至能夠修改服務器返回的數據，功能很是強大，是Web 調試的利器。

2. HttpWatch: 可用於錄製HTTP請求信息的工具。

常見軟件的QPS

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

• Nginx ：通常狀況下，系統的性能瓶頸基本不會是 Nginx。單機 Nginx 能夠達到 30w +。

• Redis: Redis 官方的性能測試報告：https://redis.io/topics/benchmarks 。從報告中，咱們能夠得出 Redis 的單機 QPS 能夠達到 8w+（CPU性能有關係，也和執行的命令也有關係好比執行 SET 命令甚至能夠達到10w+QPS）。

• MySQL: MySQL 單機的 QPS 爲 大概在 4k 左右。

• Tomcat ：單機 Tomcat 的QPS 在 2w左右。這個和你的 Tomcat 配置有很大關係，舉個例子Tomcat 支持的鏈接器有 NIO、NIO.2 和 APR。 AprEndpoint 是經過 JNI 調用 APR 本地庫而實現非阻塞 I/O 的，性能更好，Tomcat 配置 APR 爲 鏈接器的話，QPS 能夠達到 3w左右。更多相關內容能夠自行搜索 Tomcat 性能優化。

系統設計原則

合適優於先進 > 演化優於一步到位 > 簡單優於複雜

常見的性能優化策略

性能優化以前咱們須要對請求經歷的各個環節進行分析，排查出可能出現性能瓶頸的地方，定位問題。

下面是一些性能優化時，我常常拿來自問的一些問題：

1. 當前系統的SQL語句是否存在問題？

2. 當前系統是否須要升級硬件？

3. 系統是否須要緩存？

4. 系統架構自己是否是就有問題？

5. 系統是否存在死鎖的地方？

6. 數據庫索引使用是否合理？

7. 系統是否存在內存泄漏？（Java 的自動回收內存雖然很方便，可是，有時候代碼寫的很差真的會形成內存泄漏）

8. 系統的耗時操做進行了異步處理？

9. ……

性能優化必知法則

SQL優化，JVM、DB，Tomcat參數調優 > 硬件性能優化（內存升級、CPU核心數增長、機械硬盤—>固態硬盤等等）> 業務邏輯優化/緩存 > 讀寫分離、集羣等 > 分庫分表

系統設計面試的注意事項

---

1.想好再說

不必面試官剛問了問題以後，你沒準備好就開始回答。這樣不會給面試官帶來好印象的！系統設計本就須要面試者結合本身的以往的經驗進行思考，這個過程是須要花費一些時間的。

2.沒有絕對的答案

系統設計沒有標準答案。重要的是你和麪試官一塊兒交流的過程。

最後

2020年在匆匆忙忙慌慌亂亂中就這麼度過了，咱們迎來了新一年，互聯網的發展如此之快，技術突飛猛進，更新迭代成爲了這個時代的代名詞，堅持下來的技術體系會愈來愈健壯，JVM做爲現在是跳槽大廠必備的技能，若是你還沒掌握，更別提以後更新的新技術了。

更多JVM面試整理：

點擊這裏免費下載「百萬級」「JVM筆記」