SpringBoot 玩转读写分离

环境概览

框架	版本号
Spring Boot	1.5.12.RELEASE
Sharding-JDBC	2.0.3
MyBatis-Plus	2.2.0

前言介绍

Sharding-JDBC是当当网的一个开源项目，只需引入jar便可轻松实现读写分离与分库分表。与MyCat不一样的是，Sharding-JDBC致力于提供轻量级的服务框架，无需额外部署，底层是对JDBC进行加强，兼容各类链接池和ORM框架。不只如此还提供分布式事务及分布式治理功能，即将出世的3.X版本可能会提供更加全面的功能。有兴趣的小伙伴们，能够去了解下，这里提供官方文档、GitHub地址和码云地址。

读写分离

引自Sharding-JDBC官方文档

面对日益增长的系统访问量，数据库的吞吐量面临着巨大瓶颈。 对于同一时间有大量并发读操做和较少写操做类型的应用系统来讲，将单一的数据库拆分为主库和从库，主库负责处理事务性的增删改操做，从库负责处理查询操做，可以有效的避免由数据更新致使的行锁，使得整个系统的查询性能获得极大的改善。 经过一主多从的配置方式，能够将查询请求均匀的分散到多个数据副本，可以进一步的提高系统的处理能力。 使用多主多从的方式，不但可以提高系统的吞吐量，还可以提高系统的可用性，能够达到在任何一个数据库宕机，甚至磁盘物理损坏的状况下仍然不影响系统的正常运行。

虽然读写分离能够提高系统的吞吐量和可用性，但同时也带来了数据不一致的问题，这包括多个主库之间的数据一致性，以及主库与从库之间的数据一致性的问题。而且，读写分离也带来了与数据分片一样的问题，它一样会使得应用开发和运维人员对数据库的操做和运维变得更加复杂。透明化读写分离所带来的影响，让使用方尽可能像使用一个数据库同样使用主从数据库，是读写分离中间件的主要功能。

读写分离，简单来讲，就是将DML交给主数据库去执行，将更新结果同步至各个从数据库保持主从数据一致，DQL分发给从数据库去查询，从数据库只提供读取查询操做。读写分离特别适用于读多写少的场景下，经过分散读写到不一样的数据库实例上来提升性能，缓解单机数据库的压力。

这里解释一下什么是DML和DQL？SQL语言四大分类：DQL、DML、DDL、DCL。

• DQL（Data QueryLanguage）：数据查询语言，好比select查询语句
• DML（Data Manipulation Language）：数据操纵语言，好比insert、delete、update更新语句
• DDL（）：数据定义语言，好比create/drop/alter等语句
• DCL（）：数据控制语言，好比grant/rollback/commit等语句

实现步骤

实现步骤很是简单，仅需两步，便可在代码上实现读写分离功能，感受很是带劲。

1.引入jar包

<dependency>
    <groupId>io.shardingjdbc</groupId>
    <artifactId>sharding-jdbc-core-spring-boot-starter</artifactId>
    <version>2.0.3</version>
</dependency>

2.配置读写分离

sharding:
  jdbc:
    # 配置真实数据源
    datasource:
      names: ds_master_0,ds_slave_0_1,ds_slave_0_2
      # 配置主库
      ds_master_0:
        type: com.zaxxer.hikari.HikariDataSource
        driver-class-name: com.mysql.jdbc.Driver
        jdbc-url: jdbc:mysql://ip:3306/test?useSSL=false&useUnicode=true&characterEncoding=utf8&autoReconnect=true
        username: username
        password: password
        maxPoolSize: 20
      # 配置第一个从库
      ds_slave_0_1:
        type: com.zaxxer.hikari.HikariDataSource
        driver-class-name: com.mysql.jdbc.Driver
        jdbc-url: jdbc:mysql://ip:3307/test?useSSL=false&useUnicode=true&characterEncoding=utf8&autoReconnect=true
        username: username
        password: password
        maxPoolSize: 20
      # 配置第二个从库
      ds_slave_0_2:
        type: com.zaxxer.hikari.HikariDataSource
        driver-class-name: com.mysql.jdbc.Driver
        jdbc-url: jdbc:mysql://ip:3308/test?useSSL=false&useUnicode=true&characterEncoding=utf8&autoReconnect=true
        username: username
        password: password
        maxPoolSize: 20
    # 配置读写分离
    config:
      masterslave:
        # 配置从库选择策略，提供轮询与随机，这里选择用轮询
        load-balance-algorithm-type: round_robin
        name: ds_m_1_s_2
        master-data-source-name: ds_master_0
        slave-data-source-names: ds_slave_0_1,ds_slave_0_2
      sharding:
        props:
          # 开启SQL显示，默认值: false，注意：仅配置读写分离时不会打印日志！！！
          sql:
            show: true

准备测试

在测试开始以前，咱们先明确一点，因为只配置了读写分离，即便上文中配置了sql.show=true也不会有日志打印出来（若是配置了分库/分表就不会有这种状况），那么咱们怎么知道数据库操做究竟是走的主库仍是主库呢？怎么知道若是走从库有没有遵循轮询算法走的具体是哪一个从库呢？

带着上述的疑问，追溯源码进入MasterSlaveDataSource这个类中（友情提示：IDEA连续按两次shift在弹框中输入MasterSlaveDataSource便可查看该类），主要关注其中的getDataSource()方法。下面贴出关键源码。

/**
     * Get data source from master-slave data source.
     *
     * @param sqlType SQL type
     * @return data source from master-slave data source
     */
    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);
    }

    private boolean isMasterRoute(final SQLType sqlType) {
        return SQLType.DQL != sqlType || DML_FLAG.get() || HintManagerHolder.isMasterRouteOnly();
    }

isMasterRoute() 方法判断当前操做是否应该路由到主库数据源，若是SQL类型是DML则返回true

getDataSource() 方法根据SQL类型返回一个数据源。若是SQL类型是DQL则经过配置的算法返回一个从库数据源，若是SQL类型是DML则返回主库数据源。

那么了解了以上两个方法后，经过打断点DEBUG的方式，咱们能够很容易的得知，执行SQL时到底走的是哪一个库。

开始测试

这边我准备了两个测试接口，一个用于测试读操做，一个用于测试写操做。

@RestController
@RequestMapping("/users")
public class UserController {
    @Autowired
    private IUserService userService;

    /**
     * 查询用户列表
     * @return
     */
    @GetMapping
    public List<User> getUser() {
        return userService.selectList(null);
    }

    /**
     * 建立/修改用户信息
     * @param user
     * @return
     */
    @PostMapping
    public User saveUser(@RequestBody User user) {
        return userService.insertOrUpdate(user) ? userService.selectById(user.getId()) : null;
    }
}

发起GET请求/users接口，指望经过轮询算法去从库中查询获取数据

第一次，经过上图咱们能够很容易发现SQL类型是DQL，走的是ds_slave_0_1从数据库，且策略是轮询策略

第二次，咱们能够发现走的是ds_slave_0_2从数据库，读操做和轮询算法都没毛病

发起POST请求/users接口，指望从主库中建立或修改用户数据。

可见，写操做时，走的是ds_master_0主数据库。当userService.insertOrUpdate(user)执行成功返回true后，接着再执行userService.selectById(user.getId())时，又会走到ds_slave_0_1从库读取数据。写操做也没毛病，以上咱们的测试阶段就大功告成了。

轮询策略

有兴趣的小伙伴能够看下轮询策略的源码，很是的简单。这里贴出轮询策略主要源码

/**
 * Round-robin slave database load-balance algorithm.
 *
 * @author zhangliang
 */
public final class RoundRobinMasterSlaveLoadBalanceAlgorithm implements MasterSlaveLoadBalanceAlgorithm {
    
    private static final ConcurrentHashMap<String, AtomicInteger> COUNT_MAP = new ConcurrentHashMap<>();
    
    @Override
    public String getDataSource(final String name, final String masterDataSourceName, final List<String> 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());
    }
}

其内部经过并发容器ConcurrentHashMap与AtomicInteger的CAS保障高并发下计数线程安全，使用无锁的方式比加锁效率更高。

灵活性

Sharding-JDBC使用简单，容易上手且十分灵活，不只可使用默认策略，还可使用自定义的策略。能够说是对Java开发者十分的友好，经过写Java代码的方式就能够实现更加深度的定制化路由规则。这里若是想要自定义轮询策略可使用以下配置来自定义的轮询策略。

sharding:
  jdbc:
    config:
      masterslave:
        load-balance-algorithm-class-name: 自定义算法类的全限定名

注意点

在玩转读写分离时，遇到以下几个须要注意的地方

1. Sharding-JDBC目前仅支持一主多从的结构
2. Sharding-JDBC没有提供主从同步的实现，该功能须要本身额外搭建，可参照《基于Docker搭建MySQL主从复制》简易搭建测试使用
3. 主库和从库的数据同步延迟致使的数据不一致问题须要本身去解决
4. Sharding-JDBC虽然提供了打印SQL日志的开关，可是若是仅配置了读写分离好像是没有用的
5. 文中配置使用的是HikariCP链接池，使用其余链接池时，须要将jdbc-url配置名该为url，不然可能会抛异常

总结

这一篇，简单带你们用Java代码实现了读写分离，下一篇预计会带你们玩一下数据库的分库分表。