面試問：“你為啥自研路由組件，咋不用sharding-jdbc”
作者：小傅哥
工程中，提供了 docker 配置數據庫環境操作，并提供了對應的建表測試語句。如果你本機已經安裝了數據庫，那么只做庫表語句導入以及 yml 配置數據庫連接信息就可以。
作者：小傅哥
博客：https://bugstack.cn
面試問：“你為什么要自研，市面不是有嗎，怎么回答？” 可以從以下3個點解答；
- 維護性；市面的路由組件比如 shardingsphere 但過于龐大，還需要隨著版本做一些升級，市面上已經有很多版本了。而我們需要更少的維護成本。
- 擴展性；結合自身的業務需求，我們的路由組件可以分庫分表、自定義路由協議，掃描指定庫表數據等各類方式。研發擴展性好，簡單易用。
- 安全性；自研的組件更好的控制了安全問題。當然，我們的組件主要是為了更好的適應目前系統的訴求，所以使用自研的方式處理。甚至各個大廠也都自研一整套分布式服務，來讓自己的系統更加穩定可控。
接著問，你們為什么分庫分表？
我們分庫分表用的非常熟。但不能為了等到系統到了200萬數據，才拆。那么工作量會非常大 我們的做法是，因為有成熟方案，所以前期就分庫分表了。但，為了解釋服務器空間。所以把分庫分表的庫，用服務器虛擬出來機器安裝。這樣即不過多的占用服務器資源，也方便后續數據量真的上來了，好拆分。
同時，Xxx系統，是瞬時峰值較高的系統，歷史數據不一定多。所以我們希望，用戶可以快速的檢索到個人數據，做最優響應。因為大家都知道，Xxx這東西，push發完，基本就1~3分鐘結束，10分鐘人都沒了。所以我們這也是做了分庫分表的理由。
不過用和不用是一方面，會和不會是另外一方面。不能因為不會所以不用，不用是因為不同場景的所需。像 Apache ShardingSphere 在很多大的場景還是非常好用的，所以我們需要學習積累。積累不同的思想和設計，以及積累技術的運用。
- 碎片知識：https://bugstack.cn/md/road-map/road-map.html
- 實戰項目：https://bugstack.cn/md/zsxq/introduce.html
本文的宗旨在于通過簡單干凈實踐的方式教會讀者，快速 Easy 的使用上 sharding-jdbc 這個笨重的大家伙！—— 這篇文章并不復雜，但市面上的案例，還真的很少有能拿過來就能運行起來的！
之所以說"笨重"，是因為 Apache ShardingSphere 不只是簡單意義上的路由組件，而是一款分布式 SQL 事務和查詢引擎，可通過數據分片、彈性伸縮、加密等能力對任意數據庫進行增強。同時它又在迭代過程中，衍生出了很多的版本，以及對應了不同的使用方式。并在 ShardingSphere 5.3 以后又做了不小的架構調整。所以很多伙伴在使用的時候，經常是找了一上午的資料，到下午下班還沒對接上。
本文涉及的工程：
- xfg-dev-tech-shardingjdbc：https://gitcode.net/KnowledgePlanet/road-map/xfg-dev-tech-shardingjdbc
- 官網：https://shardingsphere.apache.org/index_zh.html
一、路由本質
分庫分表的本質是數據的散列，分攤數據庫資源壓力。如把原本在一臺機器上的數據庫存放1000萬數據，分攤到n臺機上，拆分這1000萬的數據和后續的增量。讓每個數據庫資源來分攤原本需要一臺數據庫所提供的服務。
圖片
- 當使用分庫分表以后，并確定如使用用戶ID作為路由分片鍵。那么所做的CRUD操作，都是需要使用到這個用戶ID，并根據ID做路由庫表計算。
- 在大廠中，開發項目。并不會說目前這個業務需求規模不大，就不使用分庫分表，而是分庫分表都是非常成熟的方案，并不會因為使用了就降低很大的開發效率。所以基本就是默認就使用了。
- 那么使用了分庫分表，就會很占用資源嗎。也不會，因為剛開始業務體量不大的時候，都是虛擬機交叉使用，你的1臺物理機虛出來10個虛擬機，大家交叉使用主備。這樣你只是使用了分庫分表，但庫表的實際資源沒占用那么多。
二、使用案例
- jdk 1.8 +
- ShardingSphere 5.4.1
<!-- https://mvnrepository.com/artifact/org.apache.shardingsphere/shardingsphere-jdbc-core -->
<dependency>
<groupId>org.apache.shardingsphere</groupId>
<artifactId>shardingsphere-jdbc-core</artifactId>
<version>5.4.1</version>
</dependency>
<!-- https://mvnrepository.com/artifact/org.yaml/snakeyaml -->
<dependency>
<groupId>org.yaml</groupId>
<artifactId>snakeyaml</artifactId>
<version>1.33</version>
</dependency>- 因為需要解析 yaml 但默認的 SpringBoot 提供版本不支持 shardingsphere-jdbc-core 使用。
1. 工程結構
圖片
- 工程中，提供了 docker 配置數據庫環境操作，并提供了對應的建表測試語句。如果你本機已經安裝了數據庫，那么只做庫表語句導入以及 yml 配置數據庫連接信息就可以。
- sharding-jdbc-dev.yaml 配置了詳細的分庫分表路由信息，在 algorithms 下配置的是庫表的路由算法。這里的算法要根據實際自己使用中庫表數量來設置&設計，避免發生較大的數據偏移。
- 配置完 sharding-jdbc-dev.yaml 需要在 application-dev.yml 中配置上 sharding-jdbc-dev.yaml 路徑，這樣才能正確加載。
- 如果你還需要定義出自己特定的路由算法，它還支持自己寫個實現類的方式處理。
2. 算法配置
sharding/sharding-jdbc-dev.yaml
# https://shardingsphere.apache.org/index_zh.html
mode:
# 運行模式類型。可選配置：內存模式 Memory、單機模式 Standalone、集群模式 Cluster - 目前為單機模式
type: Standalone
dataSources:
ds_0:
dataSourceClassName: com.zaxxer.hikari.HikariDataSource
driverClassName: com.mysql.cj.jdbc.Driver
jdbcUrl: jdbc:mysql://127.0.0.1:13306/xfg_dev_tech_db_00?useUnicode=true&characterEncoding=utf8&autoRecnotallow=true&zeroDateTimeBehavior=convertToNull&serverTimeznotallow=UTC&useSSL=true
username: root
password: 123456
connectionTimeoutMilliseconds: 30000
idleTimeoutMilliseconds: 60000
maxLifetimeMilliseconds: 1800000
maxPoolSize: 15
minPoolSize: 5
ds_1:
dataSourceClassName: com.zaxxer.hikari.HikariDataSource
driverClassName: com.mysql.cj.jdbc.Driver
jdbcUrl: jdbc:mysql://127.0.0.1:13306/xfg_dev_tech_db_01?useUnicode=true&characterEncoding=utf8&autoRecnotallow=true&zeroDateTimeBehavior=convertToNull&serverTimeznotallow=UTC&useSSL=true
username: root
password: 123456
connectionTimeoutMilliseconds: 30000
idleTimeoutMilliseconds: 60000
maxLifetimeMilliseconds: 1800000
maxPoolSize: 15
minPoolSize: 5
rules:
- !SHARDING
# 庫的路由
defaultDatabaseStrategy:
standard:
shardingColumn: user_id
shardingAlgorithmName: database_inline
# 表的路由
tables:
user_order:
actualDataNodes: ds_$->{0..1}.user_order_$->{0..3}
tableStrategy:
standard:
shardingColumn: user_id
shardingAlgorithmName: user_order_inline
# 路由算法
shardingAlgorithms:
# 庫-路由算法 2是兩個庫，庫的數量。庫的數量用哈希模2來計算。
database_inline:
type: INLINE
props:
algorithm-expression: ds_$->{Math.abs(user_id.hashCode()) % 2}
# 表-路由算法 4是一個庫里，表的數量。4 - 1 為了獲得 011 這樣的二進制值。不推薦 user_order_$->{Math.abs(user_id.hashCode()) % 2} 作為表的路由
user_order_inline:
type: INLINE
props:
algorithm-expression: user_order_$->{(user_id.hashCode() ^ (user_id.hashCode()) >>> 16) & (4 - 1)}
props:
# 是否在日志中打印 SQL。
# 打印 SQL 可以幫助開發者快速定位系統問題。日志內容包含：邏輯 SQL，真實 SQL 和 SQL 解析結果。
# 如果開啟配置，日志將使用 Topic ShardingSphere-SQL，日志級別是 INFO。false
sql-show: true
# 是否在日志中打印簡單風格的 SQL。false
sql-simple: true
# 用于設置任務處理線程池的大小。每個 ShardingSphereDataSource 使用一個獨立的線程池，同一個 JVM 的不同數據源不共享線程池。
executor-size: 20
# 查詢請求在每個數據庫實例中所能使用的最大連接數。1
max-connections-size-per-query: 1
# 在程序啟動和更新時，是否檢查分片元數據的結構一致性。
check-table-metadata-enabled: false
# 在程序啟動和更新時，是否檢查重復表。false
check-duplicate-table-enabled: false- mode：運行模式，默認就單機模式。
- dataSources：數據庫連接信息。
- rules：路由算法。defaultDatabaseStrategy 庫的路由、tables 表的路由。之后在 shardingAlgorithms 中配置具體的路由算法。這里的名稱都是關聯的，不要配置錯。
- props：一些屬性信息，包括是否打印日志等。
與這個對比，如果你使用的路由功能并不那么大，其實自研會更加簡單。當然你也可以想辦法，簡化 sharding-jdbc 的配置。
3. 配置引入
application-dev.yml
spring:
datasource:
driver-class-name: org.apache.shardingsphere.driver.ShardingSphereDriver
url: jdbc:shardingsphere:classpath:sharding/sharding-jdbc-dev.yaml- 和之前的一些 sharding 版本不同，這里是需要使用具體的 ShardingSphereDriver 和 url 地址，才能加載上我們配置的路由信息。
三、測試驗證
圖片
- 基于工程中 docs/dev-ops/mysql/sql 創建庫表。已經提供了庫名、表和測試數據。
- 無論你使用哪種方式，都可以安裝MySql 并使用可視化工具鏈接。這里小傅哥用的是 Sequel Ace
1. 寫入數據
@Test
public void test_insert() {
for (int i = 0; i < 1000; i++) {
UserOrderPO userOrderPO = UserOrderPO.builder()
.userName("小傅哥")
.userId("xfg_" + RandomStringUtils.randomAlphabetic(6))
.userMobile("+86 13521408***")
.sku("13811216")
.skuName("《手寫MyBatis：漸進式源碼實踐》")
.orderId(RandomStringUtils.randomNumeric(11))
.quantity(1)
.unitPrice(BigDecimal.valueOf(128))
.discountAmount(BigDecimal.valueOf(50))
.tax(BigDecimal.ZERO)
.totalAmount(BigDecimal.valueOf(78))
.orderDate(new Date())
.orderStatus(0)
.isDelete(0)
.uuid(UUID.randomUUID().toString().replace("-", ""))
.ipv4("127.0.0.1")
.ipv6("2001:0db8:85a3:0000:0000:8a2e:0370:7334".getBytes())
.extData("{\"device\": {\"machine\": \"IPhone 14 Pro\", \"location\": \"shanghai\"}}")
.build();
userOrderDao.insert(userOrderPO);
}
}- 測試數據寫入，你可以寫入1000條數據，觀察散列效果。并可以在這個過程中，調試修改 sharding-jdbc-dev.yaml 文件對庫表路由的計算方式。
2. 查詢數據
@Test
public void test_selectByUserId() {
List<UserOrderPO> list = userOrderDao.selectByUserId("xfg_PrmgwQ");
log.info("測試結果：{}", JSON.toJSONString(list));
}- 查詢的用戶ID是已經寫入到數據庫表里的數據，查詢的時候會根據用戶ID繼續路由計算。
3. 散列算法
@Test
public void test_idx() {
for (int i = 0; i < 50; i++) {
String user_id = "xfg_" + RandomStringUtils.randomAlphabetic(6);
log.info("測試結果 {}", (user_id.hashCode() ^ (user_id.hashCode()) >>> 16) & 3);
}
}- 你可以嘗試驗證和編寫新的散列算法，最終目的都是讓數據盡可能散列到庫表。
- 此外，關于算法的好壞，可以基于雪崩測試計算
責任編輯：武曉燕
來源：
bugstack蟲洞棧
