在应用层通过spring解决数据库读写分离1.pdf

在应用层通过 spring 解决数据库读写分离

<
>

猎头职位: 上海: Senior Software Engineer

相关文章:
Spring 中事物管理一二配制无限制的 Spring 事务管理不整
合 hibernate 和 spring,只想用 spring 的事务处理，配置文
件...

推荐群组: Hibernate

更多相关推荐


Spring



如何配置 mysql 数据库的主从？
单机配置 mysql 主从：

常见的解决数据库读写分离有两种方案
1、应用层
实现数据库读写分离
目前的一些解决方案需要在程序中手动指定数据源，比较
麻烦，后边我会通过 AOP 思想来解决这个问题。

2、中间件
mysql-proxy：

50fab07
Amoeba for MySQL：
和

此处我们介绍一种在应用层的解决方案，通过 spring 动态
数据源和 AOP 来解决数据库的读写分离。

该方案目前已经在一个互联网项目中使用了，而且可以很
好的工作。

该方案目前支持
一读多写；当写时默认读操作到写库、当写时强制读操作
到读库。

考虑未来支持
读库负载均衡、读库故障转移等。

使用场景
不想引入中间件，想在应用层解决读写分离，可以考虑这
个方案；
建议数据访问层使用 jdbc、ibatis，不建议 hibernate；

优势
应用层解决，不引入额外中间件；
在应用层支持『当写时默认读操作到写库』，这样如果我们
采用这种方案，在写操作后读数据直接从写库拿，不会产
生数据复制的延迟问题；
应用层解决读写分离，理论支持任意数据库。

缺点
1、不支持***@Transactional 注解事务，此方案要求所有读方
法必须是 read-only=true，因此如果是***@Transactional，这
样就要求在每一个读方法头上加***@Transactional 且
readOnly 属性=true，相当麻烦。 :oops:
2、必须按照配置约定进行配置，不够灵活。两种方案方案
1：当只有读操作的时候，直接操作读库（从库）；
当在写事务（即写主库）中读时，也是读主库
（即参与到主库操作），这样的优势是可以防止写完后可能
读不到刚才写的数据；

此方案其实是使用事务传播行为为：SUPPORTS 解决的。
方案 2：当只有读操作的时候，直接操作读库（从库）；
当在写事务（即写主库）中读时，强制走从库，
即先暂停写事务，开启读（读从库），然后恢复写事务。
此方案其实是使用事务传播行为为：NOT_SUPPORTS 解
决的。

核心组件
：读
写分离的动态数据源，类似于
AbstractRoutingDataSource，具体参考 javadoc；

sion：读写库选择的决策者，具体参考 javadoc；

essor：此类实现了两个职责（为了减少类的数量将两个功
能合并到一起了）：读/写动态数据库选择处理器、通过
AOP 切面实现读/写选择，具体参考 javadoc。

具体配置
1、数据源配置