使用sharding-jdbc实现读写分离
简介
读写分离是一种数据库架构设计的模式,主要用于提高数据库的性能和可扩展性。它将数据库的读取操作和写入操作分离到不同的数据库实例上,从而优化系统的负载和响应速度。
实现前提是需要进行主从复制(数据层面的分离)
实现
读写分离实现起来并不麻烦,因为利用了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