在昨天，我們討論了連接池，有朋友留言表示還不是很懂連接池的優(yōu)勢，知識不是死記硬背的，我們今天從計算機網(wǎng)絡(luò)、已經(jīng)分布式系統(tǒng)的可用性方面，來跟大家解釋解釋，連接池的優(yōu)點。

相信大家對TCP的三次握手已經(jīng)非常地熟悉，很多人之前都覺得這些都是背誦來面試的，今天我們就來講講他們的應用。建立TCP連接需要三次握手之后才開始發(fā)送數(shù)據(jù)，這樣才能保證數(shù)據(jù)的可靠傳輸。 假設(shè)后端服務與數(shù)據(jù)庫單程訪問需要10毫秒，那么我們對數(shù)據(jù)庫發(fā)起一次數(shù)據(jù)庫查詢請求，就需要30毫秒用來先建立連接。每個請求的延遲就要多30毫秒，系統(tǒng)的吞吐必然會大大降低。實際上TCP的優(yōu)化可以在發(fā)起方第二次ack的時候把請求包也帶過去，所以只會多兩程往返路徑，多了20毫秒。

如果你覺得只多這20毫秒么？那就太天真了，TCP能夠一次就把所有的數(shù)據(jù)都發(fā)送完么？網(wǎng)絡(luò)環(huán)境是非常復雜的，中間有著多個結(jié)點，發(fā)送方并不知道整條鏈路的帶寬是多少，如果一下子發(fā)送太多，就會造成丟包，而TCP一旦丟包就需要重試，最后發(fā)送速度反而更慢。我們都知道TCP是有發(fā)送窗口的，并且這個發(fā)送窗口是可以改變的，為了保證網(wǎng)絡(luò)的高效可靠傳輸，TCP采用慢啟動的算法。TCP會先嘗試發(fā)4個窗口數(shù)據(jù)，如果發(fā)送成功再發(fā)送8個窗口，成功了在16個窗口，如果你用過下載器下載軟件，就會發(fā)現(xiàn)，一開始下載速度比較慢，然后越來越快，最后達到家里網(wǎng)絡(luò)帶寬的下載速度。

假如我們初試窗口大小為4kb(事實上linux上面默認的不止這么多，大概有16kb,這里為了計算方便，我們使用4kb),如果我們一次數(shù)據(jù)庫查詢要查詢100Kb的數(shù)據(jù)，要花多長點額時間呢？

一次查詢竟然要花120毫秒，如果我們本來就與數(shù)據(jù)庫建立長連接，除去三次握手跟慢啟動的時間，同樣查詢100kb大小的查詢，只要40毫秒。

同理，我們的很多Http,Rpc協(xié)議都是支持長連接的，也是同樣的道理，長連接相對與短鏈接，免去了TCP握手跟慢啟動的時間，如果通信的雙方的距離越遠，延遲越高，傳輸?shù)臄?shù)據(jù)包越大，那么長連接的優(yōu)勢就越明顯。當然，維護長連接對服務器來說也是一種開銷，如何更高效利用長連接也是一個值得研究的事情。如果你有興趣，可以關(guān)注我，后面我們再一起討論。

緊接著，我們再來從分布式系統(tǒng)的穩(wěn)定性跟可用性討論這個問題，假如我們在做一個電商系統(tǒng)，A業(yè)務是屬于下單的主流程，B業(yè)務是商家后臺，很明顯，他們都需要讀取訂單的數(shù)據(jù)。設(shè)想，如果存在某一個時刻，有一些商家都拼命讀取數(shù)據(jù)，特別是大商家，就會占用特別多的數(shù)據(jù)庫資源。所以我們不難想到，針對這種情況，我們要進行限流，連接池也是一種限流的方案。通過連接池，我們給每個業(yè)務配置一定數(shù)量的長連接。如果不存在可用的長連接，業(yè)務就會等待，避免流量到數(shù)據(jù)庫，增加數(shù)據(jù)庫的壓力。

上述例子，我們只允許5個商家系統(tǒng)的后臺同時使用訂單數(shù)據(jù)庫，而允許30個用戶長連接可以保證用戶下單的并發(fā)最少有30個，從而減少系統(tǒng)的壓力。

總結(jié)：

? ? 不要死背概念，只要我們從原理出發(fā)，就能很清楚了了解每一個系統(tǒng)設(shè)計的妙處。如果你感興趣，可以關(guān)注我，后面我們會剖析更多精彩的設(shè)計。