IO密集型服務(wù)提升性能的三種方式

大部分的業(yè)務(wù)系統(tǒng)其實(shí)都是IO密集型的系統(tǒng)，比如像我們面向B端提供攝像頭服務(wù)，很多的接口其實(shí)就是將各種各樣的數(shù)據(jù)匯總起來(lái)，展示給用戶，我們的數(shù)據(jù)來(lái)源包括Redis、Mysql、Hbase、以及依賴的一些服務(wù)方的數(shù)據(jù)，并不涉及到太多復(fù)雜的計(jì)算邏輯。

在過(guò)去的半年中，因?yàn)槲覀償?shù)據(jù)量和業(yè)務(wù)復(fù)雜性的增長(zhǎng)，確實(shí)遇到了一些明顯的性能問(wèn)題，分析大部分問(wèn)題的本質(zhì)原因就是IO太慢了。

我們系統(tǒng)中最復(fù)雜的計(jì)算邏輯執(zhí)行最慢也就微秒級(jí)，而調(diào)一次數(shù)據(jù)庫(kù)最快也得1-2毫秒，有著2-3個(gè)數(shù)量級(jí)的差距。

然而IO又是業(yè)務(wù)系統(tǒng)中不可能干掉的操作，但頻繁或者錯(cuò)誤的使用IO會(huì)給系統(tǒng)帶來(lái)非常明顯的性能問(wèn)題，輕則拖慢接口影響用戶體驗(yàn)，重則OOM直接宕機(jī)。

針對(duì)IO問(wèn)題帶來(lái)性能問(wèn)題，這里我總結(jié)了三種方式 批處理、緩存和多線程，雖然看起來(lái)是很簡(jiǎn)單的操作，但還是得在合適的地方正確使用才能發(fā)揮出這三種方法的價(jià)值。

批處理

首先是批處理，這里先說(shuō)一個(gè)真實(shí)的案例， 在2021年我們?cè)谧龇?wù)上云過(guò)程中，有個(gè)接口上云后，時(shí)延從原本的50ms左右漲到了150ms，后來(lái)排查發(fā)現(xiàn)，之前是串行化去調(diào)用KMS，這個(gè)服務(wù)上云后和KMS的服務(wù)端出現(xiàn)了跨機(jī)房調(diào)用，單次KMS的調(diào)用時(shí)長(zhǎng)增長(zhǎng)了近0.5ms。 單看這0.5ms確實(shí)不算多，但也架不住幾十次的串行調(diào)用累計(jì)到一起，最終出現(xiàn)了100ms的總延時(shí)增長(zhǎng)。這種接口時(shí)延增長(zhǎng)大到原來(lái)的三倍，用戶是很容易感受到的，可能他們的感受就是這應(yīng)用真卡！

上面這個(gè)問(wèn)題復(fù)現(xiàn)起來(lái)很簡(jiǎn)單，其實(shí)就一個(gè)for循環(huán)，串行去調(diào)用kms解密數(shù)據(jù)量。

for (String str : strList) {
   decodedStr = kmsClient.decrypt(str);  // 單次調(diào)用需要0.5-1ms，串行100次需要50-100ms
}

上述代碼整體的主要的耗時(shí)其實(shí)并不是kms對(duì)數(shù)據(jù)解密的過(guò)程上(僅需要微秒級(jí))，而是請(qǐng)求發(fā)送和接收結(jié)果數(shù)據(jù)時(shí)數(shù)據(jù)在網(wǎng)絡(luò)上傳輸?shù)暮臅r(shí)，這就取決于雙方服務(wù)之間的物理距離了，我們大部分服務(wù)都是在北京部署，但仍會(huì)出現(xiàn)跨機(jī)房調(diào)用的情況，這個(gè)時(shí)候網(wǎng)絡(luò)延時(shí)也會(huì)增長(zhǎng)0.5-1ms。批處理提升IO性能的原理，其實(shí)就是用單次網(wǎng)絡(luò)IO替代掉原有的多次網(wǎng)絡(luò)IO，IO時(shí)長(zhǎng)越長(zhǎng)，優(yōu)化效果越顯著。 用一個(gè)生活中的例子大家更容易理解些，假設(shè)你要給家里準(zhǔn)備一份晚餐，其中很重要的一步就是去菜市場(chǎng)買菜，你是一樣一樣買？還是一次性全買齊了？ 這就是單次處理和批處理的區(qū)別。

這個(gè)性能問(wèn)題看似簡(jiǎn)單，其實(shí)在實(shí)際編程過(guò)程中經(jīng)常犯，稍不留神就大批量串行IO調(diào)用，比如在for循環(huán)中查庫(kù)（你是不是已經(jīng)在腦海中想到自己寫的問(wèn)題代碼了）。 如何避免自己在日常編程中出現(xiàn)類似的問(wèn)題，我總結(jié)了一條編程指導(dǎo)經(jīng)驗(yàn)，那就是 在任何循環(huán)中盡量不要產(chǎn)生IO調(diào)用，除非你知道自己在做什么。

當(dāng)然也不是所有的IO都會(huì)產(chǎn)生問(wèn)題，有些IO非常快，而且你串行的頻次也不是很高，貿(mào)然將代碼改成批處理的邏輯會(huì)顯著增加代碼復(fù)雜度，增加維護(hù)成本反而得不償失，所以建議還是根據(jù)具體的IO類型和具體需求，評(píng)估具體是否要做批處理。

以下我給出一些具體的IO類型和單次IO耗時(shí)參考值，大家寫代碼的時(shí)候可以關(guān)注下。

緩存

高IO的應(yīng)用有個(gè)特點(diǎn)，就是大量的數(shù)據(jù)其實(shí)是被重復(fù)加載的，這也是”局部性“的一個(gè)體現(xiàn)，局部性告訴我們，只有少量的數(shù)據(jù)會(huì)被大量的加載。

利用局部性，我們只要將重要的小部分?jǐn)?shù)據(jù)緩存起來(lái)，就可以減少大量的IO，從而提升我們系統(tǒng)的性能。

如果我們用平均延時(shí)來(lái)評(píng)估性能，我們可以用一個(gè)平均延遲計(jì)算公式來(lái)描述加緩存后的性能：

avgLatency = hitRate * cacheLatency +  (1 - hitRate) * originalLatency

其中avgLatency代指加了緩存后的平均延遲，hitRate表示緩存的命中率，cacheLatency指的是訪問(wèn)一次緩存所需要的耗時(shí)，在實(shí)際使用中，如果我們使用了本地緩存，我們可以簡(jiǎn)單粗暴認(rèn)為cacheLatency是0，以上公式就可以簡(jiǎn)化為avgLatency = (1 - hitRate) * originalLatency 。

從簡(jiǎn)化后的公式可以看出加緩存后的效果僅跟緩存的命中率有關(guān)系，如果cache命中率是90%，就會(huì)有10倍的性能提升，如果是99%就會(huì)有100百性能提升(簡(jiǎn)略計(jì)算)，只要我們無(wú)限提升緩存命中率，似乎就能無(wú)限提升性能。

那命中率又和什么相關(guān)呢？

答案就是數(shù)據(jù)的分布、緩存的大小和數(shù)據(jù)的淘汰策略三者相關(guān)。

• 數(shù)據(jù)分布： 現(xiàn)實(shí)世界中，大部分?jǐn)?shù)據(jù)的訪問(wèn)都受局部性的影響，用大白話講就是只有少部分?jǐn)?shù)據(jù)會(huì)被頻繁訪問(wèn)，如果把數(shù)據(jù)被訪問(wèn)頻次曲線畫出來(lái)，如上圖。
• 緩存大?。?/strong> 這個(gè)很好理解，只要緩存的數(shù)據(jù)足夠多，緩存命中率就越高。
• 淘汰策略： 淘汰策略是指在緩存容量不足的情況下，如何剔除價(jià)值最低的數(shù)據(jù)，常見的淘汰策略有LRU、LFU、FIFO，我們實(shí)際情況中用的最多的就是LRU。