一次I/O問題引發(fā)的P0重大故障

幾年前的一個下午，公司里碼農(nóng)們正在安靜地敲著代碼，突然很多人的手機同時“嗶嗶”地響了起來。本來以為發(fā)工資了，都挺高興！打開一看，原來是告警短信

故障回顧

告警提示“線程數(shù)過多，超出閾值”，“CPU空閑率太低”。打開監(jiān)控系統(tǒng)一看，訂單服務(wù)所有20個服務(wù)節(jié)點都不行了，服務(wù)沒響應(yīng)。

到聽云（一個全鏈路性能監(jiān)控工具）上看監(jiān)控，每個springboot節(jié)點線程數(shù)全都達到了最大值。但是JVM堆內(nèi)存和GC沒有明顯異常。CPU 空閑率基本都是0%，但是CPU使用率并不高，反而IO等待卻非常高。下面是執(zhí)行top命令查看CPU狀況的截圖：

從上圖，我們可以看到:

CPU空閑率是0%（上圖中紅框id）

CPU使用率是22%（上圖中紅框 us 13% 加上 sy 9%，us可以理解成用戶進程占用的CPU，sy可以理解成系統(tǒng)進程占用的CPU）

CPU 在等待磁盤IO操作上花費的時間占比是76.6% （上圖中紅框 wa）

到現(xiàn)在可以確定，問題肯定發(fā)生在IO等待上。利用監(jiān)控系統(tǒng)和jstack命令，最終定位問題發(fā)生在文件寫入上。大量的磁盤讀寫導(dǎo)致了系統(tǒng)線程資源耗盡。最終導(dǎo)致訂單服務(wù)無法響應(yīng)上游服務(wù)的請求。

具體原因：當時剛好趕上一次促銷活動，我們當時的日志框架采用的log4j，大家知道log4j有性能瓶頸，高并發(fā)時I/O等待很明顯，再加上當時采用同步記錄日志的方式，這就導(dǎo)致了大量線程阻塞，最終導(dǎo)致線程池線程資源全部耗盡。當時的解決辦法就是日志框架改成更高效的logback，再把記錄日志改成異步的方式，問題解決。

I/O，你不知道的那些事兒

既然I/O對系統(tǒng)性能和穩(wěn)定性影響這么大，我們就來深入探究一下。

所謂的I/O（Input/Output）操作實際上就是輸入輸出的數(shù)據(jù)傳輸行為。程序員最關(guān)注的主要是磁盤IO和網(wǎng)絡(luò)IO，因為這兩個IO操作和應(yīng)用程序的關(guān)系最直接最緊密。

磁盤IO：磁盤的輸入輸出，比如磁盤和內(nèi)存之間的數(shù)據(jù)傳輸。

網(wǎng)絡(luò)IO：不同系統(tǒng)間跨網(wǎng)絡(luò)的數(shù)據(jù)傳輸，比如兩個系統(tǒng)間的遠程接口調(diào)用。

下面這張圖展示了應(yīng)用程序中發(fā)生IO的具體場景：

通過上圖，我們可以了解到IO操作發(fā)生的具體場景。一個請求過程可能會發(fā)生很多次的IO操作：

1，頁面請求到服務(wù)器會發(fā)生網(wǎng)絡(luò)IO

2，服務(wù)之間遠程調(diào)用會發(fā)生網(wǎng)絡(luò)IO

3，應(yīng)用程序訪問數(shù)據(jù)庫會發(fā)生網(wǎng)絡(luò)IO

4，數(shù)據(jù)庫查詢或者寫入數(shù)據(jù)會發(fā)生磁盤IO

IO和CPU的關(guān)系

不少攻城獅會這樣理解，如果CPU空閑率是0%，就代表CPU已經(jīng)在滿負荷工作，沒精力再處理其他任務(wù)了。真是這樣的嗎？

我們先看一下計算機是怎么管理磁盤IO操作的。計算機發(fā)展早期，磁盤和內(nèi)存的數(shù)據(jù)傳輸是由CPU控制的，也就是說從磁盤讀取數(shù)據(jù)到內(nèi)存中，是需要CPU存儲和轉(zhuǎn)發(fā)的，期間CPU一直會被占用。我們知道磁盤的讀寫速度遠遠比不上CPU的運轉(zhuǎn)速度。這樣在傳輸數(shù)據(jù)時就會占用大量CPU資源，造成CPU資源嚴重浪費。

后來有人設(shè)計了一個IO控制器，專門控制磁盤IO。當發(fā)生磁盤和內(nèi)存間的數(shù)據(jù)傳輸前，CPU會給IO控制器發(fā)送指令，讓IO控制器負責數(shù)據(jù)傳輸操作，數(shù)據(jù)傳輸完IO控制器再通知CPU。因此，從磁盤讀取數(shù)據(jù)到內(nèi)存的過程就不再需要CPU參與了，CPU可以空出來處理其他事情，大大提高了CPU利用率。這個IO控制器就是“DMA”，即直接內(nèi)存訪問，Direct Memory Access?，F(xiàn)在的計算機基本都采用這種DMA模式進行數(shù)據(jù)傳輸。

通過上面內(nèi)容我們了解到，IO數(shù)據(jù)傳輸時，是不占用CPU的。當應(yīng)用進程或線程發(fā)生IO等待時，CPU會及時釋放相應(yīng)的時間片資源并把時間片分配給其他進程或線程使用，從而使CPU資源得到充分利用。所以，假如CPU大部分消耗在IO等待（wa）上時，即便CPU空閑率（id）是0%，也并不意味著CPU資源完全耗盡了，如果有新的任務(wù)來了，CPU仍然有精力執(zhí)行任務(wù)。如下圖：

在DMA模式下執(zhí)行IO操作是不占用CPU的，所以CPU IO等待（上圖的wa）實際上屬于CPU空閑率的一部分。所以我們執(zhí)行top命令時，除了要關(guān)注CPU空閑率，CPU使用率（us，sy），還要關(guān)注IO Wait（wa）。注意，wa只代表磁盤IO Wait，不包括網(wǎng)絡(luò)IO Wait。

Java中線程狀態(tài)和IO的關(guān)系

當我們用jstack查看Java線程狀態(tài)時，會看到各種線程狀態(tài)。當發(fā)生IO等待時（比如遠程調(diào)用時），線程是什么狀態(tài)呢，Blocked還是Waiting？

答案是Runnable狀態(tài)，是不是有些出乎意料！實際上，在操作系統(tǒng)層面Java的Runnable狀態(tài)除了包括Running狀態(tài)，還包括Ready（就緒狀態(tài)，等待CPU調(diào)度）和IO Wait等狀態(tài)。

如上圖，Runnable狀態(tài)的注解明確說明了，在JVM層面執(zhí)行的線程，在操作系統(tǒng)層面可能在等待其他資源。如果等待的資源是CPU，在操作系統(tǒng)層面線程就是等待被CPU調(diào)度的Ready狀態(tài)；如果等待的資源是磁盤網(wǎng)卡等IO資源，在操作系統(tǒng)層面線程就是等待IO操作完成的IO Wait狀態(tài)。

有人可能會問，為什么Java線程沒有專門的Running狀態(tài)呢？

目前絕大部分主流操作系統(tǒng)都是以時間分片的方式對任務(wù)進行輪詢調(diào)度，時間片通常很短，大概幾十毫秒，也就是說一個線程每次在cpu上只能執(zhí)行幾十毫秒，然后就會被CPU調(diào)度出來變成Ready狀態(tài)，等待再一次被CPU執(zhí)行，線程在Ready和Running兩個狀態(tài)間快速切換。通常情況，JVM線程狀態(tài)主要為了監(jiān)控使用，是給人看的。當你看到線程狀態(tài)是Running的一瞬間，線程狀態(tài)早已經(jīng)切換N次了。所以，再給線程專門加一個Running狀態(tài)也就沒什么意義了。

深入理解網(wǎng)絡(luò)IO模型

5種Linux網(wǎng)絡(luò)IO模型包括：同步阻塞IO、同步非阻塞IO、多路復(fù)用IO、信號驅(qū)動IO和異步IO。

寫在前面

為了更好地理解網(wǎng)絡(luò)IO模型，我們先了解幾個基本概念。

Socket（套接字）：Socket可以理解成，在兩個應(yīng)用程序進行網(wǎng)絡(luò)通信時，分別在兩個應(yīng)用程序中的通信端點。通信時，一個應(yīng)用程序?qū)?shù)據(jù)寫入Socket，然后通過網(wǎng)卡把數(shù)據(jù)發(fā)送到另外一個應(yīng)用程序的Socket中。我們平常所說的HTTP和TCP協(xié)議的遠程通信，底層都是基于Socket實現(xiàn)的。5種網(wǎng)絡(luò)IO模型也都要基于Socket實現(xiàn)網(wǎng)絡(luò)通信。

阻塞與非阻塞：所謂阻塞，就是發(fā)出一個請求不能立刻返回響應(yīng)，要等所有的邏輯全處理完才能返回響應(yīng)。非阻塞反之，發(fā)出一個請求立刻返回應(yīng)答，不用等處理完所有邏輯。

內(nèi)核空間與用戶空間：在Linux中，應(yīng)用程序穩(wěn)定性遠遠比不上操作系統(tǒng)程序，為了保證操作系統(tǒng)的穩(wěn)定性，Linux區(qū)分了內(nèi)核空間和用戶空間?？梢赃@樣理解，內(nèi)核空間運行操作系統(tǒng)程序和驅(qū)動程序，用戶空間運行應(yīng)用程序。Linux以這種方式隔離了操作系統(tǒng)程序和應(yīng)用程序，避免了應(yīng)用程序影響到操作系統(tǒng)自身的穩(wěn)定性。這也是Linux系統(tǒng)超級穩(wěn)定的主要原因。所有的系統(tǒng)資源操作都在內(nèi)核空間進行，比如讀寫磁盤文件，內(nèi)存分配和回收，網(wǎng)絡(luò)接口調(diào)用等。所以在一次網(wǎng)絡(luò)IO讀取過程中，數(shù)據(jù)并不是直接從網(wǎng)卡讀取到用戶空間中的應(yīng)用程序緩沖區(qū)，而是先從網(wǎng)卡拷貝到內(nèi)核空間緩沖區(qū)，然后再從內(nèi)核拷貝到用戶空間中的應(yīng)用程序緩沖區(qū)。對于網(wǎng)絡(luò)IO寫入過程，過程則相反，先將數(shù)據(jù)從用戶空間中的應(yīng)用程序緩沖區(qū)拷貝到內(nèi)核緩沖區(qū)，再從內(nèi)核緩沖區(qū)把數(shù)據(jù)通過網(wǎng)卡發(fā)送出去。

同步阻塞IO

我們先看一下傳統(tǒng)阻塞IO。在Linux中，默認情況下所有socket都是阻塞模式的。當用戶線程調(diào)用系統(tǒng)函數(shù)read()，內(nèi)核開始準備數(shù)據(jù)（從網(wǎng)絡(luò)接收數(shù)據(jù)），內(nèi)核準備數(shù)據(jù)完成后，數(shù)據(jù)從內(nèi)核拷貝到用戶空間的應(yīng)用程序緩沖區(qū)，數(shù)據(jù)拷貝完成后，請求才返回。從發(fā)起read請求到最終完成內(nèi)核到應(yīng)用程序的拷貝，整個過程都是阻塞的。為了提高性能，可以為每個連接都分配一個線程。因此，在大量連接的場景下就需要大量的線程，會造成巨大的性能損耗，這也是傳統(tǒng)阻塞IO的最大缺陷。

同步非阻塞IO

用戶線程在發(fā)起Read請求后立即返回，不用等待內(nèi)核準備數(shù)據(jù)的過程。如果Read請求沒讀取到數(shù)據(jù)，用戶線程會不斷輪詢發(fā)起Read請求，直到數(shù)據(jù)到達（內(nèi)核準備好數(shù)據(jù)）后才停止輪詢。非阻塞IO模型雖然避免了由于線程阻塞問題帶來的大量線程消耗，但是頻繁的重復(fù)輪詢大大增加了請求次數(shù)，對CPU消耗也比較明顯。這種模型在實際應(yīng)用中很少使用。

多路復(fù)用IO模型

多路復(fù)用IO模型，建立在多路事件分離函數(shù)select，poll，epoll之上。在發(fā)起read請求前，先更新select的socket監(jiān)控列表，然后等待select函數(shù)返回（此過程是阻塞的，所以說多路復(fù)用IO也是阻塞IO模型）。當某個socket有數(shù)據(jù)到達時，select函數(shù)返回。此時用戶線程才正式發(fā)起read請求，讀取并處理數(shù)據(jù)。這種模式用一個專門的監(jiān)視線程去檢查多個socket，如果某個socket有數(shù)據(jù)到達就交給工作線程處理。由于等待Socket數(shù)據(jù)到達過程非常耗時，所以這種方式解決了阻塞IO模型一個Socket連接就需要一個線程的問題，也不存在非阻塞IO模型忙輪詢帶來的CPU性能損耗的問題。多路復(fù)用IO模型的實際應(yīng)用場景很多，比如大家耳熟能詳?shù)腏ava NIO，Redis以及Dubbo采用的通信框架Netty都采用了這種模型。

下圖是基于select函數(shù)Socket編程的詳細流程。

信號驅(qū)動IO模型

信號驅(qū)動IO模型，應(yīng)用進程使用sigaction函數(shù)，內(nèi)核會立即返回，也就是說內(nèi)核準備數(shù)據(jù)的階段應(yīng)用進程是非阻塞的。內(nèi)核準備好數(shù)據(jù)后向應(yīng)用進程發(fā)送SIGIO信號，接到信號后數(shù)據(jù)被復(fù)制到應(yīng)用程序進程。

采用這種方式，CPU的利用率很高。不過這種模式下，在大量IO操作的情況下可能造成信號隊列溢出導(dǎo)致信號丟失，造成災(zāi)難性后果。

異步IO模型

異步IO模型的基本機制是，應(yīng)用進程告訴內(nèi)核啟動某個操作，內(nèi)核操作完成后再通知應(yīng)用進程。在多路復(fù)用IO模型中，socket狀態(tài)事件到達，得到通知后，應(yīng)用進程才開始自行讀取并處理數(shù)據(jù)。在異步IO模型中，應(yīng)用進程得到通知時，內(nèi)核已經(jīng)讀取完數(shù)據(jù)并把數(shù)據(jù)放到了應(yīng)用進程的緩沖區(qū)中，此時應(yīng)用進程

直接使用數(shù)據(jù)即可。

很明顯，異步IO模型性能很高。不過到目前為止，異步IO和信號驅(qū)動IO模型應(yīng)用并不多見，傳統(tǒng)阻塞IO和多路復(fù)用IO模型還是目前應(yīng)用的主流。Linux2.6版本后才引入異步IO模型，目前很多系統(tǒng)對異步IO模型支持尚不成熟。很多應(yīng)用場景采用多路復(fù)用IO替代異步IO模型。

如何避免IO問題帶來的系統(tǒng)故障

對于磁盤文件訪問的操作，可以采用線程池方式，并設(shè)置線程上線，從而避免整個JVM線程池污染，進而導(dǎo)致線程和CPU資源耗盡。

對于網(wǎng)絡(luò)間遠程調(diào)用。為了避免服務(wù)間調(diào)用的全鏈路故障，要設(shè)置合理的TImeout值，高并發(fā)場景下可以采用熔斷機制。在同一JVM內(nèi)部采用線程隔離機制，把線程分為若干組，不同的線程組分別服務(wù)于不同的類和方法，避免因為一個小功能點的故障，導(dǎo)致JVM內(nèi)部所有線程受到影響。

此外，完善的運維監(jiān)控（磁盤IO，網(wǎng)絡(luò)IO）和APM（全鏈路性能監(jiān)控）也非常重要，能及時預(yù)警，防患于未然，在故障發(fā)生時也能幫助我們快速定位問題。

就分享到這。原創(chuàng)不易，如果感覺本文對您有幫助，有勞點一下“在看”！

作者簡介：曾任職于阿里巴巴，每日優(yōu)鮮等互聯(lián)網(wǎng)公司，任技術(shù)總監(jiān)，15年電商互聯(lián)網(wǎng)經(jīng)歷。