Java資料庫連線池幾種方式及其特點
- 主流的資料庫連線池
在目前技術前沿比較流行的資料庫連線池有：DBCP、Tomcat Jdbc Pool、BoneCP、Druid、C3P0等 - DBCP：由Apache開發的一個Java資料庫連線池專案， Jakarta commons-pool物件池機制，Tomcat使用的連線池元件就是DBCP。單獨使用dbcp需要3個包：common-dbcp.jar,common-pool.jar,common-collections.jar，預先將資料庫連線放在記憶體中，應用程式需要建立資料庫連線時直接到連線池中申請一個就行，用完再放回。單執行緒，併發量低，效能不好，適用於小型系統。
- Tomcat Jdbc Pool：Tomcat在7.0以前都是使用common-dbcp做為連線池元件，但是dbcp是單執行緒，為保證執行緒安全會鎖整個連線池，效能較差，dbcp有超過60個類，也相對複雜。Tomcat從7.0開始引入了新增連線池模組叫做Tomcat jdbc pool，基於Tomcat JULI，使用Tomcat日誌框架，完全相容dbcp，通過非同步方式獲取連線，支援高併發應用環境，超級簡單核心檔案只有8個，支援JMX，支援XA Connection。
- BoneCP：官方說法BoneCP是一個高效、免費、開源的Java資料庫連線池實現庫。設計初衷就是為了提高資料庫連線池效能，根據某些測試資料顯示，BoneCP的速度是最快的，要比當時第二快速的連線池快25倍左右，完美整合到一些持久化產品如Hibernate和DataNucleus中。BoneCP特色：高度可擴充套件，快速；連線狀態切換的回撥機制；允許直接訪問連線；自動化重置能力；JMX支援；懶載入能力；支援XML和屬性檔案配置方式；較好的Java程式碼組織，100%單元測試分支程式碼覆蓋率；程式碼40KB左右。
- Druid：Druid是Java語言中最好的資料庫連線池，Druid能夠提供強大的監控和擴充套件功能，是一個可用於大資料實時查詢和分析的高容錯、高效能的開源分散式系統，尤其是當發生程式碼部署、機器故障以及其他產品系統遇到宕機等情況時，Druid仍能夠保持100%正常執行。主要特色：為分析監控設計；快速的互動式查詢；高可用；可擴充套件；Druid是一個開源專案，原始碼託管在github上。
- C3p0：開源的JDBC連線池，實現了資料來源和JNDI繫結，支援JDBC3規範和JDBC2的標準擴充套件。目前使用它的開源專案有Hibernate、Spring等。單執行緒，效能較差，適用於小型系統，程式碼600KB左右。
- 他們之間的對比
- 再看一組有HikariCP的：
- HikariCP效能分析
1.HikariCP通過優化(concurrentBag，fastStatementList )集合來提高併發的讀寫效率。
2.HikariCP使用threadlocal快取連線及大量使用CAS的機制，最大限度的避免lock。單可能帶來cpu使用率的上升。
3.從位元組碼的維度優化程式碼。 (default inline threshold for a JVM running the server Hotspot compiler is 35 bytecodes ）讓方法儘量在35個位元組碼一下，來提升jvm的處理效率。 - 比HikariCP更快的資料庫連線池:
一個同事告訴我，比hikari還快的連線池他也用過、研究過 https://github.com/mauricio/postgresql-async 這是scala生態圈的東西。用netty實現了mysql協議，沒用mysql官方的connector，純非同步的，它的連線池是寫的比較隨便，但是效能依然很好。 - 從Sharding-jdbc架構演進看未來:
Database Mesh，一個搭乘 Service Mesh 浪潮衍生出來的新興詞彙。顧名思義，Database Mesh 使用一個齧合層，將散落在系統各個角落中的資料庫統一治理起來。通過齧合層集中在一起的應用與資料庫之間的互動網路，就像蜘蛛網一樣複雜而有序。它的首要目標並非齧合儲存於資料庫中的資料，而是齧合應用與資料庫間的互動。
Database Mesh 的關注重點在於如何將分散式的資料訪問應用與資料庫有機串聯起來，它更加關注的是互動，是將雜亂無章的應用與資料庫之間的互動有效的梳理。
使用 Database Mesh，訪問資料庫的應用和資料庫終將形成一個巨大的網格體系，應用和資料庫只需在網格體系中對號入座即可，它們都是被齧合層所治理的物件。
Sharding-JDBC 一直以來，以 JDBC 層分片作為其核心理念。它的架構圖如下： 
Sharding-JDBC 將分別實現 Driver、Server 以及 Sidecar 這三個不同的版本，一起組成 Sharding-JDBC 的生態圈，為不同的需求與環境提供更加具有針對性的差異化服務。 
由於 Sharding-JDBC-Server 的出現，使得原來 DBA 通過 Sharding-JDBC-Driver 無法對資料進行操作的缺憾得到了補償。由於 Sharding-JDBC-Driver 無需通過代理層進行二次轉發，因此線上效能更佳，可以通過以下的混合部署方案使用 Sharding-JDBC：
線上應用使用 Sharding-JDBC-Driver 直連資料庫以獲取最優效能，使用 MySQL 命令列或 UI 客戶端連線 Sharding-JDBC-Server 方便的查詢資料和執行各種 DDL 語句。它們使用同一個註冊中心叢集，通過管理端配置註冊中心中的資料，即可由註冊中心自動將配置變更推送至 Driver 和 Server 應用。若資料庫拆分的過多而導致連線數會暴漲，則可以考慮直接在線上使用 Sharding-JDBC-Server，以達到有效控制連線數的目的。
在不久的將來，Sharding-JDBC-Sidecar 也將問世，它的部署架構是這樣的： 
基於 Sharding-JDBC 的 Database Mesh 與 Service Mesh 互不干擾，相得益彰。服務之間的互動由 Service Mesh Sidecar 接管，基於 SQL 的資料庫訪問由 Sharding-JDBC-Sidecar 接管。
對於業務應用來說，無論是 RPC 還是對資料庫的訪問，都無需關注其真實的物理部署結構，做到真正的零侵入。由於 Sharding-JDBC-Sidecar 是隨著宿主機的生命週期建立和消亡的，
因此，它並非靜態 IP，而是完全動態和彈性的存在，整個系統中並無任何中心節點的存在。對於資料運維等操作，仍然可以通過啟動一個 Sharding-JDBC-Server 的程序作為靜態 IP 的入口，通過各種命令列或 UI 客戶端進行操作。