你們要的面試題來啦！

最近很多朋友在後臺諮詢

京東雲面試 的問題

“小編，你們面試一般都有幾輪啊？”

“小編，你們可以一個 面試福利嗎 ？”

“小編，才畢業一年可以進你們公司嗎？”

“小編，我就是想要 面試題 。”

emm……

作為貼心的小編??

當然會儘量滿足大家的需求

今天我們挑了部分

可能出現在 京東雲 面試實戰中的題目  和大家分享

Q:

使用者訪問京東網站時都透過瀏覽器輸入網址而非IP地址，其中是藉助DNS進行解析，在DNS解析中都會經過哪些過程？

A：

1. 使用者輸入訪問的域名，查詢本機DNS快取
2. 如果本地快取未命中則向LocalDNS進行查詢
3. 如果LocalDNS快取則返回結果，如果快取未命中則向ROOT DNS進行迭代
4. 查詢，獲得域名的權威DNS地址
5. LocalDNS向權威DNS查詢域名的IP地址
6. LocalDNS將IP地址返回給使用者並快取解析記錄
7. 使用者使用IP地址進行訪問

Q：

在京東專有云環境中，涉及到眾多的系統，一個系統的響應快慢可能決定著產品效能的好壞，請問如果發現一個應用響應緩慢，如何最佳化？

A：

一個介面的響應緩慢可能是多方面的原因，具體分析如下：

1. 前端介面呼叫 ：如介面本身呼叫速度較快，而到達前端的耗時較大，或是頻寬較少，或是介面返回資料較多導致緩慢。可適量增加頻寬，或使用cdn等方式加速靜態資源。
2. 應用程式方面 ：確保程式演算法足夠最佳化，無特耗時的演算法處理，如演算法無業務處理瓶頸，則可利用多執行緒將應用邏輯與資料處理併發處理，分而治之，加快響應速度。
3. 資料庫方面 ：檢視資料庫慢日誌資訊，確定待最佳化的sql語句，檢視sql語句是否使用索引，如未使用索引，可為其建立索引，如已使用索引，則最佳化索引結構(如是否符合三星索引等)，減少sql語句查詢資料的隨機訪問磁碟次數，加快資料的檢索速度。其次可增加資料庫記憶體大小，新增查詢快取等減少資料庫層面的耗時。
4. 快取方面 ：對於常用資料資訊也可將其存放到快取中，如使用Redis、Memcache等中介軟體產品，減少程式對磁碟的訪問，加快應用響應速度。
5. 應用伺服器效能方面 ：伺服器的效能是有限的，當一臺伺服器資源被佔用殆盡時，可適量橫向擴充套件伺服器數量，使多個伺服器均衡處理請求，提高服務響應能力。

Q:

京東商城在舉辦促銷活動期間，經常會有業務訪問量大幅波動的情況發生，為保證業務平穩健康的執行，一般需要在促銷活動之前人工擴充套件叢集規模。能否使用雲產品來應對這種場景？

A：

彈性伸縮產品。彈性伸縮透過設定伸縮策略，可以自動調整叢集規模。在業務高峰期，自動增加雲主機例項的數量，保證業務效能不受影響；當業務需求較低時，減少雲主機例項數量，以節省成本。

Q:

彈性伸縮有哪幾種伸縮策略？適用的場景有哪些？

A：

1. 定時策略 ：在指定週期內定時伸縮叢集規模，適用於業務負載變化情況可預知的場景；
2. 告警策略 ：基於監控指標（如CPU、記憶體利用率）動態擴充套件伸縮組中的例項數，適用於無法預估的業務波動場景。

Q:

彈性伸縮適用於什麼型別的業務？

A：

被伸縮的叢集服務需要是無狀態、可替換的。不能儲存應用的狀態資訊（如會話）和相關資料（如資料庫、日誌等）。

Q：

客戶要求在我們的專有云JDStack系統裡有一個審批流系統，用於審批資源，且需要相容IE11。產品釋出後卻發現這樣一個問題：在IE瀏覽器裡開啟審批單列表，刪除其中一條後，前端會重新請求列表，此時後端確定已刪除此條資料，但是介面裡卻仍然返回了此條資料。請問是什麼原因？如何解決？

A：

此問題的出現是由於IE瀏覽器對ajax的get請求響應存在快取機制。即當我們請求過一次列表，緊接著刪除一條資料之後重新傳送此獲取列表的get請求，那麼IE瀏覽器只會把第一次請求該介面的資料拿出來，所以我們看到的頁面資料是沒有變化的，留心看控制檯的介面情況，可以發現狀態碼是“304”，即表示“只讀/無變化 Not Modified”。

解決這個問題的方法除了把get改成post，也可以在請求介面上做一些處理，讓瀏覽器認為前後兩次請求是不一樣的，即在url後加上時間字尾的方法：

url:'xxxxxxxxxxxxxxxxxxx+"&"+new Date()

Q:

A是一個建構函式，var a = new A()，那麼new運算子做了什麼？

A：

首先建立了一個物件。然後每個物件都有一個__proto__屬性，指向它所對應的原型物件，並且繼承了原型的方法和屬性。其次，每一個函式被建立的時候，JS都會自動為函式新增prototype屬性，這個屬性指向一個包含constructor欄位的物件，constructor物件指向函式自身。

如果把函式當做建構函式，即透過new關鍵字創造例項的時候，就會把例項的__proto__屬性指向建構函式的prototype屬性，然後把建構函式prototype上constructor屬性傳遞給例項，並且建構函式內部物件的this替換成例項。

所以new一共做了四件事情：

1. 創造一個物件；
2. 例項.__proto__ ===> 建構函式.prototype；
3. 例項.constructor ===> 建構函式；
4. 建構函式.call(例項)。