nginx面試

⑴ 面試官：請問Nginx為什麼比Apache性能好

Nginx才短短幾年，就拿下了web伺服器大筆江山，眾所周知，Nginx在處理大並發靜態請求方面，效率明顯高於httpd，甚至能輕松解決C10K問題。下面我們就來聊聊Web伺服器背後的一些原理。

進程是具有一定獨立功能的，在計算機中已經運行的程序的實體。在早期系統中（如linux 2.4以前），進程是基本運作單位，在支持線程的系統中（如windows，linux2.6）中，線程才是基本的運作單位，而進程只是線程的容器。程序本身只是指令、數據及其組織形式的描述，進程才是程序（那些指令和數據）的真正運行實例。若干進程有可能與同一個程序相關系，且每個進程皆可以同步（循序）或非同步（平行）的方式獨立運行。現代計算機系統可在同一段時間內以進程的形式將多個程序載入到存儲器中，並藉由時間共享（或稱時分復用），以在一個處理器上表現出同時（平行性）運行的感覺。同樣的，使用多線程技術（多線程即每一個線程都代表一個進程內的一個獨立執行上下文）的操作系統或計算機架構，同樣程序的平行線程，可在多 CPU 主機或網路上真正同時運行（在不同的CPU上）。

Web伺服器要為用戶提供服務，必須以某種方式，工作在某個套接字上。一般Web伺服器在處理用戶請求是，一般有如下三種方式可選擇：多進程方式、多線程方式、非同步方式。Web伺服器要為用戶提供服務，必須以某種方式，工作在某個套接字上。一般Web伺服器在處理用戶請求是，一般有如下三種方式可選擇：多進程方式、多線程方式、非同步方式。多進程方式：為每個請求啟動一個進程來處理。由於在操作系統中，生成進程、銷毀進程、進程間切換都很消耗CPU和內存，當負載高是，性能會明顯降低。優點： 穩定性！由於採用獨立進程處理獨立請求，而進程之間是獨立的，單個進程問題不會影響其他進程，因此穩定性最好。缺點： 資源佔用！當請求過大時，需要大量的進程處理請求，進程生成、切換開銷很大，而且進程間資源是獨立的，造成內存重復利用。多線程方式：一個進程中用多個線程處理用戶請求。由於線程開銷明顯小於進程，而且部分資源還可以共享，因此效率較高。優點：開銷較小！線程間部分數據是共享的，且線程生成與線程間的切換所需資源開銷比進程間切換小得多。缺點：穩定性！線程切換過快可能造成線程抖動，且線程過多會造成伺服器不穩定。非同步方式：使用非阻塞方式處理請求，是三種方式中開銷最小的。但非同步方式雖然效率高，但要求也高，因為多任務之間的調度如果出現問題，就可能出現整體故障，因此使用非同步工作的，一般是一些功能相對簡單，但卻符合伺服器任務調度、且代碼中沒有影響調度的錯誤代碼存在的程序。優點：性能最好！一個進程或線程處理多個請求，不需要額外開銷，性能最好，資源佔用最低。缺點：穩定性！某個進程或線程出錯，可能導致大量請求無法處理，甚至導致整個服務宕機。

從上圖中我們可以看出，可以看出，越往後，阻塞越少，理論上效率也是最優。其五種I/O模型中，前三種屬於同步I/O，後兩者屬於非同步I/O。

同步I/O:

非同步I/O:

非同步 I/O 和 信號驅動I/O的區別:

注，其中iocp是Windows實現的，select、poll、epoll是Linux實現的，kqueue是FreeBSD實現的，/dev/poll是SUN的Solaris實現的。select、poll對應第3種（I/O復用）模型，iocp對應第5種（非同步I/O）模型，那麼epoll、kqueue、/dev/poll呢？其實也同select屬於同一種模型，只是更高級一些，可以看作有了第4種（信號驅動I/O）模型的某些特性，如callback機制。

答案是，他們無輪詢。因為他們用callback取代了。想想看，當套接字比較多的時候，每次select()都要通過遍歷FD_SETSIZE個Socket來完成調度，不管哪個Socket是活躍的，都遍歷一遍。這會浪費很多CPU時間。如果能給套接字注冊某個回調函數，當他們活躍時，自動完成相關操作，那就避免了輪詢，這正是epoll、kqueue、/dev/poll做的。這樣子說可能不好理解，那麼我說一個現實中的例子，假設你在大學讀書，住的宿舍樓有很多間房間，你的朋友要來找你。select版宿管大媽就會帶著你的朋友挨個房間去找，直到找到你為止。而epoll版宿管大媽會先記下每位同學的房間號，你的朋友來時，只需告訴你的朋友你住在哪個房間即可，不用親自帶著你的朋友滿大樓找人。如果來了10000個人，都要找自己住這棟樓的同學時，select版和epoll版宿管大媽，誰的效率更高，不言自明。同理，在高並發伺服器中，輪詢I/O是最耗時間的操作之一，select、epoll、/dev/poll的性能誰的性能更高，同樣十分明了。

誠然，Windows的IOCP非常出色，目前很少有支持asynchronous I/O的系統，但是由於其系統本身的局限性，大型伺服器還是在UNIX下。而且正如上面所述，kqueue、epoll、/dev/poll 與 IOCP相比，就是多了一層從內核數據到應用層的阻塞，從而不能算作asynchronous I/O類。但是，這層小小的阻塞無足輕重，kqueue、epoll、/dev/poll 已經做得很優秀了。

只有IOCP(windows實現)是asynchronous I/O，其他機制或多或少都會有一點阻塞。select（Linux實現）低效是因為每次它都需要輪詢。但低效也是相對的，視情況而定，也可通過良好的設計改善epoll(Linux實現)、kqueue（FreeBSD實現）、/dev/poll（Solaris實現）是Reacor模式，IOCP是Proactor模式。Apache 2.2.9之前只支持select模型，2.2.9之後支持epoll模型Nginx 支持epoll模型Java nio包是select模型

我們都知道Apache有三種工作模塊，分別為prefork、worker、event。prefork：多進程，每個請求用一個進程響應，這個過程會用到select機制來通知。worker：多線程，一個進程可以生成多個線程，每個線程響應一個請求，但通知機制還是select不過可以接受更多的請求。event：基於非同步I/O模型，一個進程或線程，每個進程或線程響應多個用戶請求，它是基於事件驅動（也就是epoll機制）實現的。

如果不用「--with-mpm」顯式指定某種MPM,prefork就是Unix平台上預設的MPM.它所採用的預派生子進程方式也是 Apache1.3中採用的模式。prefork本身並沒有使用到線程，2.0版使用它是為了與1.3版保持兼容性；另一方面，prefork用單獨的子進程來處理不同的請求，進程之間是彼此獨立的,這也使其成為最穩定的MPM之一。

相對於prefork，worker是2.0版中全新的支持多線程和多進程混合模型的MPM。由於使用線程來處理，所以可以處理相對海量的請求，而系統資源的開銷要小於基於進程的伺服器。但是，worker也使用了多進程,每個進程又生成多個線程，以獲得基於進程伺服器的穩定性，這種MPM的工作方 式將是Apache2.0的發展趨勢。

一個進程響應多個用戶請求，利用callback機制，讓套接字復用，請求過來後進程並不處理請求，而是直接交由其他機制來處理，通過epoll機制來通知請求是否完成；在這個過程中，進程本身一直處於空閑狀態，可以一直接收用戶請求。可以實現一個進程程響應多個用戶請求。支持持海量並發連接數，消耗更少的資源。

有幾個基本條件：

剛好，Nginx 支持以上所有特性。所以Nginx官網上說，Nginx支持50000並發，是有依據的。

傳統上基於進程或線程模型架構的web服務通過每進程或每線程處理並發連接請求，這勢必會在網路和I/O操作時產生阻塞，其另一個必然結果則是對內存或CPU的利用率低下。生成一個新的進程/線程需要事先備好其運行時環境，這包括為其分配堆內存和棧內存，以及為其創建新的執行上下文等。這些操作都需要佔用CPU，而且過多的進程/線程還會帶來線程抖動或頻繁的上下文切換，系統性能也會由此進一步下降。另一種高性能web伺服器/web伺服器反向代理：Nginx（Engine X），nginx的主要著眼點就是其高性能以及對物理計算資源的高密度利用，因此其採用了不同的架構模型。受啟發於多種操作系統設計中基於「事件」的高級處理機制，nginx採用了模塊化、事件驅動、非同步、單線程及非阻塞的架構，並大量採用了多路復用及事件通知機制。在nginx中，連接請求由為數不多的幾個僅包含一個線程的進程worker以高效的回環(run-loop)機制進行處理，而每個worker可以並行處理數千個的並發連接及請求。

Nginx會按需同時運行多個進程：一個主進程(master)和幾個工作進程(worker)，配置了緩存時還會有緩存載入器進程(cache loader)和緩存管理器進程(cache manager)等。所有進程均是僅含有一個線程，並主要通過「共享內存」的機制實現進程間通信。主進程以root用戶身份運行，而worker、cache loader和cache manager均應以非特權用戶身份運行。

主進程主要完成如下工作：

註：如果負載以CPU密集型應用為主，如SSL或壓縮應用，則worker數應與CPU數相同；如果負載以IO密集型為主，如響應大量內容給客戶端，則worker數應該為CPU個數的1.5或2倍。

Nginx的代碼是由一個核心和一系列的模塊組成, 核心主要用於提供Web Server的基本功能，以及Web和Mail反向代理的功能；還用於啟用網路協議，創建必要的運行時環境以及確保不同的模塊之間平滑地進行交互。不過，大多跟協議相關的功能和某應用特有的功能都是由nginx的模塊實現的。這些功能模塊大致可以分為事件模塊、階段性處理器、輸出過濾器、變數處理器、協議、upstream和負載均衡幾個類別，這些共同組成了nginx的http功能。事件模塊主要用於提供OS獨立的(不同操作系統的事件機制有所不同)事件通知機制如kqueue或epoll等。協議模塊則負責實現nginx通過http、tls/ssl、smtp、pop3以及imap與對應的客戶端建立會話。在Nginx內部，進程間的通信是通過模塊的pipeline或chain實現的；換句話說，每一個功能或操作都由一個模塊來實現。例如，壓縮、通過FastCGI或uwsgi協議與upstream伺服器通信，以及與memcached建立會話等。

處理靜態文件，索引文件以及自動索引；反向代理加速(無緩存)，簡單的負載均衡和容錯；FastCGI，簡單的負載均衡和容錯；模塊化的結構。過濾器包括gzipping, byte ranges, chunked responses, 以及 SSI-filter 。在SSI過濾器中，到同一個 proxy 或者 FastCGI 的多個子請求並發處理；SSL 和 TLS SNI 支持；

使用外部 HTTP 認證伺服器重定向用戶到 IMAP/POP3 後端；使用外部 HTTP 認證伺服器認證用戶後連接重定向到內部的 SMTP 後端；認證方法：POP3: POP3 USER/PASS, APOP, AUTH LOGIN PLAIN CRAM-MD5;IMAP: IMAP LOGIN;SMTP: AUTH LOGIN PLAIN CRAM-MD5;SSL 支持；在 IMAP 和 POP3 模式下的 STARTTLS 和 STLS 支持；

FreeBSD 3.x, 4.x, 5.x, 6.x i386; FreeBSD 5.x, 6.x amd64;Linux 2.2, 2.4, 2.6 i386; Linux 2.6 amd64;Solaris 8 i386; Solaris 9 i386 and sun4u; Solaris 10 i386;MacOS X (10.4) PPC;Windows 編譯版本支持 windows 系列操作系統

一個主進程和多個工作進程，工作進程運行於非特權用戶；kqueue (FreeBSD 4.1+), epoll (Linux 2.6+), rt signals (Linux 2.2.19+), /dev/poll (Solaris 7 11/99+), select, 以及 poll 支持；kqueue支持的不同功能包括 EV_CLEAR, EV_DISABLE （臨時禁止事件）， NOTE_LOWAT, EV_EOF, 有效數據的數目，錯誤代碼；sendfile (FreeBSD 3.1+), sendfile (Linux 2.2+), sendfile64 (Linux 2.4.21+), 和 sendfilev (Solaris 8 7/01+) 支持；輸入過濾 (FreeBSD 4.1+) 以及 TCP_DEFER_ACCEPT (Linux 2.4+) 支持；10,000 非活動的 HTTP keep-alive 連接僅需要 2.5M 內存。最小化的數據拷貝操作；

基於IP 和名稱的虛擬主機服務；Memcached 的 GET 介面；支持 keep-alive 和管道連接；靈活簡單的配置；重新配置和在線升級而無須中斷客戶的工作進程；可定製的訪問日誌，日誌寫入緩存，以及快捷的日誌回卷；4xx-5xx 錯誤代碼重定向；基於 PCRE 的 rewrite 重寫模塊；基於客戶端 IP 地址和 HTTP 基本認證的訪問控制；PUT, DELETE, 和 MKCOL 方法；支持 FLV （Flash 視頻）；帶寬限制；

在高連接並發的情況下，Nginx是Apache伺服器不錯的替代品: Nginx在美國是做虛擬主機生意的老闆們經常選擇的軟體平台之一. 能夠支持高達 50,000 個並發連接數的響應, 感謝Nginx為我們選擇了 epoll and kqueue 作為開發模型。Nginx作為負載均衡伺服器: Nginx 既可以在內部直接支持 Rails 和 PHP 程序對外進行服務, 也可以支持作為 HTTP代理 伺服器對外進行服務. Nginx採用C進行編寫, 不論是系統資源開銷還是CPU使用效率都比 Perlbal 要好很多。作為郵件代理伺服器: Nginx 同時也是一個非常優秀的郵件代理伺服器（最早開發這個產品的目的之一也是作為郵件代理伺服器）, Last.fm 描述了成功並且美妙的使用經驗.Nginx 安裝非常的簡單 , 配置文件非常簡潔（還能夠支持perl語法）,Bugs 非常少的伺服器: Nginx 啟動特別容易, 並且幾乎可以做到7*24不間斷運行，即使運行數個月也不需要重新啟動. 你還能夠 不間斷服務的情況下進行軟體版本的升級 。Nginx 的誕生主要解決C10K問題

⑵ tomct和nginx有什麼不同,都是用來做web伺服器的嗎

從應用方面
tomcat一般是做動態解析才會用得到，支持jsp的解析，需要配置JDK支持
nginx，則一般是做靜態，本身不具備動態解析功能，需要配置其他插件或通過其他軟體協同才具備動態功能，比如php，tomcat，或者proxypass到win2008的iis伺服器做ASP的動態鏈接等，但nginx在靜態上的功能非常強大，也可做訪問控制，而且可以做成各種協議負載伺服器，包括流媒體的也可以做，具體得去官方網站去看；
在性能方面
如果再不做系統調優的情況下
tomcat一般支持並發並不高100個差不多了
nginx在靜態方面支持並發輕松達幾萬

如果這是個面試的人給你出的這道題目上你回答，你可以簡單的告訴他，兩者應用領域不一樣，tomcat是做java語言的動態解析，而nginx則是一款功能強大的負載軟體，配合各種插件可以實現各種功能

⑶ 技術面試會問很多技術問題嗎

筆者其實沒有想到去面試，只是在智聯上更新了一下簡歷，就陸陸續續接到很多獵頭的郵件和電話，實在是沒准備好要去面試，就推掉了幾家公司的面試了。正因為筆者也很久沒有面試了，筆者也想去面試學習一下，閑話少說，下面就分享給大家筆者在2018年1月4號上午10點30分的面試經歷：

首先，獵頭或者公司人資會把公司的介紹及崗位要求發到你郵箱（或者QQ、微信），下面這份是獵頭發給我的崗位說明，為了職業道德操守，公司的介紹和面試通知信息我就不貼出來了，我就把崗位要求貼出來：

職位描述：

1、 負責應用伺服器的安裝、配置、優化與維護；

2、 負責應用系統的日誌信息備份、管理、維護與分析；

3、 負責應用系統的日常監測於維護、故障處理、性能分析與優化；

4、 負責應用部署系統、環境配置系統、監控系統的開發、部署、升級與維護，建設高性能的運維平台。

崗位要求:

1、 熟悉Linux操作系統的基礎知識，熟練使用Linux常用操作命令；

2、 熟練配置Nginx、HAproxy 等應用相關軟體的部署、配置與優化維護；

3、 熟悉網路基礎知識、熟悉TCP/IP的工作原理，會配交換機或路由器，能熟練的對網路情況進行分析

4、 熟悉shell/perl/python中的一種或多種進行運維程序的開發；

5、 熟悉Nagios,Ganglia等監控軟體

看著上面的要求大家是不是覺得要求也不高啊，你要細看就會發現，這家公司要求的還挺多，不僅要會網路知識（熟悉TCP/IP好像是每家單位的都會寫這樣的要求），還要會開發技能。相信很多做運維的兄弟在網路這一塊是個頭疼的事情，都對交換機和路由器不怎麼會配置和管理。

然後，筆者詳細了解他們公司，了解崗位要求，在突擊復習一下可能會問到的知識點和技術點。到了面試的這天時間，早早的起床，把牙一定要刷干凈，特別是有口臭的兄弟，最好准備點口香糖，到達面試公司前嚼塊口香糖，以免因為口氣的原因熏到面試官，讓你在面試官心裡減分。早點要記得吃，如果你是下午面試的話也要吃午飯，吃早點了精氣神就有了。還要注意，帶上你的簡歷和一支筆，雖然他們那邊也會有你的簡歷，為了以防萬一還是准備好簡歷。

最後，關鍵點來了，就是和面試官溝通了，有筆試的公司會讓你做些面試題，沒有筆試就直接和面試官聊了，下面是我和面試官溝通完之後記住的一些問題，分享給大家看一下，筆者一共記住了7個問題，好像還有兩個問題實在想不起來了，如果大家有更恰當的回答一定要貼出來一起探討和進步：

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

筆者回答：此處省略筆者的自我介紹，筆者建議介紹自己的時間不宜過長，3-4分鍾為宜，說多了面試官會覺得你太啰嗦了。說太少了也不行，那樣會讓人感覺你的經歷太簡單了、太空了。正常情況下，一般你在做自我介紹的同時，面試官這個時候在看你的簡歷，他需要一邊看簡歷、一邊聽你介紹自己，如果你說個幾句話就把自己介紹完了，他肯定還沒緩過神來，對你的映像會減分的。在介紹的同時思維要清晰，邏輯要清楚，最好是根據你簡歷上寫的經歷來介紹，這樣可以把面試官的思路帶到你這里來，讓他思路跟著你走。不要東扯一句，西扯一句。竟量少介紹自己的性格、愛好（最好能不說就不說），你可以簡單羅列干過幾家公司（最多羅列3家公司/也包含目前所在的公司，注意順序不要亂），都在那幾家公司負責什麼工作，都用過什麼技術，在著重介紹一下你目前所在的公司是負責哪些工作的，可以稍微詳細一點介紹，不要讓面試官聽著暈頭轉向的感覺。

2、灰度發布如何實現？

筆者回答：其實對這個問題筆者也答的不好，就不寫出來誤導大家了。大家有好的方法可以共享出來。不過筆事後在知呼上看到了一位網友的建議覺得不錯，大家可以參考看一下 ：https://www.hu.com/question/20584476

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

筆者回答：部署過，沒有深入研究過，一般mongodb部署主從、或者mongodb分片集群；建議3台或5台伺服器來部署。MongoDB分片的基本思想就是將集合切分成小塊。這些塊分散到若乾片裡面，每個片只負責總數據的一部分。 對於客戶端來說，無需知道數據被拆分了，也無需知道服務端哪個分片對應哪些數據。數據在分片之前需要運行一個路由進程，進程名為mongos。這個路由器知道所有數據的存放位置，知道數據和片的對應關系。對客戶端來說，它僅知道連接了一個普通的mongod，在請求數據的過程中，通過路由器上的數據和片的對應關系，路由到目標數據所在的片上，如果請求有了回應，路由器將其收集起來回送給客戶端。

4、如何發布和回滾，用jenkins又是怎麼實現？

筆者回答：發布：jenkins配置好代碼路徑（SVN或GIT），然後拉代碼，打tag。需要編譯就編譯，編譯之後推送到發布伺服器（jenkins裡面可以調腳本），然後從分發伺服器往下分發到業務伺服器上。

回滾：按照版本號到發布伺服器找到對應的版本推送

5、Tomcat工作模式？

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

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

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

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

6、監控用什麼實現的？

筆者回答：現在公司的業務都跑在阿里雲上，我們首選的監控就是用阿里雲監控，阿里雲監控自帶了ECS、RDS等服務的監控模板，可結合自定義報警規則來觸發監控項。上家公司的業務是託管在IDC，用的是zabbix監控方案，zabbix圖形界面豐富，也自帶很多監控模板，特別是多個分區、多個網卡等自動發現並進行監控做得非常不錯，不過需要在每台客戶機（被監控端）安裝zabbix agent。

7、你是怎麼備份數據的，包括資料庫備份？

筆者回答：在生產環境下，不管是應用數據、還是資料庫數據首先在部署的時候就會有主從架構、或者集群，這本身就是屬於數據的熱備份；其實考慮冷備份，用專門一台伺服器做為備份伺服器，比如可以用rsync+inotify配合計劃任務來實現數據的冷備份，如果是發版的包備份，正常情況下有台發布伺服器，每次發版都會保存好發版的包。

總結

總結一下面試注意幾點事項，可能筆者也說得不太對，為了我們運維工作的兄弟們都能拿到高薪，大家一定要指證出來一起進步、一起探討：

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

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

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

第四，面試完後一定要總結，盡量記住面試官問的每一個問題，回去記錄下來，如果問到不會的問題，事後要立馬查網路或者找朋友搞清楚、弄明白，這樣你才能記勞，下次面試說不定又問到同樣的問題。

問完之後，面試官就跟我聊薪資待遇了，問我多少錢能達到自己的要求，我就不便透露了，可以私聊，哈哈，後續筆者會陸陸續續更新以前面試的經歷和問題，有需要的朋友可以轉載或者收藏起來一起討論。

基於大家熱情高昂的氣氛，筆者又花了一個下午的時間回憶並整理在2017年2月24號筆者在東三環邊上（快到東四環了，沒有地鐵過去，到了四惠還要轉公交車）的一家傳媒公司的面試經歷，還好筆者有做筆記的習慣，把之前面試的問題都記錄在案，這一次的面試筆者可是記憶猶新，因為這次這家公司都跟筆者發offer了，實在是真心不想去這家公司就找原因推掉了，大家可別學我這么不靠譜。下面是這家公司中的崗位要求說明：

崗位職責：
1、負責公司產品的版本控制、構建和發布管理；
2、負責公司統一配置庫管理工作，許可權管理與分配准確及時，定期完成配置備份；
3、負責公司內部開發/測試伺服器的運行管理工作；
4、負責Linux操作系統的安裝、配置、監控和維護、問題處理、軟體升級、 數據備份、應急響應、故障排除等、保證線上環境的穩定運行；
5、負責支撐平台24×7穩定運行，並進行前瞻性容量規劃；
6、負責公司機房伺服器日常維護及網路系統安裝、部署、維護工作。

崗位要求：
1、計算機相關專業本科及以上學歷，2年以上運維或配置管理工作經驗；
2、至少熟悉一種監控系統搭建，如Nagios/Zabbix/等；
3、至少熟悉一種集群管理工具，如Ansible/SaltStack等；
4、有使用集成發布工具發布構建經驗優先。比如：bamboo或者Jenkins；
5、熟悉Unix/Linux操作系統，熟悉Weblogic/tomcat等中間件，能夠編寫shell腳本，熟悉軟體開發過程及過程產品，有一定的網路基礎；
6、熟悉rsyslog, flume等日誌收集和處理系統；
7、具有強烈的安全意識及較強的溝通協調和學習能力，良好的團隊合作精神，工作積極主動。

過去之後，前台美眉把我帶到他們公司的地下室，我掃視了一下周圍的環境，貌似旁邊就是機房，因為我聽到伺服器的聲音。等了幾分鍾，面試官下來了，面試官目測比較瘦，看著跟我身材差不多（應該不到120），他說他是負責運維部的，然後開始就叫我先自我介紹，都是一個套路，免不了介紹的，所以兄弟們一定要把自我介紹練好。然後開始問我問題了，跟面試官聊得還行，問我應該有不下10個以上的問題，我記住了下面有10個問題：

1、LVS負載的原理，和Nginx負載有啥區別？

筆者回答：這個問題我覺得面試官司沒問好，正常都會這么問「LVS有哪些負載均衡技術和調度演算法?"。我回答就是按我說的這種問法回答的，反正他也頻繁點頭，當然，筆者回答的可能沒有下面我整理出來的那麼詳細，大概意思我都說明白了。

LVS是Liunx虛擬伺服器的簡稱，利用LVS提供的負載均衡技術和linux操作系統可實現高性能、高可用的伺服器集群，一般LVS都是位於整個集群系統的最前端，由一台或者多台負載調度器（Director Server）組成，分發給應用伺服器（Real Server）。它是工作在4層（也就是TCP/IP中的傳輸層），LVS是基於IP負載均衡技術的IPVS模塊來實現的，IPVS實現負載均衡機制有三種，分別是NAT、TUN和DR，詳述如下：

 VS/NAT： 即（Virtual Server via Network Address Translation）

也就是網路地址翻譯技術實現虛擬伺服器，當用戶請求到達調度器時，調度器將請求報文的目標地址（即虛擬IP地址）改寫成選定的Real Server地址，同時報文的目標埠也改成選定的Real Server的相應埠，最後將報文請求發送到選定的Real Server。在伺服器端得到數據後，Real Server返回數據給用戶時，需要再次經過負載調度器將報文的源地址和源埠改成虛擬IP地址和相應埠，然後把數據發送給用戶，完成整個負載調度過程。

可以看出，在NAT方式下，用戶請求和響應報文都必須經過Director Server地址重寫，當用戶請求越來越多時，調度器的處理能力將稱為瓶頸。

 VS/TUN ：即（Virtual Server via IP Tunneling）

也就是IP隧道技術實現虛擬伺服器。它的連接調度和管理與VS/NAT方式一樣，只是它的報文轉發方法不同，VS/TUN方式中，調度器採用IP隧道技術將用戶請求轉發到某個Real Server，而這個Real Server將直接響應用戶的請求，不再經過前端調度器，此外，對Real Server的地域位置沒有要求，可以和Director Server位於同一個網段，也可以是獨立的一個網路。因此，在TUN方式中，調度器將只處理用戶的報文請求，集群系統的吞吐量大大提高。

 VS/DR： 即（Virtual Server via Direct Routing）

也就是用直接路由技術實現虛擬伺服器。它的連接調度和管理與VS/NAT和VS/TUN中的一樣，但它的報文轉發方法又有不同，VS/DR通過改寫請求報文的MAC地址，將請求發送到Real Server，而Real Server將響應直接返回給客戶，免去了VS/TUN中的IP隧道開銷。這種方式是三種負載調度機制中性能最高最好的，但是必須要求Director Server與Real Server都有一塊網卡連在同一物理網段上。

回答負載調度演算法，IPVS實現在八種負載調度演算法，我們常用的有四種調度演算法（輪叫調度、加權輪叫調度、最少鏈接調度、加權最少鏈接調度）。一般說了這四種就夠了，也不會需要你詳細解釋這四種演算法的。你只要把上面3種負載均衡技術講明白面試官就對這道問題很滿意了。接下來你在簡單說下與nginx的區別：

LVS的優點：

抗負載能力強、工作在第4層僅作分發之用，沒有流量的產生，這個特點也決定了它在負載均衡軟體里的性能最強的；無流量，同時保證了均衡器IO的性能不會受到大流量的影響；

工作穩定，自身有完整的雙機熱備方案，如LVS+Keepalived和LVS+Heartbeat；

應用范圍比較廣，可以對所有應用做負載均衡；

配置性比較低，這是一個缺點也是一個優點，因為沒有可太多配置的東西，所以並不需要太多接觸，大大減少了人為出錯的幾率。

LVS的缺點：

軟體本身不支持正則處理，不能做動靜分離，這就凸顯了Nginx/HAProxy+Keepalived的優勢。

如果網站應用比較龐大，LVS/DR+Keepalived就比較復雜了，特別是後面有Windows Server應用的機器，實施及配置還有維護過程就比較麻煩，相對而言，Nginx/HAProxy+Keepalived就簡單一點

Nginx的優點：

工作在OSI第7層，可以針對http應用做一些分流的策略。比如針對域名、目錄結構。它的正則比HAProxy更為強大和靈活；

Nginx對網路的依賴非常小，理論上能ping通就就能進行負載功能，這個也是它的優勢所在；

Nginx安裝和配置比較簡單，測試起來比較方便；

可以承擔高的負載壓力且穩定，一般能支撐超過幾萬次的並發量；

Nginx可以通過埠檢測到伺服器內部的故障，比如根據伺服器處理網頁返回的狀態碼、超時等等，並且會把返回錯誤的請求重新提交到另一個節點；

Nginx不僅僅是一款優秀的負載均衡器/反向代理軟體，它同時也是功能強大的Web應用伺服器。LNMP現在也是非常流行的web環境，大有和LAMP環境分庭抗禮之勢，Nginx在處理靜態頁面、特別是抗高並發方面相對apache有優勢；

Nginx現在作為Web反向加速緩存越來越成熟了，速度比傳統的Squid伺服器更快，有需求的朋友可以考慮用其作為反向代理加速器；

Nginx的缺點：

Nginx不支持url來檢測。

Nginx僅能支持http和Email，這個它的弱勢。

Nginx的Session的保持，Cookie的引導能力相對欠缺。

2、redis集群的原理，redis分片是怎麼實現的，你們公司redis用在了哪些環境？

筆者回答：reids集群原理：

其實它的原理不是三兩句話能說明白的，redis 3.0版本之前是不支持集群的，官方推薦最大的節點數量為1000，至少需要3(Master)+3(Slave)才能建立集群，是無中心的分布式存儲架構，可以在多個節點之間進行數據共享，解決了Redis高可用、可擴展等問題。集群可以將數據自動切分(split)到多個節點，當集群中的某一個節點故障時，redis還可以繼續處理客戶端的請求。

redis分片：

分片(partitioning)就是將你的數據拆分到多個 Redis 實例的過程，這樣每個實例將只包含所有鍵的子集。當數據量大的時候,把數據分散存入多個資料庫中,減少單節點的連接壓力,實現海量數據存儲。分片部署方式一般分為以下三種：

（1）在客戶端做分片；這種方式在客戶端確定要連接的redis實例，然後直接訪問相應的redis實例；

（2）在代理中做分片；這種方式中，客戶端並不直接訪問redis實例，它也不知道自己要訪問的具體是哪個redis實例，而是由代理轉發請求和結果；其工作過程為：客戶端先將請求發送給代理，代理通過分片演算法確定要訪問的是哪個redis實例，然後將請求發送給相應的redis實例，redis實例將結果返回給代理，代理最後將結果返回給客戶端。

（3）在redis伺服器端做分片；這種方式被稱為「查詢路由」，在這種方式中客戶端隨機選擇一個redis實例發送請求，如果所請求的內容不再當前redis實例中它會負責將請求轉交給正確的redis實例，也有的實現中，redis實例不會轉發請求，而是將正確redis的信息發給客戶端，由客戶端再去向正確的redis實例發送請求。

redis用在了哪些環境：

java、php環境用到了redis，主要緩存有登錄用戶信息數據、設備詳情數據、會員簽到數據等

3、你會怎麼統計當前訪問的IP，並排序？

筆者回答：統計用戶的訪問IP，用awk結合uniq、sort過濾access.log日誌就能統計並排序好。一般這么回答就夠了，當然你還可以說出其它方式來統計，這都是你的加分項。

4、你會使用哪些虛擬化技術？

筆者回答：vmware vsphere及kvm，我用得比較多的是vmware vsphere虛擬化，幾本上生產環境都用的vmware vsphere，kvm我是用在測試環境中使用。vmware 是屬於原生架構虛擬化技術，也就是可直接在硬體上運行。kvm屬於寄居架構的虛擬化技術，它是依託在系統之上運行。vmware vcenter

管理上比較方便，圖形管理界面功能很強大，穩定性強，一般比較適合企業使用。KVM管理界面稍差點，需要管理人員花費點時間學習它的維護管理技術。

5、假如有人反應，調取後端介面時特別慢，你會如何排查？

筆者回答：其實這種問題都沒有具體答案，只是看你回答的內容與面試官契合度有多高，能不能說到他想要的點上，主要是看你排查問題的思路。我是這么說的：問清楚反應的人哪個服務應用或者頁面調取哪個介面慢，叫他把頁面或相關的URL發給你，首先，最直觀的分析就是用瀏覽器按F12，看下是哪一塊的內容過慢（DNS解析、網路載入、大圖片、還是某個文件內容等），如果有，就對症下葯去解決（圖片慢就優化圖片、網路慢就查看內網情況等）。其次，看後端服務的日誌，其實大多數的問題看相關日誌是最有效分析，最好用tail -f 跟蹤一下日誌，當然你也要點擊測試來訪問介面日誌才會打出來。最後，排除sql，，找到sql去mysql執行一下，看看時間是否很久，如果很久，就要優化SQL問題了，expain一下SQL看看索引情況啥的，針對性優化。數據量太大的能分表就分表，能分庫就分庫。如果SQL沒啥問題，那可能就是寫的邏輯代碼的問題了，一行行審代碼，找到耗時的地方改造，優化邏輯。

6、mysql資料庫用的是主從讀寫分離，主庫寫，從庫讀，假如從庫無法讀取了、或者從庫讀取特別慢，你會如何解決？

筆者回答：這個問題筆者覺得回答的不太好，對mysql比較在行的朋友希望能給點建議。以解決問題為前提條件，先添加從庫數量，臨時把問題給解決，然後抓取slow log ，分析sql語句，該優化就優化處理。慢要不就是硬體跟不上，需要升級；要不就是軟體需要調試優化，等問題解決在細化。

7、cpu單核和多核有啥區別？

筆者回答：很少有面試官會問這樣的問題，即然問到了，也要老實回答。還好筆者之前了解過CPU，我是這么說的：雙核CPU就是能處理多份任務，順序排成隊列來處理。單核CPU一次處理一份任務，輪流處理每個程序任務。雙核的優勢不是頻率，而是對付同時處理多件事情。單核同時只能幹一件事，比如你同時在後台BT下載，前台一邊看電影一邊拷貝文件一邊QQ。

8、機械磁碟和固態硬碟有啥區別？

筆者回答：我擦，啥年代了，還問磁碟的問題，這面試官有點逗啊。那也要回答啊：

HDD代表機械硬碟，SSD代表固態硬碟。首先，從性能方面來說，固態硬碟幾乎完勝機械硬碟，固態硬碟的讀寫速度肯定要快機械硬碟，因為固態硬碟和機械硬碟的構造是完全不同的（具體的構造就沒必要解釋了）。其次，固態盤幾乎沒有噪音、而機械盤噪音比較大。還有就是，以目前的市場情況來看，一般機械盤容量大，價格低；固態盤容量小，價格偏高。但是企業還是首選固態盤。

9、說一下用過哪些監控系統？

筆者回答：這個監控的問題又問到了，筆者在2018年1月4號也被問到類似這樣的問題，筆者曾經用過zabbix、nagios、 cacit等。但是在這次面試中只說用過zabbix和nagios。說完了之後，面試官就讓我說一下這兩個監控有啥區別：

從web功能及畫圖來講：

Nagios簡單直觀，報警與數據都在同一頁面， 紅色即為問題項。Nagios web端不要做任何配置。 Nagios需要額外安裝插件，且插件畫圖不夠美觀。

Zabbix監控數據與報警是分開的，查看問題項需要看觸發器，查看數據在最新數據查看。而且zabbix有很多其它配置項， zabbix攜帶畫圖功能，且能手動把多個監控項集在一個圖中展示。

從監控服務來講：

Nagios自帶的監控項很少。對一些變動的如多個分區、多個網卡進行監控時需要手動配置。

Zabbix自帶了很多監控內容，感覺zabbix一開始就為你做了很多事，特別是對多個分區、多個網卡等自動發現並進行監控時，那一瞬間很驚喜，很省心的感覺。

從批量配置和報警來講：

Nagios對於批量監控主機，需要用腳本在server端新增host，並拷貝service文件。 Nagios用腳本來修改所有主機的services文件，加入新增服務。

Zabbix在server端配置自動注冊規則，配置好規則後，後續新增client端不需要對server端進行操作。 Zabbix只需手動在模板中新增一監控項即可。

總體來講：

Nagios要花很多時間寫插件，Zabbix要花很多時間探索功能。

Nagios更易上手，Nagios兩天弄會，Zabbix兩周弄會。

Zabbix畫圖功能比Nagios更強大

Zabbix對於批量監控與服務更改，操作更簡潔；Nagios如果寫好自動化腳本後，也很簡單，問題在於寫自動化腳本很費神。

10、給你一套環境，你會如何設計高可用、高並發的架構？

筆者回答：如果這套環境是部署在雲端(比如阿里雲)，你就不用去考慮硬體設計的問題。可直接上阿里雲的SLB+ECS+RDS這套標準的高可用、高並發的架構。對外服務直接上SLB負載均衡技術，由阿里的SLB分發到後端的ECS主機；ECS主機部署多台，應用拆分在不同的ECS主機上，盡量細分服務。資料庫用RDS高可用版本（一主一備的經典高可用架構）、或者用RDS金融版（一主兩備的三節點架構）。在結合阿里其它的服務就完全OK，業務量上來了，主機不夠用了，直橫向擴容ECS主機搞定。

如果這套環境託管在IDC，那麼你就要從硬體、軟體（應用服務）雙面去考慮了。硬體要達到高可用、高並發公司必須買多套網路硬體設備（比如負載設備F5、防火牆、核心層交換、接入層交換）都必須要冗餘，由其是在網路設計上，設備之間都必須有雙線連接。設備如果都是跑的單機，其中一個設備掛了，你整個網路都癱瘓了，就談不上高可用、高並發了。其次在是考慮應用服務了，對外服務我會採用成熟的開源方案LVS+Keepalived或者Nginx+Keepalived，緩存層可以考慮redis集群及Mongodb集群，中間件等其它服務可以用kafka、zookeeper，圖片存儲可以用fastDFS或MFS，如果數據量大、又非常多，那麼可採用hadoop這一套方案。後端資料庫可採用 「主從+MHA」。這樣一套環境下來是絕對滿足高可用、高並發的架構

⑷ 軟體測試面試一般都問什麼問題

必然會問軟體測試的基礎知識，比如黑盒、白盒測試都是什麼，區別等；專性能測試、壓力測試等各屬種測試都是什麼含義？測試用例是什麼？怎麼設計？然後可能會舉個案例問你怎麼設計測試用例，怎麼著手測試。差不多就這樣吧。你可以看看這本書，《軟體測試面試突擊——為自己贏得一份測試工程師職位》，裡面說了面試會問什麼問題，怎麼回答。

⑸ 一個新手面試 Linux 運維工作至少需要知道哪些知識

1.shell指令
2.各種常見的linux系統（rhel、centos等操作系統）大致了解，交換機、網路方面有一定涉獵。當下的回話了解一下PC server。
3.接觸過答一兩種資料庫，能寫create、update、delete、select等語句
4.vi熟悉
5.sed、awk能運用自如
6.用一個自己的例子表明自己的學習能力
7.溝通能力不差

⑹ 怎麼讀Nginx

網路一下，你就知道怎麼發音了，多聽幾遍，多讀幾次，面試官一定能聽懂！

⑺ nginx和tomcat的區別

從應用方面tomcat一般是做動態解析才會用得到，支持jsp的解析，需要配置JDK支持nginx，則一般回是做靜態，本身不具備答動態解析功能，需要配置其他插件或通過其他軟體協同才具備動態功能，比如php，tomcat，或者proxypass到win2008的iis伺服器做ASP的動態鏈接等，但nginx在靜態上的功能非常強大，也可做訪問控制，而且可以做成各種協議負載伺服器，包括流媒體的也可以做，具體得去官方網站去看；在性能方面如果再不做系統調優的情況下tomcat一般支持並發並不高100個差不多了nginx在靜態方面支持並發輕松達幾萬如果這是個面試的人給你出的這道題目上你回答，你可以簡單的告訴他，兩者應用領域不一樣，tomcat是做java語言的動態解析，而nginx則是一款功能強大的負載軟體，配合各種插件可以實現各種功能

⑻ 面試被問nginx和tomcat性能誰更好

nginx性能好一些 但是2個不是一樣的 沒法比較，nginx負責http請求 tomcat負責處理

⑼ Linux運維工程師會面試哪些

知識上面的答主說的很精準了，我來說說技巧。我本身是一名HR，負責新盟專教育的Linux講師屬招聘，所以我需要懂Linux基礎知識，方便對面試者提問。
首先，我會就應聘者簡歷上填寫的內容進行，提問，一般會包括拿到的證書，有無經驗，熟悉的技能，然後我的同事會提問專業內容。比如你寫了擅長MySQL ，Jquery，bootstrap，那麼我們就會提問這些內容，當然都不會特別困難，只需要證明你確實知道，不是在吹噓就行。
其次我們會就崗位需求進行提問，我會問到加班，出差，經驗等問題，我的同事會問會不會某些特定要求的內容，比如zabbix、nagios、elk等……
如果不會，請千萬不要吹牛，我們會問到說明我們肯定知道這玩意，如果吹牛肯定一眼就看出來，然後三兩句話把你送走這樣。
如果你一面過了，要准備二面，那麼請你至少，在二面之前，把我們提到的崗位要求的內容了解一下，避免我們再次提到的時候還是不知道，這樣很影響面試結果。

⑽ .nginx第一次的啟動的時候會創建哪些文件

nginx是個多進程web容器，不同的配置下它的啟動方式也是不同的，這里我只說說最典型的啟動方式。
它有1個master進程，和多個worker進程（最優配置的數量與CPU核數相關）。那麼，首先我們要找到main函數，它在src/core/nginx.c文件中。談到源碼了，這時我們先簡單看下源碼的目錄結構吧。
nginx主要有下列目錄：
src/core，這個目錄存放了基礎的數據結構像LIST、紅黑樹、nginx字元串，貫穿始終的一些邏輯結構如ngx_cycle_s、ngx_connection_s等，還有對一些底層操作的封裝如log、文件操作、共享內存、內存池等，最後還有個nginx.c這個main啟動函數了。
src/event，這個目錄下存放與抽象事件相關的結構和鉤子函數。nginx是以事件驅動處理流程的，事件自然是整個體系的核心了，這里定義了最核心的ngx_event_s結構。
src/event/moles目錄存放了具體的種種事件驅動方式，例如epoll、kqueue、poll、aio、select等，它們通過ngx_event_actions_t結構體中的鉤子掛在nginx中。nginx啟動時會根據配置來決定使用哪種實現方式。
src/os/unix中存放了unix系統下許多函數調用的UNIX實現。
src/http目錄存放到http mole的相關實現，這個mole負責處理http請求，包括協議的解析以及訪問backend server的代碼。
src/http/mole目錄存放http mole類型的一些特定用途的mole，比如gzip處理加密，圖片壓縮等。
有個初步了解後，回到main函數中，順序看看我們感興趣的事情。它先執行了ngx_time_init，為什麼要初始化時間呢？nginx考慮的還是很周到的，取系統時間gettimeofday是系統調用，這意味著，需要發送中斷給linux內核，內核需要做進程間切換來處理這個調用。這是一個不能忽視成本的函數。nginx封裝了時間函數，這樣，每次我們需要處理時間時，並不是調用gettimeofday，而是nginx自己緩存的時間，這樣大量減少了系統調用，取當前時間這事可是誰都愛乾的。
那麼，nginx是怎麼維護自己的這個時鍾呢？如何保證用戶取到的當前時間是有意義的？nginx設計者的出發點是，nginx是事件驅動機制，當一批事件發生時，也就是epoll_wait返回時，會取一次gettimeofday來更新自己的時間，然後調用各個事件對應的處理函數。這些函數都會保證自己是無阻塞的，也就是毫秒級的處理能力，所以，在任何一個事件處理函數中，取到的時間都是之前epoll_wait剛返回時取到的時間，這樣，即使拿到的時間慢了幾毫秒也無所謂。關鍵是，每個函數都是無阻塞的，都要迅速的把控制權交還給nginx，這是基本設計原則哈。