基于当当开源shardingjdbc的分库分表的配置-单主键分库分表策略配置

由于最近在做公司各种中间件的替换方案调研，其中就有调研到当当已经开源的shardingjdbc。今天搞了一天，从一头雾水到慢慢的拨开了迷雾。最搞的是，分库分表规则的配置，结合我们自己的实际使用场景，分库分表规则采用的是单一主键，并不是gitgub上提供的demo，采用userid分库，orderid分表的策略。着实被搞了一天。官网的配置如下。

<bean id="dbtbl_0" class="org.apache.commons.dbcp.BasicDataSource" destroy-method="close">
<property name="driverClassName" value="com.mysql.jdbc.Driver"/>
<property name="url" value="jdbc:mysql://localhost:3306/dbtbl_0"/>
<property name="username" value="root"/>
<property name="password" value=""/>
</bean>

<bean id="dbtbl_1" class="org.apache.commons.dbcp.BasicDataSource" destroy-method="close">
<property name="driverClassName" value="com.mysql.jdbc.Driver"/>
<property name="url" value="jdbc:mysql://localhost:3306/dbtbl_1"/>
<property name="username" value="root"/>
<property name="password" value=""/>
</bean>

<rdb:strategy id="databaseStrategy" sharding-columns="user_id" algorithm-class="com.dangdang.ddframe.rdb.sharding.spring.algorithm.SingleKeyModuloDatabaseShardingAlgorithm"/>
<rdb:strategy id="tableStrategy" sharding-columns="order_id" algorithm-class="com.dangdang.ddframe.rdb.sharding.spring.algorithm.SingleKeyModuloTableShardingAlgorithm"/>

<rdb:data-source id="shardingDataSource">
<rdb:sharding-rule data-sources="dbtbl_0,dbtbl_1" default-data-source="dbtbl_0">
<rdb:table-rules>
<rdb:table-rule logic-table="t_order" actual-tables="t_order_${0..3}" table-strategy="tableStrategy"/>
<rdb:table-rule logic-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-rule logic-tables="t_order, t_order_item"/>
</rdb:binding-table-rules>
<rdb:default-database-strategy sharding-columns="none" algorithm-class="com.dangdang.ddframe.rdb.sharding.api.strategy.database.NoneDatabaseShardingAlgorithm"/>
</rdb:sharding-rule>
<rdb:props>
<prop key="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_3db_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条，即完美实现了数据的散落。以上仅是个人的使用经验，也希望对后来的同学有所帮助。如果错误，也可以联系我进行纠正。