為你總結了 N 個真實線上故障，從容應對面試官！
很多人在面試時，會被問到這樣的問題：遇到過什麼系統故障？怎麼解決的？下面是筆者根據自己15年網際網路研發經歷總結的多個線上故障真實案例。相信可以幫你從容應對面試官的提問！
本文圖不多，但內容很乾！理解為主，面試為輔，學以致用！
故障一：JVM頻繁FULL GC快速排查
在分享此案例前，先聊聊哪些場景會導致頻繁Full GC：
-
記憶體洩漏（程式碼有問題，物件引用沒及時釋放，導致物件不能及時回收）
-
死迴圈
-
大物件
尤其是大物件，80%以上的情況就是他。
那麼大物件從哪裡來的呢？
-
資料庫（包括Mysql和Mongodb等NOSql資料庫），結果集太大
-
第三方介面傳輸的大物件
-
訊息佇列，訊息太大
根據多年一線網際網路經驗，絕大部分情況是資料庫大結果集導致。
好，現在我們開始介紹這次線上故障：
在沒有任何釋出的情況下，POP服務（接入第三方商家的服務）突然開始瘋狂Full GC，觀察堆記憶體監控沒記憶體洩漏，回滾到前一版本，問題仍然存在，尷尬了！！！
按照常規做法，一般先用jmap匯出堆記憶體快照（jmap -dump:format=b,file=檔名 [pid]），然後用mat等工具分析出什麼物件佔用了大量空間，再檢視相關引用找到問題程式碼。這種方式定位問題週期會比較長，如果是關鍵服務，長時間不能定位解決問題，影響太大。
下面來看看我們的做法。先按照常規做法分析堆記憶體快照，與此同時另外的同學去檢視資料庫伺服器網路IO監控，如果資料庫伺服器網路IO有明顯上升，並且時間點吻合，基本可以確定是資料庫大結果集導致了Full GC，趕緊找DBA快速定位大SQL（對DBA來說很簡單，分分鐘搞定，如果DBA不知道怎麼定位，那他要被開除了，哈哈），定位到SQL後再定位程式碼就非常簡單了。按照這種辦法，我們很快定位了問題。原來是一個介面必傳的引數沒傳進來，也沒加校驗，導致SQL語句where後面少了兩個條件，一次查幾萬條記錄出來，真坑啊！這種方法是不是要快很多，哈哈，5分鐘搞定。
當時的DAO層是基於Mybatis實現的，出問題的SQL語句如下：
<select id="selectOrders" resultType="com.***.Order" >
select * from user where 1=1
<if test=" orderID != null ">
and order_id = #{orderID}
</if >
<if test="userID !=null">
and user_id=#{userID}
</if >
<if test="startTime !=null">
and create_time >= #{createTime}
</if >
<if test="endTime !=null">
and create_time <= #{userID}
</if >
</select>上面SQL語句意思是根據orderID查一個訂單，或者根據userID查一個使用者所有的訂單，兩個引數至少要傳一個。但是兩個引數都沒傳，只傳了startTime和endTime。所以一次Select就查出了幾萬條記錄。
所以我們在使用Mybatis的時候一定要慎用if test，一不小心就會帶來災難。後來我們將上面的SQL拆成了兩個：
根據訂單ID查詢訂單：
<select id="selectOrderByID" resultType="com.***.Order" >
select * from user where
order_id = #{orderID}
</select>
根據userID查詢訂單：
<select id="selectOrdersByUserID" resultType="com.***.Order" >
select * from user where
user_id=#{userID}
<if test="startTime !=null">
and create_time >= #{createTime}
</if >
<if test="endTime !=null">
and create_time <= #{userID}
</if >
</select>
故障二：記憶體洩漏
介紹案例前，先了解一下記憶體洩漏和記憶體溢位的區別。
記憶體溢位：程式沒有足夠的記憶體使用時，就會發生記憶體溢位。記憶體溢位後程序基本上就無法正常運行了。
記憶體洩漏：當程式不能及時釋放記憶體，導致佔用記憶體逐漸增加，就是記憶體洩漏。記憶體洩漏一般不會導致程式無法執行。不過持續的記憶體洩漏，累積到記憶體上限時，就會發生記憶體溢位。在Java中，如果發生記憶體洩漏，會導致GC回收不徹底，每次GC後，堆記憶體使用率逐漸增高。下圖是JVM發生記憶體洩漏的監控圖，我們可以看到每次GC後堆記憶體使用率都比以前提高了。
當時記憶體洩漏的場景是，用本地快取（公司基礎架構組自己研發的框架）存放了商品資料，商品數量不算太多，幾十萬的樣子。如果只存熱點商品，記憶體佔用不會太大，但是如果存放全量商品，記憶體就不夠了。初期我們給每個快取記錄都加了7天的過期時間，這樣就可以保證快取中絕大部分都是熱點商品。不過後來本地快取框架經過一次重構，過期時間被去掉了。沒有了過期時間，日積月累本地快取越來越大，很多冷資料也被載入到了快取。直到有一天接到告警簡訊，提示堆記憶體過高。趕緊通過jmap（jmap -dump:format=b,file=檔名 [pid] ）下載了堆記憶體快照，然後用eclipse的mat工具分析快照，發現了本地快取中有大量的商品記錄。定位問題後趕緊讓架構組加上了過期時間，然後逐個節點重啟了服務。
虧了我們加了伺服器記憶體和JVM堆記憶體監控，及時發現了記憶體洩漏的問題。否則隨著洩漏問題日積月累，如果哪天真的OOM就慘了。所以技術團隊除了做好CPU，記憶體等運維監控，JVM監控也非常重要。
故障三：冪等問題
很多年前，筆者在一家大型電商公司做Java程式設計師，當時開發了積分服務。當時的業務邏輯是，使用者訂單完結後，訂單系統傳送訊息到訊息佇列，積分服務接到訊息後給使用者積分，在使用者現有的積分上加上新產生的積分。
由於網路等原因會有訊息重複傳送的情況，這樣也就導致了訊息的重複消費。當時筆者還是個初入職場的小菜鳥，並沒有考慮到這種情況。所以上線後偶爾會出現重複積分的情況，也就是一個訂單完結後會給使用者加兩次或多次積分。
後來我們加了一個積分記錄表，每次消費訊息給使用者增加積分前，先根據訂單號查一遍積分記錄表，如果沒有積分記錄才給使用者增加積分。這也就是所謂的“冪等性”，即多次重複操作不影響最終的結果。實際開發中很多需要重試或重複消費的場景都要實現冪等，以保證結果的正確性。例如，為了避免重複支付，支付介面也要實現冪等。
故障四：快取雪崩
我們經常會遇到需要初始化快取的情況。比如，我們曾經經歷過使用者系統重構，使用者系統表結構發生了變化，快取資訊也要變。重構完成後上線前，需要初始化快取，將使用者資訊批量存入Reids。每條使用者資訊快取記錄過期時間是1天，記錄過期後再從資料庫查詢最新的資料並拉取到Redis中。灰度上線時一切正常，所以很快就全量釋出了。整個上線過程非常順利，碼農們也很開心。
不過，第二天，災難發生了！到某一個時間點，各種報警紛至沓來。使用者系統響應突然變得非常慢，甚至一度沒有任何響應。檢視監控，使用者服務CPU突然飆高（IO wait很高），Mysql訪問量激增，Mysql伺服器壓力也隨之暴增，Reids快取命中率也跌到了極點。依賴於我們強大的監控系統（運維監控，資料庫監控，APM全鏈路效能監控），很快定位了問題。原因就是Reids中大量使用者記錄集中失效，獲取使用者資訊的請求在Redis中查不到使用者記錄，導致大量的請求穿透到資料庫，瞬間給資料庫帶來巨大壓力。同時使用者服務和相關聯的其他服務也都受到了影響。
這種快取集中失效，導致大量請求同時穿透到資料庫的情況，就是所謂的“快取雪崩”。如果沒到快取失效時間點，效能測試也測不出問題。所以一定要引起大家注意。
所以，需要初始化快取資料時，一定要保證每個快取記錄過期時間的離散性。例如，我們給這些使用者資訊設定過期時間，可以採用一個較大的固定值加上一個較小的隨機值。比如過期時間可以是：24小時 + 0到3600秒的隨機值。
故障五：磁碟IO導致執行緒阻塞
問題發生在2017年下半年，有一段時間地理網格服務時不常的會響應變慢，每次持續幾秒鐘到幾十秒鐘就自動恢復。
如果響應變慢是持續的還好辦，直接用jstack抓執行緒堆疊，基本可以很快定位問題。關鍵持續時間只有最多幾十秒鐘，而且是偶發的，一天只發生一兩次，有時幾天才發生一次，發生時間點也不確定，人盯著然後用jstack手工抓執行緒堆疊顯然不現實。
好吧，既然手工的辦法不現實，咱們就來自動的，寫一個shell指令碼自動定時執行jstack，5秒執行一次jstack，每次執行結果放到不同日誌檔案中，只儲存20000個日誌檔案。
Shell指令碼如下：
#!/bin/bash
num=0
log="/tmp/jstack_thread_log/thread_info"
cd /tmp
if [ ! -d "jstack_thread_log" ]; then
mkdir jstack_thread_log
fi
while ((num <= 10000));
do
ID=`ps -ef | grep java | grep gaea | grep -v "grep" | awk '{print $2}'`
if [ -n "$ID" ]; then
jstack $ID >> ${log}
fi
num=$(( $num + 1 ))
mod=$(( $num%100 ))
if [ $mod -eq 0 ]; then
back=$log$num
mv $log $back
fi
sleep 5
done
下一次響應變慢的時候，我們找到對應時間點的jstack日誌檔案，發現裡面有很多執行緒阻塞在logback輸出日誌的過程，後來我們精簡了log，並且把log輸出改成非同步，問題解決了，這個指令碼果真好用！建議大家保留，以後遇到類似問題時，可以拿來用！
故障六：資料庫死鎖問題
在分析案例之前，我們先了解一下MySQL INNODB。在MySQL INNODB引擎中主鍵是採用聚簇索引的形式，即在B樹的葉子節點中既儲存了索引值也儲存了資料記錄，即資料記錄和主鍵索引是存在一起的。而普通索引的葉子節點儲存的只是主鍵索引的值，一次查詢找到普通索引的葉子節點後，還要根據葉子節點中的主鍵索引去找到聚簇索引葉子節點並拿到其中的具體資料記錄，這個過程也叫“回表”。
故障發生的場景是關於我們商城的訂單系統。有一個定時任務，每一小時跑一次，每次把所有一小時前未支付訂單取消掉。而客服後臺也可以批量取消訂單。
訂單表t_order結構大至如下：
id訂單id，主鍵status訂單狀態created_time訂單建立時間
id是表的主鍵，created_time欄位上是普通索引。
聚簇索引（主鍵id）
id（索引）statuscreated_time1UNPAID2020-01-01 07:30:002UNPAID2020-01-01 08:33:003UNPAID2020-01-01 09:30:004UNPAID2020-01-01 09:39:005UNPAID2020-01-01 09:50:00
普通索引（created_time欄位）
created_time（索引）id（主鍵）2020-01-01 09:50:0052020-01-01 09:39:0042020-01-01 09:30:0032020-01-01 08:33:0022020-01-01 07:30:001
定時任務每一小時跑一次，每次把所有一小時前兩小時內的未支付訂單取消掉，比如上午11點會取消8點到10點的未支付訂單。SQL語句如下：
update t_order set status = 'CANCELLED' where created_time > '2020-01-01 08:00:00' and created_time < '2020-01-01 10:00:00' and status = 'UNPAID' 複製程式碼客服批量取消訂單SQL如下：
update t_order set status = 'CANCELLED' where id in (2, 3, 5) and status = 'UNPAID'上面的兩條語句同時執行就可能發生死鎖。我們來分析一下原因。
第一條定時任務的SQL，會先找到created_time普通索引並加鎖，然後再在找到主鍵索引並加鎖。
第一步，created_time普通索引加鎖
第二步，主鍵索引加鎖
第二條客服批量取消訂單SQL，直接走主鍵索引，直接在主鍵索引上加鎖。
我們可以看到，定時任務SQL對主鍵加鎖順序是5,4,3,2。客服批量取消訂單SQL對主鍵加鎖順序是2，3，5。當第一個SQL對3加鎖後，正準備對2加鎖時，發現2已經被第二個SQL加鎖了，所以第一個SQL要等待2的鎖釋放。而此時第二個SQL準備對3加鎖，卻發現3已經被第一個SQL加鎖了，就要等待3的鎖釋放。兩個SQL互相等待對方的鎖，也就發生了“死鎖”。
解決辦法就是從SQL語句上保證加鎖順序一致。或者把客服批量取消訂單SQL改成每次SQL操作只能取消一個訂單，然後在程式裡多次迴圈執行SQL，如果批量操作的訂單數量不多，這種笨辦法也是可行的。
故障七：域名劫持
先看看DNS解析是怎麼回事，當我們訪問www.baidu.com時，首先會根據www.baidu.com到DNS域名解析伺服器去查詢百度伺服器對應的IP地址，然後再通過http協議訪問該IP地址對應的網站。而DNS劫持是網際網路攻擊的一種方式，通過攻擊域名解析伺服器（DNS）或者偽造域名解析伺服器，把目標網站域名解析到其他的IP。從而導致請求無法訪問目標網站或者跳轉到其他網站。如下圖：
下面這張圖是我們曾經經歷過的DNS劫持的案例。
看圖中的紅框部分，本來上方的圖片應該是商品圖片，但是卻顯示成了廣告圖片。是不是圖片配錯了？不是，是域名（DNS）被劫持了。原本應該顯示儲存在CDN上的商品圖片，但是被劫持之後卻顯示了其他網站的廣告連結圖片。由於當時的CDN圖片連結採用了不安全的http協議，所以很容易被劫持。後來改成了https，問題就解決了。
當然域名劫持有很多方式，https也不能規避所有問題。所以，除了一些安全防護措施，很多公司都有自己的備用域名，一旦發生域名劫持可以隨時切換到備用域名。
故障八：頻寬資源耗盡
頻寬資源耗盡導致系統無法訪問的情況，雖然不多見，但是也應該引起大家的注意。來看看，之前遇到的一起事故。
場景是這樣的。社交電商每個分享出去的商品圖片都有一個唯一的二維碼，用來區分商品和分享者。所以二維碼要用程式生成，最初我們在服務端用Java生成二維碼。前期由於系統訪問量不大，系統一直沒什麼問題。但是有一天運營突然搞了一次優惠力度空前的大促，系統瞬時訪問量翻了幾十倍。問題也就隨之而來了，網路頻寬直接被打滿，由於頻寬資源被耗盡，導致很多頁面請求響應很慢甚至沒任何響應。原因就是二維碼生成數量瞬間也翻了幾十倍，每個二維碼都是一張圖片，對頻寬帶來了巨大壓力。
怎麼解決呢？如果服務端處理不了，就考慮一下客戶端。把生成二維碼放到客戶端APP處理，充分利用使用者終端手機，目前Andriod，IOS或者React都有相關生成二維碼的SDK。這樣不但解決了頻寬問題，而且也釋放了服務端生成二維碼時消耗的CPU資源（生成二維碼過程需要一定的計算量，CPU消耗比較明顯）。
外網頻寬非常昂貴，我們還是要省著點用啊！
看完三件事❤️
如果你覺得這篇內容對你還蠻有幫助，我想邀請你幫我三個小忙：
-
點贊，轉發，有你們的 『點贊和評論』，才是我創造的動力。
-
關注公眾號 『 java爛豬皮 』，不定期分享原創知識。
-
同時可以期待後續文章ing