奉节集团网站建设,深圳的网站,一家专门做护肤的网站,建筑工程包括哪些内容简介
读写分离是一种数据库架构设计的模式#xff0c;主要用于提高数据库的性能和可扩展性。它将数据库的读取操作和写入操作分离到不同的数据库实例上#xff0c;从而优化系统的负载和响应速度。
实现前提是需要进行主从复制#xff08;数据层面的分离#xff09;
实现…简介
读写分离是一种数据库架构设计的模式主要用于提高数据库的性能和可扩展性。它将数据库的读取操作和写入操作分离到不同的数据库实例上从而优化系统的负载和响应速度。
实现前提是需要进行主从复制数据层面的分离
实现
读写分离实现起来并不麻烦因为利用了sharding-jdbc中间件帮我们实现
引入sharding依赖
!--依赖sharding--
dependencygroupIdorg.apache.shardingsphere/groupIdartifactIdsharding-jdbc-spring-boot-starter/artifactIdversion${sharding-sphere.version}/version
/dependency
dependencygroupIdorg.apache.shardingsphere/groupIdartifactIdsharding-core-common/artifactIdversion${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?useUnicodetruecharacterEncodingutf8tinyInt1isBitfalseuseSSLfalseserverTimezoneGMTusername: 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?useUnicodetruecharacterEncodingutf8tinyInt1isBitfalseuseSSLfalseserverTimezoneGMTusername: 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?useUnicodetruecharacterEncodingutf8tinyInt1isBitfalseuseSSLfalseserverTimezoneGMTusername: 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
