共計 3294 個字符，預計需要花費 9 分鐘才能閱讀完成。

這篇文章主要介紹“Linux 經典面試題有哪些”的相關知識，丸趣 TV 小編通過實際案例向大家展示操作過程，操作方法簡單快捷，實用性強，希望這篇“Linux 經典面試題有哪些”文章能幫助大家解決問題。

1、介紹下自己？

（幾乎每家公司首先都會讓你做個自我介紹，好像是必修課一樣）

回答：此處省略筆者的自我介紹，筆者建議介紹自己的時間不宜過長，3- 4 分鐘為宜，說多了面試官會覺得你太啰嗦了。說太少了也不行，那樣會讓人感覺你的經歷太簡單了、太空了。

正常情況下，一般你在做自我介紹的同時，面試官這個時候在看你的簡歷，他需要一邊看簡歷、一邊聽你介紹自己，如果你說個幾句話就把自己介紹完了，他肯定還沒緩過神來，對你的映像會減分的。在介紹的同時思維要清晰，邏輯要清楚，*** 是根據你簡歷上寫的經歷來介紹，這樣可以把面試官的思路帶到你這里來，讓他思路跟著你走。不要東扯一句，西扯一句。

盡量少介紹自己的性格、愛好（*** 能不說就不說），你可以簡單羅列干過幾家公司（最多羅列 3 家公司 / 也包含目前所在的公司，注意順序不要亂），都在那幾家公司負責什么工作，都用過什么技術，在著重介紹一下你目前所在的公司是負責哪些工作的，可以稍微詳細一點介紹，不要讓面試官聽著暈頭轉向的感覺。

2、灰度發(fā)布如何實現？

回答：這個問題事后在知乎上看到了一位網友的建議覺得不錯，大家可以參考看一下！

仔細考慮一下灰度發(fā)布系統(tǒng)要達到哪些目的，基本就能有答案了。需要注意的是，客戶端應用（無論 PC 端還是移動端）的灰度發(fā)布要比 Web 應用的灰度發(fā)布更為復雜，因為應用運行在用戶持有的終端上，數據采集和回滾都更為困難（但可采集的數據類型要更加豐富）。

注：本人缺乏移動客戶端產品的經驗，下述內容可能不適用于移動客戶端產品。

我所理解的灰度發(fā)布系統(tǒng)，主要任務是從產品用戶群中按照一定策略選取部分用戶，讓他們先行體驗新版本的應用，通過收集這部分用戶對新版本應用的顯式反饋（論壇、微博）或隱式反饋（應用自身統(tǒng)計數據），對新版本應用的功能、性能、穩(wěn)定性等指標進行評判，進而決定繼續(xù)放大新版本投放范圍直至全量升級或回滾至老版本。

從上述描述可以得出灰度發(fā)布系統(tǒng)需要具備的一些要素：

用戶標識

用于區(qū)分用戶，輔助數據統(tǒng)計，保證灰度發(fā)布過程中用戶體驗的連貫性（避免用戶在新舊版本中跳變，匿名 Web 應用比較容易有這個問題）。匿名 Web 應用可采用 IP、Cookie 等，需登錄的應用可直接采用應用的帳號體系。

目標用戶選取策略

即選取哪些用戶先行體驗新版本，是強制升級還是讓用戶自主選擇等。可考慮的因素很多，包括但不限于地理位置、用戶終端特性（如分辨率、性能）、用戶自身特點（性別、年齡、忠誠度等）。對于細微修改（如文案、少量控件位置調整）可直接強制升級，對于類似新浪微博改版這樣的大型升級，應讓用戶自主選擇，*** 能夠提供讓用戶自主回滾至舊版本的渠道。

對于客戶端應用，可以考慮類似 Chrome 的多 channel 升級策略，讓用戶自主選擇采用 stable、beta、unstable channel 的版本。在用戶有明確預期的情況下自行承擔試用風險。

數據反饋

用戶數據反饋：在得到用戶允許的前提下，收集用戶的使用新版本應用的情況。如客戶端性能、客戶端穩(wěn)定性、使用次數、使用頻率等。用于與舊版本進行對比，決策后續(xù)是繼續(xù)擴大新版本投放范圍還是回滾。

服務端數據反饋：新版本服務端性能、服務端穩(wěn)定性等，作用與用戶數據反饋類似。

新版本回滾策略

當新版本灰度發(fā)布表現不佳時，應回滾至舊版本。對于純粹的 Web 應用而言，回滾相對簡單。主要難點在于用戶數據的無縫切換。對于客戶端應用，如果期待用戶自行卸載新版本另行安裝舊版本，成本和流失率都太高。可以考慮通過快速另行發(fā)布新版本，利用升級來“回滾”，覆蓋上次灰度發(fā)布的修改。

對于移動客戶端，新版本發(fā)布成本較高，需要 Appstore、Market 審核。本人沒有移動客戶端產品的經驗，不太確定移動客戶端產品如何處理灰度發(fā)布及回滾。但盡量將客戶端打造成 Web App，會更有利于升級和回滾。（不過蘋果對純 Web App 類的 App 有較強的限制，好像已經不允許在 Appstore 上發(fā)布這類應用了？）

新版本公關運營支持

對于改版級別的大型升級，需要配合公關運營支持，用于及時處理用戶在微博、博客等渠道給出的“顯式反饋”。對比通過隱式數據反饋得到的結論后，綜合考慮應對策略。

3、Mongodb 熟悉嗎，一般部署幾臺？

回答：部署過，沒有深入研究過，一般 mongodb 部署主從、或者 mongodb 分片集群；建議 3 臺或 5 臺服務器來部署。MongoDB 分片的基本思想就是將集合切分成小塊。這些塊分散到若干片里面，每個片只負責總數據的一部分。對于客戶端來說，無需知道數據被拆分了，也無需知道服務端哪個分片對應哪些數據。

數據在分片之前需要運行一個路由進程，進程名為 mongos。這個路由器知道所有數據的存放位置，知道數據和片的對應關系。對客戶端來說，它僅知道連接了一個普通的 mongod，在請求數據的過程中，通過路由器上的數據和片的對應關系，路由到目標數據所在的片上，如果請求有了回應，路由器將其收集起來回送給客戶端。

4、如何發(fā)布和回滾，用 jenkins 又是怎么實現？

回答：發(fā)布：jenkins 配置好代碼路徑（SVN 或 GIT），然后拉代碼，打 tag。需要編譯就編譯，編譯之后推送到發(fā)布服務器（jenkins 里面可以調腳本），然后從分發(fā)服務器往下分發(fā)到業(yè)務服務器上。

回滾：按照版本號到發(fā)布服務器找到對應的版本推送

5、Tomcat 工作模式？

回答：Tomcat 是一個 JSP/Servlet 容器。其作為 Servlet 容器，有三種工作模式：獨立的 Servlet 容器、進程內的 Servlet 容器和進程外的 Servlet 容器。

進入 Tomcat 的請求可以根據 Tomcat 的工作模式分為如下兩類：

Tomcat 作為應用程序服務器：請求來自于前端的 web 服務器，這可能是 Apache, IIS, Nginx 等；

Tomcat 作為獨立服務器：請求來自于 web 瀏覽器；

6、監(jiān)控用什么實現的？

回答：現在公司的業(yè)務都跑在阿里云上，我們 *** 的監(jiān)控就是用阿里云監(jiān)控，阿里云監(jiān)控自帶了 ECS、RDS 等服務的監(jiān)控模板，可結合自定義報警規(guī)則來觸發(fā)監(jiān)控項。上家公司的業(yè)務是托管在 IDC，用的是 zabbix 監(jiān)控方案，zabbix 圖形界面豐富，也自帶很多監(jiān)控模板，特別是多個分區(qū)、多個網卡等自動發(fā)現并進行監(jiān)控做得非常不錯，不過需要在每臺客戶機（被監(jiān)控端）安裝 zabbix agent。

7、你是怎么備份數據的，包括數據庫備份？

回答：在生產環(huán)境下，不管是應用數據、還是數據庫數據首先在部署的時候就會有主從架構，這本身就是是屬于數據的熱備份；

其實考慮冷備份，用專門一臺服務器做為備份服務器，比如可以用 rsync+inotify 配合計劃任務來實現數據的冷備份，如果是發(fā)版的包備份，正常情況下有臺發(fā)布服務器，每次發(fā)版都會保存好發(fā)版的包。

總結一下面試注意幾點事項：

***，你要對自己的簡歷很熟悉

簡歷上的寫的技能自己一定要能說出個一二，因為面試官的很多問題都會挑你簡歷上寫的問。比如你簡歷上寫了這么一條技能“熟悉 mysql 數據庫的部署安裝及原理”。你即然寫了這么一條技能，你在怎么不熟悉你也要了解 mysql 的原理，能說出個大概意思。萬一面試官問到了你寫的這一條，你都答不上來，那在他心里你又減分了，基本上這次面試希望不大。

第二，不要不懂裝懂

如果面試官問到你不會的問題，你就說這個不太熟悉，沒有具體研究過，千萬別不懂裝懂，還扯一堆沒用的話題來掩飾，這樣只會讓面試官反感你。

第三，準備充分

竟可能多的記住原理性的知識，一般面試問的多的就是原理。很少問具體的配置文件是怎么配置的。面試前也要了解清楚“職位描述”和“崗位要求”，雖然有時候大多數不會問到崗位要求的問題，但也要了解和熟悉。

第四，面試完后一定要總結

關于“Linux 經典面試題有哪些”的內容就介紹到這里了，感謝大家的閱讀。如果想了解更多行業(yè)相關的知識，可以關注丸趣 TV 行業(yè)資訊頻道，丸趣 TV 小編每天都會為大家更新不同的知識點。