Web服務端效能提升實踐
隨著網際網路的不斷髮展，日常生活中越來越多的需求通過網路來實現，從衣食住行到金融教育，從口袋到身份，人們無時無刻不依賴著網路，而且越來越多的人通過網路來完成自己的需求。
作為直接面對來自客戶請求的Web服務端，無疑要同時承受更多的請求，併為使用者提供更好的體驗。這個時候Web端的效能常常會成為業務發展的瓶頸，提升效能刻不容緩。本文作者在開發過程中總結了一些提升Web服務端效能的經驗，與大家分享。
問題分析
對於Web服務端效能，首先我們分析一下相關指標。從使用者角度講，使用者呼叫Web服務時，請求返回時間越短，使用者體驗越好。從服務端角度講，同一時間能承載使用者請求量越大，服務端效能就越強。綜合兩方面，我們總結效能優化的兩個方向：
1. 增加服務端所能支撐併發請求的最大數量；
2. 提高每個請求處理速度。
明確了優化方向，首先介紹一種服務端通常的架構模式，即來自瀏覽器或者App的Web一個請求，在服務端經過哪幾層結構被處理並返回的。
架構模式：IP負載均衡->快取伺服器->反向代理->應用伺服器->資料庫
如圖1所示，為了說明方便，我們來舉個實際的例子: LVS(Keepalived)->Squid->nginx->Go->MySQL
圖1：服務端架構
我們對請求在每層做分發處理，這樣可以使下一級結構有多個分支同時工作，來提高總體的最大併發數。
結合架構，我們來分析通常有哪些問題在拖了效能的後腿，以及找出對應的解決方法。
正常情況下，IP負載均衡，快取伺服器和nginx代理這幾層主要是叢集穩定性問題。容易出現效能瓶頸的地方往往是應用伺服器層和資料庫層，我們下面來列舉幾個例子：
1. 阻塞的影響
（1）問題：
大部分Web請求都是阻塞性質的，當一個請求被處理時，程序就會被掛起（佔用CPU）直至請求完成。在大多數情況下，Web請求完成的足夠快，所以這個問題並不被關注。然而，對於那些響應時間來完成的請求（像返回資料量大的請求或外部API），這意味著應用程式被鎖定直至處理結束，這期間，其他的請求不會被處理，很明顯，這些無效的等待時間浪費掉了，並且佔用系統資源，嚴重的影響了我們可以負擔的併發請求的數量。
（2）解決辦法：
Web服務端在等待上一個請求處理的過程中，我們可以讓I/O迴圈開啟以便處理其他應用請求，直到處理完成時啟動一個請求並給予反饋，而不再是等待請求完成的過程中掛起程序。這樣，我們可以節省一些沒有必要的等待時間，用這些時間去處理更多的請求，這樣我們就可以大大增加請求的吞吐量，也就是在巨集觀上提高了我們可處理的併發請求數。
（3）例子
這裡我們用Python的一款Web框架Tornado來具體說明改變阻塞方式提高併發效能。
場景：我們構建一個向遠端（某個十分穩定的網站）傳送HTTP請求的簡單Web應用。這期間，網路傳輸穩定，我們不考慮網路來帶的影響。
在這個例子中，我們使用Siege（一款壓力測試軟體）對服務端在10秒內執行大約10個併發請求。
如圖2所示，我們可以很容易看出，這裡的問題是無論每個請求自身返回多麼快，伺服器對遠端的訪問請求往返都會產生足夠大的滯後，因為程序直到請求完成並且資料被處理前都一直處於強制掛起狀態。當一兩個請求時這還不是一個問題，但達到100個（甚至10個）使用者時，這意味著整體變慢。如圖，不到10秒時間10個相似使用者的平均響應時間達到了1.99秒，共計29次。這個例子只展示了非常簡單的邏輯。如果你要新增其他業務邏輯或資料庫的呼叫的話，結果會更糟糕。增加更多的使用者請求時，同時可被處理的請求就會增長緩慢，甚至有些請求會發生超時或失敗。
圖2：阻塞式響應
下面我們用Tornado執行非阻塞的HTTP請求。
如圖3所示，我們從每秒3.20個事務提升到了12.59，在相同的時間內總共提供了118次請求。這真是一個非常大的改善！正如你所想象的，隨著使用者請求增多和測試時間增長時，它將能夠提供更多連線，並且不會遇到上面版本遭受的變慢的問題。從而穩定的提高了可負載的併發請求數。
圖3：非阻塞式響應
2. 計算效率對響應時間和併發數的影響
先來介紹一下基礎知識：一個應用程式是執行在機器上的一個程序；程序是一個執行在自己記憶體地址空間裡的獨立執行體。一個程序由一個或多個作業系統執行緒組成，這些執行緒其實是共享同一個記憶體地址空間的一起工作的執行體。
（1）問題
傳統計算方式單執行緒執行，效率低，計算能力弱。
（2）解決辦法
一種解決辦法就是完全避免使用執行緒。例如，可以使用多個程序將重擔交給作業系統來處理。但是，有個劣勢就是，我們必須處理所有程序間通訊，通常這比共享記憶體的併發模型有更多的開銷。
另一種辦法是用多執行緒工作，不過，公認的，使用多執行緒的應用難以做到準確，同步不同的執行緒，對資料加鎖，這樣同時就只有一個執行緒可以變更資料。不過過去的軟體開發經驗告訴我們這會帶來更高的複雜度，更容易使程式碼出錯以及更低的效能。
其中最主要的問題是記憶體中的資料共享，它們會被多執行緒以無法預知的方式進行操作，導致一些無法重現或者隨機的結果（稱作“競態”）。所以這個經典的方法明顯不再適合現代多核/多處理器程式設計：thread-per-connection 模型不夠有效。在諸多比較合適的正規化中，有個被稱作 Communicating Sequential Processes（順序通訊處理）（CSP, C. Hoare 發明的）還有一個叫做 message-passing-model（訊息傳遞）（已經運用在了其他語言中，比如 Erlang）。
我們這裡使用辦法是利用並行的架構來處理任務，一個併發程式可以在一個處理器或者核心上使用多個執行緒來執行任務，但是隻有同一個程式在某個時間點同時執行在多核或者多處理器上才是真正的並行。
並行是一種通過使用多處理器以提高速度的能力。所以併發程式可以是並行的，也可以不是。
並行模式可以同時使用多執行緒、多核、多處理器，甚至多計算機，這無疑可以調動更多資源，從而壓縮響應時間，提升運算效率，極大地增強了服務端的效能。
（3）例子
這裡用Go語言中的Goroutine來具體說明。
在Go語言中，應用程式併發處理的部分被稱作 goroutines（協程），它可以進行更有效的併發運算。在協程和作業系統執行緒之間並無一對一的關係：協程是根據一個或多個執行緒的可用性，對映（多路複用，執行於）在他們之上的；協程排程器在 Go 執行時很好的完成了這個工作。協程是輕量的，比執行緒更輕。它們痕跡非常不明顯（使用少量的記憶體和資源）：使用 4K 的棧記憶體就可以在堆中建立它們。因為建立非常廉價，必要的時候可以輕鬆建立並執行大量的協程（在同一個地址空間中 100,000 個連續的協程）。並且它們對棧進行了分割，從而動態的增加（或縮減）記憶體的使用；棧的管理是自動的，但不是由垃圾回收器管理的，而是在協程退出後自動釋放。協程可以執行在多個作業系統執行緒之間，也可以執行線上程之內，讓你可以很小的記憶體佔用就可以處理大量的任務。由於作業系統執行緒上的協程時間片，你可以使用少量的作業系統執行緒就能擁有任意多個提供服務的協程，而且 Go 執行時可以聰明地意識到哪些協程被阻塞了，暫時擱置它們並處理其他協程。甚至，程式可以在不同的處理器和計算機上同時執行不同的程式碼段。
我們通常想將一個長計算過程切分成幾塊，然後讓每個goroutine各自負責一塊工作，這樣對於單一請求的響應時間有成倍的提升。
舉個例子，有一個任務分3個階段，a階段去資料庫a中取資料，b階段去資料庫b中取資料，c階段合併資料返回。我們啟動goroutine以後a、b階段可以一起進行，極大地縮短了響應時間。
說白了就是部分計算過程由序列轉換為並行，一個任務不需要等待其他無關的任務執行完在執行，實際計算中程式的並行執行會更有用處。
關於這部分佐證的資料就不在這邊過多敘述了，感興趣的同學可以自己看一下這方面的資料。比如Web服務端由Ruby切換為Go效能提升15倍的老故事（Ruby使用的是綠色執行緒，即只有一個CPU得到利用）。雖然這個故事可能有點誇大，但是並行帶來的效能提升是毫無疑問的。（Ruby切換為Go：http://www.vaikan.com/how-we-went-from-30-servers-to-2-go/）。
3. 磁碟I/O對效能的影響
(1) 問題
磁碟讀取資料靠的是機械運動，每次讀取資料花費的時間可以分為尋道時間、旋轉延遲、傳輸時間三個部分，尋道時間指的是磁臂移動到指定磁軌所需要的時間，主流磁碟一般在5ms以下；旋轉延遲就是我們經常聽說的磁碟轉速，比如一個磁碟7200轉，表示每分鐘能轉7200次，也就是說1秒鐘能轉120次，旋轉延遲就是1/120/2 = 4.17ms；傳輸時間指的是從磁碟讀出或將資料寫入磁碟的時間，一般在零點幾毫秒，相對於前兩個時間可以忽略不計。那麼訪問一次磁碟的時間，即一次磁碟I/O的時間約等於9ms（5ms+4.17ms）左右，聽起來還挺不錯的，但要知道一臺500 -MIPS的機器每秒可以執行5億條指令，因為指令依靠的是電的性質，換句話說執行一次I/O的時間可以執行40萬條指令，資料庫動輒十萬百萬乃至千萬級資料，每次9毫秒的時間，顯然是個災難。
(2) 解決辦法
磁碟I/O對伺服器效能的影響沒有根本的解決辦法，除非你把磁碟扔掉，換成別的東西。我們能在網上搜到各種儲存介質的響應速度與價格，如果你有錢，你就可以任性的更換儲存介質。
在不更換儲存介質的條件下，我們可以減少應用程式對磁碟的訪問次數，比如設定快取，還可以把部分磁碟I/O放到請求週期外，比如用佇列和棧來處理資料的I/O等。
4. 優化資料庫查詢
隨著業務開發模式的變化，敏捷式開發被越來越多的團隊採用，週期越來越短，很多資料庫查詢語句都是按照業務邏輯來寫，時間久了常常就忽略了SQL查詢的格式問題，造成資料庫壓力的增加，使資料庫查詢的響應變慢。這裡簡單介紹MySQL資料庫中，幾條被我們忽略的常見問題和優化方式：
- 最左字首匹配原則，非常重要的原則，MySQL會一直向右匹配直到遇到範圍查詢(>、<、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的順序可以任意調整。
- 儘量選擇區分度高的列作為索引，區分度的公式是count(distinct col)/count(*)，表示欄位不重複的比例，比例越大我們掃描的記錄數越少，唯一鍵的區分度是1，而一些狀態、性別欄位可能在大資料面前區分度就是0，那可能有人會問，這個比例有什麼經驗值嗎？使用場景不同，這個值也很難確定，一般需要join的欄位我們都要求是0.1以上，即平均1條掃描10條記錄。
- 儘量使用數字型欄位，若只含數值資訊的欄位儘量不要設計為字元型，這會降低查詢和連線的效能，並會增加儲存開銷。這是因為引擎在處理查詢和連線時會逐個比較字串中每一個字元，而對於數字型而言只需要比較一次就夠了。
- 索引列不能參與計算，保持列“乾淨”，比如
from_unixtime(create_time) = ’2014-05-29’就不能使用到索引，原因很簡單，b+樹中存的都是資料表中的欄位值，但進行檢索時，需要把所有元素都應用函式才能比較，顯然成本太大。所以語句應該寫成create_time = unix_timestamp(’2014-05-29’);應儘量避免在 where 子句中對欄位進行 null 值判斷，否則將導致引擎放棄使用。 - 索引而進行全表掃描，如：
select id from t where num is null可以在num上設定預設值0，確保表中num列沒有null值，然後這樣查詢：
select id from t where num=0 - 應儘量避免在 where 子句中使用 or 來連結條件，否則將導致引擎放棄使用索引而進行全表掃描，如：
select id from t where num=10 or num=20
可以這樣查詢：select id from t where num=10 union all select id from t where num=20 - 下面的查詢也將導致全表掃描(不能前置百分號)：
select id from t where name like ‘%abc%’
若要提高效率，可以考慮全文檢索。 - in 和 not in 也要慎用，否則會導致全表掃描，如：
select id from t where num in(1,2,3)
對於連續的數值，能用 between 就不要用 in 了：
select id from t where num between 1 and 3
文章來自微信公眾號：網際網路架構師