共計 3102 個字符，預計需要花費 8 分鐘才能閱讀完成。

行業資訊    
數據庫    
DB 分庫分表中關于使用框架還是自主開發以及 sharding 實現層面的考量是怎樣的

這篇文章將為大家詳細講解有關 DB 分庫分表中關于使用框架還是自主開發以及 sharding 實現層面的考量是怎樣的，文章內容質量較高，因此丸趣 TV 小編分享給大家做個參考，希望大家閱讀完這篇文章后對相關知識有一定的了解。

當團隊對系統業務和數據庫進行了細致的梳理，確定了切分方案后，接下來的問題就是如何去實現切分方案了，目前在 sharding 方面有不少的開源框架和產品可供參考，同時很多團隊也會選擇自主開發實現，而不管是選擇框架還是自主開發，都會面臨一個在哪一層上實現 sharding 邏輯的問題，丸趣 TV 小編會對這一系列的問題逐一進行分析和考量。

一、sharding 邏輯的實現層面

從一個系統的程序架構層面來看，sharding 邏輯可以在 DAO 層、JDBC  API 層、介于 DAO 與 JDBC 之間的 Spring 數據訪問封裝層 (各種 spring 的 template) 以及介于應用服務器與數據庫之間的 sharding 代理服務器四個層面上實現。

圖 1. Sharding 實現層面與相關框架 / 產品

在 DAO 層實現

當團隊決定自行實現 sharding 的時候，DAO 層可能是嵌入 sharding 邏輯的 *** 位置，因為在這個層面上，每一個 DAO 的方法都明確地知道需要訪問的數據表以及查詢參數，借助這些信息可以直接定位到目標 shard 上，而不必像框架那樣需要對 SQL 進行解析然后再依據配置的規則進行路由。另一個優勢是不會受 ORM 框架的制約。由于現在的大多數應用在數據訪問層上會依賴某種 ORM 框架，而多數的 shrading 框架往往無法支持或只能支持一種 orm 框架，這使得在選擇和應用框架時受到了很大的制約，而自行實現 sharding 完全沒有這方面的問題，甚至不同的 shard 使用不同的 orm 框架都可以在一起協調工作。比如現在的 java 應用大多使用 hibernate，但是當下還沒有非常令人滿意的基于 hibernate 的 sharding 框架，(關于 hibernate  hards 會在下文介紹)，因此很多團隊會選擇自行實現 sharding。

簡單總結一下，在 DAO 層自行實現 sharding 的優勢在于：不受 ORM 框架的制約、實現起來較為簡單、易于根據系統特點進行靈活的定制、無需 SQL 解析和路由規則匹配，性能上表現會稍好一些; 劣勢在于：有一定的技術門檻，工作量比依靠框架實現要大(反過來看，框架會有學習成本)、不通用，只能在特定系統里工作。當然，在 DAO 層同樣可以通過 XML 配置或是注解將 sharding 邏輯抽離到“外部”，形成一套通用的框架.   不過目前還沒有出現此類的框架。

在 ORM 框架層實現

在 ORM 框架層實現 sharding 有兩個方向，一個是在實現 O -R  Mapping 的前提下同時提供 sharding 支持，從而定位為一種分布式的數據訪問框架，這一類類型的框架代表就是 guzz 另一個方向是通過對既有 ORM 框架進行修改增強來加入 sharding 機制。此類型的代表產品是 hibernate  shard.   應該說以 hibernate 這樣主流的地位，行業對于一款面向 hibernate 的 sharding 框架的需求是非常迫切的，但是就目前的 hibernate  shards 來看，表現還算不上令人滿意，主要是它對使用 hibernate 的限制過多，比如它對 HQL 的支持就非常有限。在 mybatis 方面，目前還沒有成熟的相關框架產生。有人提出利用 mybatis 的插件機制實現 sharding, 但是遺憾的是，mybatis 的插件機制控制不到多數據源的連接層面，另一方面，離開插件層又失去了對 sql 進行集中解析和路由的機會，因此在 mybatis 框架上，目前還沒有可供借鑒的框架，團隊可能要在 DAO 層或 Spring 模板類上下功夫了。

在 JDBC API 層實現

JDBC API 層是很多人都會想到的一個實現 sharding 的 *** 場所，如果我們能提供一個實現了 sharding 邏輯的 JDBC  API 實現，那么 sharding 對于整個應用程序來說就是完全透明的，而這樣的實現可以直接作為通用的 sharding 產品了。但是這種方案的技術門檻和工作量顯然不是一般團隊能做得來的，因此基本上沒有團隊會在這一層面上實現 sharding, 甚至也沒有此類的開源產品。筆者知道的只有一款商業產品 dbShards 采用的是這一方案。

在介于 DAO 與 JDBC 之間的 Spring 數據訪問封裝層實現

在 springd 大行其道的今天，幾乎沒有哪個 java 平臺上構建的應用不使用 spring，在 DAO 與 JDBC 之間，spring 提供了各種 template 來管理資源的創建與釋放以及與事務的同步，大多數基于 spring 的應用都會使用 template 類做為數據訪問的入口，這給了我們另一個嵌入 sharding 邏輯的機會，就是通過提供一個嵌入了 sharding 邏輯的 template 類來完成 sharding 工作. 這一方案在效果上與基于 JDBC  API 實現的方案基本一致，同樣是對上層代碼透明，在進行 sharding 改造時可以平滑地過度，但它的實現卻比基于 JDBC  API 的方式簡單，因此成為了不少框架的選擇，阿里集團研究院開源的 Cobar Client 就是這類方案的一種實現。

在應用服務器與數據庫之間通過代理實現

在應用服務器與數據庫之間加入一個代理，應用程序向數據發出的數據請求會先通過代理，代理會根據配置的路由規則，對 SQL 進行解析后路由到目標 shard，因為這種方案對應用程序完全透明，通用性好，所以成為了很多 sharding 產品的選擇。在這方面較為知名的產品是 mysql 官方的代理工具：Mysql  Proxy 和一款國人開發的產品:amoeba。mysql  proxy 本身并沒有實現任何 sharding 邏輯，它只是作為一種面向 mysql 數據庫的代理，給開發人員提供了一個嵌入 sharding 邏輯的場所，它使用 lua 作為編程語言，這對很多團隊來說是需要考慮的一個問題。amoeba 則是專門實現讀寫分離與 sharding 的代理產品，它使用非常簡單，不使用任何編程語言，只需要通過 xml 進行配置。不過 amoeba 不支持事務 (從應用程序發出的包含事務信息的請求到達 amoeba 時，事務信息會被抹去，因此，即使是單點數據訪問也不會有事務存在) 一直是個硬傷。當然，這要看產品的定位和設計理念，我們只能說對于那些對事務要求非常高的系統，amoeba 是不適合的。

二、使用框架還是自主開發?

前面的討論中已經羅列了很多開源框架與產品，這里再整理一下：基于代理方式的有 MySQL  Proxy 和 Amoeba，基于 Hibernate 框架的是 Hibernate Shards，通過重寫 spring 的 ibatis template 類是 Cobar  Client，這些框架各有各的優勢與短板，架構師可以在深入調研之后結合項目的實際情況進行選擇，但是總的來說，我個人對于框架的選擇是持謹慎態度的。一方面多數框架缺乏成功案例的驗證，其成熟性與穩定性值得懷疑。另一方面，一些從成功商業產品開源出框架 (如阿里和淘寶的一些開源項目) 是否適合你的項目是需要架構師深入調研分析的。當然，最終的選擇一定是基于項目特點、團隊狀況、技術門檻和學習成本等綜合因素考量確定的。

關于 DB 分庫分表中關于使用框架還是自主開發以及 sharding 實現層面的考量是怎樣的就分享到這里了，希望以上內容可以對大家有一定的幫助，可以學到更多知識。如果覺得文章不錯，可以把它分享出去讓更多的人看到。