一、Sharding-JDBC 採用在 JDBC 層擴充套件分庫分表，支援讀寫分離，是一個以 jar 形式提供服務的輕量級元件，其核心思路是小而美地完成最核心的事情，基於 JDBC 層進行分片的好處是輕量、簡單、相容性好以及無需額外的運維工作。缺點是無法跨語言，目前僅支援 Java

二、Sharding-JDBC 適用於哪些場景，不適用於哪些場景？是否有效能評估？

（1）適合場景：

對於關係型資料庫資料量很大的情況，需要進行水平拆庫和拆表（即分庫和分表），這種場景很適合使用 Sharding-JDBC。

舉例說明：假設有一億資料的使用者庫，放在 MySQL 資料庫裡查詢效能會比較低，而採用水平拆庫，將其分為 10 個庫，根據使用者的 ID 模10，這樣資料就能比較平均的分在 10 個庫中，每個庫只有 1000w 記錄，查詢效能會大大提升。分片策略型別非常多，大致分為 Hash +Mod、Range、Tag 等。

Sharding-JDBC 還提供了讀寫分離的能力，用於減輕寫庫的壓力。

此外，Sharding-JDBC 可以用在 JPA 場景中，如 JPA、Hibernate、Mybatis，Spring JDBC Template 等任何 Java 的 ORM 框架。Java 的 ORM 框架也都是採用 JDBC 與資料庫互動。這也是我們選擇在 JDBC 層，而非選擇一個 ORM 框架進行開發的原因。我們希望 Sharding-JDBC 可以儘量的相容所有的 Java 資料庫訪問層，並且無縫的接入業務應用。

（2）不合適的場景主要是兩方面：

（2.1）不適合 OLAP 的場景。雖然 Sharding-JDBC 也能做聚合分組查詢，但大量的 OLAP 場景，仍然會比較慢，而且複雜的SQL（如子查詢等）目前還沒有支援。這種查詢不太適合大資料和高併發的網際網路 online 資料庫，建議使用合理的 OLTP 查詢。

（2.2）不適合事務強一致的要求。目前 Sharding-JDBC 的事務支援兩種，一種是弱 XA，另一種是柔性事務（BASE）。因為 XA的兩階段或三階段提交其效能較低，因此網際網路公司基本不會採用。而無論是弱 XA還是柔性事務，都無法保證事務在任意時間段完全保證一致，其中柔性事務能保證資料的最終一致性，但達到最終一致性的時間仍然不可控。因此對於對跨庫事務強一致要求很高的場景，需要從設計方面去考慮資料庫schema 的合理性。

對於 JTA 事務，目前 Shariding-JDBC 沒有實現 JTA 的標準。而且由於在網際網路場景下使用 JTA 比較少見，因此暫時不支援 JTA 事務。

（3）效能測試報告如下：

（3.1）使用Sharding-JDBC，效能是大家最關心的問題。在資料量一致的情況下，使用Sharding-JDBC和原生JDBC的效能測試報告如下：

查詢操作：Sharding-JDBC的TPS為JDBC的TPS的99.8%。

插入操作：Sharding-JDBC的TPS為JDBC的TPS的90.2%。

更新操作：Sharding-JDBC的TPS為JDBC的TPS的93.1%。

可以看到，Sharding-JDBC在查詢中的效能損失非常低，插入和更新略高。

（3.2）將單表的資料拆分為二，放入兩個表中，使用Sharding-JDBC和原生JDBC的效能測試報告如下：

查詢操作：TPS雙庫比單庫可以增加大約94%的效能。

插入操作：TPS雙庫比單庫可以增加大約60%的效能。

更新操作：TPS雙庫比單庫可以增加大約89%的效能。

結果表明，Sharding-JDBC可有效利用水平擴充套件大幅度提升效能。

三、sharding-jdbc架構圖

四、sharding-jdbc與mycat 相似性以及區別

從設計理念上看確實有一定的相似性。主要流程都是SQL 解析 -> SQL 路由 -> SQL 改寫 -> SQL 執行 -> 結果歸併。但架構設計上是不同的。Mycat 是基於 Proxy，它複寫了 MySQL 協議，將 Mycat Server 偽裝成一個 MySQL 資料庫，而 Sharding-JDBC 是基於 JDBC 的擴充套件，是以 jar 包的形式提供輕量級服務的。

五、sharding-jdbc支援讀寫分離

Sharding-JDBC 從 1.3.0 開始支援讀寫分離。其功能包括：

（5.1）根據配置區分寫庫和多個讀庫，目前暫時只有輪訓策略選取讀庫，可以配合分庫分表使用。

（5.2）通過 Hint 強制指定某次查詢走寫庫。

（5.3）如果在同一執行緒且同一資料庫連線中有發現 DML 語句，則該 DML 之後的查詢都從寫庫查詢，DML 之前的 DQL 語句不受影響，仍然查詢讀庫。其目的是保持同一使用者執行緒的資料一致性。

但限於 Sharding-JDBC 本身設計的考慮，資料庫層面的主從切換以及主從資料同步，Sharding-JDBC並不負責。Sharding-JDBC 定位仍然是輕量級的增強版資料庫驅動。因此由於主庫和從庫同步延遲導致的資料不一致，並不是Sharding-JDBC 的處理範疇。

六、sharding-jdbc 3.0版本：更名為sharding-sphere

Sharding-Sphere是一套開源的分散式資料庫中介軟體解決方案組成的生態圈，它由Sharding-JDBC、Sharding-Proxy和Sharding-Sidecar這3款相互獨立的產品組成，詳情請參考官網地址：http://shardingsphere.io/document/current/en/quick-start/。

（6.1） Sharding-JDBC

Sharding-JDBC是Sharding-Sphere的第一個產品，也是Sharding-Sphere的前身。

它定位為輕量級Java框架，在Java的JDBC層提供分庫分表、讀寫分離、資料庫治理、柔性事務等服務。它使用客戶端直連資料庫，以jar包形式提供服務，無需額外部署和依賴，可理解為增強版的JDBC驅動，完全相容JDBC和各種ORM框架。

（6.2） Sharding-Proxy

Sharding-Proxy是Sharding-Sphere的第二個產品。

它定位為透明化的資料庫代理端，提供封裝了資料庫二進位制協議的服務端版本，用於完成對異構語言的支援。

Sharding-Proxy遮蔽了底層的分庫分表，您可以像使用一個簡單的資料庫一樣來操作分庫分表的資料。目前提供MySQL版本，它可以使用任何相容MySQL協議的訪問客戶端(如：MySQL Command Client, MySQLWorkbench等)來訪問Sharding-Proxy，進而進行DDL/DML等操作來變更資料，對DBA更加友好。

七、目前分庫分表的中介軟體有兩種思想，分別是：

（7.1）類似 Sharding-JDBC 及 TDDL 的增強版 JDBC 驅動思想

（7.2）類似 Mycat 增加中間層，然後在中間層進行分庫分表思想

JDBC 驅動版的優點：

1、輕量，範圍更加容易界定，只是 JDBC 增強，不包括 HA、事務以及資料庫元資料管理

2、開發的工作量較小，無需關注 nio，各個資料庫協議等

3、運維無需改動，無需關注中介軟體本身的 HA

4、效能高，JDBC 直連資料庫，無需二次轉發

5、可支援各種基於 JDBC 協議的資料庫，如：MySQL，Oralce，SQLServer

Proxy 版的優點：

1、可以負責更多的內容，將資料遷移，分散式事務等納入 Proxy 的範疇

2、更有效的管理資料庫的連線

3、整合大資料思路，將 OLTP 和 OLAP 分離處理

因此兩種方式互相可以互補，建議使用 Java 的團隊，且僅 OLTP 的網際網路前端操作。有可能會使用多種資料庫的情況，可以選擇 JDBC層的中介軟體；如果需要 OLAP 和 OLTP 混合，加以重量級的操作，如資料遷移，分散式事務等，可以考慮 Proxy 層的中介軟體。

八、專案地址：

GitHub：https://github.com/shardingjdbc/sharding-jdbc

碼雲：https://gitee.com/shardingjdbc/sharding-jdbc