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

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

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

1. 網絡IO多

2. 響應時間長，導致QPS降低

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

使用連接池的好處：

1. 減少網絡開銷

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

金笛短信中間件對連接池有2個要求：一要快，二要穩(wěn)。目前，流行的Java數(shù)據庫連接池有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 脫穎而出，符合金笛短信中間件短信要求既要快，又要穩(wěn)的要求。短信從提取到發(fā)送，在數(shù)據庫這個環(huán)節(jié)，把時間壓縮到毫秒內，只有短信發(fā)送的每個環(huán)節(jié)都榨干，才能保證最終短信發(fā)送秒到。

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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