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

骑猪看日落 2022-08-09 02:09 116阅读 0赞

###     ###

### 转载自开涛的博客：http://jinnianshilongnian.iteye.com/blog/1720618 ###

###     ###

### 如何配置mysql数据库的主从？ ###

单机配置mysql主从：[http://my.oschina.net/god/blog/496][http_my.oschina.net_god_blog_496]

### 常见的解决数据库读写分离有两种方案 ###

**1、应用层**

[**http://neoremind.net/2011/06/**spring实现数据库读写分离][http_neoremind.net_2011_06_spring]

目前的一些解决方案需要在程序中手动指定数据源，比较麻烦，后边我会通过AOP思想来解决这个问题。

**2、中间件**

mysql-proxy：[http://hi.baidu.com/geshuai2008/item/0ded5389c685645f850fab07][http_hi.baidu.com_geshuai2008_item_0ded5389c685645f850fab07]

Amoeba for MySQL：[http://www.iteye.com/topic/188598][http_www.iteye.com_topic_188598]和[http://www.iteye.com/topic/1113437][http_www.iteye.com_topic_1113437]

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

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

### 该方案目前支持 ###

一读多写；当写时默认读操作到写库、当写时强制读操作到读库。

### 考虑未来支持 ###

读库负载均衡、读库故障转移等。

### 使用场景 ###

不想引入中间件，想在应用层解决读写分离，可以考虑这个方案；

建议数据访问层使用jdbc、ibatis，不建议hibernate。

### 优势 ###

应用层解决，不引入额外中间件；

在应用层支持『当写时默认读操作到写库』，这样如果我们采用这种方案，在写操作后读数据直接从写库拿，不会产生数据复制的延迟问题；

应用层解决读写分离，理论支持任意数据库。

### 缺点 ###

1、不支持@Transactional注解事务，此方案要求所有读方法必须是read-only=true，因此如果是@Transactional，这样就要求在每一个读方法头上加@Transactional 且readOnly属性=true，相当麻烦。 :oops:

2、必须按照配置约定进行配置，不够灵活。

### 两种方案 ###

### ![ebfdc7b0-f06a-3bcc-8622-9d424432132b.jpg][]       ###

方案1：当只有读操作的时候，直接操作读库（从库）；

当在写事务（即写主库）中读时，也是读主库（即参与到主库操作），这样的优势是可以防止写完后可能读不到刚才写的数据；

此方案其实是使用事务传播行为为：SUPPORTS解决的。

![b98f6123-8c63-3ec7-b2c1-54e3e439df92.jpg][]

方案2：当只有读操作的时候，直接操作读库（从库）；

当在写事务（即写主库）中读时，强制走从库，即先暂停写事务，开启读（读从库），然后恢复写事务。

此方案其实是使用事务传播行为为：NOT\_SUPPORTS解决的。

### 核心组件 ###

cn.javass.common.datasource.ReadWriteDataSource：读写分离的动态数据源，类似于AbstractRoutingDataSource，具体参考javadoc；

cn.javass.common.datasource.ReadWriteDataSourceDecision：读写库选择的决策者，具体参考javadoc；

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

### 具体配置 ###

**1、数据源配置**

1.1、写库配置