分庫分表中間件常見方案對比分析

點(diǎn)擊上方藍(lán)色字體，選擇“標(biāo)星公眾號”

優(yōu)質(zhì)文章，第一時間送達(dá)

76套java從入門到精通實(shí)戰(zhàn)課程分享

1.為什么需要分庫分庫分表?

1.1 數(shù)據(jù)庫性能瓶頸的出現(xiàn)

最直觀的表現(xiàn)就是對數(shù)據(jù)庫的各種操作變慢,在高并發(fā)的場景下出現(xiàn)應(yīng)用無法獲取數(shù)據(jù)庫連接,

1.2 數(shù)據(jù)庫優(yōu)化方案對比

1.2.1 SQL 與索引

在程序中對 SQL 語句進(jìn)行優(yōu)化，在數(shù)據(jù)庫中添加索引。

這個是我們這邊最常用的手段，也是成本低，效果明顯的手段，但是過多的索引也會帶來一些問題，不可盲目添加。個人理解是需要建立收益大的索引，建立最優(yōu)的索引，一個索引可以對多個sql起作用，同時命中后對有效的減小數(shù)據(jù)集，所以建立索引也是一個值得探討問題。

1.2.2 引擎和配置層面優(yōu)化

• 選用特定的存儲引擎，或者對表進(jìn)行分區(qū)，對表結(jié)構(gòu)進(jìn)行拆分或者冗余處理，

或者對表結(jié)構(gòu)比如字段的定義進(jìn)行優(yōu)化。

• 數(shù)據(jù)庫配置的優(yōu)化，比如連接數(shù)，緩沖區(qū)大小等等，優(yōu)化配置的目的都是為了更高效地利用硬件。

1.2.3 操作系統(tǒng)與硬件

操作系統(tǒng)和硬件的優(yōu)化,增加cpu,增加內(nèi)存。

是否需要提升硬件，需要視情況而定，主要看導(dǎo)致數(shù)據(jù)庫慢的原因是什么，盲目的疊加配置是不可取的。

1.2.4 數(shù)據(jù)庫架構(gòu)優(yōu)化

• 讀寫分離

• 數(shù)據(jù)分片

當(dāng)前面三種的收益不大時候,我們就要開始考慮在架構(gòu)層面進(jìn)行優(yōu)化了,而架構(gòu)層面最為有效的方法

就是進(jìn)行分庫分表,我的理解是,使用分庫分表使用的恰當(dāng)獲得的收益十分顯著

2 .分庫分表的類型和特點(diǎn)

2.1分庫分表的類型

垂直切分：基于表或字段劃分，表結(jié)構(gòu)不同。我們有單庫的分表，也有多庫的分庫。

水平切分：基于數(shù)據(jù)劃分，表結(jié)構(gòu)相同，數(shù)據(jù)不同，也有同庫的水平切分和多庫的 切分

• 垂直拆分：

• 單庫垂直分表 : 將一張表中的數(shù)據(jù)差分的得更加的細(xì)粒度，如：將用戶信息表，拆分成基本信息表，聯(lián)系方式表等

• 多庫垂直分表：多庫垂直分表就是把原來存儲在一個庫的不同的表，拆分到不同的數(shù)據(jù)庫。個人理解微服務(wù)劃分?jǐn)?shù)據(jù)庫的思想和這個類似，按照業(yè)務(wù)分到不同的數(shù)據(jù)庫

垂直拆分還是由于業(yè)務(wù)量大的業(yè)務(wù)導(dǎo)致數(shù)據(jù)庫數(shù)據(jù)量大,沒有從根本上解決問題

• 水平拆分：

• 單庫水平分表 ：將一張表按照字段值的來劃分到不同的表中

• 多庫水平分表：將一張表按照字段值的來劃分到不同的庫中，例如：按照租戶分庫

2.2分庫分表的帶來的問題

分完庫分完表之后,之前在單庫的的不會存在的問題都暴露出來了:

• 跨庫關(guān)聯(lián)查詢:

如何解決跨數(shù)據(jù)關(guān)聯(lián)查詢的問題

（1）字段冗余：將需要跨庫查詢查詢的字段進(jìn)行冗余處理

（2）數(shù)據(jù)同步：采用etl方式將需要關(guān)聯(lián)的查詢的數(shù)據(jù)進(jìn)行同步

（3）廣播表：將一些多個數(shù)據(jù)庫都需要用到表在操作的時候進(jìn)行廣播，例如表單表

（4）綁定表：將相同分片值相同的數(shù)據(jù)

（5）系統(tǒng)層面封裝：在不同的數(shù)據(jù)庫節(jié)點(diǎn)把符合條件數(shù)據(jù)的數(shù)據(jù)查詢出來，然后重新組裝，返回給客戶端。

• 分布式事務(wù)

如果在一個數(shù) 據(jù)庫里面，我們可以用本地事務(wù)來控制，但是在不同的數(shù)據(jù)庫里面就不行了。所以分布式環(huán)境里面的事務(wù)，我們也需要通過一些方案來解決.

• 全局事務(wù)

• 基于可靠消息服務(wù)的分布式事務(wù)

• 柔性事務(wù) TCC

• 最大努力通知，通過消息中間件向其他系統(tǒng)發(fā)送消息

• 排序、翻頁、函數(shù)等計算問題

max、min、sum、count 之類的函數(shù)在進(jìn)行計算的時候，也需要先在每個分片上執(zhí)行相應(yīng)的函數(shù)，然后將各個分片的結(jié)果集進(jìn)行匯總和再次計算，最終將結(jié)果返回

• 全局主鍵避重問題

使用主鍵自增策略，在不同的數(shù)據(jù)庫會出現(xiàn)主鍵沖突問題，該如何解決：

• UUID

• Snowflake

• 使用redis來做自增策略

現(xiàn)在的一些開源產(chǎn)品來解決分庫分表帶來的問題，也大多采用以上一些解決方案

3.分庫分表的方案設(shè)計與對比

思考一個sql執(zhí)行的流程: DAO——Mapper（ORM）——JDBC——代理——數(shù)據(jù)庫服務(wù)
當(dāng)前市面的解決方案基本都是從這個流程入手,下面我們將一一為其做探討:

3.1 DAO層

在這一層主要是做數(shù)據(jù)源的路由,一般也是多數(shù)據(jù)路由的選擇方案,Spring 中提供了一個抽象類

AbstractRoutingDataSource，可以實(shí)現(xiàn)數(shù)據(jù)源的動態(tài)切換.

這種實(shí)現(xiàn)方案目前在我們這邊也是有應(yīng)用的,在shc中的patient-document中對多數(shù)據(jù)源的路由就采取了這種方式

• 優(yōu)點(diǎn): 不需要依賴 ORM 框架，即使替換了 ORM 框架也不受影響。實(shí)現(xiàn)簡單（不需要解析 SQL 和路由規(guī)則），可以靈活地定制。

• 缺點(diǎn)：不能復(fù)用，不能跨語言,對于以上出現(xiàn)的問題都需要自己手動來進(jìn)行處理

3.2 ORM 框架層

如我們用 MyBatis 連接數(shù)據(jù)庫，也可以指定數(shù)據(jù)源。我們可以基于 MyBatis 插件的攔截機(jī)制（攔截 query 和 update 方法），實(shí)現(xiàn)數(shù)據(jù)源的選擇.

• 缺點(diǎn): 很明顯同上

3.3 驅(qū)動層

不管是MyBatis 還是Hibernate，還是Spring 的JdbcTemplate，本質(zhì)上都是對JDBC的封裝，所以第三層就是驅(qū)動層。比如 Sharding-JDBC，就是對 JDBC 的對象進(jìn)行了封裝。

JDBC 的核心對象：

• DataSource：數(shù)據(jù)源

• Connection：數(shù)據(jù)庫連接

• Statement：語句對象

• ResultSet：結(jié)果集

只要對這幾個對象進(jìn)行封裝或者攔截或者代理，就可以實(shí)現(xiàn)分片的操作.

• 缺點(diǎn)：

      1.僅支持JAVA

      2.占用較多的數(shù)據(jù)庫連接

      3.數(shù)據(jù)聚合在業(yè)務(wù)實(shí)例執(zhí)行

      4.版本升級較為麻煩

• 優(yōu)點(diǎn): 相對靈活,性能高,支持豐富的DB

      例如:TDDL、ShardingJDBC

3.4代理層

前面三種都是在客戶端實(shí)現(xiàn)的，也就是說不同的項(xiàng)目都要做同樣的改動，不同的編程語言也有不同的實(shí)現(xiàn)，代理層。代理層的數(shù)據(jù)庫中間件，將自己偽裝成一個數(shù)據(jù)庫，接受業(yè)務(wù)端的鏈接。然后負(fù)載業(yè)務(wù)端的請求，解析或者轉(zhuǎn)發(fā)到真正的數(shù)據(jù)庫中，其實(shí)是基于協(xié)議層面的，可以看后續(xù)的對比。

• 缺點(diǎn):

異構(gòu)支持，DB支持有限

運(yùn)維負(fù)擔(dān)大，需要高可用，單獨(dú)部署，穩(wěn)定性高,配置后需要重啟

• 優(yōu)點(diǎn): 無代碼入侵

比如 Mycat ，Sharding-Proxy和一些云廠商的分布式數(shù)據(jù)庫都是屬于這一層。

3.5 數(shù)據(jù)庫層面

最后一層就是在數(shù)據(jù)庫服務(wù)上實(shí)現(xiàn)，也就是服務(wù)層，某些特定的數(shù)據(jù)庫或者數(shù)據(jù)庫的特定版本可以實(shí)現(xiàn)這個功能。

• 缺點(diǎn): 受限于使用數(shù)據(jù)庫的類型

例如很多非關(guān)系型數(shù)據(jù)庫, redis,mongodb等

3.6方案對比

目前主流的分庫分表方案就是sharding-jdbc和mycat,為此做了一個對比

由于我們這邊需要采用動態(tài)的配置，以及更加個性化的實(shí)現(xiàn)，所以選擇sharding-jdbc

————————————————

版權(quán)聲明：本文為CSDN博主「永恒1996」的原創(chuàng)文章，遵循CC 4.0 BY-SA版權(quán)協(xié)議，轉(zhuǎn)載請附上原文出處鏈接及本聲明。

原文鏈接：

https://blog.csdn.net/weixin_38437520/article/details/106610213

鋒哥最新SpringCloud分布式電商秒殺課程發(fā)布

??????

??長按上方微信二維碼 2 秒

感謝點(diǎn)贊支持下哈