前段时间写了篇如何使用Sharding-JDBC进行分库分表的例子,相信能够感受到Sharding-JDBC的强大了,而且使用配置都非常干净。官方支持的功能还包括读写分离、分布式主键、强制路由等。这里再介绍下如何在分库分表的基础上集成读写分离的功能。
就是为了缓解数据库压力,将写入和读取操作分离为不同数据源,写库称为主库,读库称为从库,一主库可配置多从库。
设置主从库后,第一个问题是如何进行主从的同步。官方不支持主从的同步,也不支持因为主从同步延迟导致的数据不一致问题。工程实践上进行主从同步有很多做法,一种常用的做法是每天定时同步或者实时同步。这个话题太大,暂不展开。
读写可以单独使用,也可以配合分库分表进行使用,由于上个分库分表的例子是基于1.5.4.1
版本进行说明的,这里为了紧跟官方的步伐,升级Sharding-JDBC到最新的2.0.0.M2
项目结构如下:
org.springframework.boot
spring-boot-starter-web
org.mybatis.spring.boot
mybatis-spring-boot-starter
mysql
mysql-connector-java
com.alibaba
druid
io.shardingjdbc
sharding-jdbc-core
io.shardingjdbc
sharding-jdbc-spring-boot-starter
com.google.guava
guava
org.springframework.boot
spring-boot-configuration-processor
org.springframework.boot
spring-boot-starter-test
test
在配置前,我们希望分库分表规则和之前保持一致:
基于
t_user
表,根据city_id
进行分库,如果city_id mod 2
为奇数则落在ds_master_1
库,偶数则落在ds_master_0
库;根据user_id
进行分表,如果user_id mod 2
为奇数则落在t_user_1
表,偶数则落在t_user_0
表
读写分离规则:
读都落在从库,写落在主库
因为使用Sharding-JDBC Spring Boot Starter
,所以只需要在properties配置文件配置主从库的数据源即可:
spring.application.name=spring-boot-mybatis-sharding-jdbc-masterslave
server.context-path=/springboot
mybatis.config-location=classpath:mybatis-config.xml
# 所有主从库
sharding.jdbc.datasource.names=ds_master_0,ds_master_1,ds_master_0_slave_0,ds_master_0_slave_1,ds_master_1_slave_0,ds_master_1_slave_1
# ds_master_0
sharding.jdbc.datasource.ds_master_0.type=com.alibaba.druid.pool.DruidDataSource
sharding.jdbc.datasource.ds_master_0.driverClassName=com.mysql.jdbc.Driver
sharding.jdbc.datasource.ds_master_0.url=jdbc:mysql://127.0.0.1:3306/ds_master_0?useSSL=false
sharding.jdbc.datasource.ds_master_0.username=travis
sharding.jdbc.datasource.ds_master_0.password=
# slave for ds_master_0
sharding.jdbc.datasource.ds_master_0_slave_0.type=com.alibaba.druid.pool.DruidDataSource
sharding.jdbc.datasource.ds_master_0_slave_0.driverClassName=com.mysql.jdbc.Driver
sharding.jdbc.datasource.ds_master_0_slave_0.url=jdbc:mysql://127.0.0.1:3306/ds_master_0_slave_0?useSSL=false
sharding.jdbc.datasource.ds_master_0_slave_0.username=travis
sharding.jdbc.datasource.ds_master_0_slave_0.password=
sharding.jdbc.datasource.ds_master_0_slave_1.type=com.alibaba.druid.pool.DruidDataSource
sharding.jdbc.datasource.ds_master_0_slave_1.driverClassName=com.mysql.jdbc.Driver
sharding.jdbc.datasource.ds_master_0_slave_1.url=jdbc:mysql://127.0.0.1:3306/ds_master_0_slave_1?useSSL=false
sharding.jdbc.datasource.ds_master_0_slave_1.username=travis
sharding.jdbc.datasource.ds_master_0_slave_1.password=
# ds_master_1
sharding.jdbc.datasource.ds_master_1.type=com.alibaba.druid.pool.DruidDataSource
sharding.jdbc.datasource.ds_master_1.driverClassName=com.mysql.jdbc.Driver
sharding.jdbc.datasource.ds_master_1.url=jdbc:mysql://127.0.0.1:3306/ds_master_1?useSSL=false
sharding.jdbc.datasource.ds_master_1.username=travis
sharding.jdbc.datasource.ds_master_1.password=
# slave for ds_master_1
sharding.jdbc.datasource.ds_master_1_slave_0.type=com.alibaba.druid.pool.DruidDataSource
sharding.jdbc.datasource.ds_master_1_slave_0.driverClassName=com.mysql.jdbc.Driver
sharding.jdbc.datasource.ds_master_1_slave_0.url=jdbc:mysql://127.0.0.1:3306/ds_master_1_slave_0?useSSL=false
sharding.jdbc.datasource.ds_master_1_slave_0.username=travis
sharding.jdbc.datasource.ds_master_1_slave_0.password=
sharding.jdbc.datasource.ds_master_1_slave_1.type=com.alibaba.druid.pool.DruidDataSource
sharding.jdbc.datasource.ds_master_1_slave_1.driverClassName=com.mysql.jdbc.Driver
sharding.jdbc.datasource.ds_master_1_slave_1.url=jdbc:mysql://127.0.0.1:3306/ds_master_1_slave_1?useSSL=false
sharding.jdbc.datasource.ds_master_1_slave_1.username=travis
sharding.jdbc.datasource.ds_master_1_slave_1.password=
# 分库规则
sharding.jdbc.config.sharding.default-database-strategy.inline.sharding-column=city_id
sharding.jdbc.config.sharding.default-database-strategy.inline.algorithm-expression=ds_${city_id % 2}
# 分表规则
sharding.jdbc.config.sharding.tables.t_user.actualDataNodes=ds_${0..1}.t_user_${0..1}
sharding.jdbc.config.sharding.tables.t_user.tableStrategy.inline.shardingColumn=user_id
sharding.jdbc.config.sharding.tables.t_user.tableStrategy.inline.algorithmExpression=t_user_${user_id % 2}
# 使用user_id作为分布式主键
sharding.jdbc.config.sharding.tables.t_user.keyGeneratorColumnName=user_id
# 逻辑主从库名和实际主从库映射关系
sharding.jdbc.config.sharding.master-slave-rules.ds_0.masterDataSourceName=ds_master_0
sharding.jdbc.config.sharding.master-slave-rules.ds_0.slaveDataSourceNames=ds_master_0_slave_0, ds_master_0_slave_1
sharding.jdbc.config.sharding.master-slave-rules.ds_1.masterDataSourceName=ds_master_1
sharding.jdbc.config.sharding.master-slave-rules.ds_1.slaveDataSourceNames=ds_master_1_slave_0, ds_master_1_slave_1
测试代码如下:
@RunWith(SpringRunner.class)
@SpringBootTest
public class UserMapperTest {
/** Logger */
private static Logger log = LoggerFactory.getLogger(UserMapperTest.class);
@Resource
private UserMapper userMapper;
@Before
public void setup() throws Exception {
create();
clear();
}
private void create() throws SQLException {
userMapper.createIfNotExistsTable();
}
private void clear() {
userMapper.truncateTable();
}
@Test
public void insert() throws Exception {
UserEntity user = new UserEntity();
user.setCityId(1);
user.setUserName("insertTest");
user.setAge(10);
user.setBirth(new Date());
assertTrue(userMapper.insert(user) > 0);
Long userId = user.getUserId();
log.info("Generated Key--userId:" + userId);
userMapper.delete(userId);
}
@Test
public void find() throws Exception {
UserEntity userEntity = userMapper.find(138734796783222784L);
log.info("user:{}", userEntity);
}
}
先运行insert
方法,插入一条数据后,获取插入的user_id
为138734796783222784L
(每次运行会不一样),由于city_id=1
,读写分离约定,会落在主库,又根据分库规则会落在ds_master_1
,再根据分表规则,会落在t_user_0
再运行find
方法,指定userId,你会发现查出来是空的,这是因为Sharding-JDBC不支持主从同步以及主从同步延迟造成的数据不一致。这里我们显然术语第一种,因为根本就没有进行主从同步,那么从从库读取肯定是空的。
我们可以反向推理下,假如开启了主从同步,现在数据落在主库ds_master_1
,这个主库有两个从库:ds_master_1_slave_0
和ds_master_1_slave_1
,所以我们可以往这两个主库的t_user_0
表插入刚才的数据,语句如下:
INSERT INTO t_user_0(user_id,city_id,user_name,age,birth) values(138734796783222784,1,'insertTest',10,'2017-11-18 00:00:00');
先往ds_master_1_slave_0
的t_user_0
表插入该条数据,可以理解为主库同步到从库的数据。重新运行find
方法,发现返回的数据和主库的一致,表明Sharding-JDBC从ds_master_1
的从库ds_master_1_slave_0
的t_user_0
表查到了数据。
再删掉ds_master_1_slave_0
的t_user_0
表的数据,往ds_master_1_slave_1
的t_user_0
表插入刚才那条数据,重新运行发现返回的结果为空,表明从ds_master_1
的从库ds_master_1_slave_1
的t_user_0
表没有查到数据。
最后往ds_master_1_slave_0
的t_user_0
表重新插入刚才的数据,再运行发现又返回了数据。
基于以上现象,可以推论选择从库查询的时候经过了某种算法得到访问的从库,然后在从库根据分表规则查询数据。
这里包括几个问题:
MasterSlaveDataSource
RoundRobinMasterSlaveLoadBalanceAlgorithm
得到从库数据源,拿到连接后就开始执行具体的SQL查询了,这里通过PreparedStatementExecutor.execute()
得到执行结果MasterSlaveDataSource:
public class MasterSlaveDataSource extends AbstractDataSourceAdapter {
private static final ThreadLocal DML_FLAG = new ThreadLocal() {
@Override
protected Boolean initialValue() {
return false;
}
};
// 主从配置关系
private MasterSlaveRule masterSlaveRule;
public MasterSlaveDataSource(final MasterSlaveRule masterSlaveRule) throws SQLException {
super(getAllDataSources(masterSlaveRule.getMasterDataSource(), masterSlaveRule.getSlaveDataSourceMap().values()));
this.masterSlaveRule = masterSlaveRule;
}
private static Collection getAllDataSources(final DataSource masterDataSource, final Collection slaveDataSources) {
Collection result = new LinkedList<>(slaveDataSources);
result.add(masterDataSource);
return result;
}
...省略部分代码
// 获取数据源
public NamedDataSource getDataSource(final SQLType sqlType) {
// 强制路由到主库查询
if (isMasterRoute(sqlType)) {
DML_FLAG.set(true);
return new NamedDataSource(masterSlaveRule.getMasterDataSourceName(), masterSlaveRule.getMasterDataSource());
}
// 获取选中的从库数据源
String selectedSourceName = masterSlaveRule.getStrategy().getDataSource(masterSlaveRule.getName(),
masterSlaveRule.getMasterDataSourceName(), new ArrayList<>(masterSlaveRule.getSlaveDataSourceMap().keySet()));
DataSource selectedSource = selectedSourceName.equals(masterSlaveRule.getMasterDataSourceName())
? masterSlaveRule.getMasterDataSource() : masterSlaveRule.getSlaveDataSourceMap().get(selectedSourceName);
Preconditions.checkNotNull(selectedSource, "");
return new NamedDataSource(selectedSourceName, selectedSource);
}
MasterSlaveRule:
public final class MasterSlaveRule {
// 名称(这里是ds_0和ds_1)
private final String name;
// 主库数据源名称(这里是ds_master_0和ds_master_1)
private final String masterDataSourceName;
// 主库数据源
private final DataSource masterDataSource;
// 所属从库列表,key为从库数据源名称,value是真实的数据源
private final Map slaveDataSourceMap;
// 主从库负载均衡算法
private final MasterSlaveLoadBalanceAlgorithm strategy;
RoundRobinMasterSlaveLoadBalanceAlgorithm:
// 轮询负载均衡策略,按照每个从节点访问次数均衡
public final class RoundRobinMasterSlaveLoadBalanceAlgorithm implements MasterSlaveLoadBalanceAlgorithm {
private static final ConcurrentHashMap COUNT_MAP = new ConcurrentHashMap<>();
@Override
public String getDataSource(final String name, final String masterDataSourceName, final List slaveDataSourceNames) {
AtomicInteger count = COUNT_MAP.containsKey(name) ? COUNT_MAP.get(name) : new AtomicInteger(0);
COUNT_MAP.putIfAbsent(name, count);
count.compareAndSet(slaveDataSourceNames.size(), 0);
return slaveDataSourceNames.get(count.getAndIncrement() % slaveDataSourceNames.size());
}
}
DefaultResultSetHandler:
@Override
public List