導讀
node
上一篇文章《ShardingJdbc分庫分表實戰案例解析（上）》中咱們初步介紹了使用ShardingJdbc實現訂單數據分散存儲的分庫分表方法，在本篇文章中將重點介紹在不停服的狀況下實現數據分片存儲的在線擴容。具體將以以下兩個常見的場景進行演示：1)、還沒有進行分庫分表的單庫單表系統如何平穩的實施分庫分表方案；2)、已經實施過度庫分表方案的系統，因爲數據量的持續增加致使原有分庫分表不夠用了，須要二次擴容的狀況。mysql
實施方案概述
web
在具體演示以前，咱們先簡單聊一聊關於分庫分表數據遷移中，幾種常見的思路，具體以下：算法
1)、停服遷移
spring
停服遷移方案，是數據遷移方案中最多見、也是相對安全，可是也是最不能讓人接受的方案。之因此說它安全，是由於停服以後就不會有新的數據寫入，這樣能保證數據遷移工做可以在一個相對穩定的環境中進行，於是能較大程度上避免遷移過程當中產生數據不一致的問題。
sql
但停服務方案會比較嚴重傷害用戶體驗、下降服務的可用性，而若是數據量較大遷移須要大量的時間的話，長時間的停服會嚴重影響業務，對於強調"9999"服務體驗的互聯網公司來講，停服方案絕對是讓人不能接受的。
數據庫
通常來講停服方案更適合於哪些非7X24小時，且對自身數據一致性要求很是高的系統，例如社保基金、銀行核心系統等。固然，這也並非說非停服方案，作不到數據遷移的絕對準確，僅僅在於這些系統出於管理、規則等非技術因素上的考慮是否可以容忍小几率的風險事件罷了。express
停服遷移的流程，通常以下：apache
一、提早進行演練、預估停服時間，發佈停服公告；json
二、停服，經過事先準備好的數據遷移工具（通常爲遷移腳本），按照新的數據分片規則，進行數據遷移；
三、覈對遷移數據的準確性；
四、修改應用程序代碼，切換數據分片讀寫規則，並完成測試驗證；
五、啓動服務，接入外部流量；
2)、升級從庫方案
關於升級從庫的方案，通常是針對線上數據庫配置了主從同步結構的系統來講的。其具體思路是，當須要從新進行分庫分表擴容時，可將現有從庫直接升級成主庫。例如原先分庫分表結構是A、B兩個分庫爲主庫、A0、B0分別爲A、B對應的從庫，具體以下圖所示：
假設此時若是須要擴容，新增兩個分庫的話，那麼能夠將A0、B0升級爲主庫，如此原先的兩個分庫將變爲4個分庫。與此同時，將上層服務的分片規則進行更改，將原先uid%2=0(原先存在A庫)的數據分裂爲uid%4=0和uid%=2的數據分別存儲在A和A0上；同時將uid%2=1(原先存在B庫)的數據分裂爲uid%4=1和uid%=3的數據分別存儲在B和B0上。而由於A0庫和A庫，B0庫與B1庫數據相同，因此這樣就不須要進行數據遷移了，只須要變動服務的分片規則配置便可。以後結構以下：
而以前uid%2的數據分配在2個庫中，此時分散到4個庫，因爲老數據還在，因此uid%4=2的數據還有一半存儲在uid%4=0的分庫中。所以還須要對冗餘數據進行清理，但這類清理並不影響線上數據的一致性，能夠隨時隨地進行。
處理完成後，爲保證高可用，以及下一步擴容的需求，能夠爲現有主庫再次分配一個從庫，具體以下圖所示：
升級從庫方案的流程，通常以下：
一、修改服務數據分片配置，作好新庫和老庫的數據映射；
二、DBA協助完成從庫升級爲主庫的數據庫切換；
三、DBA解除現有數據庫主從配置關係；
四、異步完成冗餘數據的清理；
五、從新爲新的數據節點搭建新的從庫；
這種方案避免了因爲數據遷移致使的不肯定性，但也有其侷限性。首先，現有數據庫主從結構要能知足新的分庫分表的規劃；其次，這種方案的主要技術風險點被轉移至DBA，實施起來可能會有較大阻力，畢竟DBA也不見得願意背這個鍋；最後，因爲須要在線更改數據庫的存儲結構，可能也會出現意想不到的狀況，而若是還存在多應用共享數據庫實例狀況的話，狀況也會變得比較複雜。
3)、雙寫方案
雙寫方案是針對線上數據庫遷移時使用的一種常見手段，而對於分庫分表的擴容來講，也涉及到數據遷移，因此也能夠經過雙寫來協助分庫分表擴容的問題。
雙寫方案實際上同升級從庫的原理相似，都是作"分裂擴容"，從而減小直接數據遷移的規模下降數據不一致的風險，只是數據同步的方式不一樣。雙寫方案的核心步驟是：1)、是直接增長新的數據庫，並在原有分片邏輯中增長寫連接，同時寫兩份數據；2)、與此同時，經過工具(例如腳本、程序等)將原先老庫中的歷史數據逐步同步至新庫，此時因爲新庫只有新增寫入，應用上層其餘邏輯還在老庫之中，因此數據的遷移對其並沒有影響；3)、對遷移數據進行校驗，因爲是業務直接雙寫，因此新增數據的一致性是很是高的（但須要注意insert、update、delete操做都須要雙更新操做）；4)、完成數據遷移同步，並校驗一致後就能夠在應用上層根據老庫的分裂方式從新修改分片配置規則了。之前面的例子爲例，雙寫方案以下圖所示：
如上圖所示原先的A、B兩個分庫，其中uid%2=0的存放在A庫，uid%2=1的存放在B庫；增長新的數據庫，其中寫入A庫是雙寫A0庫，寫入B庫時雙寫B0庫。
以後分別將A庫的歷史數據遷移至A0庫；B庫的歷史數據遷移至B0庫。最終確保A庫與A0庫的數據一致；B庫與B0庫的數據一致。具體以下圖所示：
以後修改分片規則，確保原先uid%2=0存放在A庫的數據，在分裂爲uid%4=0和uid%4=2的狀況下能分別存儲在A庫和A0庫中；原先uid%2=1存放在B庫的數據，在分裂爲uid%4=1和uid%4=3的狀況下分別存在到B庫和B0庫之中。具體以下圖所示：
雙寫方案避免了像升級從庫那樣改變數據庫結構的風險，更容易由開發人員本身控制，但雙寫方案須要侵入應用代碼，而且最終須要完成數據遷移和冗餘數據刪除兩個步驟，實施起來也不輕鬆。
那麼到底有沒有一個絕對完美的方案呢？
答案實際上是沒有！由於不管哪一種方案都沒法避免要遷移數據，即使像升級從庫那樣避免了數據遷移，也沒法避免對冗餘數據進行刪除的額外操做。但咱們能夠在數據遷移手段和從新處理數據分片的方式上進行優化，目前在分庫分表領域著名的開源項目ShardingSphere本質上其實就是在這兩方面進行了優化，從而提供了一組解決方案工具集。
具體來講ShardingSphere是由"Sharding-JDBC+Sharding-Proxy+Sharding-Scaling"三個核心組件組成的分庫分表開源解決方案，Sharding-JDBC在《ShardingJdbc分庫分表實戰案例解析（上）》中咱們已經介紹過。而Sharding-Proxy+Sharding-Scaling則是專門用於設計處理分庫分表擴容數據遷移問題的組件，其運行原理以下：
如上圖所示，在ShardingSphere的解決方案中，當須要對Service(舊)服務進行分庫分表擴容時，咱們能夠先部署Sharding-Scaling+Sharding-Proxy組件進行數據遷移+數據分片預處理。具體來講步驟以下：
1)、在Sharding-Proxy中按照擴容方案配置好分片規則，啓動服務並提供JDBC協議鏈接機制，此時經過Sharding-Proxy鏈接寫入的數據會按照新的分片規則進行數據存儲；
2)、部署Sharding-Scaling服務，並經過HTTP接口的形式，向其發送數據遷移任務配置（配置數據中有須要遷移的數據庫鏈接串，也有Sharding-Proxy的數據鏈接串）；
3)、啓動Sharding-Scaling遷移任務後，Sharding-Scaling將根據目標數據源的Binlog日誌變化，讀取後從新發送至Sharding-Proxy進行分片數據的從新處理；
4)、當Sharding-Scaling遷移數據任務完成，檢查數據遷移結果，若是沒有問題，則能夠修改Service（新）服務的數據分片規則，並完成Service（舊）服務的替換；
5)、確認擴容無誤後，中止Sharding-Proxy+Sharding-Scaling服務；
6)、異步完成冗餘數據的清理（目前ShardingSphere還不支持數據遷移後自動完成冗餘數據的清理，因此須要本身根據數據分裂規則，編寫清除腳本）；
上述過程徹底自動，在完成數據遷移及從新分片前，舊服務保持持續服務，不會對線上形成影響；此外因爲Sharding-Scaling一直處於監聽目標數據源Binlog日誌狀態，因此即使在服務切換過程當中，舊Service服務仍有數據寫入，也會自動被Sharding-Proxy從新分片處理，因此不用擔憂會出現不一致。
此外Sharding-Scaling+Sharding-Proxy通訊方式採用的是JDBC鏈接原生鏈接方式以及基於Binlog日誌的同步方案，因此在遷移效率上也是有保證的。接下來將基於Sharding-Scaling+Sharding-Proxy方案具體演示在不停服的狀況下進行分庫分表在線擴容。
ShardingSphere分庫分表在線擴容
仍是以上一篇文章中的訂單分庫分表存儲爲例，將其原有的分庫分表規劃：1)、數據庫節點2個(ds0、ds1)；2)、每一個庫的分表數爲32張表(0~31)。擴容爲：1)、數據庫節點4個(ds0、ds一、ds二、ds3)；2)、每一個庫的分表數仍爲32張表（0~31）。
首先咱們部署Sharding-Scaling+Sharding-Proxy進行在線數據遷移及數據分片處理，具體以下：
1)、部署Sharding-Proxy
該服務的做用是一個數據庫中間件，咱們在此服務上編輯好分庫分表規則後，Sharding-Scaling會把原數據寫入Sharding-Proxy，而後由Sharding-Proxy對數據進行路由後寫入對應的庫和表。
咱們能夠在Github上下載ShardingSphere對應的版本的源碼（演示所用版本爲4.1.1）自行編譯，也能夠下載已經編譯好的版本文件。本次演示所用方式爲源碼編譯，其執行程序目錄以下：
/shardingsphere-4.1.1/sharding-distribution/sharding-proxy-distribution/target/apache-shardingsphere-4.1.1-sharding-proxy-bin.tar.gz
找到編譯執行程序後進行解壓！以後編輯"conf/server.yaml"文件，添加鏈接帳號配置，具體以下：
authentication:
users:
root:
password: 123456
該配置主要是供Sharding-Scaling鏈接Sharding-Proxy時使用！以後編輯Sharding-Proxy的分庫分表配置文件"conf/config-sharding.yaml "，按照新的擴容方案進行配置，具體以下：
#對外暴露的數據庫名稱
schemaName: order
dataSources:
ds_0:
url: jdbc:mysql://127.0.0.1:3306/order_0?serverTimezone=UTC&useSSL=false
username: root
password: 123456
connectionTimeoutMilliseconds: 30000
idleTimeoutMilliseconds: 60000
maxLifetimeMilliseconds: 1800000
maxPoolSize: 300
ds_1:
url: jdbc:mysql://127.0.0.1:3306/order_1?serverTimezone=UTC&useSSL=false
username: root
password: 123456
connectionTimeoutMilliseconds: 30000
idleTimeoutMilliseconds: 60000
maxLifetimeMilliseconds: 1800000
maxPoolSize: 300
ds_2:
url: jdbc:mysql://127.0.0.1:3306/order_2?serverTimezone=UTC&useSSL=false
username: root
password: 123456
connectionTimeoutMilliseconds: 30000
idleTimeoutMilliseconds: 60000
maxLifetimeMilliseconds: 1800000
maxPoolSize: 300
ds_3:
url: jdbc:mysql://127.0.0.1:3306/order_3?serverTimezone=UTC&useSSL=false
username: root
password: 123456
connectionTimeoutMilliseconds: 30000
idleTimeoutMilliseconds: 60000
maxLifetimeMilliseconds: 1800000
maxPoolSize: 300
shardingRule:
tables:
t_order:
actualDataNodes: ds_${0..3}.t_order_$->{0..31}
databaseStrategy:
inline:
shardingColumn: user_id
algorithmExpression: ds_${user_id % 4}
tableStrategy:
inline:
shardingColumn: order_id
algorithmExpression: t_order_${order_id % 32}
keyGenerator:
type: SNOWFLAKE
column: id
完成分庫分表配置後，啓動Sharding-Proxy服務，命令以下：
sh bin/start.sh
爲了驗證ShardingProxy的部署正確下，能夠經過Mysql命令進行鏈接，並插入一條數據，驗證其是否按照新的分庫分表規則進行存儲，具體以下：
#使用mysql客戶端檢查是否能連接成功
mysql -h 127.0.0.1 -p 3307 -uroot -p123456
mysql> show databases;
+----------+
| Database |
+----------+
| order |
+----------+
1 row in set (0.02 sec)
#執行如下腳本，寫入成功後， 檢查order_0～3的分表數據是否按照規則落庫
mysql> insert into t_order values('d8d5e92550ba49d08467597a5263205b',10001,'topup',100,'CNY','2','3','1010010101',63631722,now(),now(),'測試sharding-proxy');
Query OK, 1 row affected (0.20 sec)
按照新的分庫分表規則uid->63631722%4=2;orderId->10001%32=17，測試數據應該落在ds_2中的t_order_17表中！如正確插入，則說明新的分庫分表規則配置正確。
2)、部署Sharding-Scaling
源碼編譯的Sharding-Scaling執行程序包路徑爲：
/shardingsphere-4.1.1/sharding-distribution/sharding-scaling-distribution/target/apache-shardingsphere-4.1.1-sharding-scaling-bin.tar.gz
解壓後，啓動Scaling服務，命令以下：
sh bin/start.sh
Sharding-Scaling是一個獨立的數據遷移服務，其自己不與任何具體的環境關聯，在建立遷移任務時，具體信息由接口傳入。接下來咱們調用Sharding-Scaling建立具體的遷移任務。
在此以前，原有分庫中的數據有：
1)、userId=63631725;orderId=123458存儲在ds_1中的t_order_2號表中；
2)、userId=63631722;orderId=123457存儲在ds_0中的t_order_1號表中；
而按照新的規則數據1不須要遷移，數據2須要遷移至ds_2中的t_order_1號表中，具體建立Sharding-Scaling遷移任務的指令以下：
#提交order_0的遷移數據命令
curl -X POST --url http://localhost:8888/shardingscaling/job/start \
--header 'content-type: application/json' \
--data '{
"ruleConfiguration": {
"sourceDatasource": "ds_0: !!org.apache.shardingsphere.orchestration.core.configuration.YamlDataSourceConfiguration\n dataSourceClassName: com.zaxxer.hikari.HikariDataSource\n properties:\n jdbcUrl: jdbc:mysql://127.0.0.1:3306/order_0?serverTimezone=UTC&useSSL=false&zeroDateTimeBehavior=convertToNull\n driverClassName: com.mysql.jdbc.Driver\n username: root\n password: 123456\n connectionTimeout: 30000\n idleTimeout: 60000\n maxLifetime: 1800000\n maxPoolSize: 100\n minPoolSize: 10\n maintenanceIntervalMilliseconds: 30000\n readOnly: false\n",
"sourceRule": "tables:\n t_order:\n actualDataNodes: ds_0.t_order_$->{0..31}\n keyGenerator:\n column: order_id\n type: SNOWFLAKE",
"destinationDataSources": {
"name": "dt_1",
"password": "123456",
"url": "jdbc:mysql://127.0.0.1:3307/order?serverTimezone=UTC&useSSL=false",
"username": "root"
}
},
"jobConfiguration": {
"concurrency": 1
}
}'
以上咱們提交了針對老庫order_0的數據遷移任務，若是提交成功Sharding-Scaling會返回以下信息：
{"success":true,"errorCode":0,"errorMsg":null,"model":null}
此時可經過命令查看任務詳情進度，命令及結果顯示以下：
#curl http://localhost:8888/shardingscaling/job/progress/1;
{
"success": true,
"errorCode": 0,
"errorMsg": null,
"model": {
"id": 1,
"jobName": "Local Sharding Scaling Job",
"status": "RUNNING",
"syncTaskProgress": [{
"id": "127.0.0.1-3306-order_0",
"status": "SYNCHRONIZE_REALTIME_DATA",
"historySyncTaskProgress": [{
"id": "history-order_0-t_order_24#0",
"estimatedRows": 0,
"syncedRows": 0
}, {
"id": "history-order_0-t_order_25#0",
"estimatedRows": 0,
"syncedRows": 0
}, {
"id": "history-order_0-t_order_22#0",
"estimatedRows": 0,
"syncedRows": 0
}, {
"id": "history-order_0-t_order_23#0",
"estimatedRows": 0,
"syncedRows": 0
}, {
"id": "history-order_0-t_order_20#0",
"estimatedRows": 0,
"syncedRows": 0
}, {
"id": "history-order_0-t_order_21#0",
"estimatedRows": 0,
"syncedRows": 0
}, {
"id": "history-order_0-t_order_19#0",
"estimatedRows": 0,
"syncedRows": 0
}, {
"id": "history-order_0-t_order_17#0",
"estimatedRows": 0,
"syncedRows": 0
}, {
"id": "history-order_0-t_order_18#0",
"estimatedRows": 0,
"syncedRows": 0
}, {
"id": "history-order_0-t_order_15#0",
"estimatedRows": 0,
"syncedRows": 0
}, {
"id": "history-order_0-t_order_16#0",
"estimatedRows": 0,
"syncedRows": 0
}, {
"id": "history-order_0-t_order_13#0",
"estimatedRows": 0,
"syncedRows": 0
}, {
"id": "history-order_0-t_order_14#0",
"estimatedRows": 0,
"syncedRows": 0
}, {
"id": "history-order_0-t_order_8#0",
"estimatedRows": 0,
"syncedRows": 0
}, {
"id": "history-order_0-t_order_11#0",
"estimatedRows": 0,
"syncedRows": 0
}, {
"id": "history-order_0-t_order_9#0",
"estimatedRows": 0,
"syncedRows": 0
}, {
"id": "history-order_0-t_order_12#0",
"estimatedRows": 0,
"syncedRows": 0
}, {
"id": "history-order_0-t_order_6#0",
"estimatedRows": 0,
"syncedRows": 0
}, {
"id": "history-order_0-t_order_31#0",
"estimatedRows": 0,
"syncedRows": 0
}, {
"id": "history-order_0-t_order_7#0",
"estimatedRows": 0,
"syncedRows": 0
}, {
"id": "history-order_0-t_order_10#0",
"estimatedRows": 0,
"syncedRows": 0
}, {
"id": "history-order_0-t_order_4#0",
"estimatedRows": 0,
"syncedRows": 0
}, {
"id": "history-order_0-t_order_5#0",
"estimatedRows": 0,
"syncedRows": 0
}, {
"id": "history-order_0-t_order_30#0",
"estimatedRows": 0,
"syncedRows": 0
}, {
"id": "history-order_0-t_order_2#0",
"estimatedRows": 0,
"syncedRows": 0
}, {
"id": "history-order_0-t_order_3#0",
"estimatedRows": 0,
"syncedRows": 0
}, {
"id": "history-order_0-t_order_0#0",
"estimatedRows": 0,
"syncedRows": 0
}, {
"id": "history-order_0-t_order_1#0",
"estimatedRows": 1,
"syncedRows": 1
}, {
"id": "history-order_0-t_order_28#0",
"estimatedRows": 0,
"syncedRows": 0
}, {
"id": "history-order_0-t_order_29#0",
"estimatedRows": 0,
"syncedRows": 0
}, {
"id": "history-order_0-t_order_26#0",
"estimatedRows": 0,
"syncedRows": 0
}, {
"id": "history-order_0-t_order_27#0",
"estimatedRows": 0,
"syncedRows": 0
}],
"realTimeSyncTaskProgress": {
"id": "realtime-order_0",
"delayMillisecond": 8759,
"logPosition": {
"filename": "mysql-bin.000001",
"position": 190285,
"serverId": 0
}
}
}]
}
}
一樣針對其餘老庫,如order_1數據庫的遷移，也能夠以相似的方式提交遷移任務！若是此時觀察數據2，就會發現其已經被從新分片到ds_2的t_order_1號表中；但其以前的歷史分片數據仍然會冗餘在ds_0的t_order_1號表中(須要清理)。
假設此時，有一條經過老服務寫入的"userId=63631723&orderId=123457"數據，那麼其會被存儲在ds_1的t_order_1號表中，而其最新存儲規則應該在ds_3的t_order_1號表中。若是以前也同時開啓了order_1庫的Scaling數據遷移任務，那麼此時該數據將會被自動從新遷移並分片至ds_3的t_order_1號表中。
完成數據遷移後，就能夠將以前舊服務的分片規則進行調整並從新發布了，具體以下：
#SQL控制檯打印（開發時配置）
spring.shardingsphere.props.sql.show = true
# 配置真實數據源
spring.shardingsphere.datasource.names=ds0,ds1,ds2,ds3
# 配置第1個數據源
spring.shardingsphere.datasource.ds0.type=com.alibaba.druid.pool.DruidDataSource
spring.shardingsphere.datasource.ds0.driver-class-name=com.mysql.jdbc.Driver
spring.shardingsphere.datasource.ds0.url=jdbc:mysql://127.0.0.1:3306/order_0?characterEncoding=utf-8
spring.shardingsphere.datasource.ds0.username=root
spring.shardingsphere.datasource.ds0.password=123456
# 配置第2個數據源
spring.shardingsphere.datasource.ds1.type=com.alibaba.druid.pool.DruidDataSource
spring.shardingsphere.datasource.ds1.driver-class-name=com.mysql.jdbc.Driver
spring.shardingsphere.datasource.ds1.url=jdbc:mysql://127.0.0.1:3306/order_1?characterEncoding=utf-8
spring.shardingsphere.datasource.ds1.username=root
spring.shardingsphere.datasource.ds1.password=123456
# 配置第3個數據源
spring.shardingsphere.datasource.ds2.type=com.alibaba.druid.pool.DruidDataSource
spring.shardingsphere.datasource.ds2.driver-class-name=com.mysql.jdbc.Driver
spring.shardingsphere.datasource.ds2.url=jdbc:mysql://127.0.0.1:3306/order_2?characterEncoding=utf-8
spring.shardingsphere.datasource.ds2.username=root
spring.shardingsphere.datasource.ds2.password=123456
# 配置第4個數據源
spring.shardingsphere.datasource.ds3.type=com.alibaba.druid.pool.DruidDataSource
spring.shardingsphere.datasource.ds3.driver-class-name=com.mysql.jdbc.Driver
spring.shardingsphere.datasource.ds3.url=jdbc:mysql://127.0.0.1:3306/order_3?characterEncoding=utf-8
spring.shardingsphere.datasource.ds3.username=root
spring.shardingsphere.datasource.ds3.password=123456
# 配置t_order表規則
spring.shardingsphere.sharding.tables.t_order.actual-data-nodes=ds$->{0..3}.t_order_$->{0..31}
# 配置t_order表分庫策略（inline-基於行表達式的分片算法）
spring.shardingsphere.sharding.tables.t_order.database-strategy.inline.sharding-column=user_id
spring.shardingsphere.sharding.tables.t_order.database-strategy.inline.algorithm-expression=ds${user_id % 2}
# 配置t_order表分表策略
spring.shardingsphere.sharding.tables.t_order.table-strategy.inline.sharding-column=order_id
spring.shardingsphere.sharding.tables.t_order.table-strategy.inline.algorithm-expression = t_order_$->{order_id % 32}
#如其餘表有分庫分表需求，配置同上述t_order表
# ...
以上內容詳細介紹並演示了針對已經分庫分表的系統進行二次擴容時使用Sharding-Scaling+Sharding-Proxy進行數據遷移的過程；而關於還沒有進行過度庫分表，但須要進行分庫分表的系統來講，其過程與二次擴容並沒有差異，這裏就再也不贅述！
分庫分表實踐中須要注意的其餘問題
在具體的分庫分表實踐中還須要注意表的主鍵問題，通常能夠考慮分佈式ID生成方案，例如UUID等，避免在擴容遷移數據時發生主鍵衝突。另外關於Sharding-Scaling+Sharding-Proxy的使用，也須要注意一些異常狀況，目前Sharding-Scaling的版本仍是Alpha版本，因此使用過程當中不排除會有一些問題，能夠多看看源碼，增進了解！
最後因爲篇幅的緣由，就沒有具體演示歷史數據的清理方法，你們若是在實踐中有更好的方法，也歡迎同步給我！以上就是本篇文章想要表達的所有內容了，但願對你們有用！
—————END—————
參考資料：
https://shardingsphere.apache.org/document/current/en/quick-start/shardingsphere-scaling-quick-start/
https://blog.csdn.net/beichen8641/article/details/106924189
本文分享自微信公衆號 - 無敵碼農（jiangqiaodege）。
若有侵權，請聯繫 support@oschina.cn 刪除。
本文參與「OSC源創計劃」，歡迎正在閱讀的你也加入，一塊兒分享。