由於最近在做公司各種中介軟體的替換方案調研，其中就有調研到噹噹已經開源的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條，即完美實現了資料的散落。

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