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

數據庫連接池就是一個池子，里面放著數據庫連接，應用服務需要的時候就去池子里面拿，用完之后歸還給池子。數據庫連接池負責分配、管理、釋放數據庫連接，它允許應用服務重復使用數據庫連接，而非重新建立。數據庫的連接創(chuàng)建和關閉連接均由連接池來實現。

應用訪問時，首先查看連接池中是否有空閑連接，如果存在空閑連接，則將連接分配給客戶使用；如果沒有空閑連接，則查看當前所開的連接數是否已經達到最大連接數，如果沒達到就重新創(chuàng)建一個連接給請求的客戶；如果達到就按設定的最大等待時間進行等待，如果超出最大等待時間，則拋出異常給客戶。當客戶釋放數據庫連接時，先判斷該連接的引用次數是否超過了規(guī)定值，如果超過就從連接池中刪除該連接，否則保留等待再次使用。

如果不使用數據庫連接池，進行一次查詢，要進行很多次網絡交互，可以看到，這樣的缺點是：

使用連接池的好處：

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

關于HikariCP和druid的性能對比，在github/HikariCP上有過討論，結果是HikariCP性能上優(yōu)于druid，吃瓜地址：

https://github.com/brettwooldridge/HikariCP/issues/232

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

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

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

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

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

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

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

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

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

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

也就是在數據庫連接中斷的情況下，HikariCP在5秒內就可以感知，并在最短時間內通知上層應用。這個響應夠快，夠及時。實際測試中，就是拔網線，等半分鐘再插上，看誰最先恢復數據庫連接。HikariCP 又勝出。

金笛短信中間件WEB版集成光速數據庫連接池，在各種數據庫環(huán)境下表現異常穩(wěn)定。有的客戶在局域網連接阿里云主機數據庫因為不明原因，間歇性斷網的情況，也沒有影響短信發(fā)送。實測支持SQLServer、Oracle、MySQL，支持神舟通用、人大金倉、南大通用等國產化數據庫，支持win和linux各個版本。