
业务发展初期,数据库的压力相对较小,这时候使用单独一个库就可以。
引出的问题:如果数据库出现故障,我们的业务就不能使用,只能说是停机重启修复故障。
由于单体带出的问题,这时候我们就需要加一个备用库,紧急情况可以用备库顶上,相当于加一个替补队员。
通过MySQL自带的主从同步机制,就可以放我们的替补队员上线。
当正式队员(主库)发生故障,我们就可以人工让其下线,让替补队员(备库)顶上。
引出的问题:随着业务大规模爆发,主库的压力过大,我们就想让备库承担起更大的责任来。
读写分离架构本质也就是主备架构,与主备架构没有本质区别,就是在主备架构的基础上,增加一层对读写请求的处理,使其能够更大程度上利用备用库为我们分担一些读的压力。
读写分离架构,需要在中间加一层控制读写请求的路由
分库分表的本质上是切分数据,是由于数据量级的提升,不对数据切分会严重影响数据库读写性能。
甚至是如果不切分,磁盘、内存、CPU无法承载这样的压力,数据库随时在奔溃的边缘。
分库分表与前三者是有本质区别的,分库分表后每一个库分片都可以采取以上三种方式的任意一种,可以是单体分片,也可以是主备分片,也可以是做了读写分离的分片。
分库分表和前三者中的一种是共生的关系。
不知道如何进行分库分表设计的可以读我之前的这篇文章《收好这份武林秘籍,让你分库分表再无烦恼》
在应用程序和数据库之间增加代理层,代理层接收应用程序对数据库的请求,根据不同请求类型转发到不同的实例,实现读写分离的同时还可以实现负载均衡(读请求按照负载均衡的规则传入各个从节点)。
代理也就是借助中间件的方式,控制不同类型请求,进入不同的数据库。
目前常用的mysql的读写分离中间件有:
在程序中进行控制,我们利用持久层框架的拦截器实现,动态路由不同数据源。
利用Sharding-JDBC也可以实现
实现思路:
主从复制模式,一般都是异步写数据到从库,当然这个异步也可以设置为同步,只有当从库写完成,主库上的写请求才能返回。
这种方案是最佳单也是最有效的一种,但也是性能最差的一种,尤其是有大量从库的情况下,严重影响请求效率。
写请求时缓存记录一个key,这个key的失效时间设置为主从同步的延时,读请求的时候先去缓存中确认是否存在key,如果key存在说明发生了写请求,数据未同步到从库,这时走主库即可,若不存在这个key,直接走从库的查询即可。
中间件应该也是可以判断是否同步完成,与使用缓存记录类似。
这种方案最大的弊端是引入了缓存,系统复杂度上升。
对于一些特殊的业务场景,采用强制读主库。
弊端,需要把每一个这种情况都找出来,设置成强制走主库。
MySQL 在执行完事务后,会将该事务的 GTID 会给客户端,然后客户端可以使用该命令去要执行读 *** 作的从库中执行,等待该 GTID,等待成功后,再执行读 *** 作;如果等待超时,则去主库执行读 *** 作,或者再换一个从库执行上述流程。
MariaDB 的 MaxScale 就是使用该方案,MaxScale 是 MariaDB 开发的一个数据库智能代理服务(也支持 MySQL),允许根据数据库 SQL 语句将请求转向目标一个到多个服务器,可设定各种复杂程度的转向规则。
有延迟就有延迟,对数据强一致性要求不高的场景可以放任不管。
主要是这几点:
1增加冗余
2增加了机器的处理能力(硬件资源增加了)
3对于读 *** 作为主的应用,使用读写分离是最好的场景因为可以确保写的服务器压力更小而读又可以接受点时间上的延迟
首先声明一点,读写分离只有在读多写少的场景下才能提高性能。
一方面读写分离都是1写+N读的实现,因此READ *** 作可以分散到多台服务器上,性能自然提高。
另一方面,在一个数据库实例下,同表数据经常会遇到锁等待,WRITE时所有的READ *** 作被阻塞,将读写分离,可以很大程度上减轻这种情况。
两种方案
方案1:当只有读 *** 作的时候,直接 *** 作读库(从库);
当在写事务(即写主库)中读时,也是读主库(即参与到主库 *** 作),这样的优势是可以防止写完后可能读不到刚才写的数据;
此方案其实是使用事务传播行为为:SUPPORTS解决的。
方案2:当只有读 *** 作的时候,直接 *** 作读库(从库);
当在写事务(即写主库)中读时,强制走从库,即先暂停写事务,开启读(读从库),然后恢复写事务。
此方案其实是使用事务传播行为为:NOT_SUPPORTS解决的。
核心组件
cnjavasscommondatasourceReadWriteDataSource:读写分离的动态数据源,类似于AbstractRoutingDataSource,具体参考javadoc;
cnjavasscommondatasourceReadWriteDataSourceDecision:读写库选择的决策者,具体参考javadoc;
cnjavasscommondatasourceReadWriteDataSourceProcessor:此类实现了两个职责(为了减少类的数量将两个功能合并到一起了):读/写动态数据库选择处理器、通过AOP切面实现读/写选择,具体参考javadoc。
具体配置
1、数据源配置
11、写库配置
Java代码
<bean id="writeDataSource" class="orglogicalcobwebsproxoolProxoolDataSource">
<property name="alias" value="writeDataSource"/>
<property name="driver" value="${writeconnectiondriver_class}" />
<property name="driverUrl" value="${writeconnectionurl}" />
<property name="user" value="${writeconnectionusername}" />
<property name="password" value="${writeconnectionpassword}" />
<property name="maximumConnectionCount" value="${writeproxoolmaximumconnectioncount}"/>
<property name="minimumConnectionCount" value="${writeproxoolminimumconnectioncount}" />
<property name="statistics" value="${writeproxoolstatistics}" />
<property name="simultaneousBuildThrottle" value="${writeproxoolsimultaneousbuildthrottle}"/>
</bean>
12、读库配置
Java代码
<bean id="readDataSource1" class="orglogicalcobwebsproxoolProxoolDataSource">
<property name="alias" value="readDataSource"/>
<property name="driver" value="${readconnectiondriver_class}" />
<property name="driverUrl" value="${readconnectionurl}" />
<property name="user" value="${readconnectionusername}" />
<property name="password" value="${readconnectionpassword}" />
<property name="maximumConnectionCount" value="${readproxoolmaximumconnectioncount}"/>
<property name="minimumConnectionCount" value="${readproxoolminimumconnectioncount}" />
<property name="statistics" value="${readproxoolstatistics}" />
<property name="simultaneousBuildThrottle" value="${readproxoolsimultaneousbuildthrottle}"/>
</bean>
13、读写动态库配置
通过writeDataSource指定写库,通过readDataSourceMap指定从库列表,从库列表默认通过顺序轮询来使用读库,具体参考javadoc;
Java代码
<bean id="readWriteDataSource" class="cnjavasscommondatasourceReadWriteDataSource">
<property name="writeDataSource" ref="writeDataSource"/>
<property name="readDataSourceMap">
<map>
<entry key="readDataSource1" value-ref="readDataSource1"/>
<entry key="readDataSource2" value-ref="readDataSource1"/>
<entry key="readDataSource3" value-ref="readDataSource1"/>
<entry key="readDataSource4" value-ref="readDataSource1"/>
</map>
</property>
</bean>
2、XML事务属性配置
所以读方法必须是read-only(必须,以此来判断是否是读方法)。
Java代码
<tx:advice id="txAdvice" transaction-manager="txManager">
<tx:attributes>
<tx:method name="save" propagation="REQUIRED" />
<tx:method name="add" propagation="REQUIRED" />
<tx:method name="create" propagation="REQUIRED" />
<tx:method name="insert" propagation="REQUIRED" />
<tx:method name="update" propagation="REQUIRED" />
<tx:method name="merge" propagation="REQUIRED" />
<tx:method name="del" propagation="REQUIRED" />
<tx:method name="remove" propagation="REQUIRED" />
<tx:method name="put" read-only="true"/>
<tx:method name="query" read-only="true"/>
<tx:method name="use" read-only="true"/>
<tx:method name="get" read-only="true" />
<tx:method name="count" read-only="true" />
<tx:method name="find" read-only="true" />
<tx:method name="list" read-only="true" />
<tx:method name="" propagation="REQUIRED"/>
</tx:attributes>
</tx:advice>
3、事务管理器
事务管理器管理的是readWriteDataSource
Java代码
<bean id="txManager" class="orgspringframeworkjdbcdatasourceDataSourceTransactionManager">
<property name="dataSource" ref="readWriteDataSource"/>
</bean>
4、读/写动态数据库选择处理器
根据之前的txAdvice配置的事务属性决定是读/写,具体参考javadoc;
forceChoiceReadWhenWrite:用于确定在如果目前是写(即开启了事务),下一步如果是读,是直接参与到写库进行读,还是强制从读库读,具体参考javadoc;
Java代码
<bean id="readWriteDataSourceTransactionProcessor" class="cnjavasscommondatasourceReadWriteDataSourceProcessor">
<property name="forceChoiceReadWhenWrite" value="false"/>
</bean>
5、事务切面和读/写库选择切面
Java代码
<aop:config expose-proxy="true">
<!-- 只对业务逻辑层实施事务 -->
<aop:pointcut id="txPointcut" expression="execution( cnjavassservice())" />
<aop:advisor advice-ref="txAdvice" pointcut-ref="txPointcut"/>
<!-- 通过AOP切面实现读/写库选择 -->
<aop:aspect order="-2147483648" ref="readWriteDataSourceTransactionProcessor">
<aop:around pointcut-ref="txPointcut" method="determineReadOrWriteDB"/>
</aop:aspect>
</aop:config>
1、事务切面一般横切业务逻辑层;
2、此处我们使用readWriteDataSourceTransactionProcessor的通过AOP切面实现读/写库选择功能,order=IntegerMIN_VALUE(即最高的优先级),从而保证在 *** 作事务之前已经决定了使用读/写库。
6、测试用例
只要配置好事务属性(通过read-only=true指定读方法)即可,其他选择读/写库的 *** 作都交给readWriteDataSourceTransactionProcessor完成。
可以参考附件的:
cnjavassreadwriteReadWriteDBTestWithForceChoiceReadOnWriteFalse
cnjavassreadwriteReadWriteDBTestWithNoForceChoiceReadOnWriteTrue
可以下载附件的代码进行测试,具体选择主/从可以参考日志输出。
以上就是关于数据库读写分离同步延时问题怎么解决全部的内容,包括:数据库读写分离同步延时问题怎么解决、MySQL master/slave 模式的读写分离为什么会提高性能、为什么数据库读写分离可以提高性能等相关内容解答,如果想了解更多相关内容,可以关注我们,你们的支持是我们更新的动力!
欢迎分享,转载请注明来源:内存溢出
微信扫一扫
支付宝扫一扫
评论列表(0条)