面试题的一些汇总
1. 公司是做什么業(yè)務(wù)的
答：貫通云網(wǎng)快遞平臺網(wǎng)頁版。集合了國內(nèi)七大現(xiàn)有快遞公司的業(yè)務(wù)終端，并在陸續(xù)擴展中。集中了在線填寫，預(yù)約發(fā)件；智能跟蹤，智能查詢，快件信息管理等優(yōu)點！
指尖快遞APP---基于線上平臺數(shù)據(jù)，建立快遞代辦點業(yè)務(wù)體系。
2. 2.公司有多少服務(wù)器
答：80臺
3. 你負責(zé)多少臺
答：我主要負責(zé)web服務(wù)器nginx的40臺
4. 每臺服務(wù)器都跑的啥
答：6臺web，兩臺redis，6臺數(shù)據(jù)庫，還有nginx，tomcat，LVS負載+keepalived高可用什么的，剩下的都是平時測試用的。
5. 公司規(guī)模多大
答：中小型企業(yè)。
6. 公司有個運維
答：2個，我負載web端，另一個負責(zé)APP端。
7. 你的匯報對象是誰
答：我們老大
8. 你們公司用的什么語言
答：開發(fā)用的是JAVA
9. 你們的開發(fā)有多少人
答：開發(fā)是3個
10. 運維怎么分工的
答：也沒啥分工，一起干
11. 你的期望薪資是多少
答：因為上家公司給的是13K，所以 不低于13吧
12. 你平時出差多嗎
答：出差不多，因為公司業(yè)務(wù)主要都在線上。說實話我還是挺想出去走走的。
13. 你們學(xué)校是統(tǒng)招還是非統(tǒng)招
答：統(tǒng)招的。
14. 你們學(xué)校是全日制的嗎
答：是全日制的
15. 你離職原因是啥
答：因為學(xué)歷問題，公司要給我做降薪處理，有點接受不了
16. 你覺得你的優(yōu)點和缺點是啥
答：優(yōu)點：溝通能力強，團隊協(xié)作能力強，樂于助人，喜歡學(xué)習(xí)。缺點：長得丑算嗎？
17. 你工作之余有什么愛好
答：看一些技術(shù)方面的書，研究一些新的技術(shù)。
18. 你最近有學(xué)習(xí)過哪些新技術(shù)
答：python
19. 你住的地方，離公司有多遠
公司在哪里，我就住哪里
20. 你們公司哪年成立的
答：2014年5月成立的。
21. 你們公司服務(wù)器都是什么型號
答：戴爾R710 R720
22. 機房溫度是多少
15--22
23. 你對加班怎么看的
答：我覺得IT行業(yè)加班很正常啊，如果我有幸進入公司的話，我會主動去加班，盡快熟悉公司業(yè)務(wù)，能早點上手工作。
24. 你來北京的原因
答：當(dāng)時年輕氣盛，跟我哥打賭來的。他來北京漂了兩年，漂不下去了，就回家了，我就想，我必須在北京漂出個名堂。
25. 你是從什么時候開始接觸Linux的
答：在大學(xué)的時候就有接觸，當(dāng)時是我的一個室友，他哥就是干運維的，有一次一起吃飯了解了一下運維這個行業(yè)。
26. 你的工資是怎么樣的薪資結(jié)構(gòu)
答：基本+績效
27. 你現(xiàn)在是離職狀態(tài)嗎
答：是的
28. 你們過節(jié)都有什么福利
看老板心情
29. 你對你們領(lǐng)導(dǎo)的看法是
答：我們領(lǐng)導(dǎo)人還是挺好的，與人為善，挺隨和，對我們也挺好的。
30. 如果讓你入職了，你首先會怎么做
答：多跟公司的同事們溝通，盡快了解自己的工作和公司的業(yè)務(wù)，爭取能早點上手工作
31. 你的學(xué)歷學(xué)信網(wǎng)可查嗎
答：我是民辦本科畢業(yè)的，學(xué)信網(wǎng)好像查不了，民教網(wǎng)能查。
32. 你的年齡和身份證上 的不符合
答：沒有不符啊，身份證上就是我的真實年齡。
33. 你門的機房放在哪
答：在三元橋那邊，托管的。
34. 你能適應(yīng)出差嗎
答：剛才我也說了，我其實挺想出去看看的，畢業(yè)完了就來了北京，一直在這種快節(jié)奏的生活環(huán)境下，確實有點小累，而且我目前也是單身，沒什么牽掛，可以說走就走。
35. 如果你跟領(lǐng)導(dǎo)的意見不一樣，你會如何做
答：那就要看是什么方面的了，如果是技術(shù)方面的話，我覺得我會跟領(lǐng)導(dǎo)私下再去溝通一下，跟領(lǐng)導(dǎo)闡明我的觀點和理由，剩下的就看領(lǐng)導(dǎo)的決定了。
36. 你能提上份工作的工資流水證明嗎
答：離職以后想出國去旅游，當(dāng)時開了一個資產(chǎn)證明，可以嗎？
37. 你上份薪資多少
答：到手13K
38. 你跟同事關(guān)系怎么樣
答：我們關(guān)系還是很好的，因為我這個性格就是喜歡交朋友，所以我跟我的同事們都是比較好的朋友。
39. 你是如何看待跳槽的
答：我覺得跳槽是一種不負責(zé)任的表現(xiàn)，進入公司以后公司對我們進行了培養(yǎng)，把我們培養(yǎng)成一個技術(shù)型人才，隨意跳槽是對自己和公司不負責(zé)任。
40. 用三個詞描述自己的優(yōu)點，你覺得會是啥。 用三個詞描述自己缺點，你覺得會是啥，分別對每個詞進行舉例子
答：優(yōu)點：1.樂觀 我是一個不善于表功的人，一般就是默默的做著自己的工作，而有時候功勞卻會成文別人的，對此，我沒有任何怨言，我相信，只有真正的付出了，才會有回報。
2. 開朗 我是一個外向的人，跟誰都能合得來，跟誰都能成為朋友，這也使我跟別人溝通的時候會有很好的效果。大家也都愿意跟我成為朋友。
3. 好學(xué) 我對新鮮的事物有特別中的好奇心，這使我特別喜歡研究一些新的技能，而且我都會把它搞清楚，弄明白。
HR面試題借鑒王濟宇的（自己整理自己的HR面試題）
技術(shù)面試題：
41. 主從原理
答：從庫的 I/O 線程去請求主庫中的 bin-log 二進制日志，并將得到的 binlog 日志寫到 relay log（中繼日志） 文件中；
主庫的 dump 線程用來給從庫的 I/O 線程傳送 binlog 二進制日志；
從庫的 SQL 線程會讀取從庫中的 rely-log 文件中的日志，并且解析成具體的操作進行持久化，從而實現(xiàn)主從的一致；42. 主從同步異常如何解決
答：1） 一般異常只需要跳過一步即可恢復(fù)>slave stop;
>SET GLOBAL sql_slave_skip_counter =1;
>slave start 2) 斷電導(dǎo)致的不能同步，通過主庫的最后一個bin-log日志進行恢復(fù)。 3） 主鍵沖突，表已經(jīng)存在等錯誤代碼如1602，1032，1060 可以在配置文件中指定【MySQL】
slave-skip-errors = 1060,1032,1060
43. 主從同步主服務(wù)器宕機如何處理？答：1. 硬件問題宕機（服務(wù)器，ecs,虛擬主機） 查看IDC巡檢記錄，或通過遠程控制卡查看硬件運行狀態(tài)
1） 查看報警，確認業(yè)務(wù)是否受到影響，必要時切從庫進行數(shù)據(jù)交換
2） IDC詢問排查
3） 確認硬件故障，通知部門領(lǐng)導(dǎo)，處理進度，并實時記錄
4） 處理完成后，寫故障報告，會議通報
2. 軟件問題（服務(wù)中斷）(一主多從的場景)
1） 判斷是否影響業(yè)務(wù)，是否需要切庫，保證業(yè)務(wù)的正常運行是首要任務(wù)。
2）先查看MySQL從庫狀態(tài)，若io線程和sql線程雙YES，表示是同步的。（如果不同步，拷出binlog進行同步）
3）登陸從庫進行查看，選OPS最大的作為主庫
4）確保relay log 全部更新完畢
在每個從庫上執(zhí)行 stop slave io_thread;show processlist(在每個從庫上執(zhí)行)
5)設(shè)置選擇的從庫提升為主庫master
6)所有的從庫指向新的master
先保證業(yè)務(wù)的正常運行，暫時將從服務(wù)器變成主業(yè)務(wù)服務(wù)器；排查問題，先程序，看看數(shù)據(jù)庫的各項指標，看日志，看端口，看所占用的內(nèi)存，然后看硬件，網(wǎng)線，服務(wù)器本身是不是出問題，基本看日志就可以了。
44. 數(shù)據(jù)庫備份如何做
答：MySQL dump+全備，bin-log增量備份。
45. MySQL優(yōu)化你做了哪些操作
答：1. 對Linux內(nèi)核進行優(yōu)化防止操作系統(tǒng)影響MySQL性能
net.ipv4.tcp_fin_timeout = 30
#TIME_WAIT超時時間，默認是60s
net.ipv4.tcp_tw_reuse = 1
#1表示開啟復(fù)用，允許TIME_WAIT socket重新用于新的TCP連接，0表示關(guān)閉
net.ipv4.tcp_tw_recycle = 1
#1表示開啟TIME_WAIT socket快速回收，0表示關(guān)閉
net.ipv4.tcp_max_tw_buckets = 4096
#系統(tǒng)保持TIME_WAIT socket最大數(shù)量，如果超出這個數(shù)，系統(tǒng)將隨機清除一些TIME_WAIT并打印警告信息
net.ipv4.tcp_max_syn_backlog = 4096
#進入SYN隊列最大長度，加大隊列長度可容納更多的等待連接
2.為防止出現(xiàn)too many files open 調(diào)整打開文件句柄限制
vim /etc/security/limits.conf
#加入以下配置，*代表所有用戶，也可以指定用戶，重啟系統(tǒng)生效
* soft nofile 65535
* hard nofile 65535
# ulimit -SHn 65535 #立刻生效3.從硬件方面：加大物理內(nèi)存，用SSD代替SAS或者將RAID級別調(diào)整為RAID10.
4. 給數(shù)據(jù)庫增加緩存，把熱備數(shù)據(jù)加到內(nèi)存中，提高讀性能。我們公司用的是redis,之所以沒用memcached主要考慮到想做數(shù)據(jù)的持久化。
5. 當(dāng)然還有些分庫分表，當(dāng)時跟Java開發(fā)和新來的DBA一起做的，把一些相關(guān)的表切分到不同的數(shù)據(jù)庫里，把一些大字段放在一個單獨的表里
6.開啟慢查詢?nèi)罩?#xff0c;分析哪條SQL比較慢，我還跟DBA學(xué)了個工具 pt工具，主要用來分析慢查詢?nèi)罩?#xff0c;比如pt-querry-digest46. nginx優(yōu)化你做了哪些操作答：老服務(wù)的nginx優(yōu)化我做的比較少，新業(yè)務(wù)當(dāng)中在編譯nginx的時候做過隱藏版本信息的優(yōu)化，算是安全方面的優(yōu)化把
在一個在安全方面還做過降權(quán)啟動nginx,
性能方面的優(yōu)化，我知道一些，比如優(yōu)化nginx的進程個數(shù)（worker_process ）
還有一些調(diào)整nginx單個進程的允許的客戶最大連接數(shù)以及nginx worker進程最大打開數(shù)。
nginx 日志方面寫過腳本實現(xiàn)nginx的日志輪詢47. nginx怎么定義403錯誤界面答：首先在nginx的http模塊加入fastcgi_intercept_errors on;
然后再server模塊加入的location/{}加入403.htmllocation / {deny 192.168.1.0/24;alllow all;error_page 403 /403.html;location /403.html { allow all;}
}最后創(chuàng)建一個自己定義的頁面
# vim 403.html
<!DOCTYPE HTML PUBLIC "-//IETF//DTD HTML 2.0//EN">
<html>
<head><title>403 Forbidden</title></head>
<body bgcolor="white">
<h1>403 Forbidden</h1>
<p>You don't have permission to access the URL on this server. Sorry for the inconvenience.<br/>
This is a our test website, please visit our official website <a href="http://monitor.zmedu.com/fzj/index.html" title="Click View Site " ><font size="5"> monitor.zmedu.com </a>!
</font><br/>
Thank you very much!</p>
URL: http://monitor.zmedu.com/
<br/>Date:
<script language="JavaScript" type="text/javascript">
var enabled = 0; today = new Date();
var date;
M=today.getMonth() + 1
D=today.getDate()
HH=today.getHours()
MM=today.getMinutes()
SS=today.getSeconds()
if (M<10)
{
M="0"+M
}
if (D<10)
{
D="0"+D
}
if (MM<10)
{
MM="0"+MM
}
if (HH<10)
{
HH="0"+HH
}
if (SS<10)
{
SS="0"+SS
}
date = (today.getFullYear()) + "/" + M + "/" + D + " " + HH+":"+MM+":"+SS +"";
document.write(date);
</script>
<hr/>Powered by zmedu.com!</body>
</html>最后重啟 ： /etc/init.d/nginx reload
效果48. nginx平滑啟動的命令是什么
答：/usr/nginx/sbin/nginx -s reload
/usr/nginx/sbin/nginx -t
49. nginx和apache有什么區(qū)別
答：1. apache 相對于nginx 的優(yōu)點：
rewrite ，比nginx 的rewrite 強大
動態(tài)頁面，nginx處理動態(tài)請求是雞肋，一般動態(tài)請求要apache去做，nginx只適合靜態(tài)和反向。
模塊超多，基本想到的都可以找到
少bug ，nginx 的bug 相對較多超穩(wěn)定
2） nginx相對于apache的優(yōu)點：
輕量級，同樣起web 服務(wù)，比apache占用更少的內(nèi)存及資源 ，支持更多的并發(fā)連接，體現(xiàn)更高的效率，這點使 Nginx 尤其受到虛擬主機提供商的歡迎。在高連接并發(fā)的情況下，Nginx是Apache服務(wù)器不錯的替代品: Nginx在美國是做虛擬主機生意的老板們經(jīng)常選擇的軟件平臺之一. 能夠支持高達 50,000 個并發(fā)連接數(shù)的響應(yīng), 這歸功于Nginx為我們選擇了 epoll and kqueue 作為開發(fā)模型.
抗并發(fā)，nginx 處理請求是異步非阻塞的，而apache 則是阻塞型的，在高并發(fā)下nginx 能保持低資源低消耗高性能
高度模塊化的設(shè)計，編寫模塊相對簡單
社區(qū)活躍，各種高性能模塊出品迅速啊
Nginx本身就是一個反向代理服務(wù)器
負載均衡能力突出，Nginx 既可以在內(nèi)部直接支持 Rails 和 PHP 程序?qū)ν膺M行服務(wù), 也可以支持作為 HTTP代理 服務(wù)器對外進行服務(wù). Nginx采用C進行編寫, 不論是系統(tǒng)資源開銷還是CPU使用效率都比 Perlbal 要好很多50. tomcat端口有哪些，都是什么用途
答：80port:服務(wù)器連接器的端口號,該連接器將在指定端口偵聽來自客戶端的請求。
8005 port:指定一個端口，這個端口負責(zé)監(jiān)聽關(guān)閉Tomcat的請求51. 公司代碼上線是怎么做的，發(fā)布周期是多長時間，一般什么時候上線
答：
最初始的代碼上線dev: 開發(fā)服務(wù)版本庫 bate 測試服務(wù)版本庫， online線上服務(wù)版本庫
測試通過后，再客戶端選2000到3000個用戶強制彈窗，讓其更新版本。進行灰度發(fā)布。 有bug修復(fù)后再走一遍流程。
所謂的灰度發(fā)布： 根據(jù)自己的配置，將部分用戶的流量導(dǎo)到新系統(tǒng)來驗證新功能的修改，一旦出現(xiàn)問題可以馬上修復(fù)。
一周上線一次，周四上線，有問題就回滾，周五繼續(xù)上線2. 代碼如何回滾，用jenkins如何實現(xiàn)
答：發(fā)布：jenkins配置好代碼路徑（SVN或GIT），然后拉代碼，打tag。需要編譯就編譯，編譯之后推送到發(fā)布服務(wù)器（jenkins里面可以調(diào)腳本），然后從分發(fā)服務(wù)器往下分發(fā)到業(yè)務(wù)服務(wù)器上。發(fā)布：jenkins配置好代碼路徑（SVN或GIT），然后拉代碼，打tag。需要編譯就編譯，編譯之后推送到發(fā)布服務(wù)器（jenkins里面可以調(diào)腳本），然后從分發(fā)服務(wù)器往下分發(fā)到業(yè)務(wù)服務(wù)器上。
回滾：按照版本號到發(fā)布服務(wù)器找到對應(yīng)的版本推送
3. 什么是灰度發(fā)布，什么是灰度測試
答： 所謂的灰度發(fā)布： 根據(jù)自己的配置，將部分用戶的流量導(dǎo)到新系統(tǒng)來驗證新功能的修改，一旦出現(xiàn)問題可以馬上修復(fù)5. 上線前開發(fā)給你的包是什么包
答：jar war
6. svn與git相比有什么區(qū)別？
答：1）git 只關(guān)心文件數(shù)據(jù)的整體是否發(fā)生改變，而svn關(guān)心 的是內(nèi)容是否改變
2）git的絕大多數(shù)操作只需要訪問本地的文件和資源，不用聯(lián)網(wǎng)查看所有的歷史版本記錄，而svn需要聯(lián)網(wǎng)
3） svn斷網(wǎng)后無法commit代碼，而git可以先commit到本地倉庫
4）git克隆一個完整項目非常快，而svn非常慢
范例一：
我們公司用的是SVN，但我私下里也學(xué)習(xí)了下git,個人感覺，SVN更好上手，但是論功能強大的化還是git好一些，比如同樣是克隆一個完整項目，git就比svn快，而且有時候，一旦斷網(wǎng)git可以commit到本地倉庫，但是SVN就沒法commit . 7. 代碼上線時運維需要做的事情？
答：配合開發(fā)搭建測試環(huán)境，調(diào)試，測試代碼采購阿里云服務(wù)器，安裝系統(tǒng)，配置服務(wù)部署上線過程中發(fā)現(xiàn)bug，與開發(fā)溝通，前端溝通，開發(fā)解決完繼續(xù)上線出現(xiàn)問題，回滾（需要提前確定好回滾機制）
備份恢復(fù)：
52. 備份分為哪幾種？
答：完全備份 增量備份 文件備份
53. 全量用什么工具，增量用什么工具
答：全量：XtraBackup
增量：mysqldump
1. 寫腳本每天晚上0點，定時將B服務(wù)器數(shù)據(jù)備份到A，并把備份結(jié)果發(fā)給運維
#!/bin/sh
ip=$(/sbin/ifconfig eth0|sed -rn 's#^.*addr:(.*) Bca.*$#\1#gp')
scp -rp -P52113 /data/ 192.168.100.61:~/data_$ip
if [ $? -eq 0 ]thenecho "192.168.100.62 is ok" >> /home/heavenfish/bak62.logscp -rp -P52113 /home/heavenfish/bak62.log 192.168.100.61:~
fi
定時任務(wù)：
[heavenfish@B ~]$ crontab -e
####注釋###
00 00 * * * /bin/sh /home/heavenfish/bak62.sh >/dev/null 2>&1
54. 備份主要備份什么？
答：1） 數(shù)據(jù)庫中的數(shù)據(jù)
2） MySQL配置文件
3） 存儲過程，存儲函數(shù)和觸發(fā)器
4） 計劃任務(wù)相關(guān)的腳本
5） 主從場景下，跟復(fù)制相關(guān)的信息
6） 二進制文件
web方面
1. nginx負載均衡的算法是怎么實現(xiàn)的，目前支持幾種
答：目前支持五種算法：
1) round robin（默認）
輪詢方式，依次將請求分配到各個后臺服務(wù)器中，默認的負載均衡方式。 適用于后臺機器性能一致的情況。 掛掉的機器可以自動從服務(wù)列表中剔除
2) weight
根據(jù)權(quán)重來分發(fā)請求到不同的機器中，指定輪詢幾率，weight和訪問比率成正比，用于后端服務(wù)器性能不均的情況。
3) IP_hash
根據(jù)請求者ip的hash值將請求發(fā)送到后臺服務(wù)器中，可以保證來自同一ip的請求被打到固定的機器上，可以解決session問題。
4) url_hash(第三方)
根據(jù)請求的url的hash值將請求分到不同的機器中，當(dāng)后臺服務(wù)器為緩存的時候效率高。
5) fair（第三方）
根據(jù)后臺響應(yīng)時間來分發(fā)請求，響應(yīng)時間短的分發(fā)的請求多。
2. nginx與apache相比有什么優(yōu)勢
答：作為web服務(wù)，nginx比apache占用內(nèi)存資源少，處理請求上來看，nginx是異步非阻塞的，高并發(fā)下nginx有絕對的優(yōu)勢。而且nginx編寫模塊相對簡單，社區(qū)活躍。所以我們公司再14年用的是apache,后來換成了nginx.而且我有個體會，apache改配置文件重啟時候才知道有沒有錯，而nginx再重啟前就可以用 -t測試配置文件有沒有問題。3. nginx 的master和worker進程分別是什么？
答：master進程主要用來管理worker進程，包含：接收來自外界的信號，向各worker進程發(fā)送信號，監(jiān)控worker進程的運行狀態(tài)，當(dāng)worker進程退出后(異常情況下)，會自動重新啟動新的worker進程。
worker進程則處理基本的網(wǎng)絡(luò)事件。多個worker進程之間是對等的，他們同等競爭來自客戶端的請求，各進程互相之間是獨立的。一個請求，只可能在一個worker進程中處理，一個worker進程，不可能處理其它進程的請求。worker進程的個數(shù)是可以設(shè)置的，一般我們會設(shè)置與機器cpu核數(shù)一致。
4. 請解釋什么是C10k
答：C10K問題的本質(zhì)上是操作系統(tǒng)的問題。對于Web 1.0/2.0時代的操作系統(tǒng)，傳統(tǒng)的同步阻塞I/O模型處理方式都是requests per second。當(dāng)創(chuàng)建的進程或線程多了，數(shù)據(jù)拷貝頻繁（緩存I/O、內(nèi)核將數(shù)據(jù)拷貝到用戶進程空間、阻塞，進程/線程上下文切換消耗大， 導(dǎo)致操作系統(tǒng)崩潰，這就是C10K問題的本質(zhì)。
5. ngx_http_upstream_module的作用是什么
答：ngx_http_upstream_module 模塊用于定義可以被 proxy_pass、fastcgi_pass 以及memcached_pass 等指令引用的服務(wù)器群。
6. 使用方向代理的優(yōu)點？
答：防止主服務(wù)器被惡意攻擊
為負載均衡和動靜分離提供實現(xiàn)支持
7. nginx做過哪些方面的優(yōu)化？
答：隱藏nginx header里版本號信息。
配置nginx worker的進程個數(shù)。
設(shè)置連接超時時間。
配置nginx gzip壓縮功能。
8. 動靜分離中什么樣的數(shù)據(jù)是動態(tài)數(shù)據(jù)，什么是靜態(tài)數(shù)據(jù)
答：動態(tài)：隨著時間的發(fā)展，常常變化的數(shù)據(jù)，如網(wǎng)站訪問量、在線人數(shù)、日銷售等
靜態(tài)：是基本保持穩(wěn)定的數(shù)據(jù)，比如一個單位的名稱、員工信息、系統(tǒng)參數(shù)等
9. nginx導(dǎo)致磁盤空間占滿的問題如何解決？（too many open files)
答：這個問題一般是打開文件數(shù)量超過了系統(tǒng)的設(shè)置數(shù)量，可以用ulimit -n 65535來修改最大允許的文件數(shù)。而且nginx.conf配置文件里不要設(shè)置太大的文件數(shù)。也有一種情況你使用df -h查看某個分區(qū)幾乎被用光了，而用df -i 發(fā)現(xiàn)節(jié)點數(shù)沒那么多,可以先停掉nginx,再啟動，釋放nginx占用的空間。
10.tomcat 默認端口號
答：8080
10. 訪問一個網(wǎng)站的流程
答：第一，將域名解析成ip的過程，第二，通過ip找到網(wǎng)站服務(wù)器，請求打開具體的網(wǎng)頁，服務(wù)器響應(yīng)請求，客戶端瀏覽器收到響應(yīng)報文后，渲染html文檔，最終得到我們看到的網(wǎng)頁頁面。
12. tomcat調(diào)優(yōu)
答：JVM參數(shù)的調(diào)節(jié)（根據(jù)Java開發(fā)的要求，在 catalina.bat中把JAVA_OPTS的值調(diào)大）耗時太長時候，為了測試，禁用DNS查詢）
13. 如何修改tomcat的端口號
答：server.xml里把port = "8080" 改成你想要的端口就可以
14. tomcat 集群方式的優(yōu)缺點
答：tomcat三種集群1） 使用DNS輪詢2）使用apache R-proxy方式3）使用APACHE mod_jk方式
15. 負載均衡你聽過哪幾種，你們用的哪一種
答：LVS、NGINX、F5。我們用的是LVS的DR模式
16. LVS 與nginx相比有什么優(yōu)缺點？
答：LVS：負載能力強、配置性低、工作穩(wěn)定、無流量、能支持所有應(yīng)用
Nginx：工作在第七層，可以針對HTTP應(yīng)用本身做分流策略、對網(wǎng)絡(luò)的依賴小、安裝配置比較簡單，測試起來也很方便、負載均衡和穩(wěn)定度差了LVS幾個等級
17. LVS目前實現(xiàn)的幾種調(diào)度算法有？你們用的哪一種？說下原理？
答：調(diào)度算法：10種
輪詢（rr）、加權(quán)輪詢（wrr）、最少連接（LC）、加權(quán)最少連接（WLC）、最少隊列調(diào)度（NQ）
我們用的是wrr加權(quán)輪詢，它可以解決服務(wù)器間性能不一的情況，它用相應(yīng)的權(quán)值表示服務(wù)器的處理性能，服務(wù)器的缺省權(quán)值為1。假設(shè)服務(wù)器A的權(quán)值為1，B的權(quán)值為2，則表示服務(wù)器B的處理性能是A的兩倍。加權(quán)輪叫調(diào)度算法是按權(quán)值的高低和輪叫方式分配請求到各服務(wù)器。權(quán)值高的服務(wù)器先收到的連接，權(quán)值高的服務(wù)器比權(quán)值低的服務(wù)器處理更多的連接，相同權(quán)值的服務(wù)器處理相同數(shù)目的連接數(shù)
18. LVS集群架構(gòu)我們采用哪種調(diào)度算法？
答：一般使用加權(quán)輪叫調(diào)度算法或者加權(quán)最小連接調(diào)度。
19. LVS工作原理
答：LVS分為三層，調(diào)度層，server集群和共享存儲1) 當(dāng)用戶向負載均衡director server發(fā)送請求，調(diào)度器將請求發(fā)往內(nèi)核空間
2) prerouting鏈首先會接受用戶請求，判斷目標IP確定是本機IP，將數(shù)據(jù)包發(fā)往INPUT鏈
3) IPVS是工作再input鏈上的，當(dāng)2的請求過來后，IPVS會將用戶請求和自己定義好的集群服務(wù)做對比。如果用戶請求的就是定義集群服務(wù)，那么此時IPVS會強行修改數(shù)據(jù)包里的目標IP地址和端口，并將新的數(shù)據(jù)包發(fā)往POSTrouting鏈
4) POSTROUTING鏈接收到數(shù)據(jù)包后發(fā)現(xiàn)目標IP剛好是自己的后端服務(wù)器，那么此時選路，將數(shù)據(jù)包最終發(fā)往真實的后端服務(wù)器。
注： 詳細了解net模式原理圖和DR模式原理圖
http://www.sohu.com/a/126661836_467792##220. 大致說一下LVS搭建過程
答：配置分發(fā)器的網(wǎng)絡(luò)環(huán)境、配置LVS-DR規(guī)則、安裝服務(wù)并開啟、配置網(wǎng)絡(luò)環(huán)境、關(guān)閉APR包的轉(zhuǎn)發(fā)、測試
21. LVS在項目運行前需要注意什么問題
答：1.keepavlied 主備之間要開放防火墻2. keepalived 主備要接在同一個交換機上使用DR模式時候，如果跨了交換機，可能出現(xiàn)主備都有流量3. 版本號一致
22. 查看tomcat進程號和端口號
答：查看Tomcat的進程號：ps -aux | grep tomcat/ps -ef | grep tomcat
查看Tomcat的端口號：lsof -i | grep 8080
23. 簡單描述nginx 與 php-fpm的兩種連接方式及優(yōu)缺點答：nginx與php-fpm連接的兩種方式為：tcp-socket 和unix-socketunix socket方式要比tcp的方式快，而且消耗資源少，因為socket之間在nginx和php-fpm的進程之間通信，而tcp需要經(jīng)過本地回環(huán)驅(qū)動，還要申請臨時端口和tcp相關(guān)資源。
unix socket會顯得不是那么穩(wěn)定，當(dāng)并發(fā)連接數(shù)爆發(fā)時，會產(chǎn)生大量的長時緩存，在沒有面向連接協(xié)議支撐的情況下，大數(shù)據(jù)包很有可能就直接出錯并不會返回異常。而TCP這樣的面向連接的協(xié)議，多少可以保證通信的正確性和完整性。
24. web服務(wù)器錯誤代碼（200、201、301、404、500、502、503）代表什么？
答：200-確定。客戶端請求已成功。
201-已創(chuàng)建。
301-對象已永久移走，即永久重定向。
404-未找到。
500-內(nèi)部服務(wù)器錯誤。
502-Web服務(wù)器用作網(wǎng)關(guān)或代理服務(wù)器時收到了無效響應(yīng)。
503-服務(wù)不可用。這個錯誤代碼為IIS6.0所專用。
25. nginx組成部分及常用模塊有哪些
答：三部分：全局塊、events塊、http塊
worker性能相關(guān)配置 進程的數(shù)量，nice值，能打開文件的數(shù)量上限
時間驅(qū)動events相關(guān)的配置
http核心模塊相關(guān)配置ngx_http_core_module
web服務(wù)模板 虛擬主機
隱藏版本信息
location匹配
錯誤頁面顯示
長連接相關(guān)配置
請求報文緩存
26. nginx怎么自定義403錯誤界面
答：error_page 403 /403.html
27. keepalived原理
答：keepalived是以VRRP協(xié)議為實現(xiàn)基礎(chǔ)的，VRRP全稱Virtual Router Redundancy Protocol，即虛擬路由冗余協(xié)議。
虛擬路由冗余協(xié)議，可以認為是實現(xiàn)路由器高可用的協(xié)議，即將?臺提供相同功能的路由器組成一個路由器組，這個組里面有一個主和多個備份，主上面有一個對外提供服務(wù)的VIP（該路由器所在局域網(wǎng)內(nèi)其他機器的默認路由為該VIP），主會發(fā)組播，當(dāng)備份收不到VRRP包時就認為主宕掉了，這時就需要根據(jù)VRRP優(yōu)先的級來選舉一個備份當(dāng)master。這樣的話就可以保證路由器的高可用了。
keepalived主要有三個模塊，分別是核心，檢查和vrrp.core模塊為keepalived的核心，負責(zé)主進程的啟動，維護以及全局配置文件的加載和解析。檢查負責(zé)健康檢查，包括常見的各種檢查方式。 VRRP模塊是來實現(xiàn)VRRP協(xié)議的。
28. tomcat工作模式
答：即阻塞式I/O操作，表示Tomcat使用的是傳統(tǒng)的Java I/O操作(即java.io包及其子包)。是基于JAVA的HTTP/1.1連接器，Tomcat7以下版本在默認情況下是以bio模式運行的。一般而言，bio模式是三種運行模式中性能最低的一種。我們可以通過Tomcat Manager來查看服務(wù)器的當(dāng)前狀態(tài)。(Tomcat7 或以下，在 Linux 系統(tǒng)中默認使用這種方式）
一個線程處理一個請求，缺點：并發(fā)量高時，線程數(shù)較多，浪費資源
二、nio(new I/O)
是Java SE 1.4及后續(xù)版本提供的一種新的I/O操作方式(即java.nio包及其子包)。Java nio是一個基于緩沖區(qū)、并能提供非阻塞I/O操作的Java API，因此nio也被看成是non-blocking I/O的縮寫。它擁有比傳統(tǒng)I/O操作(bio)更好的并發(fā)運行性能。要讓Tomcat以nio模式來運行只需要在Tomcat安裝目錄/conf/server.xml 中將對應(yīng)的中protocol的屬性值改為org.apache.coyote.http11.Http11NioProtocol即可利用 Java 的異步請求 IO 處理，可以通過少量的線程處理大量的請求
三、apr(Apache Portable Runtime/Apache可移植運行時) （ 安裝配置過程相對復(fù)雜）
Tomcat將以JNI的形式調(diào)用Apache HTTP服務(wù)器的核心動態(tài)鏈接庫來處理文件讀取或網(wǎng)絡(luò)傳輸操作，從而大大地提高Tomcat對靜態(tài)文件的處理性能。Tomcat apr也是在Tomcat上運行高并發(fā)應(yīng)用的首選模式。從操作系統(tǒng)級別來解決異步的IO問題
APR是使用原生C語言編寫的非堵塞I/O，利用了操作系統(tǒng)的網(wǎng)絡(luò)連接功能，速度很快。
但是需先安裝apr和native，若直接啟動就支持apr，能大幅度提升性能。
zabbix:
1.你們zabbix運行在什么環(huán)境里
答：Zabbix Server需運行在 LAMP（Linux+Apache+Mysql+PHP）環(huán)境下對硬件要求低
2. zabbix有哪些組件
答：zabbix_agent Zabbix_get Zabbix_server Zabbix_proxy
3. zabbix是怎么實施的
答：agentd需要安裝到被監(jiān)控的主機上，它負責(zé)定期收集各項數(shù)據(jù)，并發(fā)送到zabbix server端，zabbix server將數(shù)據(jù)存儲到數(shù)據(jù)庫中，zabbix web根據(jù)數(shù)據(jù)在前端進行展現(xiàn)和繪圖。這里agentd收集數(shù)據(jù)分為主動和被動兩種模式：
主動：agent請求server獲取主動的監(jiān)控項列表，并主動將監(jiān)控項內(nèi)需要檢測的數(shù)據(jù)提交給server/proxy
被動：server向agent請求獲取監(jiān)控項的數(shù)據(jù)，agent返回數(shù)據(jù)。
4. zabbix是怎么微信報警的
答：首先需要申請一個微信企業(yè)號，點擊通訊錄創(chuàng)建公司和部門，添加需要的信息，然后添加成員信息，填上微信號，手機號、郵箱、三者中的一個，能夠和報警的微信號匹配，然后用添加的微信號掃描二維碼關(guān)注，收集資料：應(yīng)用ID 、部門ID 、成員賬號 、cropid、Secret，添加到報警腳本里面（第一組答案）
答：1.首先，需要有一個微信企業(yè)號。（一個實名認證的[微信號]一個可以使用的[手機號]一個可以登錄的[郵箱號]
2.下載并配置微信公眾平臺私有接口。
3.配置Zabbix告警，（增加示警媒介類型，添加用戶報警媒介，添加報警動作）。（二組答案）
5. zabbix監(jiān)控了多少客戶端，客戶端是怎么進行批量安裝的
答：監(jiān)控了40臺機器，客戶端用ansible分發(fā)的配置文件，配置文件里面設(shè)置了被動發(fā)現(xiàn)。
6. 你維護的zabbix監(jiān)控有多少節(jié)點（監(jiān)控項）。 zabbix數(shù)據(jù)存放在哪
答：監(jiān)控了web服務(wù)的幾個選項，機器的狀態(tài)，數(shù)據(jù)庫的狀態(tài)，加起來是30多個選項；數(shù)據(jù)存放在數(shù)據(jù)庫的var/lib/mysql
7. zabbix數(shù)據(jù)越來越大，有什么樣的解決方案
答：將數(shù)據(jù)遷移到其他地方或者直接將不需要的數(shù)據(jù)清除
8. zabbix是否支持讀寫分離
答：zabbix本事沒有讀寫分離，但是可以對儲存zabbix數(shù)據(jù)的數(shù)據(jù)庫進行讀寫分離
9. 線上的zabbix用的哪種模式監(jiān)控，服務(wù)器怎么監(jiān)控，有哪些業(yè)務(wù)做了監(jiān)控，做么做的
答：主動監(jiān)控，通過agent這個客戶端去監(jiān)控，要么是自帶的模板，要么就是自己寫一個模板，zabbix支持很多的擴展。
10. zabbix中的item是什么
答：Item是從主機里面獲取的所有數(shù)據(jù)。通常情況下我叫itme為監(jiān)控項
11. zabbix用 的哪個版本
答：3.2版本,因為這個版本比較穩(wěn)定
12. zabbix如果要監(jiān)控100臺機器，最快的方式你怎么做
答： 使用server端的自動發(fā)現(xiàn)，使用ansible或者saltstack進行快速部署agent端配置文件，然后配置自動發(fā)現(xiàn)即可
13. zabbix那臺服務(wù)器如果出現(xiàn)問題怎么解決
答：一般問題有：
找不到url，原因：Apache缺少指向/usr/share/zabbix相關(guān)目錄的配置文件
解決辦法：配置/etc/httpd/conf.d/zabbix.conf文件內(nèi)容如下
服務(wù)器無法處理說當(dāng)前請求，PHP解析出錯，原因：PHP版本太低，需要安裝PHP5.4以上的版本
解決辦法：CentOS6默認yum安裝的是php5.3，需要構(gòu)建yum源安裝或進 行源碼安裝高版本PHP
服務(wù)器無法處理當(dāng)前請求，權(quán)限不足，原因：apache對/etc/zabbix/web/maintenance.inc.php文件的權(quán)限不足導(dǎo)致處理中斷
解決辦法：更改/etc/zabbix/web/目錄的屬主14. zabbix模板有自己寫過嗎
答：比如監(jiān)控nginx，腳本就不說了，主要是agent里面加的規(guī)則，在zabbix_agentd.conf中添加UserParameter=nginx.status[*],/bin/bash /etc/zabbix/scripts/nginx_status.sh $1
15. zabbix是否可以實現(xiàn)當(dāng)一個服務(wù)斷掉，就觸發(fā)一個動作，然后重啟
答：只會執(zhí)行，成功不成功不會檢測。
遠程執(zhí)行命令是server端向agent端執(zhí)行，不支持主動模式的agent、不支持代理模式、zabbix用戶必須對命令具有執(zhí)行權(quán)限，可以使用sudo賦予root權(quán)限(配置sudo無密碼方式)、遠程命令只是執(zhí)行，執(zhí)行成功與否并不檢測并確認，可在” Monitoring-->Events”中查看action執(zhí)行時，或在”Reports-->Action log”中查看遠程命令是否執(zhí)行成功(成功為” Executed”)。
16. zabbix自動發(fā)現(xiàn)怎么做
答：agent端指定自動發(fā)現(xiàn)的ip
客戶端正常創(chuàng)建
Configuration-->Discovery-->Creat discovery rule
Name：自動發(fā)現(xiàn)規(guī)則的名字
Discovery by proxy：是否使用代理
ip range：掃描地址段，可以配置為單個IP
Delay（in sec）：延遲時長，為了試驗效果，建議設(shè)置小一點，一分鐘即可
checks：檢查客戶端手段
Device upiqueness criteris：設(shè)置唯一標準性
Enable：啟動
17.zabbix監(jiān)控MySQL哪些參數(shù)， zabbix監(jiān)控硬件哪些參數(shù)
答：查詢吞吐量 查詢執(zhí)行性能 連接情況 緩沖池使用情況
18.zabbix監(jiān)控硬件哪些參數(shù)
答：CPU使用情況，內(nèi)存使用情況，網(wǎng)絡(luò)情況，硬盤掛載使用率等
19. 除了zabbix你還用過哪些監(jiān)控工具
答：Nagios、openfalcon
20. zabbix監(jiān)控和nagios有什么區(qū)別
答：Nagios簡單直觀，報警與數(shù)據(jù)都在同一頁面，紅色即為問題項。Nagios web端不要做任何配置。
Zabbix監(jiān)控數(shù)據(jù)與報警是分開的，查看問題項需要看觸發(fā)器，查看數(shù)據(jù)在最新數(shù)據(jù)查看。而且zabbix有很多其它配置項
Nagios要花很多時間寫插件，Zabbix要花很多時間探索功能。
Nagios更易上手，Nagios兩天弄會，Zabbix兩周弄會。
Zabbix畫圖功能比Nagios更強大
高薪技術(shù)必備：
1. 你知道的中間件有哪些？
答：Tomcat、redis、memcache
2.memcache與redis區(qū)別？
答：數(shù)據(jù)結(jié)構(gòu)：Memcache僅能支持簡單的K-V形式，Redis支持的數(shù)據(jù)更多
多線程：Memcache支持多線程,Redis支持單線程，CPU利用Memcache利用率更高
持久化：Redis支持持久化，Memcache不支持持久化
分布式：Redis做主從結(jié)構(gòu)，而Memcache服務(wù)器需要通過hash一致化來支撐主從結(jié)構(gòu)
虛擬內(nèi)存：Redis當(dāng)物理內(nèi)存使用完時，會將一些很久沒有用的內(nèi)存交換到磁盤，而Memcache采取的LUR策略，將一部分數(shù)據(jù)刷新
3. redis如何做持久化？
答：Redis有二種持久化方式：
1. RDB: 將Redis內(nèi)存中的數(shù)據(jù)，完整的生成一個快照，以二進制格式文件（后綴RDB）保存在硬盤當(dāng)中。當(dāng)需要進行恢復(fù)時，再從硬盤加載到內(nèi)存中。(Redis主從復(fù)制，用的也是基于RDB方式，做一個復(fù)制文件的傳輸。)
2. AOF：就是寫日志，每次執(zhí)行Redis寫命令，讓命令同時記錄日志（以AOF日志格式）。Redis宕機時，只要進行日志回放就可以恢復(fù)數(shù)據(jù)。
4.使用redis有什么好處
答：速度快，數(shù)據(jù)運行在內(nèi)存當(dāng)中，但要小心占全部內(nèi)存支持的數(shù)據(jù)類型豐富，支持事務(wù)可以做緩存，消息隊列，可以設(shè)置過期時間。在排行榜，計數(shù)器，發(fā)布和訂閱場景下都在使用redis但是reids 不能保證數(shù)據(jù)的一致性，在特定條件下可能會丟失寫操作
5.redis集群的原理
答：redis一般最少是6臺機器，3主3從的結(jié)構(gòu)，就是說，每臺主至少會有一臺從機；每一個節(jié)點都會存有這個集群所有主節(jié)點以及從節(jié)點的信息。
投票機制：
它們之間通過互相的ping-pong判斷是否節(jié)點可以連接上。如果有一半以上的節(jié)點去ping一個節(jié)點的時候沒有回應(yīng)，集群就認為這個節(jié)點宕機了，然后去連接它的備用節(jié)點。如果一半以上的主宕機，集群就會進入fail狀態(tài)
6.docker集群最大節(jié)點數(shù)是
答：16384個
7.怎么測試redis連通性？
答：使用ping命令
8.列出安裝hadoop流程步驟
答：1) 創(chuàng)建Hadoop賬號2）更改ip3)安裝Java環(huán)境4）修改host文件域名5）安裝ssh配置無密鑰登陸6）解壓hadoop包7）配置conf 下面的配置文件8）hadoop namenode-format 格式化9） start 啟動
9.日志分析主要分析哪些數(shù)據(jù)？
答：1、基礎(chǔ)信息，總抓取量、停留時間(h)及訪問次數(shù)這三個基礎(chǔ)信息；
2、目錄抓取，提取出爬蟲抓取的目錄，分析每日目錄抓取量；
3、時間段抓取，提取每日的時間段的爬蟲抓取量，重在分析每日的抓取情況，找到相應(yīng)的抓取量較為密集的時間段；
4、IP段的抓取，進行統(tǒng)計，每日每個IP的抓取量；
5、狀態(tài)碼的統(tǒng)計，HTTP狀態(tài)碼返回值10.ELK由哪及部分組成，每個的作用是啥
答：Elasticsearch 是一個分布式的搜索引擎，負責(zé)搜集、分析、存儲數(shù)據(jù)三大功能
Logstash 用來日志的搜集、分析、過濾日志的工具，支持大量的數(shù)據(jù)獲取方式。
Kibana 提供一個友好的web界面
Logstash去搜集所需要的日志，進行過濾-->Elasticsearch再次去分析，存儲-->Kibana 將搜集的數(shù)據(jù)展示到web頁面上11.ELK主要用來分析哪些數(shù)據(jù)
答：主要就是一個日志分析系統(tǒng)，常用的有web日志，數(shù)據(jù)庫日志。也可以監(jiān)控系統(tǒng)的硬件和應(yīng)用各個組件的狀態(tài)。
12.ELK能用來做什么？
答：分析日志，也可以做系統(tǒng)監(jiān)控，報表功能。
13.ES常用插件有哪些？
答：head是一個與Elastic集群相交互的Web前臺kopf管理工具
bigdesk集群提供動態(tài)的圖表與統(tǒng)計數(shù)據(jù)
14.kibana是什么，有什么作用
答：Kibana是一個優(yōu)秀的前端日志展示框架，它可以非常詳細的將日志轉(zhuǎn)化為各種圖表，就是為了提供可視化
15.ansible與saltstack區(qū)別
答：1.響應(yīng)速度SaltStack的master和minion主機是通過ZeroMQ傳輸數(shù)據(jù)，而Ansible是通過標準SSH進行數(shù)據(jù)傳輸，SaltStack的 響應(yīng)速度要比Ansible快很多。
2.安全
SaltStack使用ZeroMQ進行數(shù)據(jù)傳輸，ZeroMQ本身不加密，AES加密，需注意MITM攻擊
Ansible使用標準SSH連接傳輸數(shù)據(jù)，不需要在遠程主機上啟動守護進程，并且標準SSH數(shù)據(jù)傳輸本身就是加密傳輸，這樣遠程主機不容易被攻擊。
3.自身運維SaltStack需要在Master和Minion主機啟動守護進程，自身需要檢測守護進程的運行狀態(tài)，增加運維成本。Ansible和遠端主機之間的 通信是通過標準SSH進行，遠程主機上只需要運行SSH進程就可以進行運維操作，SSH是機房主機中一般都安裝和啟動的進程，所以在Ansible進行運 維的時候只需要關(guān)注Ansible主機的運行狀態(tài)。Ansible對機房運維不會增加過多的運維成本。從工具本身的運維角度來說，Ansible要比 SaltStack簡單很多。
4.使用語法Ansible的Playbook語法要比SaltStack的State語法具有更好的可讀性。在使用的過程中發(fā)現(xiàn)Ansible在實現(xiàn)loop的更加的簡潔，也可以使用相對路徑。
16. ansible 使用過哪些模塊
答：copy模塊，file模塊，cron模塊，group模塊，yum模塊，service模塊，ping模塊
17. 你們在公司主要用來做什么
答：主要是用來批量自動化的去給我們的服務(wù)器部署一些服務(wù)18. elk中的logstash是怎么收集日志的，在客戶端的logstash配置文件主要有哪些內(nèi)容？
答：通過指定的配置文件，按規(guī)定的正則去收集指定文件里的數(shù)據(jù)。
input指定的輸入filter過濾規(guī)則output輸出到指定的地方運維案例1．有客戶反映無法訪問網(wǎng)站
案例:有客戶說訪問不到你們的網(wǎng)站，但是你們自己測試內(nèi)網(wǎng)和外網(wǎng)都是通的，你會怎么排查并解決客戶的問題。我們自己測了都沒問題，只是這個客戶訪問有問題，那肯定是要先聯(lián)系到這個客戶，能遠程最好問一下客戶的網(wǎng)絡(luò)是不是正常的，訪問其它的網(wǎng)站有沒有問題（比如京東、百度什么的）如果訪問其它網(wǎng)站有問題，那叫客戶解決本身網(wǎng)絡(luò)問題。
如果訪問其它網(wǎng)站都沒問題，用ping和nslookup解析一下我們的網(wǎng)站是不是正常的，讓客戶用IP來訪問我們的網(wǎng)站是否可行，如果IP訪問沒問題，那就是客戶的DNS服務(wù)器有問題或者DNS服務(wù)器解析不到我們的網(wǎng)站。還有一種可能就是跨運營商訪問的問題，比如我們的服務(wù)器用的是北方聯(lián)通、而客戶用的是南方移動，就也有可能突然在某個時間段訪問不到，這種情況在龐大的中國網(wǎng)絡(luò)環(huán)境中經(jīng)常發(fā)生（一般是靠CDN解決）。還有可能就是我們的網(wǎng)站沒有SSL證書，在公網(wǎng)是使用的是http協(xié)議，這種情況有可能就是沒有用https協(xié)議網(wǎng)站被運營商劫持。
2．如果網(wǎng)站出現(xiàn)了5XX錯誤，你會如何解決？案例:在服務(wù)器處理請求時出問題了，服務(wù)器可以發(fā)一個 5xx 系列錯誤碼給客戶端，表示服務(wù)器在處理請求的時候出問題了，問題是出在服務(wù)器身上而不是客戶端身上。
以nginxWeb服務(wù)器為例的:
5xx: 服務(wù)器錯誤
501 服務(wù)器不具備完成請求的功能。例如，服務(wù)器無法識別請求方法時可能會返回此代碼。
503 服務(wù)器目前無法使用（由于超載或停機維護）。通常，這只是暫時狀態(tài)。（服務(wù)不可用）
505 服務(wù)器不支持請求中所用的 HTTP 協(xié)議版本。（HTTP 版本不受支持）
一、解決500錯誤：
1、500錯誤指的是服務(wù)器內(nèi)部錯誤，也就是服務(wù)器遇到意外情況，而無法履行請求。
2、500錯誤一般有幾種情況：
（1）web腳本錯誤，如php語法錯誤，lua語法錯誤等。
（2）訪問量大的時候，由于系統(tǒng)資源限制，而不能打開過多的文件
3、一般分析思路：
（1）查看nginx error log ，查看php error log
（2）如果是too many open files，修改nginx的worker_rlimit_nofile參數(shù)，使用ulimit查看系統(tǒng)打開文件限制，修改/etc/security/limits.conf
（3）如果是腳本的問題，則需要修復(fù)腳本錯誤，并優(yōu)化代碼
（4）各種優(yōu)化都做好，還是出現(xiàn)too many open files，那就要考慮做負載均衡，把流量分散到不同服務(wù)器上去了
二、解決502，504錯誤
https://blog.csdn.net/chris_hee/article/details/83359438
https://blog.csdn.net/fangoooooooooooo/article/details/801034441、使用nginx代理，而后端服務(wù)器發(fā)生故障；或者php-cgi進程數(shù)不夠用；php執(zhí)行時間長，或者是php-cgi進程死掉；已經(jīng)fastCGI使用情況等都會導(dǎo)致502、504。
2、502 是指請求的php-fpm已經(jīng)執(zhí)行，但是由于某種原因而沒有執(zhí)行完畢，最終導(dǎo)致php-fpm進程終止。
一般來說，與php-fpm.conf的設(shè)置有關(guān)，也與php的執(zhí)行程序性能有關(guān)，網(wǎng)站的訪問量大，而php-cgi的進程數(shù)偏少。針對這種情況的502錯誤，只需增加php-cgi的進程數(shù)。
具體就是修改/usr/local/php/etc/php-fpm.conf文件，將其中的max_children值適當(dāng)增加。
這個數(shù)據(jù)要依據(jù)你的VPS或獨立服務(wù)器的配置進行設(shè)置。一般一個php-cgi進程占20M內(nèi)存，你可以自己計算下，適量增多。
/etc/init.d/php-fpm restart 然后重啟一下.
3、504 表示超時，也就是客戶端所發(fā)出的請求沒有到達網(wǎng)關(guān)，請求沒有到可以執(zhí)行的php-fpm。與nginx.conf的配置也有關(guān)系。3．如果網(wǎng)站訪問很慢，你會如何排查
https://blog.csdn.net/lufeisan/article/details/53150971范例一： Linux 中一個java進程占用cpu很高
解決： top -p 33301 strace -p 33301
范例二: 線上的一臺服務(wù)器，總出現(xiàn)訪問慢的情況，點擊一個鏈接要2S以上時間才打開，按照當(dāng)時對訪問人數(shù)的統(tǒng)計，服務(wù)器不應(yīng)該這么慢，所以我做了對apache進程進行分析。
一． 在頁面訪問變慢的時候，我用top查看服務(wù)器負載，發(fā)現(xiàn)負載不高，因此有可能不是程序問題。
二． 我查看了線程中HTTP的數(shù)量，線程達到了訪問最大值，由此斷定是訪問人數(shù)過多導(dǎo)致的
三． 為了驗證，我用netstat查看連接數(shù)和當(dāng)前連接數(shù)，發(fā)現(xiàn)訪問量特別大，超出了我們的估算值。
四． 查看了用戶訪問頁面的情況，把access_log打開，發(fā)現(xiàn)90%以上的訪問都是直接訪問資源文件，猜測可能用戶使用了多線程下載工具，或者遭受了盜鏈。
解決方法： 對單個IP鏈接的線程限制，不允許多個線程鏈接資源。 我當(dāng)時采用的是mod_limitipconn這個模塊。 然后添加URL重寫，防止盜鏈。4. cpu突然飆高如何處理 像這種情況有很多種可能:
1.同時運行的應(yīng)用太多了，占用服務(wù)器資源
2.服務(wù)器內(nèi)存存的數(shù)據(jù)太多了
3.服務(wù)器被CC攻擊了
4.某個程序起沖突了
案例:有個java進程占用cpu資源特多
解決:
使用top查看進程維度的CPU負載
通過 top 命令查看系統(tǒng)的負載問題，并定位耗用較多 CPU 資源的進程，發(fā)現(xiàn)是個java進程，將進程信息發(fā)送給java開發(fā)，確定此進程無用，便將此進程殺掉，cpu問題就解決了。5．數(shù)據(jù)庫強制關(guān)閉導(dǎo)致故障排查案例https://blog.csdn.net/jethai/article/details/52345231案例：
mysql意外斷電后啟動mysql數(shù)據(jù)庫報錯
Another MySQL daemon already running withthe same unix socket.
本地登錄mysql數(shù)據(jù)庫提示：
ERROR 2002 (HY000): Can't connect to local MySQL server through socket '/var/lib/mysql/mysql.sock' (111)
原因：
mysql沒有正常停止，機器重啟后mysql.sock一直存在，但機器重啟后mysql實際上為啟動的，
所以呢需要把/var/lib/mysql 下的mysql.sock文件給刪掉，然后就可以啟動了
6. CDN或者IDC機房帶寬增加很高案例分析
案例： 有一次我們公司在做一個推廣活動，CDN帶寬突然增加很多，第一反應(yīng)是不是遭受DDOS攻擊了，或者是內(nèi)部服務(wù)器中毒，比如redis服務(wù)器就有一次被當(dāng)作礦機，
原因：
內(nèi)部服務(wù)器中毒，大量外發(fā)流量。
解決辦法：
我聯(lián)系機房確定機房自身無問題后（機房一般沒法幫我們的），請機房斷開連接外部IP服務(wù)器的網(wǎng)線，如負載均衡器，僅保留VPN SERVER，然后斷掉內(nèi)部服務(wù)器出網(wǎng)光關(guān)的線路，切斷外發(fā)流量源頭。接下來查看監(jiān)控流量服務(wù)，判斷外發(fā)流量的服務(wù)器，然后進行處理。7. 一次網(wǎng)站遷移故障案例分析
案例：
公司服務(wù)器要整改，準備用一臺新服務(wù)器安裝LAMP環(huán)境，承擔(dān)現(xiàn)在的WEB服務(wù)器，然后將現(xiàn)有的服務(wù)器重新規(guī)劃整理。當(dāng)把代碼用rsync同步到新服務(wù)器上，開啟apache服務(wù)，做好DNS解析后，剛開始訪問的時候是沒問題的！但是在不到一分鐘的時候，網(wǎng)站就打開的非常慢，主頁打開時間有時到了幾分鐘（幾乎相當(dāng)于訪問不了），查看Apache報錯日志，沒有明顯的錯誤異常日志；
原因：
原因是perfork模式的參數(shù)設(shè)置有問題，根本就沒生效，而導(dǎo)致采用默認的256，但是現(xiàn)在的鏈接并發(fā)數(shù)已經(jīng)大于256了，所以后面的訪問用戶就處在等待的狀態(tài)，也就出現(xiàn)了一分鐘后就訪問特別慢的情況；
解決辦法：
遇到這種問題的時候，我們要先分析故障原因，定義問題出現(xiàn)的大范圍，這次故障是在服務(wù)器壓力并不大的時候就出現(xiàn)訪問很慢的現(xiàn)象，所以我們可以確認不是服務(wù)器本身的問題，而是配置問題。
先通過服務(wù)器的top命令我們可以得到不是服務(wù)器硬件的問題
再通過內(nèi)網(wǎng)訪問，得到的也不是網(wǎng)絡(luò)的因素
創(chuàng)建靜態(tài)頁面，排除apache以外其他服務(wù)配置問題
查看配置文件，找到了問題所在，然后解決問題
具體解決方式在以下網(wǎng)址：一次生產(chǎn)環(huán)境web服務(wù)遷移故障總結(jié)與反思http://blog.51cto.com/oldboy/1227976
8．一主多從，主從庫分別宕機解決案例
案例：
早晨發(fā)現(xiàn)msyql主宕機，并且沒有任何異常記錄，日志表現(xiàn)為執(zhí)行shutdown命令，但是shwtdown完成后沒有重新啟動
原因：
是因為apt的自動更新導(dǎo)致的mysql shutdown
解決辦法：
如果是主宕機的話，那么讀寫服務(wù)都不能提供了，我們就要把從提升為主，首先我們要確保從庫把所有的relay log日志都讀取完畢，然后通過show slave status查看，如果幾個從庫io進程都是正常，沒有落后于主的話，選擇哪個從都是一樣的，然后我們進入從庫，執(zhí)行stop slave；然后進入數(shù)據(jù)庫目錄，刪除aster.info和relay-log.info文件，刪除之前先做下備份，然后配置my.cnf文件，開啟log-bin，把程序里面之前記錄的master的IP改成現(xiàn)在從的IP，重啟就解決了這個問題
具體解決方式在以下網(wǎng)址：具體解決方式在以下網(wǎng)址：
9． 網(wǎng)站遭受木馬攻擊，導(dǎo)致網(wǎng)站目錄下所有的文件被篡改
案例：
公司一個lamp的服務(wù)器站點目錄下的文件一打開就會出現(xiàn)另一個網(wǎng)址
原因：
所有文件都被植入了一下內(nèi)容<script language=javascript src=http://luoahong.blog.51cto.com/504977/1827164>包括圖片文件也被植入了，網(wǎng)站打開時就會調(diào)用這個地址，造成的影響很惡劣
解決辦法：
遍歷所有目錄有文件 把以上被植入的內(nèi)容刪除掉。[root@test ~]# find /oldboy -type f|xargs sed -i 's# <script language=javascript src=http://luoahong.blog.51cto.com/504977/1827164>##g'
1、 先備份數(shù)據(jù)。然后，執(zhí)行命令批量修改回來。
2、 a.備份原始出問題的原始文件； b.歷史備份覆蓋；c.find+sed 替換；
[root@test ~]find. -type f -exec sed -i ‘s#<script language=javascript src=http://luoahong.blog.51cto.com/504977/1827164>##g’ {} \;
查看處理結(jié)果，詳細查看了日志，追蹤問題發(fā)生來源
10. fstab修改錯誤導(dǎo)致系統(tǒng)無法啟動修復(fù)案例
案例：
為了公司需要，在linux下修改自動掛載/dev/sda5到/u01，修改成/dev/sda5/weblogic，于是把fstab文件中/u01修改成了/weblogic，啟動時報無法掛載錯誤，進入repair filesystem模式后，想要修改/etc/fstab，結(jié)果文件都是read only
原因：
把fstab文件中/u01修改成了/weblogic，原因是把配置文件修改錯誤了
解決辦法：
1.啟動linux提示失敗,輸入root賬戶密碼，進入 repair filesystem#，注意此時修復(fù)fstab文件會提示readonly無法保存修改。
2.提權(quán)成root
3.mount / -o remount
這時候，/etc/fstab就可以修改了，這一步是核心內(nèi)容
4.修改fstab文件 vi /etc/fsta11. Linux服務(wù)器中木馬，手工清除方法 https://www.cnblogs.com/shiyiwen/p/5191869.html
故障現(xiàn)象：
那天下午有幾臺服務(wù)器出現(xiàn)流量超高，平時只有幾百M的流量，那時候發(fā)現(xiàn)流量上G了，達到這個量第一感覺就是遭受了DDOS流量攻擊，那時候手上的服務(wù)器比較多，出現(xiàn)幾臺并沒有放在眼里，覺得查查就可以出來結(jié)果。
原因：
iftop發(fā)現(xiàn)我們的服務(wù)器一直向外大量發(fā)包，對某個IP的流量能到達600多M,這時我們意識到服務(wù)器被黑了
解決方案：
一直在殺進程，剛開始進程殺了又起來，文件刪了又自動生成，線上環(huán)境又沒有防火墻配置，無奈之下只好想了一個怪招，把/bin/bash重命名一下，果然流量下來了。12記一次服務(wù)器被植入挖礦木馬CPU飆升200%解
https://blog.csdn.net/bntx2jsqfehy7/article/details/79797937
故障現(xiàn)象：
我打開了服務(wù)器，看到Tomcat掛了，然后順其自然的重啟，啟動過程中直接被killed，再試試數(shù)據(jù)庫，同樣沒成功，多次嘗試甚至重啟機器無果，我打了個top，不知道誰的進程，因為它就是Tomcat等程序啟動不了的元兇然而并沒有什么用，過一會再看那個東西又跑出來占cpu。懷疑是個定時任務(wù)，
Crontab -l 進行查看，發(fā)現(xiàn)什么也沒有，但是黑色的屏幕右下角有個白色方框，肯定是偽裝的，
原因：
crul過去是下面的腳本，過程就是在挖礦，既然知道它是個定時任務(wù)，那就先取消了它，并且看看它是誰在運行殺掉，找到存放目錄：進入臨時目錄：被我發(fā)現(xiàn)配置文件了，先來看看內(nèi)容發(fā)現(xiàn)了不少信息啊，user是他的server的登錄用戶,下面是密碼，只可惜加密過，應(yīng)該找不到對方。干掉這兩個文件后再查看top
解決方案：
找到寄生的目錄，一般都會在tmp里，我這個是在/var/tmp/。首先把crontab干掉，殺掉進程，再刪除產(chǎn)生的文件。啟動Tomcat等程序，大功告成！
13. 9臺nosql 同時宕機故障
http://www.361way.com/login-underlying-authentication/4216.html
故障現(xiàn)象：
晚上22:20分左右，手機收到現(xiàn)網(wǎng)主機的宕機撥測短信告警。收到宕機短信本屬正常，現(xiàn)網(wǎng)業(yè)務(wù)有二千多臺 server 難保其中哪臺不出問題。可是還未能趕著打開電腦，緊接著同一時間又是8臺主機的宕機短信。未查看工程文檔核對主機之前，猜測懷疑是某一刀框出了問題，導(dǎo)致同一機框內(nèi)的所有刀片不能服務(wù)。不過等查看過第一臺以后，發(fā)現(xiàn)是pc server ，另外8臺和第一臺是同一業(yè)務(wù)下的另外幾個節(jié)點。
原因：
通過查看9臺主機的操作記錄，都存在相同的histroy記錄、ts_user用戶登錄和su操作（故障發(fā)生時間點之前幾分鐘內(nèi)）。在9臺主機上也通過echo $變量名 ，發(fā)現(xiàn)history記錄中的部分變量是不存在的。導(dǎo)致前面一部分被解析成空。
解決方案：
在我的測試機中不存在變量$ABC ，所以$ABC被解析為空，這里執(zhí)行ls $ABC/ 的結(jié)果相當(dāng)于執(zhí)行成了 ls 同樣，把變量改正確
14. 大并發(fā)慢查詢導(dǎo)致CPU資源耗盡，如何處理
https://support.huaweicloud.com/usermanual-rds/rds_12_0008.html
故障現(xiàn)象：
數(shù)據(jù)庫實例上存在大量并發(fā)的select count(0)慢操作，系統(tǒng)CPU耗盡，隨時有宕機的風(fēng)險。
原因:
應(yīng)用端大并發(fā)觸發(fā)select count(0)慢操作，導(dǎo)致系統(tǒng)CPU資源耗盡。
解決方案：
申請kill權(quán)限，間歇性批量執(zhí)行kill select count(0)慢操作，定位select count(0)觸發(fā)來源，停止來源，并拆分優(yōu)化sql。
15. crontab mailr op造成的拒絕房屋
http://www.361way.com/crontab-mailto-deny-ssh/4300.html故障現(xiàn)象：
接業(yè)務(wù)同事電話，其中一臺server無法ssh正常連接，同時也收到宕機短信告警信息。直接ping了下主機地址可以ping通.
原因：
crontab進程在執(zhí)行時，每執(zhí)行一次會向root 進行一次匯報。即會調(diào)用后面的sendmail 進程和postdrop 進程，郵件文件會存放在/var/spool/postfix/maildrop目錄 ，查看logcollect 用戶的crontab任務(wù)發(fā)現(xiàn)， 有幾百個crontab任務(wù)存在,造成maildrop目錄文件越堆越多。目錄被占滿后，導(dǎo)致sendmail和postdrop進程長時間得不到釋放。進程越堆越到，直到資源耗盡，ssh連接異常。
解決方法：
禁用crontab MAILTO功能或crontab中新增自動清理/var/spool/postfix/maildrop目錄。當(dāng)然比較推薦前者，crontab里啟用這個本來就是個資源浪費的功能－－－有查看root下的性能匯報需求者除外。禁用crontab的mailto功能操作步驟為：
vi /etc/crontab
將‘MAILTO=root’替換成‘MAILTO=""，
然后service crond restart即可。
后記：
另外，這個問題和Suse工程師也溝通過，該問題更多的是操作規(guī)范性的范疇。如果在每個crontab任務(wù)后面加上1>/dev/null 2>&1 ，就不會出現(xiàn)郵件調(diào)用到maildrop目錄的問題了。這里由于crontab任務(wù)過多，使用了在用戶的crontab配置首行增加MAILTO=""的方法。16.inode滿導(dǎo)致passwd 命令出錯處理
http://www.361way.com/passwd-token-manipulation-error/4304.html故障現(xiàn)象：
1、修改密碼時報錯 passwd: Authentication token manipulation error
2、添加用戶報錯：unable to lock password file
分析問題：
1、檢查相關(guān)配置文件/etc/passwd /etc/shadow
檢查上面兩相配置文件并與正常主機進行比對，未發(fā)現(xiàn)異常。
2、查看磁盤使用率
根據(jù)報錯信息，google查看提示有可能是磁盤空間滿引起。不過通過df 查看時未發(fā)現(xiàn)異常
3、strace追蹤分析
使用命令strace -f passwd 追蹤分析原因，看到關(guān)鍵報錯信息：“No space left on device”，即然df查看硬盤空間夠用，很可能就是inode滿了。查看的確是根分區(qū)inode滿了，然后清除了一些小文件.
17.阿里云ssh連接慢問題處理
http://www.361way.com/aliyun-ssh-slow/5771.html一、問題描述
阿里云平臺上分發(fā)的虛擬機會有ssh連接慢的問題（一般30多秒才能出現(xiàn)密碼認證界面，同一模板分發(fā)的虛擬機，一小部分有ssh連接慢的問題）。
通過查看sshd_config配置文件，發(fā)現(xiàn)影響ssh連接兩項已做過處理：
UseDNS=no
GSSAPIAuthentication no
而主機OS重啟后，ssh連接慢的問題就沒有了。
1、排查網(wǎng)絡(luò)影響
通過阿里云內(nèi)部的主機通過內(nèi)網(wǎng)連接發(fā)現(xiàn)同樣慢。通過ssh 127.0.0.1也同樣很慢。
2、ssh連接詳情分析
通過 ssh -v參數(shù)查看詳細連接過程。發(fā)現(xiàn)只除了認證等待時間過長外，后面未發(fā)現(xiàn)異常。
三、問題解決
通過查詢到的資料，了解到問題原因為：dbus的服務(wù)重啟后，systemd-logind服務(wù)沒有重啟導(dǎo)致。故而在日志中會出現(xiàn)“[system] Failed to activate service ‘org.freedesktop.login1‘: timed out”的報錯。解決方法為重啟systemd-logind服務(wù)。命令如下：
systemctl restart systemd-logind
systemctl status systemd-logind18.mysql innodb異常修復(fù)
https://www.linuxprobe.com/mysql-innodb-yichang.html啟動mysql服務(wù)，提示未知/不支持的表類型：innodb，無法正常啟動。
刪除/ var / lib / mysql /目錄，重新啟動數(shù)據(jù)庫服務(wù)，并初始化，發(fā)現(xiàn)正常，show engines能發(fā)現(xiàn)有innodb引擎。再將數(shù)據(jù)庫停掉，將之前備份的/ var / lib / mysql /目錄的內(nèi)容覆蓋當(dāng)前位置的內(nèi)容，重啟。又發(fā)現(xiàn)不能進行啟動，報錯內(nèi)容和剛剛一樣。
wiki目錄是測試數(shù)據(jù)的庫，ib開頭的兩個文件為日志文件，mysql目錄下為系統(tǒng)庫相關(guān)的東西。再次使用初始化的數(shù)據(jù)，并將wiki目錄和ibdata1文件覆蓋到/ var / lib / mysql目錄下，可以正常啟動，也可以正常登錄。
打開迫使-InnoDB的恢復(fù)官方頁面，發(fā)現(xiàn)可以通過指定innodb_force_recovery參數(shù)，進行強制啟動和恢復(fù)在/etc/my.cnf中中增加如下內(nèi)容：
1. innodb_force_recovery = 6= 6不過在通過mysqldump備份時，又提示unknow table engine“Innodb”。登錄后，查看當(dāng)前所有的引擎類型，發(fā)現(xiàn)其中果然不存在innodb類型：由于mysql innodb數(shù)據(jù)文件的特性，可以在出現(xiàn)問題，無法正常啟動時，先將./ib
_logfile0和./ib_logfile1兩個日志文件先移走，再啟動，如果還不成功，可以用innodb_force_recovery參數(shù)進行強制恢復(fù)。除此之外，日志也很重啟，有問題先看日志。
19.已刪除但空間不釋放問題的分析與解決辦法
https://www.jb51.net/LINUXjishu/224652.html1、錯誤現(xiàn)象
運維的監(jiān)控系統(tǒng)發(fā)來通知，報告一臺服務(wù)器空間滿了，登陸服務(wù)器查看，根分區(qū)確實沒有空間了，由于Linux沒有回收站功能，我們的線上服務(wù)器所有要刪除的文件都會首先移動到系統(tǒng)/tmp目錄下，然后定期清除/tmp目錄下的數(shù)據(jù)。這個策略本身沒有問題，但是通過檢查發(fā)現(xiàn)這臺服務(wù)器的系統(tǒng)分區(qū)中并沒有單獨劃分/tmp分區(qū)，這樣/tmp下的數(shù)據(jù)其實是占用了根分區(qū)的空間。既然找到了問題，那么刪除/tmp目錄下一些大數(shù)據(jù)即可
從輸出可以看到，根分區(qū)空間仍然沒有釋放，這是怎么回事？
2、解決思路
之所以出現(xiàn)刪除access_log文件后，空間還沒釋放，就是因為httpd進程還在一直向這個文件寫入內(nèi)容，導(dǎo)致雖然刪除了access_log文件，但文件對應(yīng)的指針部分由于進程鎖定，并未從meta-data中清除，而由于指針并未被刪除，那么系統(tǒng)內(nèi)核就認為文件并未被刪除，因此通過df命令查詢空間并未釋放也就不足為奇了。
3、問題排查
既然有了解決問題的思路，那么接下來看看是否有進程一直在向acess.log文件中寫數(shù)據(jù)，這里需要用到Linux下的lsof命令，通過這個命令可以獲取一個已經(jīng)被刪除但仍然被應(yīng)用程序占用的文件列表.
從輸出結(jié)果可以看到，/tmp/acess.log文件被進程httpd鎖定，而httpd進程還一直向這個文件寫入日志數(shù)據(jù)，說明這個日志文件已經(jīng)被刪除，但由于進程還在一直向此文件寫入數(shù)據(jù)，空間并未釋放。
4、解決問題
到這里問題就基本排查清楚了，解決這一類問題的方法有很多種，最簡單的方法是關(guān)閉或者重啟httpd進程，當(dāng)然也可以重啟操作系統(tǒng)，不過這并不是最好的方法，對待這種進程不停對文件寫日志的操作，要釋放文件占用的磁盤空間，最好的方法是在線清空這個文件，可以通過如下命令完成：
echo " " >/tmp/acess.log
通過這種方法，磁盤空間不但可以馬上釋放，也可保障進程繼續(xù)向文件寫入日志，這種方法經(jīng)常用于在線清理Apache、Tomcat、Nginx等Web服務(wù)產(chǎn)生的日志文件20.linux Argument list too long錯誤解決方法
https://blog.csdn.net/fdipzone/article/details/41558461今日需要刪除/tmp目錄下的所有文件，文件數(shù)量比較多。
ls -lt /tmp | wc -l
385412
使用 rm * 后，系統(tǒng)提示錯誤 Argument list too long
原因是在linux下，試圖傳太多參數(shù)給一個系統(tǒng)命令(ls *; cp *; rm *; cat *; etc..)時，就會出現(xiàn) Argument list too long錯誤。
解決方法如下：
使用find -exec 遍歷，然后執(zhí)行刪除便可。
sudo find /tmp -type f -exec rm {} \
總結(jié)
- 上一篇： do…while循环语句
- 下一篇： Unity打开新项目报错