運維面試必備-面試題

面試時切記：勿緊張，邏輯排列清楚，思路清晰

1.面試基礎題：

　　1.你常用的命令都有哪些？（不要一下次說出很多，常用命令代表你之前有沒有工作經驗）

　　　　答：在某些軟件運行不流暢的情況下會先用free查看內存，磁盤使用率做的監控，超過多少的話會報警我們去清理，命令是df -h。有些時候服務未響應會用ps命令查看一下進程，或者查看一下pid文件是否存在。如果服務卡死會使用kill命令來殺掉進程，重新啟動服務

　　2.在公司的日常會做些什么？

　　　　答：根據自己簡歷總結，最好多說一些有關於自動化的與shell腳本的東西，自己懂得技術不需要說太多，關鍵在於精

　　3.你寫過最長的腳本是哪些？

　　　　答：這個需要根據自己來講，比如說一些rpm包手寫啟動腳本與開機自啟動配置文件，Jenkins+gitlab自動化部署（持續交付）

　　4.接觸過哪些高可用與分布式的架構？

　　　　答：博主是這樣回答的：由於公司是發展型公司，web端之前使用的是nginx與Keepalived，在當時nginx是完全可以承載初期的訪問量的，后期訪問量增大以后經過挑選與方便后期維護的方便選用了lvs+keepalived做負載，滿足了當下公司訪問量變大的需求

　　　　　　代碼上線問題：公司之前服務器少，只搭建了一些基礎性能方面的架構，並沒有去做一鍵化部署。但是在后期版本不斷更新迭代時需要不停的手動部署環境太費時間與人力，於是向公司申請新服務器部署基於Jenkins，docker實現自動化部署（持續交付）

　　　　分布式架構：

　　　　　　公司數據庫是做的兩種四從的方案，實現讀寫分離與redis緩存機制，來減少數據庫緩存讀寫壓力

 

2.面試進階題：

　　1.MySQL中怎么實現主從同步的？

　　　　答：

1. 1. 主庫db的更新事件(update、insert、delete)被寫到binlog
   2. 主庫創建一個binlog dump thread，把binlog的內容發送到從庫
   3. 從庫啟動並發起連接，連接到主庫
   4. 從庫啟動之后，創建一個I/O線程，讀取主庫傳過來的binlog內　　容並寫入到relay log
   5. 從庫啟動之后，創建一個SQL線程，從relay log里面讀取內容，從Exec_Master_Log_Pos位置開始執行讀取到的更新事件，將更新內容寫入到slave的db

　　2.lvs/nginx/haproxy優缺點？

　　　　答：LVS的優點：

```
1、抗負載能力強、工作在第4層僅作分發之用，沒有流量的產生，這個特點也決定了它在負載均衡軟件里的性能最強的；無流量，同時保證了均衡器IO的性能不會受到大流量的影響；
2、工作穩定，自身有完整的雙機熱備方案，如LVS+Keepalived和LVS+Heartbeat；
3、應用范圍比較廣，可以對所有應用做負載均衡；
4、配置性比較低，這是一個缺點也是一個優點，因為沒有可太多配置的東西，所以並不需要太多接觸，大大減少了人為出錯的幾率；
LVS的缺點：
1、軟件本身不支持正則處理，不能做動靜分離，這就凸顯了Nginx/HAProxy+Keepalived的優勢。
2、如果網站應用比較龐大，LVS/DR+Keepalived就比較復雜了，特別是后面有Windows Server應用的機器，實施及配置還有維護過程就比較麻煩，相對而言，Nginx/HAProxy+Keepalived就簡單多了。

　　　　　　　　　　　　　　　　　　轉載於：滄海一滴

　　　　　　　　　　　　　原文地址：https://www.cnblogs.com/softidea/p/5510137.html　　　　　　　　　　

```

　　3.什么叫網站灰度發布？

　　　　　　答：灰度發布是指在黑與白之間，能夠平滑過渡的一種發布方式
　　　　　　　　AB test就是一種灰度發布方式，讓一部用戶繼續用A，一部分用戶開始用B
　　　　　　　　如果用戶對B沒有什么反對意見，那么逐步擴大范圍，把所有用戶都遷移到B上面 來
　　　　　　　　灰度發布可以保證整體系統的穩定，在初始灰度的時候就可以發現、調整問題，以保證其影響度

　　4.講一下Keepalived的工作原理？
　　　　　　答：BACKUP不會搶占MASTER，除非它的優先級更高。當MASTER不可用時(BACKUP收不到通告信息)
　　　　　　　　多台BACKUP中優先級最高的這台會被搶占為MASTER。這種搶占是非常快速的(<1s)，以保證服務的連續性
　　　　　　　　由於安全性考慮，VRRP包使用了加密協議進行加密。BACKUP不會發送通告信息，只會接收通告信息

　　5.mysql的innodb如何定位鎖問題，mysql如何減少主從復制延遲？

　　　　　　答：

　　　　　　　　mysql的innodb如何定位鎖問題:
　　　　　　　　在使用 show engine innodb status檢查引擎狀態時，發現了死鎖問題
　　　　　　　　在5.5中，information_schema 庫中增加了三個關於鎖的表（MEMORY引擎）
　　　　　　　　innodb_trx ## 當前運行的所有事務
　　　　　　　　innodb_locks ## 當前出現的鎖
　　　　　　　　innodb_lock_waits ## 鎖等待的對應關系

　　　　　　　　mysql如何減少主從復制延遲:
　　　　　　　　如果延遲比較大，就先確認以下幾個因素：

1. 1. 1. 從庫硬件比主庫差，導致復制延遲

      2. 主從復制單線程，如果主庫寫並發太大，來不及傳送到從庫就會導致延遲。更高版本的mysql可以支持多線程復制

      3. 慢SQL語句過多

      4. 網絡延遲

      5. master負載
         主庫讀寫壓力大，導致復制延遲，架構的前端要加buffer及緩存層

      6. slave負載
         一般的做法是，使用多台slave來分攤讀請求，再從這些slave中取一台專用的服務器

　　　　　　　　　　只作為備份用，不進行其他任何操作.另外， 2個可以減少延遲的參數:
　　　　　　　　　　–slave-net-timeout=seconds 單位為秒 默認設置為 3600秒

參數含義：當slave從主數據庫讀取log數據失敗后，等待多久重新建立連接並獲取數據

　　　　　　　　　　–master-connect-retry=seconds 單位為秒 默認設置為 60秒

參數含義：當重新建立主從連接時，如果連接建立失敗，間隔多久后重試

　　　　　　　　　　通常配置以上2個參數可以減少網絡問題導致的主從數據同步延遲

　　　　　　　　　　MySQL數據庫主從同步延遲解決方案

　　　　　　　　　　最簡單的減少slave同步延時的方案就是在架構上做優化，盡量讓主庫的DDL快速執行
　　　　　　　　　　還有就是主庫是寫，對數據安全性較高，比如sync_binlog=1，innodb_flush_log_at_trx_commit
　　　　　　　　　　= 1 之類的設置，而slave則不需要這么高的數據安全，完全可以講sync_binlog設置為0或者關閉binlog
　　　　　　　　　　innodb_flushlog也可以設置為0來提高sql的執行效率。另外就是使用比主庫更好的硬件設備作為slave

未完待續。。。。