1. 程式人生 > >基於噹噹開源shardingjdbc的分庫分表的配置-單主鍵分庫分表策略配置

基於噹噹開源shardingjdbc的分庫分表的配置-單主鍵分庫分表策略配置

由於最近在做公司各種中介軟體的替換方案調研,其中就有調研到噹噹已經開源的shardingjdbc。

今天搞了一天,從一頭霧水到慢慢的撥開了迷霧。

最搞的是,分庫分表規則的配置,結合我們自己的實際使用場景,分庫分表規則採用的是單一主鍵,並不是gitgub上提供的demo,採用userid分庫,orderid分表的策略。

著實被搞了一天。

官網的配置如下。

<beanid="dbtbl_0"class="org.apache.commons.dbcp.BasicDataSource"destroy-method="close">
        <propertyname="driverClassName"
value="com.mysql.jdbc.Driver"/>
<propertyname="url"value="jdbc:mysql://localhost:3306/dbtbl_0"/> <propertyname="username"value="root"/> <propertyname="password"value=""/> </bean> <beanid="dbtbl_1"class="org.apache.commons.dbcp.BasicDataSource"destroy-method
="close">
<propertyname="driverClassName"value="com.mysql.jdbc.Driver"/> <propertyname="url"value="jdbc:mysql://localhost:3306/dbtbl_1"/> <propertyname="username"value="root"/> <propertyname="password"value=""/> </bean> <rdb:strategy
id="databaseStrategy"sharding-columns="user_id"algorithm-class="com.dangdang.ddframe.rdb.sharding.spring.algorithm.SingleKeyModuloDatabaseShardingAlgorithm"/>
<rdb:strategyid="tableStrategy"sharding-columns="order_id"algorithm-class="com.dangdang.ddframe.rdb.sharding.spring.algorithm.SingleKeyModuloTableShardingAlgorithm"/> <rdb:data-sourceid="shardingDataSource"> <rdb:sharding-ruledata-sources="dbtbl_0,dbtbl_1"default-data-source="dbtbl_0"> <rdb:table-rules> <rdb:table-rulelogic-table="t_order"actual-tables="t_order_${0..3}"table-strategy="tableStrategy"/> <rdb:table-rulelogic-table="t_order_item"actual-tables="t_order_item_${0..3}"database-strategy="databaseStrategy"table-strategy="tableStrategy"/> </rdb:table-rules> <rdb:binding-table-rules> <rdb:binding-table-rulelogic-tables="t_order, t_order_item"/> </rdb:binding-table-rules> <rdb:default-database-strategysharding-columns="none"algorithm-class="com.dangdang.ddframe.rdb.sharding.api.strategy.database.NoneDatabaseShardingAlgorithm"/> </rdb:sharding-rule> <rdb:props> <propkey="metrics.enable">true</prop> </rdb:props>

根據我們自己的實際場景,

我的分表鍵只有id,所以簡單的按照這種配置是無法完成的,跑各種測試,資料的分散均達不到想要的效果。

目標:測試環境分2庫4表後的物理檢視如下:

db_0

|---order_0

|---order_1

db_1

|---order_2

|---order_3


兩個不同的物理庫,但是order表的物理庫的字尾需要從0開始遞增,這樣才能滿足現行環境的替換,否則還要重新命名,做路由。

嘗試一:根據官網提供的demo嘗試分庫分表,具體配置如下:


這樣庫表的物理檢視如下:

db_0

|---order_0

|---order_1

|---order_2

|---order_3

db_1

|---order_0

|---order_1

|---order_2

|---order_3

各種跑測試用例,均不能實現。期間還遇到了各種各樣的錯誤。且資料也無法均勻的散落的每個庫裡。

偶然情況下,靈機一動,調整一下分庫的策略。

這裡注意一下,如果是2庫4表的話,

algorithm-expression="dbtbl_${(id.longValue() / 2).longValue() % 2}"。這個表示式裡的第一個2的含義是每個庫裡表表數。第二個代表的是庫數。

如果分成2庫6表,則每個庫裡有三個表,則配置成

algorithm-expression="dbtbl_${(id.longValue() / 3).longValue() % 2}"

<!-- 自定義規則  -->
<rdb:strategy id="databaseStrategy" sharding-columns="id"
algorithm-expression="dbtbl_${(id.longValue() / 2).longValue() % 2}"/>
<!--  分表規則  -->
<rdb:strategy id="orderTableStrategy" sharding-columns="id" algorithm-expression="b_order_${id.longValue() % 4}"/>

如上配置:在分庫的時候,根據分片主鍵id,先除以2, 然後取模2,這樣就可以了。

測試了一萬條資料,4個表裡,每個表的資料都是2500條,即完美實現了資料的散落。

以上僅是個人的使用經驗,也希望對後來的同學有所幫助。如果錯誤,也可以聯絡我進行糾正。