怎樣理解ShardingSphere

這篇文章給大家介紹怎樣理解ShardingSphere，內容非常詳細，感興趣的小伙伴們可以參考借鑒，希望對大家能有所幫助。

什么是數據庫分庫分表？

為了解決由于數據量過大而導致的數據庫性能降低的問題，將原來獨立的數據庫拆分成若干數據庫，把原來數據量大的表拆分成若干數據表，使得單一數據庫、單一數據表的數據量變得足夠小，從而達到提升數據庫性能的效果。

分庫分表的表現形式

分庫分表包括分庫和分表兩個維度，在開發過程中，對于每個維度都可以采用兩種拆分思路，即垂直拆分和水平拆分：

• 垂直分表的處理方式就是將一個表按照字段分成多張表，每個表存儲其中一部分字段。

• 垂直分庫是指按照業務將表進行分類，然后分布到不同的數據庫上。然后，每個庫可以位于不同的服務器上，其核心理念是專庫專用。從實現上講，垂直分庫很大程度上取決于業務的規劃和系統邊界的劃分。

• 水平分表是在同一個數據庫內，把同一個表的數據按一定規則拆到多個表中年。

• 水平分表是把同一個表的數據按一定規則拆分到不同的數據庫中，每個庫同樣可以位于不同的服務器上。

讀寫分離

讀寫分離這個技術與數據庫主從架構有關。

可以看到圖中的數據庫集群中存在一個主庫，也存在一個從庫，主庫和從庫之間通過同步機制實現兩者數據的一致性。在互聯網系統中，普遍認為對數據庫讀操作的頻率要遠遠高于寫操作，所以瓶頸往往出現在讀操作上。通過讀寫分離，就可以把讀操作分離出來，在獨立的從庫上進行。現實中的主從架構，主庫和從庫的數量，尤其從庫的數量都是可以根據數據量的大小進行擴充的。

讀寫分離主要解決的就是高并發下的數據庫訪問，也是一種常用的解決方案。 但是跟提升服務器配置一樣，并不是終極解決方案。終極的解決方案還是前面介紹的分庫分表，按照用戶ID等規則來拆分庫或拆分表。但是，分庫分表與讀寫分離之間的關系并不是互斥的，而是可以相輔相成的，完全可以在分庫分表的基礎上引入讀寫分離機制。

分庫分表解決方案和代表框架

基于前面關于分庫分表的討論，我們可以抽象其背后的一個核心概念，即分片(Sharding)。無論是分庫還是分表，都是把數據劃分成不同的數據片，并存儲在不同的目標對象中。而具體的分片方式涉及實現分庫分表的不同解決方案。

業界實際上也有不少關于分庫分表的框架，這些框架顯然并不是采用同一種解決方案。但通過分析這些框架在實現數據分片方案上的區別，也可以把它們分成三大類型，即客戶端分片、代理服務器分片以及分布式數據庫。

客戶端分片

所謂客戶端分片，相當于在數據庫的客戶端就實現了分片規則。顯然，這種方式將分片處理的工作進行前置，客戶端管理和維護這所有的分片邏輯，并決定每次SQL執行所對應的目標數據庫和數據表。

客戶端分片這一解決方案也有不同的表現形式，其中最為簡單的方式就是應用層分片，也就是說在應用程序中直接維護者分片規則和分片邏輯：

在具體實現上，我們通常會將分片規則的處理邏輯打包成一個公共 JAR 包，其他業務開發人員只需要在代碼工程中引入這個 JAR 包即可。針對這種方案，因為沒有獨立的服務器組件，所以也不需要專門維護某一個具體的中間件。然而，這種直接在業務代碼中嵌入分片組件的方法也有明顯的缺點：

• 一方面，由于分片邏輯侵入到了業務代碼中，業務開發人員在理解業務的基礎上還需要掌握分片規則的處理方式，增加了開發和維護成本；

• 另一方面，一旦出現問題，也只能依賴業務開發人員通過分析代碼來找到原因，而無法把這部分工作抽離出來讓專門的中間件團隊進行完成。

基于以上分析，客戶端分片在實現上通常會進一步抽象，把分片規則的管理工作從業務代碼中剝離出來，形成單獨演進的一套體系。這方面典型的設計思路是重寫 JDBC 協議，也就是說在 JDBC 協議層面嵌入分片規則。這樣，業務開發人員還是使用與 JDBC 規范完全兼容的一套 API 來操作數據庫，但這套 API 的背后卻自動完成了分片操作，從而實現了對業務代碼的零侵入：

客戶端分片結構：重寫JDBC協議

這種解決方案的優勢在于，分片操作對于業務而言是完全透明的，從而一定程度上實現業務開發人員與數據庫中間件團隊在職責上的分離。這樣，業務開發人員只需要理解 JDBC 規范就可以完成分庫分表，開發難度以及代碼維護成本得到降低。

對于客戶端分片，典型的中間件包括阿里巴巴的 TDDL 以及本課程將要介紹的 ShardingSphere。因為 TDDL 并沒有開源，所以無法判斷客戶端分片的具體實現方案。而對于 ShardingSphere 而言，它是重寫 JDBC 規范以實現客戶端分片的典型實現框架。

代理服務器分片

代理服務器分片的解決方案也比較明確，也就是采用了代理機制，在應用層和數據庫層之間添加一個代理層。有了代理層之后，就可以把分片規則集中維護在這個代理層中，并對外提供與 JDBC 兼容的 API 給到應用層。這樣，應用層的業務開發人員就不用關心具體的分片規則，而只需要完成業務邏輯的實現：

顯然，代理服務器分片的優點在于解放了業務開發人員對分片規則的管理工作，而缺點就是添加了一層代理層，所以天生具有代理機制所帶來的一些問題，比方說因為新增了一層網絡傳輸對性能所產生的影響。

對于代理服務器分片，常見的開源框架有阿里的 Cobar 以及民間開源社區的 MyCat。而在 ShardingSphere 3.X 版本中，也添加了 Sharding-Proxy 模塊來實現代理服務器分片。

分布式數據庫

以 TiDB 為代表的分布式數據庫的興起賦予了關系型數據庫一定程度的分布式特性。在這些分布式數據庫中，數據分片及分布式事務將是其內置的基礎功能，對業務開發人員是透明的。業務開發人員只需要使用框架對外提供的 JDBC 接口，就像在使用 MySQL 等傳統關系型數據庫一樣。

從這個角度講，我們也可以認為 ShardingSphere 是一種分布式數據庫中間件，它在提供標準化的數據分片解決方案之外，也實現了分布式事務和數據庫治理功能。

分庫分表帶來的問題

• 事務一致性問題：由于分庫分表把數據分布在不同庫甚至不同服務器，不可避免會帶來分布式事務問題。

• 跨節點關聯查詢

• 跨節點分頁、排序函數

• 主鍵避重

• 公共表

關于怎樣理解ShardingSphere就分享到這里了，希望以上內容可以對大家有一定的幫助，可以學到更多知識。如果覺得文章不錯，可以把它分享出去讓更多的人看到。