短信中間件核心在于中間層，把復(fù)雜的底層操作轉(zhuǎn)換為簡單、方便的數(shù)據(jù)庫操作。軟件設(shè)計(jì)為從客戶的數(shù)據(jù)庫自動定時(shí)提取數(shù)據(jù)發(fā)送。中間件需要和用戶的應(yīng)用程序共享使用數(shù)據(jù)庫，這就要求中間件訪問數(shù)據(jù)庫既要快，又不能影響數(shù)據(jù)庫的性能。數(shù)據(jù)庫連接池是必不可少的。

數(shù)據(jù)庫連接池就是一個(gè)池子，里面放著數(shù)據(jù)庫連接，應(yīng)用服務(wù)需要的時(shí)候就去池子里面拿，用完之后歸還給池子。數(shù)據(jù)庫連接池負(fù)責(zé)分配、管理、釋放數(shù)據(jù)庫連接，它允許應(yīng)用服務(wù)重復(fù)使用數(shù)據(jù)庫連接，而非重新建立。數(shù)據(jù)庫的連接創(chuàng)建和關(guān)閉連接均由連接池來實(shí)現(xiàn)。應(yīng)用訪問時(shí)，首先查看連接池中是否有空閑連接，如果存在空閑連接，則將連接分配給客戶使用；如果沒有空閑連接，則查看當(dāng)前所開的連接數(shù)是否已經(jīng)達(dá)到最大連接數(shù)，如果沒達(dá)到就重新創(chuàng)建一個(gè)連接給請求的客戶；如果達(dá)到就按設(shè)定的最大等待時(shí)間進(jìn)行等待，如果超出最大等待時(shí)間，則拋出異常給客戶。 當(dāng)客戶釋放數(shù)據(jù)庫連接時(shí)，先判斷該連接的引用次數(shù)是否超過了規(guī)定值，如果超過就從連接池中刪除該連接，否則保留等待再次使用。

如果不使用數(shù)據(jù)庫連接池，進(jìn)行一次查詢，要進(jìn)行很多次網(wǎng)絡(luò)交互，可以看到，這樣的缺點(diǎn)是：

1. 網(wǎng)絡(luò)IO多

2. 響應(yīng)時(shí)間長，導(dǎo)致QPS降低

3. 頻繁創(chuàng)建連接和關(guān)閉連接，浪費(fèi)數(shù)據(jù)庫資源，影響服務(wù)器性能

使用連接池的好處：

1. 減少網(wǎng)絡(luò)開銷

2. 提升數(shù)據(jù)庫性能

金笛短信中間件對連接池有2個(gè)要求：一要快，二要穩(wěn)。目前，流行的Java數(shù)據(jù)庫連接池有dbcp，druid，HikariCP，tomcat-jdbc，c3p0。在對所有流行的連接池進(jìn)行逐一比較之后，單從性能角度看，性能從高到低分別是：HikariCP，druid，tomcat-jdbc，dbcp，c3p0 。

關(guān)于HikariCP和druid的性能對比，在github/HikariCP上有過討論，結(jié)果是HikariCP性能上優(yōu)于druid，吃瓜地址：https://github.com/brettwooldridge/HikariCP/issues/232

HikariCP 脫穎而出，符合金笛短信中間件短信要求既要快，又要穩(wěn)的要求。短信從提取到發(fā)送，在數(shù)據(jù)庫這個(gè)環(huán)節(jié)，把時(shí)間壓縮到毫秒內(nèi)，只有短信發(fā)送的每個(gè)環(huán)節(jié)都榨干，才能保證最終短信發(fā)送秒到。

各種評測對比，也說明HikariCP是目前最快的Java數(shù)據(jù)庫連接池，spring boot 2.x已經(jīng)使用HikariCP作為默認(rèn)的數(shù)據(jù)庫連接池，足見其優(yōu)秀。總代碼量：代碼體積更是少的可憐，130kb。代碼量越少，一般意味著執(zhí)行效率越高、發(fā)生bug的可能性越低。簡單意味著可靠，好維護(hù)，兼容性好。

數(shù)據(jù)庫連接池，在20年以前就有。經(jīng)過20年的進(jìn)化，已經(jīng)非常犀利。日本人素來以工匠精神著稱，一個(gè)人一輩子就做好一件事。HikariCP是日本人在boneCP基礎(chǔ)上，把優(yōu)化做到了極致：為什么這么說呢?

1. 優(yōu)化并精簡字節(jié)碼，優(yōu)化代碼，直到編譯后的字節(jié)碼最少，這樣，CPU緩存可以加載更多的程序代碼。使用Java字節(jié)碼修改類庫Javassist來生成委托實(shí)現(xiàn)動態(tài)代理，JDK Proxy生成的字節(jié)碼更少。例如HikariCP的Statement proxy只有100行代碼，只有BoneCP的十分之一，對編譯器不滿意，就差重寫java編譯器了。

2. 定義集合類型（ConcurrentBag）：提高并發(fā)讀寫的效率。

3. 自定義數(shù)組類型（FastStatementList）代替ArrayList：避免每次get()調(diào)用都要進(jìn)行range check，避免調(diào)用remove()時(shí)的從頭到尾的掃描。

4. 其他針對BoneCP缺陷的優(yōu)化，比如對于耗時(shí)超過一個(gè)CPU時(shí)間片的優(yōu)化。

光速，每秒30萬公里。沒有比光速更快的了。HikariCP ，就是光速。

本著geek精神，在可靠性方面，繼續(xù)研究。對于數(shù)據(jù)庫連接中斷的情況，通過測試getConnection()，各種CP的不相同處理方法如下：

（所有CP都配置了跟connectionTimeout類似的參數(shù)為5秒鐘）

HikariCP：等待5秒鐘后，如果連接還是沒有恢復(fù)，則拋出一個(gè)SQLExceptions 異常；后續(xù)的getConnection()也是一樣處理；

C3P0：完全沒有反應(yīng)，沒有提示，也不會在“CheckoutTimeout”配置的時(shí)長超時(shí)后有任何通知給調(diào)用者；然后等待2分鐘后終于醒來了，返回一個(gè)error；

Tomcat：返回一個(gè)connection，然后……調(diào)用者如果利用這個(gè)無效的connection執(zhí)行SQL語句……結(jié)果可想而知；大約55秒之后終于醒來了，這時(shí)候的getConnection()終于可以返回一個(gè)error，但沒有等待參數(shù)配置的5秒鐘，而是立即返回error；

BoneCP：跟Tomcat的處理方法一樣；也是大約55秒之后才醒來，有了正常的反應(yīng)，并且終于會等待5秒鐘之后返回error了；

也就是在數(shù)據(jù)庫連接中斷的情況下，HikariCP在5秒內(nèi)就可以感知，并在最短時(shí)間內(nèi)通知上層應(yīng)用。這個(gè)響應(yīng)夠快，夠及時(shí)。實(shí)際測試中，就是拔網(wǎng)線，等半分鐘再插上，看誰最先恢復(fù)數(shù)據(jù)庫連接。HikariCP 又勝出。

金笛短信中間件WEB版集成光速數(shù)據(jù)庫連接池，在各種數(shù)據(jù)庫環(huán)境下表現(xiàn)異常穩(wěn)定。有的客戶在局域網(wǎng)連接阿里云主機(jī)數(shù)據(jù)庫因?yàn)椴幻髟颍g歇性斷網(wǎng)的情況，也沒有影響短信發(fā)送。實(shí)測支持SQLServer、Oracle、MySQL，支持win和linux各個(gè)版本。