怎樣理解ShardingSphere

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

什么是數(shù)據(jù)庫分庫分表？

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

分庫分表的表現(xiàn)形式

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

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

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

• 水平分表是在同一個數(shù)據(jù)庫內(nèi)，把同一個表的數(shù)據(jù)按一定規(guī)則拆到多個表中年。

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

讀寫分離

讀寫分離這個技術(shù)與數(shù)據(jù)庫主從架構(gòu)有關(guān)。

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

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

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

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

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

客戶端分片

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

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

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

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

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

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

客戶端分片結(jié)構(gòu)：重寫JDBC協(xié)議

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

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

代理服務器分片

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

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

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

分布式數(shù)據(jù)庫

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

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

分庫分表帶來的問題

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

• 跨節(jié)點關(guān)聯(lián)查詢

• 跨節(jié)點分頁、排序函數(shù)

• 主鍵避重

• 公共表

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