面試題1：當(dāng)你發(fā)現(xiàn)一條SQL很慢，你的處理思路是什么？

• 發(fā)現(xiàn)Bug
• 確定Bug不是自己造成的，如果無(wú)法確定，不要理會(huì)步驟1
• 向組內(nèi)宣傳“程序里有一個(gè)未知Bug，錯(cuò)不在我”
• 誰(shuí)響應(yīng)，誰(shuí)對(duì)Bug負(fù)責(zé)
• 沒(méi)人響應(yīng)，就要求特定人員配合調(diào)試
• 如果不配合，就是特定人員對(duì)Bug負(fù)責(zé)
• 如果特定人員配合，就相當(dāng)于特定人員發(fā)現(xiàn)了一個(gè)Bug
• 讓特定人員看步驟1
• 完美，無(wú)懈可擊

我們是如何發(fā)現(xiàn)慢SQL的？除了慢查詢(xún)?nèi)罩竞腿藶榘l(fā)現(xiàn)之外，一般出現(xiàn)慢查詢(xún)時(shí)會(huì)有如下三個(gè)特征：

• 數(shù)據(jù)庫(kù)CPU負(fù)載高。一般是查詢(xún)語(yǔ)句中有很多計(jì)算邏輯，或并發(fā)處理線程較多，導(dǎo)致數(shù)據(jù)庫(kù)cpu負(fù)載。
• IO過(guò)高導(dǎo)致服務(wù)器卡住，這個(gè)一般和全表查詢(xún)沒(méi)索引有關(guān)系，問(wèn)題出在處理的數(shù)據(jù)量太大。
• 查詢(xún)語(yǔ)句正常，索引正常但是還是慢。如果表面上索引都配置了，但是查詢(xún)慢，那得看看索引是否生效。

有些SQL雖然出現(xiàn)在慢查詢(xún)?nèi)罩局?，但未必是其本身的性能?wèn)題，可能是因?yàn)殒i等待，服務(wù)器壓力高等等。

需要分析SQL語(yǔ)句真實(shí)的執(zhí)行計(jì)劃，而不是看重新執(zhí)行一遍SQL時(shí)，看是不是變快了（查詢(xún)緩存都不帶考慮的？）。。而是使用Explain工具來(lái)逐步調(diào)優(yōu)，了解 MySQL 在執(zhí)行這條數(shù)據(jù)時(shí)的一些細(xì)節(jié)，比如是否進(jìn)行了優(yōu)化、是否使用了索引、索引選擇器是否正確選擇等等?；?Explain 的返回結(jié)果我們就可以根據(jù) MySQL 的執(zhí)行細(xì)節(jié)進(jìn)一步優(yōu)化語(yǔ)法，使索引能被正確使用，實(shí)現(xiàn)性能需求。

關(guān)于索引的創(chuàng)建及優(yōu)化原則，美團(tuán)點(diǎn)評(píng)技術(shù)團(tuán)隊(duì)的幾點(diǎn)總結(jié)，引用一下：

1.最左前綴匹配原則，非常重要的原則，mysql會(huì)一直向右匹配直到遇到范圍查詢(xún)(>、<、between、like)就停止匹配，比如a = 1 and b = 2 and c > 3 and d = 4 如果建立(a,b,c,d)順序的索引，d是用不到索引的，如果建立(a,b,d,c)的索引則都可以用到，a,b,d的順序可以任意調(diào)整；

2.=和in可以亂序，比如a = 1 and b = 2 and c = 3 建立(a,b,c)索引可以任意順序，mysql的查詢(xún)優(yōu)化器會(huì)幫你優(yōu)化成索引可以識(shí)別的形式，當(dāng)然，好習(xí)慣要靠自己保持；

3.盡量選擇區(qū)分度高的列作為索引,區(qū)分度的公式是count(distinct col)/count(*)，表示字段不重復(fù)的比例，比例越大我們掃描的記錄數(shù)越少，唯一鍵的區(qū)分度是1，而一些狀態(tài)、性別字段可能在大數(shù)據(jù)面前區(qū)分度就是0，那可能有人會(huì)問(wèn)，這個(gè)比例有什么經(jīng)驗(yàn)值嗎？使用場(chǎng)景不同，這個(gè)值也很難確定，一般需要join的字段我們都要求是0.1以上，即平均1條掃描10條記錄；

4.索引列不能參與計(jì)算，保持列“干凈”，比如from_unixtime(create_time) = '2014-05-29'就不能使用到索引，原因很簡(jiǎn)單，b+樹(shù)中存的都是數(shù)據(jù)表中的字段值，但進(jìn)行檢索時(shí)，需要把所有元素都應(yīng)用函數(shù)才能比較，顯然成本太大。所以語(yǔ)句應(yīng)該寫(xiě)成create_time = unix_timestamp('2014-05-29')；

5.盡量的擴(kuò)展索引，不要新建索引。比如表中已經(jīng)有a的索引，現(xiàn)在要加(a,b)的索引，那么只需要修改原來(lái)的索引即可。

當(dāng)然，我們知道還有單表數(shù)據(jù)量過(guò)大、大字段檢索、模糊匹配效率、時(shí)間維度統(tǒng)計(jì)效果差等MySQL硬性問(wèn)題，俗稱(chēng)硬傷，那我們就得基于實(shí)際情況來(lái)進(jìn)行分庫(kù)分表、切換檢索引擎（如ES、FastDFS）等方式來(lái)處理了，術(shù)業(yè)有專(zhuān)攻，總不能在一棵樹(shù)上吊死對(duì)吧。

面試題2：怎么理解負(fù)載均衡的？你處理負(fù)載均衡都有哪些途徑？

負(fù)載均衡(Load Balance)是集群技術(shù)（Cluster）的一種應(yīng)用。負(fù)載均衡可以將工作任務(wù)分?jǐn)偟蕉鄠€(gè)處理單元，從而提高并發(fā)處理能力。下面是一組普通的web架構(gòu)，我理解做負(fù)載均衡的切入點(diǎn)一般在web層和數(shù)據(jù)層。

目前最常見(jiàn)的負(fù)載均衡應(yīng)用是Web層負(fù)載均衡。根據(jù)實(shí)現(xiàn)的原理不同，常見(jiàn)的web負(fù)載均衡技術(shù)包括：DNS輪詢(xún)、IP負(fù)載均衡、CDN、反向代理以及http重定向等等。其中IP負(fù)載均衡可以使用硬件設(shè)備或軟件方式來(lái)實(shí)現(xiàn)。

對(duì)于數(shù)據(jù)層負(fù)載均衡，我們常用的分布式架構(gòu)、多節(jié)點(diǎn)集群、消息中間件（如Mycat）等來(lái)控制集群負(fù)載均衡狀況，同樣是橫向擴(kuò)展，但側(cè)重點(diǎn)在于對(duì)集群的管理和災(zāi)備（高可用）方面。因此，實(shí)際大多負(fù)載均衡的工作還是在Web層。

高性能集群：將單個(gè)重負(fù)載的請(qǐng)求分散到多個(gè)節(jié)點(diǎn)進(jìn)行處理，最后再將處理結(jié)果進(jìn)行匯總;
高可用集群：提高冗余單元，避免單點(diǎn)故障;
負(fù)載均衡集群：將大量的并發(fā)請(qǐng)求分擔(dān)到多個(gè)處理節(jié)點(diǎn)。由于單個(gè)處理節(jié)點(diǎn)的故障不影響整個(gè)服務(wù)，負(fù)載均衡集群同時(shí)也實(shí)現(xiàn)了高可用性。

Web層負(fù)載均衡

任何的負(fù)載均衡技術(shù)都要想辦法建立某種一對(duì)多的映射機(jī)制：一個(gè)請(qǐng)求的入口映射到多個(gè)處理請(qǐng)求的節(jié)點(diǎn)，從而實(shí)現(xiàn)分而治之（Divide and Conquer）。

1、【協(xié)議層】http重定向

當(dāng)http代理（比如瀏覽器）向web服務(wù)器請(qǐng)求某個(gè)URL后，web服務(wù)器可以通過(guò)http響應(yīng)頭信息中的Location標(biāo)記來(lái)返回一個(gè)新的URL。這意味著HTTP代理需要繼續(xù)請(qǐng)求這個(gè)新的URL，完成自動(dòng)跳轉(zhuǎn)。

這種負(fù)載均衡方案的有點(diǎn)是比較簡(jiǎn)單，缺點(diǎn)是瀏覽器需要兩次請(qǐng)求服務(wù)器才能完成一次訪問(wèn)，性能較差；同時(shí)，重定向服務(wù)器本身的處理能力有可能成為瓶頸，整個(gè)集群的伸縮性規(guī)模有限；使用HTTP返回碼302重定向，有可能使搜索引擎判斷為SEO作弊，降低搜索排名。因此實(shí)踐中很少使用這種負(fù)載均衡方案來(lái)部署。

2、【協(xié)議層】DNS輪詢(xún)

DNS負(fù)責(zé)提供域名解析服務(wù)，當(dāng)訪問(wèn)某個(gè)站點(diǎn)時(shí)，實(shí)際上首先需要通過(guò)該站點(diǎn)域名的DNS服務(wù)器來(lái)獲取域名指向的IP地址，在這一過(guò)程中，DNS服務(wù)器完成了域名到IP地址的映射，同樣，這樣映射也可以是一對(duì)多的，這時(shí)候，DNS服務(wù)器便充當(dāng)了負(fù)載均衡調(diào)度器，它就像http重定向轉(zhuǎn)換策略一樣，將用戶(hù)的請(qǐng)求分散到多臺(tái)服務(wù)器上，但是它倆的實(shí)現(xiàn)機(jī)制完全不同。

相比http重定向，基于DNS的負(fù)載均衡完全節(jié)省了所謂的主站點(diǎn)，或者說(shuō)DNS服務(wù)器已經(jīng)充當(dāng)了主站點(diǎn)的職能。但不同的是，作為調(diào)度器，DNS服務(wù)器本身的性能幾乎不用擔(dān)心。因?yàn)镈NS記錄可以被用戶(hù)瀏覽器或者互聯(lián)網(wǎng)接入服務(wù)商的各級(jí)DNS服務(wù)器緩存，只有當(dāng)緩存過(guò)期后才會(huì)重新向域名的DNS服務(wù)器請(qǐng)求解析。也說(shuō)是DNS不存在http的吞吐率限制，理論上可以無(wú)限增加實(shí)際服務(wù)器的數(shù)量。

優(yōu)勢(shì):

1.可以根據(jù)用戶(hù)IP來(lái)進(jìn)行智能解析。DNS服務(wù)器可以在所有可用的A記錄中尋找離用記最近的一臺(tái)服務(wù)器。

2.動(dòng)態(tài)DNS：在每次IP地址變更時(shí)，及時(shí)更新DNS服務(wù)器。當(dāng)然，因?yàn)榫彺?，一定的延遲不可避免。

不足：

1.沒(méi)有用戶(hù)能直接看到DNS解析到了哪一臺(tái)實(shí)際服務(wù)器，對(duì)運(yùn)維人員的調(diào)試帶來(lái)了不便。

2.策略的局限性。例如你無(wú)法將HTTP請(qǐng)求的上下文引入到調(diào)度策略中，而在前面介紹的基于HTTP重定向的負(fù)載均衡系統(tǒng)中，調(diào)度器工作在HTTP層面，它可以充分理解HTTP請(qǐng)求后根據(jù)站點(diǎn)的應(yīng)用邏輯來(lái)設(shè)計(jì)調(diào)度策略，比如根據(jù)請(qǐng)求不同的URL來(lái)進(jìn)行合理的過(guò)濾和轉(zhuǎn)移。

3、【協(xié)議層】CDN

CDN（Content Delivery Network，內(nèi)容分發(fā)網(wǎng)絡(luò)）。通過(guò)發(fā)布機(jī)制將內(nèi)容同步到大量的緩存節(jié)點(diǎn)，并在DNS服務(wù)器上進(jìn)行擴(kuò)展，找到里用戶(hù)最近的緩存節(jié)點(diǎn)作為服務(wù)提供節(jié)點(diǎn)。

因?yàn)楹茈y自建大量的緩存節(jié)點(diǎn)，所以通常使用CDN運(yùn)營(yíng)商的服務(wù)。目前國(guó)內(nèi)的服務(wù)商很少，而且按流量計(jì)費(fèi)，價(jià)格昂貴。

4、【協(xié)議層】反向代理負(fù)載均衡

在客戶(hù)端明確的前提下，大量訪問(wèn)請(qǐng)求（QPS）涌入。我們后臺(tái)通過(guò)Nginx代理了20個(gè)服務(wù)器，高QPS打進(jìn)來(lái)后先打到Nginx中，通過(guò)Nginx的負(fù)載均衡來(lái)把請(qǐng)求分發(fā)給這20臺(tái)服務(wù)器，減輕了單臺(tái)服務(wù)器負(fù)擔(dān)。這種客戶(hù)端 → Nginx → 服務(wù)器 的模式稱(chēng)為反向代理，如下圖：

N個(gè)客戶(hù)端給服務(wù)器發(fā)送的請(qǐng)求，Nginx服務(wù)器接收到之后，按照一定的規(guī)則均衡分發(fā)給了后端的業(yè)務(wù)處理服務(wù)器進(jìn)行處理了。此時(shí)，請(qǐng)求的客戶(hù)端是明確的，但是請(qǐng)求具體由哪臺(tái)服務(wù)器處理的并不明確了，Nginx扮演的就是一個(gè)反向代理角色。

1.客戶(hù)端是無(wú)感知代理的存在的，反向代理對(duì)外都是透明的，訪問(wèn)者并不知道自己訪問(wèn)的是一個(gè)代理。因?yàn)榭蛻?hù)端不需要任何配置就可以訪問(wèn)。

2.反向代理，它代理的是服務(wù)端，代服務(wù)端接收請(qǐng)求，主要用于服務(wù)器集群分布式部署的情況下，反向代理隱藏了服務(wù)器的信息。

反向代理的作用：

（1）保證內(nèi)網(wǎng)的安全，通常將反向代理服務(wù)器配置為公網(wǎng)訪問(wèn)地址，代理的Web服務(wù)器是內(nèi)網(wǎng)IP。

（2）負(fù)載均衡，通過(guò)反向代理服務(wù)器來(lái)優(yōu)化每個(gè)單機(jī)服務(wù)實(shí)例的負(fù)載。

5、【網(wǎng)絡(luò)層】IP負(fù)載均衡

1.客戶(hù)端會(huì)向一個(gè)ip地址發(fā)出請(qǐng)求，這個(gè)ip地址是一個(gè)VIP(虛擬IP)，這也是調(diào)度器向外公布的一個(gè)地址。

2.請(qǐng)求達(dá)到調(diào)度器，調(diào)度器會(huì)根據(jù)負(fù)載均衡算法從RealServer列表中選取一個(gè)負(fù)載不高的服務(wù)器，然后把請(qǐng)求報(bào)文的目標(biāo)地址，也就是VIP和端口通過(guò)iptables進(jìn)行NAT轉(zhuǎn)換成選中的服務(wù)器的真實(shí)ip地址。最后，調(diào)度器會(huì)把其連接保存在一個(gè)hash表中，只要這個(gè)連接下次再發(fā)請(qǐng)求報(bào)文過(guò)來(lái)就會(huì)把其分發(fā)到上次選定的服務(wù)器中。

3.RealServer收到報(bào)文之后，會(huì)把響應(yīng)返回給調(diào)度器。

4.調(diào)度器收到報(bào)文之后，會(huì)把源地址和源端口改為虛擬ip和端口，最后再返回給客戶(hù)端。

特點(diǎn)

• RealServer和調(diào)度器必須位于一個(gè)ip網(wǎng)絡(luò)之中。
• 調(diào)度器位于RealServer和客戶(hù)端之間，處理進(jìn)出的通信。
• RIP通常是內(nèi)部地址，僅用于集群之間通信。
• RealServer的網(wǎng)關(guān)必須指向調(diào)度器。
• 支持端口映射，RealServer沒(méi)必要跟調(diào)度器一個(gè)端口。

限制

響應(yīng)報(bào)文一般比較大，每一次都需要NAT轉(zhuǎn)換的話(huà)，大流量的時(shí)候，會(huì)導(dǎo)致調(diào)度器成為一個(gè)瓶頸。

面試題3：你平時(shí)是怎樣定位線上問(wèn)題的？

本題回答摘自朱曄的《Java業(yè)務(wù)開(kāi)發(fā)常見(jiàn)錯(cuò)誤100例》

定位問(wèn)題，首先要定位問(wèn)題出在哪個(gè)層次上。比如，是 Java 應(yīng)用程序自身的問(wèn)題還是外部因素導(dǎo)致的問(wèn)題。我們可以先查看程序是否有異常，異常信息一般比較具體，可以馬上定位到大概的問(wèn)題方向；如果是一些資源消耗型的問(wèn)題可能不會(huì)有異常，我們可以通過(guò)指標(biāo)監(jiān)控配合顯性問(wèn)題點(diǎn)來(lái)定位。

一般情況下，程序的問(wèn)題來(lái)自以下三個(gè)方面。

第一，程序發(fā)布后的 Bug，回滾后可以立即解決。這類(lèi)問(wèn)題的排查，可以回滾后再慢慢分析版本差異。

第二，外部因素，比如主機(jī)、中間件或數(shù)據(jù)庫(kù)的問(wèn)題。這類(lèi)問(wèn)題的排查方式，按照主機(jī)層面的問(wèn)題、中間件或存儲(chǔ)（統(tǒng)稱(chēng)組件）的問(wèn)題分為兩類(lèi)。

主機(jī)層面的問(wèn)題，可以使用工具排查：

• CPU 相關(guān)問(wèn)題：可以使用 top、vmstat、pidstat、ps 等工具排查；
• 內(nèi)存相關(guān)問(wèn)題：可以使用 free、top、ps、vmstat、cachestat、sar 等工具排查；
• IO 相關(guān)問(wèn)題：可以使用 lsof、iostat、pidstat、sar、iotop、df、du 等工具排查；
• 網(wǎng)絡(luò)相關(guān)問(wèn)題：可以使用 ifconfig、ip、nslookup、dig、ping、tcpdump、iptables 等工具排查。

組件的問(wèn)題，可以從以下幾個(gè)方面排查：

• 排查組件所在主機(jī)是否有問(wèn)題；
• 排查組件進(jìn)程基本情況，觀察各種監(jiān)控指標(biāo)；
• 查看組件的日志輸出，特別是錯(cuò)誤日志；
• 進(jìn)入組件控制臺(tái)，使用一些命令查看其運(yùn)作情況。

第三，因?yàn)橄到y(tǒng)資源不夠造成系統(tǒng)假死的問(wèn)題，通常需要先通過(guò)重啟和擴(kuò)容解決問(wèn)題，之后再進(jìn)行分析，不過(guò)最好能留一個(gè)節(jié)點(diǎn)作為現(xiàn)場(chǎng)。系統(tǒng)資源不夠，一般體現(xiàn)在 CPU 使用高、內(nèi)存泄漏或 OOM 的問(wèn)題、IO 問(wèn)題、網(wǎng)絡(luò)相關(guān)問(wèn)題這四個(gè)方面。

對(duì)于 CPU 使用高的問(wèn)題，如果現(xiàn)場(chǎng)還在，具體的分析流程是：

• 首先，在 Linux 服務(wù)器上運(yùn)行top -Hp pid命令，來(lái)查看進(jìn)程中哪個(gè)線程 CPU 使用高；
• 然后，輸入大寫(xiě)的 P 將線程按照 CPU 使用率排序，并把明顯占用 CPU 的線程 ID 轉(zhuǎn)換為 16 進(jìn)制；
• 最后，在 jstack 命令輸出的線程棧中搜索這個(gè)線程 ID，定位出問(wèn)題的線程當(dāng)時(shí)的調(diào)用棧。

如果沒(méi)有條件直接在服務(wù)器上運(yùn)行 top 命令的話(huà)，我們可以用采樣的方式定位問(wèn)題：間隔固定秒數(shù)（比如 10 秒）運(yùn)行一次 jstack 命令，采樣幾次后，對(duì)比采樣得出哪些線程始終處于運(yùn)行狀態(tài)，分析出問(wèn)題的線程。

如果現(xiàn)場(chǎng)沒(méi)有了，我們可以通過(guò)排除法來(lái)分析。CPU 使用高，一般是由下面的因素引起的：

• 突發(fā)壓力。這類(lèi)問(wèn)題，我們可以通過(guò)應(yīng)用之前的負(fù)載均衡的流量或日志量來(lái)確認(rèn)，諸如 Nginx 等反向代理都會(huì)記錄 URL，可以依靠代理的 Access Log 進(jìn)行細(xì)化定位，也可以通過(guò)監(jiān)控觀察 JVM 線程數(shù)的情況。壓力問(wèn)題導(dǎo)致 CPU 使用高的情況下，如果程序的各資源使用沒(méi)有明顯不正常，之后可以通過(guò)壓測(cè) +Profiler（jvisualvm 就有這個(gè)功能）進(jìn)一步定位熱點(diǎn)方法；如果資源使用不正常，比如產(chǎn)生了幾千個(gè)線程，就需要考慮調(diào)參。
• GC。這種情況，我們可以通過(guò) JVM 監(jiān)控 GC 相關(guān)指標(biāo)、GC Log 進(jìn)行確認(rèn)。如果確認(rèn)是 GC 的壓力，那么內(nèi)存使用也很可能會(huì)不正常，需要按照內(nèi)存問(wèn)題分析流程做進(jìn)一步分析。
• 程序中死循環(huán)邏輯或不正常的處理流程。這類(lèi)問(wèn)題，我們可以結(jié)合應(yīng)用日志分析。一般情況下，應(yīng)用執(zhí)行過(guò)程中都會(huì)產(chǎn)生一些日志，可以重點(diǎn)關(guān)注日志量異常部分。

對(duì)于內(nèi)存泄露或 OOM 的問(wèn)題，最簡(jiǎn)單的分析方式，就是堆轉(zhuǎn)儲(chǔ)后使用MAT分析。堆轉(zhuǎn)儲(chǔ)，包含了堆現(xiàn)場(chǎng)全貌和線程棧信息，一般觀察支配樹(shù)圖、直方圖就可以馬上看到占用大量?jī)?nèi)存的對(duì)象，可以快速定位到內(nèi)存相關(guān)問(wèn)題。

需要注意的是，Java 進(jìn)程對(duì)內(nèi)存的使用不僅僅是堆區(qū)，還包括線程使用的內(nèi)存（線程個(gè)數(shù) * 每一個(gè)線程的線程棧）和元數(shù)據(jù)區(qū)。每一個(gè)內(nèi)存區(qū)都可能產(chǎn)生 OOM，可以結(jié)合監(jiān)控觀察線程數(shù)、已加載類(lèi)數(shù)量等指標(biāo)分析。另外，我們需要注意看一下，JVM 參數(shù)的設(shè)置是否有明顯不合理的地方，限制了資源使用。

問(wèn)題來(lái)了，JVM 哪塊內(nèi)存區(qū)域不會(huì)發(fā)生內(nèi)存溢出？

程序計(jì)數(shù)器：程序計(jì)數(shù)器是一塊內(nèi)存較小的區(qū)域，它用于存儲(chǔ)線程的每個(gè)執(zhí)行指令，每個(gè)線程都有自己的程序計(jì)數(shù)器，此區(qū)域不會(huì)有內(nèi)存溢出的情況。

IO 相關(guān)的問(wèn)題，除非是代碼問(wèn)題引起的資源不釋放等問(wèn)題，否則通常都不是由 Java 進(jìn)程內(nèi)部因素引發(fā)的。網(wǎng)絡(luò)相關(guān)的問(wèn)題，一般也是由外部因素引起的。

對(duì)于連通性問(wèn)題，結(jié)合異常信息通常比較容易定位；對(duì)于性能或瞬斷問(wèn)題，可以先嘗試使用 ping 等工具簡(jiǎn)單判斷，如果不行再使用 tcpdump 或 Wireshark 來(lái)分析。

總結(jié)

本篇文章就到這里了，希望能給你帶來(lái)幫助，也希望您能夠多多關(guān)注腳本之家的更多內(nèi)容！