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