当前位置：首页 > news >正文

使用sharding-jdbc实现读写分离

news 2025/12/29 22:14:34

简介

读写分离是一种数据库架构设计的模式，主要用于提高数据库的性能和可扩展性。它将数据库的读取操作和写入操作分离到不同的数据库实例上，从而优化系统的负载和响应速度。

实现前提是需要进行主从复制（数据层面的分离）

实现

读写分离实现起来并不麻烦，因为利用了sharding-jdbc中间件帮我们实现

引入sharding依赖

<!--依赖sharding-->
<dependency><groupId>org.apache.shardingsphere</groupId><artifactId>sharding-jdbc-spring-boot-starter</artifactId><version>${sharding-sphere.version}</version>
</dependency>
<dependency><groupId>org.apache.shardingsphere</groupId><artifactId>sharding-core-common</artifactId><version>${sharding-sphere.version}</version>
</dependency>

配置yml文件

server:port: 8085
spring:main:allow-bean-definition-overriding: trueshardingsphere:# 参数配置，显示sqlprops:sql:show: true# 配置数据源datasource:# 给每个数据源取别名，下面的ds1,ds2,ds3任意取名字names: ds1,ds2,ds3# 给master-ds1每个数据源配置数据库连接信息ds1:# 配置druid数据源type: com.alibaba.druid.pool.DruidDataSourcedriver-class-name: com.mysql.cj.jdbc.Driverurl: jdbc:mysql://47.115.94.78:3306/dbname?useUnicode=true&characterEncoding=utf8&tinyInt1isBit=false&useSSL=false&serverTimezone=GMTusername: rootpassword: mkxiaoer1986.maxPoolSize: 100minPoolSize: 5# 配置ds2-slaveds2:type: com.alibaba.druid.pool.DruidDataSourcedriver-class-name: com.mysql.cj.jdbc.Driverurl: jdbc:mysql://114.215.145.201:3306/dbname?useUnicode=true&characterEncoding=utf8&tinyInt1isBit=false&useSSL=false&serverTimezone=GMTusername: rootpassword: mkxiaoer1986.maxPoolSize: 100minPoolSize: 5# 配置ds3-slaveds3:type: com.alibaba.druid.pool.DruidDataSourcedriver-class-name: com.mysql.cj.jdbc.Driverurl: jdbc:mysql://114.215.145.201:3306/dbname?useUnicode=true&characterEncoding=utf8&tinyInt1isBit=false&useSSL=false&serverTimezone=GMTusername: rootpassword: mkxiaoer1986.maxPoolSize: 100minPoolSize: 5# 配置默认数据源ds1sharding:# 默认数据源，主要用于写，注意一定要配置读写分离 ,注意：如果不配置，那么就会把三个节点都当做从slave节点，新增，修改和删除会出错。default-data-source-name: ds1# 配置数据源的读写分离，但是数据库一定要做主从复制masterslave:# 配置主从名称，可以任意取名字name: ms# 配置主库master，负责数据的写入master-data-source-name: ds1# 配置从库slave节点slave-data-source-names: ds2,ds3# 配置slave节点的负载均衡均衡策略，采用轮询机制load-balance-algorithm-type: round_robin
# 整合mybatis的配置XXXXX
mybatis:mapper-locations: classpath:mapper/*.xmltype-aliases-package: com.xuexiangban.shardingjdbc.entity

这样就完成了

问题

使用限制

这里是官网给出的线程
1.不处理主库和从库的数据同步
2.不处理主库和从库的数据同步延迟导致的数据不一致
3.不支持主库多写
4.不处理主从库间的事务一致性。主从模型中，事务中的数据读写均用主库。

不处理主库和从库的数据同步

简单的说就是主从同步是数据库层面，sharing-jdbc只是中间件不处理这个过程

不处理主库和从库的数据同步延迟导致的数据不一致

主从复制通常会有一定的延迟，尤其是在数据量大或网络条件不佳的情况下，从库的数据可能会滞后于主库。如果你的应用在从库上读取数据，可能会读取到过时的数据。Sharding-JDBC 不处理这种由同步延迟导致的数据不一致问题，因为它不负责同步机制。你需要自己处理这个问题，比如通过一些策略确保读取最新的数据（例如始终从主库读取数据）。

不支持主库多写

sharding-jdbc只支持一个主库

不处理主从库间的事务一致性。主从模型中，事务中的数据读写均用主库。

事务一致性指的是，在分布式系统中，所有涉及到的操作必须在一个事务中保持一致。Sharding-JDBC 不处理主从库之间的事务一致性，意味着它不会确保主库和从库之间的数据一致性。在主从架构中，事务操作默认都是发生在主库上的，也就是说，读写操作都在主库完成，这样可以保证事务的一致性。
从库不参与，因为有延迟

事务的一致性和延迟问题

由于主库和从库之间的数据同步是异步的（除非你使用同步复制），从库的数据可能会有一定的延迟。因此，在事务中进行的读操作和写操作之间，如果存在时间差，可能会出现数据不一致的情况。

举个例子，如果你有三个事务：

第一个和第二个事务是UPDATE操作，它们会修改主库的数据。
第三个事务是SELECT操作，如果这个查询在从库上执行，它有可能读取到旧的数据，因为从库的数据更新还没有完全同步到最新状态。

事务中的二进制文件是怎么同步的

主库中的作用修改操作都会记录到binlog,每个线程连接都是单独的操作，日志里面会有相应的记录，因此是可能会出现从库延迟情况
例如有一个事务begin,update,update,commit,这四条会依次发送给binlog

简介

实现