這個是我面試的一道題：解決方案在下面 如果能夠幫到你，請喜歡 關注一下。

嚴重鄙視伸手黨。

一、解決方案設計題：

考慮災備（比如由于火災、斷電等原因導致服務器不可用）與負載（指突然間有大量客戶端訪問數據導致服務器任務量加大），公司在a、b兩機房分別部署了服務器，請你設計客戶端訪問服務端的方案，以便達到最優交互體驗。

一．災備解決方案：

根據請求服務器a的響應來判斷服務器的狀態，200是正常，非200是錯誤，錯誤切換另一個服務器b，并且設置默認下次訪問服務器b；下面的解決方案一并解決此方案；

二．負載解決方案：

在服務器方面來看待是，正常來說完成一次訪問，通常在0.1-5s間，正常的情況下取1s一次訪問來說，APP每次訪該資源到服務器響應后得到數據有一個時間過程；

在服務器測試階段，同時訪問服務器的用戶數量不同，響應時間不同；

舉例:1000個用戶同時訪問，從訪問到拿到數據時間為梯度t1s

2000個用戶同時訪問，從訪問到拿到數據時間為梯度t2s

3000個用戶同時訪問，從訪問到拿到數據時間為梯度t3s

…………

當然可以分的更細一點。

當一個服務器的資源對一個APP接受訪問的時候，就相當于已經為一個APP開啟一個線程了，對于服務器的情況不同同時開啟的線程數不同，當大量客戶端訪問服務器的時候，服務器開啟的線程就會增多，線程一增多每個線程分得的時間片就少，相對于來說用戶訪問數據的時間就長了。在服務器方面來看待是，APP每次訪該資源到服務器響應后得到數據有一個時間過程，此時app可以記錄此次訪問用得的時間timeA，在APP測試的階段設定訪問時間段為標準值假如設定t1s，當本次APP訪問服務器a的時間大于t1s的時候下次再次訪問服務器就是訪問服務器b，同時記錄此次時間段timeNow，如果timeNow> t1，此時

說明兩臺服務器各自訪問人數均在1000人以上，此時

標準值為第二梯度值t2s；當用戶在高梯度值訪問一段時間后，此時標準值自動設置成比當前梯度值低一級，這樣就能解決當服務器a，b;都在大負荷的時候，此時假如其中一臺服務器a用戶量降低了；另一太服務器的負荷能力；

依次類推每次獲得的timeNow跟梯度值對比，再對服務器訪問的時間對比；

把服務器的訪問時間梯度值分的越細，用戶體驗就越好，因為這些用戶對服務器的選擇更合理；