對(duì)速度的不滿(mǎn)在調(diào)優(yōu)的場(chǎng)景里占大多數(shù)，速度的不滿(mǎn)一般來(lái)說(shuō)也是分兩種：

一種是對(duì)一個(gè)“體型”較大的任務(wù)執(zhí)行的時(shí)間過(guò)長(zhǎng)不滿(mǎn);

一種是對(duì)一個(gè)“體型”較小的任務(wù)的響應(yīng)速度過(guò)長(zhǎng)不滿(mǎn)。

這兩種不滿(mǎn)看上去都是一樣的速度問(wèn)題，但是思路不完全一樣。一般來(lái)說(shuō)，在做這類(lèi)優(yōu)化之前先要做一件事，就是判斷一下究竟是資源不足，還是資源分配不合理。

常見(jiàn)的場(chǎng)景可能有以下這些：例如，一個(gè)進(jìn)程在服務(wù)器上運(yùn)行，但是速度確實(shí)比期望的慢，而CPU和磁盤(pán)的帶寬卻大量閑置，這種情況下很顯然是資源配置不合理。

因?yàn)橘Y源不是不夠，而是由于線(xiàn)程調(diào)度，或者算法，或者其他一些原因沒(méi)有被利用上。這種情況下估計(jì)你去申請(qǐng)購(gòu)買(mǎi)新機(jī)器，如果老板花的確實(shí)是自己的錢(qián)的話(huà)十有八九是不會(huì)給你批的，相信我。

1、思路一：邏輯層面的優(yōu)化

在服務(wù)器上跑的程序，尤其是Batch通常是彼此之間獨(dú)立的。這種情況下，其實(shí)是可以考慮讓它們同時(shí)來(lái)執(zhí)行，充分利用CPU和內(nèi)存的資源。但是也要注意，要確認(rèn)這種變化給磁盤(pán)帶來(lái)的IO增加不會(huì)讓它成為系統(tǒng)的瓶頸。這就是進(jìn)程級(jí)別的并發(fā)。

還有的時(shí)候一個(gè)進(jìn)程可以分解為多個(gè)獨(dú)立作業(yè)和一個(gè)合并操作，那么這種情況下通?？梢試L試著多啟動(dòng)幾個(gè)進(jìn)程或者線(xiàn)程，讓每個(gè)進(jìn)程或者線(xiàn)程處理整個(gè)作業(yè)的一部分，最后結(jié)束的時(shí)候做一個(gè)作業(yè)結(jié)果的“合并”操作，提高并行化，提高資源利用率。

這種應(yīng)用比較典型的就是Hadoop環(huán)境中的MapReduce程序，實(shí)際是在很多節(jié)點(diǎn)各啟動(dòng)若干個(gè)Map進(jìn)程和Reduce進(jìn)程，讓它們?cè)诓煌?jié)點(diǎn)上操作，分?jǐn)侷O和CPU的資源壓力。在單臺(tái)服務(wù)器上也有類(lèi)似的操作，如一個(gè)MySQL服務(wù)器進(jìn)程在接受一個(gè)SQL請(qǐng)求時(shí)，這個(gè)SQL不論請(qǐng)求多少個(gè)表，不論它有多少個(gè)不相干的子查詢(xún)，不論寫(xiě)得有多“優(yōu)美”，它都只能在一個(gè)CPU內(nèi)核上一步一步地走下去。

所以，如果采用MySQL環(huán)境做關(guān)聯(lián)分析，就只能把一個(gè)SQL中的兩個(gè)獨(dú)立子查詢(xún)放到兩個(gè)或者更多的線(xiàn)程(進(jìn)程)里去做請(qǐng)求，再用一個(gè)監(jiān)控線(xiàn)程(進(jìn)程)觀察結(jié)果，最后做連接查詢(xún)。有必要的話(huà)可以使用Memory內(nèi)存視圖的Hash索引進(jìn)行速度優(yōu)化。

2、思路二：容器層面的優(yōu)化

當(dāng)一臺(tái)或多臺(tái)服務(wù)器上有很多進(jìn)程，但是資源占用普遍比較低時(shí)，還可以考慮使用容器層面的優(yōu)化。

可以使用KVM或者Docker這樣的容器把服務(wù)器資源劃分成多個(gè)虛擬的服務(wù)器資源。這種情況下，原本在多個(gè)服務(wù)器的少量負(fù)載經(jīng)過(guò)遷移會(huì)合起來(lái)加載在一個(gè)服務(wù)器上，而節(jié)省出來(lái)的服務(wù)器資源可以用來(lái)做其他的服務(wù)，在硬件的成本上會(huì)有一大筆節(jié)省。

現(xiàn)在的阿里云、騰訊云、金山云、亞馬遜云等云產(chǎn)品服務(wù)商就是大規(guī)模使用了虛擬化技術(shù)，從而使得運(yùn)維成本大為降低。

雖然容器層面的優(yōu)化對(duì)于直接減少程序運(yùn)行的時(shí)間作用較為間接，但在龐大的系統(tǒng)內(nèi)提高硬件整體的使用效率還是非常有好處的。

3、思路三：存儲(chǔ)結(jié)構(gòu)層面的優(yōu)化

目前在服務(wù)器普遍配置了RAID10磁盤(pán)陣列以后，磁盤(pán)IO在硬件層面進(jìn)一步并行化的余地越來(lái)越小了。那么還有沒(méi)有其他的辦法可以對(duì)IO層面進(jìn)行優(yōu)化呢?有的。

例如，為了緩存一些數(shù)據(jù)做迭代運(yùn)算，磁盤(pán)發(fā)生非常頻繁的讀寫(xiě)，每次幾個(gè)GB(量比較小，至少內(nèi)存能夠承載)，但是一次處理可能要讀寫(xiě)數(shù)百次，這樣會(huì)大量占用磁盤(pán)IO。這種情況下，不妨嘗試在內(nèi)存中虛擬或者劃分出一個(gè)獨(dú)立的空間，以供做IO使用。這樣把CPU和磁盤(pán)之間的IO轉(zhuǎn)化成為CPU和內(nèi)存之間的IO，這種效率的提升可能是數(shù)千倍的。

另外，磁盤(pán)在做IO的過(guò)程中，是不是掃描了一些本可以不掃描的磁盤(pán)塊?解決這種問(wèn)題有很多成熟的辦法。

在數(shù)據(jù)倉(cāng)庫(kù)里使用列式存儲(chǔ)，從本質(zhì)來(lái)講也是用這種方法來(lái)規(guī)避沒(méi)必要掃描的數(shù)據(jù)塊被掃描。表分區(qū)(Table Partitioning)、索引(Index)，這兩種技術(shù)同樣是為了解決數(shù)據(jù)查找中沒(méi)必要掃描的數(shù)據(jù)塊被訪(fǎng)問(wèn)而帶來(lái)的IO效率下降問(wèn)題。

資源分配不合理的情況比較好解決，就是找出在系統(tǒng)里CPU、內(nèi)存、磁盤(pán)、網(wǎng)絡(luò)中，哪些資源被大量閑置，如果利用起來(lái)能否提高并行性，基本就是這樣一種思路。

4、思路四：環(huán)節(jié)層面的優(yōu)化

環(huán)節(jié)層面的優(yōu)化是一個(gè)邊緣化的問(wèn)題，因?yàn)檫@個(gè)層面上的優(yōu)化通常會(huì)涉及硬件資源以外的一些問(wèn)題——換句話(huà)說(shuō)，這一類(lèi)問(wèn)題在計(jì)算機(jī)的CPU、內(nèi)存、磁盤(pán)、網(wǎng)絡(luò)層面考慮可能還是不能解決的。

(1)虛擬機(jī)惹的禍

筆者幾年前在某500強(qiáng)企業(yè)的IT解決方案中心做顧問(wèn)的時(shí)候，曾經(jīng)遇到過(guò)一個(gè)案例。

這個(gè)案例從技術(shù)層面來(lái)說(shuō)就是一個(gè)ERP系統(tǒng)頁(yè)面請(qǐng)求速度太慢的問(wèn)題，大概需要2到3秒時(shí)間才能把一個(gè)頁(yè)面的數(shù)據(jù)完全加載完畢。不管2到3秒這個(gè)速度是不是夠快，是不是比平時(shí)訪(fǎng)問(wèn)電商網(wǎng)頁(yè)或者在線(xiàn)論壇的速度快，對(duì)于一個(gè)對(duì)效率要求很苛刻的500強(qiáng)企業(yè)來(lái)說(shuō)，這是一件不能容忍的事情。況且，頁(yè)面所訪(fǎng)問(wèn)的服務(wù)器也是DELL提供的很新的技術(shù)方案，48個(gè)CPU內(nèi)核，192GB內(nèi)存。

服務(wù)器在公司內(nèi)網(wǎng)，內(nèi)網(wǎng)帶寬又基本都是1Gbps的光纖到樓層，樓層內(nèi)部又都是100Mbps的以太網(wǎng)。所以從這個(gè)層面上看這種頁(yè)面的延遲沒(méi)有道理，而其他項(xiàng)目組在配置基本相當(dāng)?shù)姆?wù)器環(huán)境和終端環(huán)境，打開(kāi)頁(yè)面時(shí)間都是1秒以?xún)?nèi)。

但是很快就發(fā)現(xiàn)了問(wèn)題所在，這個(gè)ERP系統(tǒng)的頁(yè)面是使用Silverlight制作的。Silverlight是微軟出品的一種跨服務(wù)器跨平臺(tái)的插件，主要目的是解決瀏覽器上的流媒體和交互豐富性的問(wèn)題，基本可以認(rèn)為是Adobe Flash的替代者。然而這種技術(shù)框架有一個(gè)天生的問(wèn)題就是慢，因?yàn)樗{(diào)用的是微軟.NET虛擬機(jī)的資源，而虛擬機(jī)本身的運(yùn)行機(jī)制就是一種多層間接調(diào)用的架構(gòu)，指令不是直接下達(dá)到CPU上，而是經(jīng)過(guò)虛擬機(jī)，由虛擬機(jī)調(diào)度線(xiàn)程再發(fā)送到CPU。在一次HTTP請(qǐng)求的過(guò)程中，有幾百個(gè)指令會(huì)以這種方式傳遞給CPU，延遲是顯而易見(jiàn)的。

最后為了贏得這1秒多的時(shí)間，不得不推翻了整個(gè)項(xiàng)目的架構(gòu)部分，采用HTML4+CSS2的方式。立竿見(jiàn)影，延遲瞬間就壓縮到1秒以?xún)?nèi)了。但是代價(jià)是犧牲了一些交互上的豐富性和美觀性，那個(gè)時(shí)候HTML5和CSS3還不成熟，還不能作為成熟的技術(shù)方案，所以說(shuō)現(xiàn)在用HTML5和CSS3的程序員們真是趕上好時(shí)候了。

(2)CDN是個(gè)好東西

除了剛剛這個(gè)例子以外，平時(shí)也能見(jiàn)到很多從環(huán)節(jié)層面進(jìn)行優(yōu)化的例子。最常見(jiàn)的就是CDN技術(shù)。

CDN技術(shù)是一種近幾年非常火的技術(shù)，全稱(chēng)是Content Delivery Network，內(nèi)容分發(fā)網(wǎng)絡(luò)。CDN應(yīng)該說(shuō)是一套完整的網(wǎng)絡(luò)加速解決方案，包括分布式存儲(chǔ)、負(fù)載均衡、網(wǎng)絡(luò)請(qǐng)求的重定向和內(nèi)容管理等多個(gè)技術(shù)環(huán)節(jié)部分。對(duì)于用戶(hù)在網(wǎng)頁(yè)上請(qǐng)求圖片加載慢，或者文件下載慢等非本地帶寬過(guò)小帶來(lái)的數(shù)據(jù)下載問(wèn)題能有很好的改善作用。

例如，當(dāng)一個(gè)網(wǎng)站使用了CDN技術(shù)對(duì)網(wǎng)頁(yè)資源進(jìn)行加速的策略開(kāi)啟后，這些資源就會(huì)通過(guò)CDN提供商的分發(fā)策略分發(fā)到很多的緩存服務(wù)器上去。當(dāng)用戶(hù)進(jìn)行該網(wǎng)站的訪(fǎng)問(wèn)時(shí)，這些資源引用的地址會(huì)自動(dòng)指向這個(gè)離得最“近”，訪(fǎng)問(wèn)最快的緩存服務(wù)器節(jié)點(diǎn)上去，這樣就能使資源下載加速了。

互聯(lián)網(wǎng)是一個(gè)非常復(fù)雜的東西，不僅是拓?fù)浣Y(jié)構(gòu)復(fù)雜，其中不同的交換設(shè)備有著不同的交換策略，是一個(gè)分布式的自協(xié)調(diào)的連通系統(tǒng)。不同運(yùn)營(yíng)商之間也會(huì)由于技術(shù)性的或者非技術(shù)性的問(wèn)題引發(fā)跨網(wǎng)(跨運(yùn)營(yíng)商)的帶寬變窄問(wèn)題。為了解決這種問(wèn)題，我們不僅僅會(huì)用到CDN技術(shù)，還需要使用一種叫BGP雙線(xiàn)/多線(xiàn)機(jī)房的技術(shù)來(lái)進(jìn)行網(wǎng)絡(luò)加速。

BGP(Border Gateway Protocol，邊界網(wǎng)關(guān)協(xié)議)是一種在TCP協(xié)議上運(yùn)行的自治系統(tǒng)之間動(dòng)態(tài)交換路由信息的路由協(xié)議。啟用BGP技術(shù)的機(jī)房一般稱(chēng)作BGP機(jī)房，服務(wù)器租用商或提供商通過(guò)技術(shù)的手段，實(shí)現(xiàn)不同運(yùn)營(yíng)商能共同訪(fǎng)問(wèn)一個(gè)IP，并且不同運(yùn)營(yíng)商之間都能以最快的速度訪(fǎng)問(wèn)這個(gè)IP地址。把服務(wù)器放在BGP機(jī)房給用戶(hù)帶來(lái)的好處就是，在BGP機(jī)房基本可以不考慮不同的用戶(hù)跨網(wǎng)訪(fǎng)問(wèn)服務(wù)器會(huì)因運(yùn)營(yíng)商網(wǎng)絡(luò)不同而產(chǎn)生的“帶寬歧視”問(wèn)題。

5、資源不足

資源不足的情況通常比較麻煩，因?yàn)槿绻^察到服務(wù)器上的CPU、磁盤(pán)IO、網(wǎng)絡(luò)IO都非常繁忙，要想辦法先排除是業(yè)務(wù)邏輯上設(shè)計(jì)的疏漏導(dǎo)致的不合理或者意外的資源請(qǐng)求太多，還是“真的”資源不夠。

如果是由于一些疏漏導(dǎo)致的資源請(qǐng)求過(guò)于集中，那么通過(guò)debug或者優(yōu)化業(yè)務(wù)邏輯，還是能夠獲解的。但是如果不是這些問(wèn)題，那就是資源確實(shí)比客觀真實(shí)的需求少了。典型的例子就是，在保存日志的情況下，業(yè)務(wù)要求無(wú)損永久存檔，但是即便在啟用壓縮且不留冗余的情況下，還是很快把磁盤(pán)填滿(mǎn)，那就是典型的磁盤(pán)資源不足了。

總之，還是要先用一些辦法確定資源分配究竟是不足還是不合理，再用“低成本”的資源換取“高成本”的資源。