【愚公系列】2022年04月 .NET架構(gòu)班 039-分布式中間件 ShardingSphere-Proxy之分庫

一、ShardingSphere-Proxy之分庫

將hmms分成hmms-0和hmms-1的步驟如下：

1、創(chuàng)建數(shù)據(jù)庫

創(chuàng)建數(shù)據(jù)庫hmms、hmms-0、hmms-1三個數(shù)據(jù)庫

2、然后在config-sharding.yaml中添加分庫配置

# 3、創(chuàng)建客戶端連接庫 schemaName: hmms #1、連接mysql dataSources: hmmsdatasources-0: url: jdbc:mysql://localhost:3306/hmms-0?serverTimezone=UTC&useSSL=false username: root password: 123456 connectionTimeoutMilliseconds: 30000 idleTimeoutMilliseconds: 60000 maxLifetimeMilliseconds: 1800000 maxPoolSize: 50 minPoolSize: 1 hmmsdatasources-1: url: jdbc:mysql://localhost:3306/hmms-1?serverTimezone=UTC&useSSL=false username: root password: 123456 connectionTimeoutMilliseconds: 30000 idleTimeoutMilliseconds: 60000 maxLifetimeMilliseconds: 1800000 maxPoolSize: 50 minPoolSize: 1 # 2、分片規(guī)則 rules: - !SHARDING tables: user: actualDataNodes: hmmsdatasources-${0..1}.user-${0..1} tableStrategy: standard: shardingColumn: useid shardingAlgorithmName: use_MOD databaseStrategy: #分庫規(guī)則 standard: shardingColumn: useid shardingAlgorithmName: use_MOD keyGenerateStrategy: column: useid keyGeneratorName: snowflake shardingAlgorithms: use_MOD: type: MOD props:

二、ShardingSphere-Proxy數(shù)據(jù)查詢分庫分表原理

對查詢語句進(jìn)行分析： select * from user where useid= 1

方案：

1.SQL解析

2.查詢優(yōu)化

3.SQL路由

4.SQL改寫

5.SQL執(zhí)行

6.結(jié)果歸并

技術(shù)

1、SQL解析

SQLParserFacade 配置用于SQL解析的詞法分析器和語法分析器入口

SQLVisitorFacade SQL 語法樹訪問器入口

2、路由解析

– 使用ModShardingAlgorithm分片算法

SQLRouter ShardingSQLRouter 用于處理路由結(jié)果

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

ModShardingAlgorithm分片算法

3、SQL改寫

SQLRewriteContextDecorator ShardingSQLRewriteContextDecorator 用于處理 SQL 改寫結(jié)果

4、SQL執(zhí)行

SQLExecution SQL執(zhí)行過程

5、結(jié)果歸并

ResultProcessEngine ShardingResultMergerEngine 用于處理分片結(jié)果集歸并

過程

1、先取出ProductId % 2 然后進(jìn)行取模得到 0 1

2、如果結(jié)果為0:根據(jù)路由ShardingSQLRouter 找到真實表seckill_0 數(shù)據(jù)就存儲到第一張庫。如果結(jié)果為1:根據(jù)路由ShardingSQLRouter 找到真實表seckill_1 數(shù)據(jù)就存儲到第二張表。

總結(jié)

ShardingSphere-Proxy的分庫分表就介紹到這里了。下面是對應(yīng)遇到數(shù)據(jù)庫問題方案選擇總結(jié)。

1.數(shù)據(jù)庫瓶頸

不管是IO瓶頸，還是CPU瓶頸，最終都會導(dǎo)致數(shù)據(jù)庫的活躍連接數(shù)增加，進(jìn)而逼近甚至達(dá)到數(shù)據(jù)庫可承載活躍連接數(shù)的閾值。在業(yè)務(wù)Service來看就是，可用數(shù)據(jù)庫連接少甚至無連接可用。接下來就可以想象了吧（并發(fā)量、吞吐量、崩潰）。

1.1 IO瓶頸

第一種：磁盤讀IO瓶頸，熱點數(shù)據(jù)太多，數(shù)據(jù)庫緩存放不下，每次查詢時會產(chǎn)生大量的IO，降低查詢速度 -> 分庫和垂直分表。

第二種：網(wǎng)絡(luò)IO瓶頸，請求的數(shù)據(jù)太多，網(wǎng)絡(luò)帶寬不夠 -> 分庫。

1.2 CPU瓶頸

第一種：SQL問題，如SQL中包含join，group by，order by，非索引字段條件查詢等，增加CPU運算的操作 -> SQL優(yōu)化，建立合適的索引，在業(yè)務(wù)Service層進(jìn)行業(yè)務(wù)計算。

第二種：單表數(shù)據(jù)量太大，查詢時掃描的行太多，SQL效率低，CPU率先出現(xiàn)瓶頸 -> 水平分表。

.NET 分布式

版權(quán)聲明：本文內(nèi)容由網(wǎng)絡(luò)用戶投稿，版權(quán)歸原作者所有，本站不擁有其著作權(quán)，亦不承擔(dān)相應(yīng)法律責(zé)任。如果您發(fā)現(xiàn)本站中有涉嫌抄襲或描述失實的內(nèi)容，請聯(lián)系我們jiasou666@gmail.com 處理，核實后本網(wǎng)站將在24小時內(nèi)刪除侵權(quán)內(nèi)容。