建站
咨詢
售后
建站咨詢
新聞中心
來想象這樣一個場景，一天，公司 CEO 把你叫到會議室，告訴你公司看到了一個新的商業(yè)機會，希望你能帶領(lǐng)一位兄弟，迅速研發(fā)出一套面向某個垂直領(lǐng)域的電商系統(tǒng)。
在資源匱乏、時間緊迫的情況下，我迅速采用了一種極為簡化的系統(tǒng)架構(gòu)：一臺Web服務(wù)器負責運行業(yè)務(wù)代碼，而一臺獨立的數(shù)據(jù)庫服務(wù)器則存儲所有業(yè)務(wù)數(shù)據(jù)。這種簡單的架構(gòu)設(shè)計允許我們盡快啟動項目并專注于核心功能的開發(fā)，以在有限的資源和時間內(nèi)完成任務(wù)。
圖片
當垂直電商系統(tǒng)開始吸引更多用戶流量時，我們遇到了性能問題，主要是因為我們的數(shù)據(jù)庫連接方式。在原始設(shè)計中，每次查詢都需要建立和關(guān)閉數(shù)據(jù)庫連接，這導致了性能下降。為了解決這個問題，我們需要優(yōu)化數(shù)據(jù)庫連接管理，考慮使用連接池技術(shù)來減少連接的頻繁建立和關(guān)閉，以提高系統(tǒng)的響應速度和性能。這將是一個重要的性能優(yōu)化步驟，以適應不斷增長的用戶流量。
那么為什么頻繁創(chuàng)建連接會造成響應時間慢呢？來看一個實際的測試。
通過運行"tcpdump -i bond0 -nn -tttt port 4490"命令來捕獲線上MySQL連接的網(wǎng)絡(luò)包后，我們可以將MySQL連接過程簡化為兩個主要階段：
前三個數(shù)據(jù)包描繪了MySQL連接的起始階段。首先，客戶端發(fā)送了一個帶有SYN標志的數(shù)據(jù)包，表示要與服務(wù)器建立連接。然后，服務(wù)器回應客戶端，確認收到連接請求，并且也發(fā)送一個帶有SYN標志的數(shù)據(jù)包。最后，客戶端再次回應服務(wù)器，確認連接已建立。這個過程就是TCP協(xié)議中的三次握手，用于確保客戶端和服務(wù)器之間的連接正常建立。
第二部分是 MySQL 服務(wù)端校驗客戶端密碼的過程。其中第一個包是服務(wù)端發(fā)給客戶端要求認證的報文，第二和第三個包是客戶端將加密后的密碼發(fā)送給服務(wù)端的包，最后兩個包是服務(wù)端回給客戶端認證 OK 的報文。從圖中，你可以看到整個連接過程大概消耗了 4ms（969012-964904）。
圖片
根據(jù)我們的統(tǒng)計數(shù)據(jù)，單條SQL執(zhí)行時間平均約為1毫秒，這意味著相對于SQL的執(zhí)行來說，MySQL建立連接的過程所花費的時間較長。當請求量較小時，這并不會產(chǎn)生顯著影響，因為不管是建立連接還是執(zhí)行SQL，都在毫秒級別完成。然而，一旦請求量增加，如果每次都按照原始方式建立連接，然后只執(zhí)行一條SQL，那么每秒只能執(zhí)行大約200次數(shù)據(jù)庫查詢，其中有四分之三的時間都花在了建立連接上。
那這時你要怎么做呢？
在進行了一番谷歌搜索后，我找到了一個相對簡單的解決方案：使用連接池來預先建立數(shù)據(jù)庫連接。通過這個改進，我們不再需要在每次使用數(shù)據(jù)庫時都頻繁地創(chuàng)建連接。調(diào)整后，系統(tǒng)的性能顯著提高，現(xiàn)在每秒可以執(zhí)行1000次數(shù)據(jù)庫查詢，這是之前的5倍，從而更好地滿足了高請求量的需求。這種連接池的優(yōu)化方式有效地減少了連接建立的開銷，提高了系統(tǒng)的響應速度和性能。
用連接池預先建立數(shù)據(jù)庫連接
雖然短時間解決了問題，不過你還是想徹底搞明白解決問題的核心原理，于是又開始補課。
在開發(fā)過程中，我們經(jīng)常使用連接池，比如數(shù)據(jù)庫連接池、HTTP連接池和Redis連接池等。連接池的管理是連接池設(shè)計的核心，讓我以數(shù)據(jù)庫連接池為例，簡要說明一下關(guān)鍵點。
數(shù)據(jù)庫連接池有兩個關(guān)鍵配置參數(shù)：最小連接數(shù)和最大連接數(shù)。這些參數(shù)控制著連接池如何管理連接的獲?。?/p>
- 如果當前連接數(shù)小于最小連接數(shù)，連接池會創(chuàng)建新的連接來處理數(shù)據(jù)庫請求。
- 如果連接池中有空閑連接，它將會被重用。
- 如果空閑連接池沒有可用連接，且當前連接數(shù)小于最大連接數(shù)，連接池會創(chuàng)建新的連接來處理請求。
- 如果當前連接數(shù)已經(jīng)達到最大連接數(shù)，連接池會根據(jù)設(shè)定的等待時間（比如C3P0連接池中的checkoutTimeout配置）等待已有連接變?yōu)榭捎谩?/li>
- 如果等待超過了設(shè)定的時間，連接池將向用戶拋出錯誤。
為了方便你理解記憶這個流程，我來舉個例子。
假設(shè)你在機場里運營一家按摩椅的小店，店里總共有10臺按摩椅（類似于數(shù)據(jù)庫連接池的最大連接數(shù)）。為了控制成本（按摩椅費電），通常你會保持4臺按摩椅開啟（最小連接數(shù)），其余6臺關(guān)閉。當顧客到來時，如果這4臺按摩椅中有空位，你可以直接為顧客提供服務(wù)。但如果所有4臺按摩椅都在使用中，那么你會開啟一臺新的按摩椅，直到所有10臺都被占用。
當所有10臺按摩椅都在使用中時，你會告知等待的顧客：“請稍等5分鐘，我保證在這段時間內(nèi)會有按摩椅空出來?！比缓蟮?1位顧客開始等待。這時有兩種可能性：如果在5分鐘內(nèi)有按摩椅空出來，顧客可以立即使用；但如果等待了5分鐘還沒有按摩椅空出來，你需要道歉并建議顧客去其他地方嘗試。
對于數(shù)據(jù)庫連接池，根據(jù)我的經(jīng)驗，一般在線上我建議最小連接數(shù)控制在 10 左右，最大連接數(shù)控制在 20～30 左右即可。
用線程池預先創(chuàng)建線程
JDK 1.5引入的ThreadPoolExecutor是一種線程池的實現(xiàn)，它有兩個關(guān)鍵參數(shù)：coreThreadCount和maxThreadCount。它的工作原理類似于之前描述的按摩椅店模式：
- 如果線程池中的線程數(shù)量小于coreThreadCount，新任務(wù)到來時會創(chuàng)建新線程來處理。
- 如果線程數(shù)量超過coreThreadCount，任務(wù)會被放入一個隊列中，等待當前空閑的線程執(zhí)行。
- 當隊列中的任務(wù)堆積滿了時，線程池會繼續(xù)創(chuàng)建線程，直到達到maxThreadCount。
- 一旦線程數(shù)量達到maxThreadCount，并且仍有新任務(wù)提交，那么這些新任務(wù)可能會被丟棄。
圖片
這個任務(wù)處理流程看似簡單，實際上有很多坑，你在使用的時候一定要注意。
JDK實現(xiàn)的ThreadPoolExecutor在處理任務(wù)時，更傾向于將任務(wù)暫存于隊列中而不是過早地創(chuàng)建新線程。這種方式更適合執(zhí)行CPU密集型任務(wù)，即需要大量的CPU計算任務(wù)。為什么呢？
這是因為在執(zhí)行CPU密集型任務(wù)時，CPU非常繁忙，因此只需要創(chuàng)建與CPU核心數(shù)相近的線程即可。過多的線程反而會導致線程上下文切換，降低任務(wù)執(zhí)行效率。所以，當當前線程數(shù)超過核心線程數(shù)時，線程池不會立即創(chuàng)建更多線程，而是將任務(wù)放入隊列中等待核心線程的空閑。
但是，在我們通常的Web系統(tǒng)中，存在大量的IO操作，例如數(shù)據(jù)庫查詢、緩存查詢等。當任務(wù)執(zhí)行IO操作時，CPU空閑下來，此時如果增加執(zhí)行任務(wù)的線程而不是將任務(wù)暫存在隊列中，可以在單位時間內(nèi)執(zhí)行更多的任務(wù)，從而大大提高任務(wù)執(zhí)行的吞吐量。這種情況下，Tomcat等Web服務(wù)器通常會對線程池進行定制，當線程數(shù)超過核心線程數(shù)時，它們會優(yōu)先創(chuàng)建新線程，直到達到線程池的最大線程數(shù)，以更好地適應Web系統(tǒng)中的大量IO操作場景。你可以在實際應用中考慮類似的線程池調(diào)整來提高性能。
此外，要監(jiān)控線程池中隊列的積壓情況也非常重要，特別是對于實時性要求較高的任務(wù)。我曾在實際項目中遇到過一個奇怪的問題：任務(wù)被提交到線程池后，長時間沒有被執(zhí)行。起初，我懷疑是代碼中的bug，但經(jīng)過排查發(fā)現(xiàn)，問題出在線程池的配置上，coreThreadCount和maxThreadCount設(shè)置得太小，導致任務(wù)在隊列中積壓。一旦我增大了這些參數(shù)，問題就得以解決。
從那以后，我將線程池隊列的任務(wù)積壓量視為系統(tǒng)監(jiān)控的重要指標，將其顯示在監(jiān)控大屏上。最后，我要強調(diào)，如果使用線程池，請不要使用無界隊列（即沒有設(shè)置固定大小的隊列）。有人可能認為無界隊列可以確保任務(wù)永遠不會丟失，只要任務(wù)對實時性要求不高，遲早會被執(zhí)行完。然而，大量任務(wù)的堆積會占用大量內(nèi)存空間。一旦內(nèi)存空間用盡，將頻繁觸發(fā)Full GC，導致服務(wù)不可用。我曾經(jīng)排查過一次因為Full GC引發(fā)的系統(tǒng)宕機，而它的根本原因就是系統(tǒng)中的一個線程池使用了無界隊列。因此，理解線程池的關(guān)鍵要點后，我確保在系統(tǒng)中設(shè)置了合適的配置，保障了系統(tǒng)的穩(wěn)定性，成功完成了公司交給我的研發(fā)任務(wù)。
回顧連接池和線程池，它們都有一個共同特點：它們管理的對象，無論是連接還是線程，都需要耗費相對較多的時間和系統(tǒng)資源來創(chuàng)建。因此，我們將這些對象放入一個池中進行統(tǒng)一管理，以提高性能和資源的重復利用。這是一種常見的軟件設(shè)計思想，稱為池化技術(shù)。其核心思想是通過提前創(chuàng)建對象來減少頻繁創(chuàng)建對象的性能開銷，同時實現(xiàn)對象的統(tǒng)一管理，從而降低對象使用的成本?？傊?，池化技術(shù)帶來了許多好處。
然而，池化技術(shù)也存在一些缺點。例如，存儲池中的對象會占用額外的內(nèi)存，如果對象不經(jīng)常使用，可能會導致內(nèi)存浪費。此外，池中的對象需要在系統(tǒng)啟動時預先創(chuàng)建，這可能增加系統(tǒng)啟動時間。然而，這些缺點相對于池化技術(shù)的優(yōu)勢來說通常較小，只要我們明確需要頻繁創(chuàng)建和銷毀的對象在創(chuàng)建時確實具有高成本和資源消耗，并且這些對象確實會被頻繁使用，那么使用池化技術(shù)來優(yōu)化是值得的。
本文標題：池化技術(shù)：如何減少頻繁創(chuàng)建數(shù)據(jù)庫連接的性能損耗？
轉(zhuǎn)載注明：http://m.5511xx.com/article/cdeoccc.html
