高性能mysql數據庫連接池,高並發數據庫連接池配置

本文目錄一覽：

• 1、mysql的數據連接池怎麼配置文件
• 2、jboss里怎麼配置mysql數據庫的連接池
• 3、高並發的MySQL數據查詢時,會不會選擇數據庫連接池?
• 4、怎麼用druid連接池連接mysql
• 5、MySQL與Redis數據庫連接池介紹（圖示+源碼+代碼演示）

mysql的數據連接池怎麼配置文件

mysql的數據連接池怎麼配置文件

連接先建立一些連接，並且這些連接允許共享，因此這樣就節省了每次連接的時間開銷。Mysql數據庫為例，連接池在Tomcat中的配置與使用。

1、創建數據庫Student,表student

2、配置server.xml文件。Tomcat安裝目錄下conf中server.xml文件。

GlobalNamingResources

Resource

name=”jdbc/DBPool”

type=”javax.sql.DataSource”

password=””

driverClassName=”com.mysql.jdbc.Driver”

maxIdle=”2″

maxWait=”5000″

username=”root”

url=”jdbc:mysql://localhost:3306/student”

maxActive=”3″

/

/GlobalNamingResources

name:指定連接池的名稱

type:指定連接池的類，他負責連接池的事務處理

url:指定要連接的數據庫

driverClassName:指定連接數據庫使用的驅動程序

username:數據庫用戶名

password:數據庫密碼

maxWait:指定最大建立連接等待時間，如果超過此時間將接到異常

maxIdle:指定連接池中連接的最大空閑數

maxActive:指定連接池最大連接數

3、配置web.xml文件。

web-app

resource-ref

descriptionmysql數據庫連接池配置/description

res-ref-namejdbc/DBPool/res-ref-name

res-typejavax.sql.DataSource/res-type

res-authContainer/res-auth

res-sharing-scopeShareable/res-sharing-scope

/resource-ref

/web-app

4、配置context.xml文件

與server.xml文件所在的位置相同。

Context

ResourceLink

name=”jdbc/DBPool”

type=”javax.sql.DataSource”

global=”jdbc/DBPool”

/

/Context

5、測試

DataSource pool = null;

Context env = null;

Connection conn = null;

Statement st = null;

ResultSet rs = null;

try{

env = (Context)new InitialContext().lookup(“java:comp/env”);

//檢索指定的對象，返回此上下文的一個新實例

pool = (DataSource)env.lookup(“jdbc/DBPool”);

//獲得數據庫連接池

if(pool==null){out.printl(“找不到指定的連接池！”);}

con = pool.getConnection();

st = con.createStatement();

rs = st.executeQuery(“select * from student”);

}catch(Exception ex){out.printl(ne.toString());}

jboss里怎麼配置mysql數據庫的連接池

一、要在JBoss中使用MySQL的話首先要把MySQL的JDBC驅動放到CLASSPATH中。然後再JBoss配置。

二、再把/docs/examples/jca/mysql-ds.xml複製到/server/default/deploy目錄下。修改mysql-ds.xml文件，其中是數據庫主機名是數據庫名。

我的mysql-ds.xml如下

三、然後需要JBoss配置standardjaws.xml （註：\server\default\conf目錄下）文件。

四、同樣也需要把JBosscmp-jdbc.xml文件 注: \server\default\conf目錄下）。

五、最後再修改login-config.xml（\server\default\conf目錄下）文件來使用。

六、測試代碼。

高並發的MySQL數據查詢時,會不會選擇數據庫連接池?

現象

Sysbench對MySQL進行壓測, 並發數過大(5k)時, Sysbench建立連接的步驟會超時.

猜想

猜想: 直覺上這很簡單, Sysbench每建立一個連接, 都要消耗一個線程, 資源消耗過大導致超時.

驗證: 修改Sysbench源碼, 調大超時時間, 仍然會發生超時.

檢查環境

猜想失敗, 回到常規的環境檢查:

MySQL error log 未見異常.

syslog 未見異常.

tcpdump 觀察網絡包未見異常, 連接能完成正常的三次握手; 只觀察到在出問題的連接中, 有一部分的TCP握手的第一個SYN包發生了重傳, 另一部分沒有發生重傳.

自己寫一個簡單的並發發生器, 替換sysbench, 可重現場景. 排除sysbench的影響

猜想2

懷疑 MySQL 在應用層因為某種原因, 沒有發送握手包, 比如卡在某一個流程上:

檢查MySQL堆棧未見異常, 彷彿MySQL在應用層沒有看到新連接進入.

通過strace檢查MySQL, 發現 accept() 調用確實沒有感知到新連接.

懷疑是OS的原因, Google之, 得到參考文檔: A TCP “stuck” connection mystery【】

分析

參考文檔中的現象跟目前的狀況很類似, 簡述如下:

正常的TCP連接流程:

Client 向 Server 發起連接請求, 發送SYN.

Server 預留連接資源, 向 Client 回復SYN-ACK.

Client 向 Server 回復ACK.

Server 收到 ACK, 連接建立.

在業務層上, Client和Server間進行通訊.

當發生類似SYN-flood的現象時, TCP連接的流程會使用SYN-cookie, 變為:

Client 向 Server 發起連接請求, 發送SYN.

Server 不預留連接資源, 向 Client 回復SYN-ACK, 包中附帶有簽名A.

Client 向 Server 回復ACK, 附帶 f(簽名A) (對簽名進行運算的結果).

Server 驗證簽名, 分配連接資源, 連接建立.

在業務層上, Client和Server間進行通訊.

當啟用SYN-cookie時, 第3步的ACK包因為 某種原因 丟失, 那麼:

從Client的視角, 連接已經建立.

從Server的視角, 連接並不存在, 既沒有建立, 也沒有”即將建立” (若不啟用SYN-cookie, Server會知道某個連接”即將建立”)

發生這種情況時:

若業務層的第一個包應是從 Client 發往 Server, 則會進行重發或拋出連接錯誤

若業務層的第一個包應是從 Server 發往 Client的, Server不會發出第一個包. MySQL的故障就屬於這種情況.

TCP握手的第三步ACK包為什麼丟失

參考文檔中, 對於TCP握手的第三步ACK包的丟失原因, 描述為:

Some of these packets get lost because some buffer somewhere overflows.

我們可以通過Systemtap進一步探究原因. 通過一個簡單的腳本:

probe kernel.function(“cookie_v4_check”).return

{

source_port = @cast($skb-head + $skb-transport_header, “struct tcphdr”)-source

printf(“source=%d, return=%d\n”,readable_port(source_port), $return)

}

function readable_port(port) {

return (port ((19)-1)) 8 | (port 8)

}

觀察結果, 可以確認cookie_v4_check (syn cookie機制進行包簽名檢查的函數)會返回 NULL(0). 即驗證是由於syn cookie驗證不通過, 導致TCP握手的第三步ACK包不被接受.

之後就是對其中不同條件進行觀察, 看看是哪個條件不通過. 最終原因是accept隊列滿(sk_acceptq_is_full):

static inline bool sk_acceptq_is_full(const struct sock  *sk){   return sk-sk_ack_backlog sk-   sk_max_ack_backlog;}

恢復故障與日誌的正關聯

在故障處理的一開始, 我們就檢查了syslog, 結論是未見異常.

當整個故障分析完成, 得知了故障與syn cookie有關, 回頭看syslog, 裡面是有相關的信息, 只是和故障發生的時間不匹配, 沒有正關聯, 因此被忽略.

檢查Linux源碼:

if (!queue-synflood_warned

sysctl_tcp_syncookies != 2

xchg(queue-synflood_warned, 1) == 0)

pr_info(“%s: Possible SYN flooding on port %d. %s.

Check SNMP counters.\n”,

proto, ntohs(tcp_hdr(skb)-dest), msg);

可以看到日誌受到了抑制, 因此日誌與故障的正關聯被破壞.

粗看源碼, 每個listen socket只會發送一次告警日誌, 要獲得日誌與故障的正關聯, 必須每次測試重啟MySQL.

解決方案

這種故障一旦形成, 難以檢測; 系統日誌中只會出現一次, 在下次重啟MySQL之前就不會再出現了; Client如果沒有合適的超時機制, 萬劫不復.

解決方案:

1. 修改MySQL的協議, 讓Client先發握手包. 顯然不現實.

2. 關閉syn_cookie. 有安全的人又要跳出來了.

3. 或者調高syn_cookie的觸發條件 (syn backlog長度). 降低系統對syn flood的敏感度, 使之可以容忍業務的syn波動.

有多個系統參數混合影響syn backlog長度, 參看【】

下圖為精華總結

請點擊輸入圖片描述

怎麼用druid連接池連接mysql

現在常用的開源數據庫連接池主要有c3p0、dbcp、proxool三種，其中：

Spring 推薦使用dbcp；

Hibernate 推薦使用c3p0和proxool；

1、 DBCP：apache

DBCP(DataBase connection pool)數據庫連接池。是apache上的一個 java連接池項目，也是 tomcat使用的連接池組件。單獨使用dbcp需要3個包：common-dbcp.jar,common-pool.jar,common-collections.jar由於建立數據庫連接是一個非常耗時耗資源的行為，所以通過連接池預先同數據庫建立一些連接，放在內存中，應用程序需要建立數據庫連接時直接到連接池中申請一個就行，用完後再放回去。dbcp沒有自動的去回收空閑連接的功能。

2、 C3P0：

C3P0是一個開源的jdbc連接池，它實現了數據源和jndi綁定，支持jdbc3規範和jdbc2的標準擴展。c3p0是異步操作的，緩慢的jdbc操作通過幫助進程完成。擴展這些操作可以有效的提升性能。目前使用它的開源項目有Hibernate，Spring等。c3p0有自動回收空閑連接功能。

3、 Proxool：Sourceforge

Proxool是一種Java數據庫連接池技術。是sourceforge下的一個開源項目,這個項目提供一個健壯、易用的連接池，最為關鍵的是這個連接池提供監控的功能，方便易用，便於發現連接泄漏的情況。

對比：

1 相同時間內同等量的線程數和循環次數下:通過對三個連接池的三個標誌性性能測試參數（Average,median,90%Line）進行比較發現：性能dbcp=c3p0proxool；

2 不同情況下的同一數據庫連接池測試：通過觀察 Average,median,90%Line三個參數發

現三個連接池的穩定性（三種連接池的三個測試參數的變化情況）依次：穩定性dbcp=c3p0proxool。

結論：

通過對三種數據庫連接池的性能測試發現，proxool和 c3p0能夠更好的支持高並發，但是在穩定性方面略遜於 dpcp；

MySQL與Redis數據庫連接池介紹（圖示+源碼+代碼演示）

數據庫連接池（Connection pooling）是程序啟動時建立足夠的數據庫連接，並將這些連接組成一個連接池，由程序動態地對池中的連接進行申請，使用，釋放。

簡單的說：創建數據庫連接是一個很耗時的操作，也容易對數據庫造成安全隱患。所以，在程序初始化的時候，集中創建多個數據庫連接，並把他們集中管理，供程序使用，可以保證較快的數據庫讀寫速度，還更加安全可靠。

不使用數據庫連接池

如果不使用數據庫連接池，對於每一次SQL操作，都要走一遍下面完整的流程：

1.TCP建立連接的三次握手（客戶端與 MySQL服務器的連接基於TCP協議）

2.MySQL認證的三次我收

3.真正的SQL執行

4.MySQL的關閉

5.TCP的四次握手關閉

可以看出來，為了執行一條SQL，需要進行大量的初始化與關閉操作

使用數據庫連接池

如果使用數據庫連接池，那麼會 事先申請（初始化）好 相關的數據庫連接，然後在之後的SQL操作中會復用這些數據庫連接，操作結束之後數據庫也不會斷開連接，而是將數據庫對象放回到數據庫連接池中

資源重用：由於數據庫連接得到重用，避免了頻繁的創建、釋放連接引起的性能開銷，在減少系統消耗的基礎上，另一方面也增進了系統運行環境的平穩性（減少內存碎片以及數據庫臨時進程/線程的數量）。

更快的系統響應速度：數據庫連接池在初始化過程中，往往已經創建了若干數據庫連接置於池中備用。 此時連接的初始化工作均已完成。對於業務請求處理而言，直接利用現有可用連接，避免了從數據庫連接初始化和釋放過程的開銷，從而縮減了系統整體響應時間。

統一的連接管理，避免數據庫連接泄露：在較為完備的數據庫連接池實現中，可根據預先的連接佔用超時設定，強制收回被佔用連接。從而避免了常規數據庫連接操作中可能出現的資源泄露。

如果說你的服務器CPU是4核i7的，連接池大小應該為((4*2)+1)=9

相關視頻推薦

90分鐘搞懂數據庫連接池技術|linux後台開發

《tcp/ip詳解卷一》： 150行代碼拉開協議棧實現的篇章

學習地址：C/C++Linux服務器開發/後台架構師【零聲教育】-學習視頻教程-騰訊課堂

需要C/C++ Linux服務器架構師學習資料加qun 812855908 獲取（資料包括 C/C++，Linux，golang技術，Nginx，ZeroMQ，MySQL，Redis，fastdfs，MongoDB，ZK，流媒體，CDN，P2P，K8S，Docker，TCP/IP，協程，DPDK，ffmpeg 等），免費分享

源碼下載

下載方式：（Github中下載）

db_pool目錄下有兩個目錄，mysql_pool目錄為MySQL連接池代碼，redis_pool為redis連接池代碼

下面介紹mysql_pool

CDBConn解析

概念： 代表一個數據連接對象實例

相關成員：

m_pDBPool：該數據庫連接對象所屬的數據庫連接池

構造函數： 綁定自己所屬於哪個數據庫連接池

Init()函數： 創建數據庫連接句柄

CDBPool解析

概念：代表一個數據庫連接池

相關成員：

Init()函數：常見指定數量的數據庫實例句柄，然後添加到m_free_list中，供後面使用

GetDBConn()函數： 用於從空閑隊列中返回可以使用的數據庫連接句柄

RelDBConn()函數： 程序使用完該數據庫句柄之後，將句柄放回到空閑隊列中

測試之前，將代碼中的數據庫地址、端口、賬號密碼等改為自己的（代碼中有好幾處）

進入MySQL， 創建mysql_pool_test數據庫

進入到mysql_pool目錄下， 創建一個build目錄並進入 ：

然後輸入如下的命令進行編譯

之後就會在目錄下生成如下的可執行文件

輸入如下兩條命令進行測試： 可以看到不使用數據庫連接池，整個操作耗時4秒左右；使用連接池之後，整個操作耗時2秒左右，提升了一倍

源碼下載

下面介紹redis_pool

測試

進入到redis_pool目錄下， 創建一個build目錄並進入 ：

然後輸入如下的命令進行編譯

之後就會在目錄下生成如下的可執行文件

輸入如下的命令進行測試： 可以看到不使用數據庫連接池，整個操作耗時182ms；使用連接池之後，整個操作耗時21ms，提升了很多

進入redis，可以看到我們新建的key：