【微信名字wid】使用Sharding-JDBC解决数据库读写分离查询延迟问题-拍拖百科

前言

一般熟悉Mysql数据库的朋友都知道，当表中的数据量达到千万级别时，sql查询会逐渐变慢，经常成为系统的瓶颈。为了提高程序性能，除了在表字段中使用索引(如主键索引、唯一索引、常规索引等)、优化程序代码和SQL语句等常用方法外，还建议您使用数据库主从读写分离(主/从)方案。但是，这种分离体系结构通常存在数据读写一致性问题。

数据读写一致性问题

主从库同步逻辑

主库主负责“写入”，数据库的BinLog日志记录通过I/O线程将异步操作同步到从属库(“读取”)，因此每当业务系统发送select语句时，都会直接路由到库而不是主库查询数据。

但是，这种同步逻辑存在数据延迟问题的严重缺陷。

我们可以想象这样的场景。

如果程序需要在更新数据后立即查询更新的数据，真的可以查询更新的数据吗？

答案是：不一定！

这是因为在主从数据同步时是异步操作，在主从同步期间可能会出现数据延迟问题，通常，如果主库的写入数据量很小，则无法查询数据。但是，随着时间的推移，使用系统的用户越来越多，数据无法查询的情况会越来越糟。

Sharding-JDBC

Sharding-JDBC定位为轻量级Java框架，这是Java的JDBC层提供的附加服务。

使用客户端直接连接数据库，以jar软件包提供服务，无需额外的部署和依赖。它被识别为增强版JDBC驱动程序，与JDBC和各种ORM框架完全兼容。

适用于所有基于JDBC的ORM框架，如Jpa、hibernate、mybatis、spring JDBC template或直接使用JDBC。支持所有第三方数据库连接池，如Dbcp、c3p0、bonecp、druid、hikaricp等。实现JDBC规范的所有数据库支持；当前符合MySQL、Oracle、SQL server、PostgreSQL和SQL92标准的所有数据库支持读写分离特性

提供主从读写分离配置，可以独立使用，也可以与子库子表一起使用。在同一个调用线程上执行多个语句。如果在此处发现未读取的作业，则所有后续读取作业都将从主库读取。Spring命名空间。基于Hint的强制主库路由ShardingSphere-JDBC公式提供了HintManager切片密钥管理器，可通过调用()强制路由到主库查询。这有助于解决数据延迟问题，使您可以随时从基础库主服务器查询最新数据，而无需在库中查询。

hint manager hint manager=Hin()；

()；

实际案例

核心依赖性

Dependency

GroupIdio.shardingjdbc/groupId

artifact dsharding-JDBC-core/artifact id

版本$ {}/版本

/dependency数据库配置

Sharding:

Jdbc:

Data-sources:

Mvip:

Type:com.alibaba.druid .

驱动程序-类-名称： com.my

URL : JDBC : MySQL ://$ { } : $ { }/Unicom _ portal？allowmultiqueries=trueuseunicode=truecharacterencoding=utf-8 use SSL=false

Username: ${}

Password: ${}

svip: type: com.alibaba.druid. driver-class-name: com.my url: jdbc:mysql://${}:${}/unicom_portal?allowMultiQueries=true&useUnicode=true&characterEncoding=UTF-8&useSSL=false username: ${} password: ${} master-slave-rule: name: ds_ms master-data-source-name: mvip slave-data-source-names: svip load-balance-algorithm-type: round_robin

源初始化配置类

@Data
@ConfigurationProperties(prefix = ";)
public class MasterSlaveConfig {
    private Map<String, DruidDataSource> dataSources = new HashMap<>();
   private MasterSlaveRuleConfiguration masterSlaveRule;
}
@ConditionalOnCla)
   @EnableConfigurationPropertie)
   @ConditionalOnProperty({
           ";,
           ";
})
static class ShardingDruid extends DruidConfig {
       @Autowired
       private MasterSlaveConfig masterSlaveConfig;
       @Bean("masterSlaveDataSource")
       public DataSource dataSource() throws SQLException {
           ma().forEach((k, v) -> configDruidParams(v));
           Map<String, DataSource> dataSourceMap = Ma();
           da(ma());
           DataSource dataSource = Ma(dataSourceMap, ma(), Ma());
           return dataSource;
       }
       @Bean
       public PlatformTransactionManager txManager(DataSource dataSource) {
           return new DataSourceTransactionManager(dataSource);
       }
       private void configDruidParams(DruidDataSource druidDataSource) {
           druidDa(20);
           druidDa(1);
           // 配置获取连接等待超时的时间
           druidDa(10000);
           druidDa(1);
           // 配置间隔多久才进行一次检测，检测需要关闭的空闲连接，单位是毫秒
           druidDa(60000);
           // 配置一个连接在池中最小生存的时间，单位是毫秒 超过这个时间每次会回收默认3个连接
           druidDa(30000);
           // 线上配置的mysql断开闲置连接时间为1小时,数据源配置回收时间为3分钟,以最后一次活跃时间开始算
           druidDa(180000);
           // 连接最大存活时间，默认是-1(不限制物理连接时间)，从创建连接开始计算，如果超过该时间，则会被清理
           druidDa(15000);
           druidDa("select 1");
           druidDa(true);
           druidDa(false);
           druidDa(false);
           druidDa(true);
           druidDa(20);
           druidDa(true);
           druidDa(true);
           druidDa(true);
           druidDaTimeout(180);
           try {
               druidDa("stat,slf4j");
               List filterList = new ArrayList<>();
               (wallFilter());
               druidDa(filterList);
           } catch (SQLException e) {
               e.printStackTrace();
           }
       }
   }

强制路由到主库查询关键代码：

public ArticleEntity getWithMasterDB(Long id, String wid) {
  HintManager hintManager = Hin() ;
  ();
  ArticleEntity article = ba(id, wid);
}

通过强制路由到主库查询有个风险，对于更新并实时查询业务场景比较多，如果都切到主库查询，势必会对主库服务器性能造成影响，可能还会影响到主从数据同步，所以要根据实际业务场景评估采用这种方式带来的系统性能问题。

另外，如果业务层面可以做妥协的话，尽量减少这种更新并实时查询方式，一种思路是实时更新库，利用 Java Future 特性异步查询（例如更新后，睡眠1-2秒再查询），伪代码如下：


Callable c1 = new Callable(){
  @Override
  public String call() throws Exception {
    ArticleEntity articleEntity = null
    try {
         T(2000);
         articleEntity = ar(id)
     } catch (InterruptedException e) {
         e.printStackTrace();
     }
    return articleEntity;
  }
};
FutureTask<ArticleEntity> f = new FutureTask<ArticleEntity>(c1);
new Thread(f).start();
ArticleEntity article = f.get()

后台私信回复 1024 免费领取微服务、SpringCloud&SpringBoot，微信小程序、Java面试等视频资料。