mysql读写分离方案比较

Question

最近有个springmvc+ibatis项目需要做mysql读写分离，目前查询到以下几个方案

1.应用层.

通过spring管理datasource的route,由aop或程序控制读写数据源.

2.中间件.

中间件维护主从数据关系,对应用层提供统一访问接口.完全解除程序耦合

3.mysql驱动

ReplicationDriver提供主从库访问的驱动,看了下原代码是保持了多个数据源的链接并根据readOnly true/false来选择数据源.相当于应用层解决方案的一个现有实现,耦合程度更低,扩展性更弱.并且貌似不能使用其他驱动.

目前比较倾向于中间件解决,求教一下对于诸如(写 读 写)这样的事务处理能否解决,有无其它影响程序结构的问题?

mysql-proxy、atlas、amoeba、tddl、cobar等中间件各自有何优劣?

Answer 1

@Sean_Liu 请问下，你现在使用的是哪种解决方案？

Answer 2

你在通过spring管理datasource的route,由aop切换数据源来控制读写分离的时候没有遇到什么问题吗？

Answer 3

比如事务问题。如果自定义aop会于spring自带的事务的aop有个先后顺序执行问题。

Answer 4

这个时候你肯定先获取数据源在获取事务吧，这个时候就会有个问题。我在做注册的时候肯定先查询账号是否存在不，如果不存在就插入，那么问题来了，在这个Service里面要获取两次数据源 但是他只是获取了一次 这就是一个问题。。我感觉还会有很多类似问题。比如切换数据源失败等等

Answer 5

360的mysql proxy据说还是不错的。等待楼主的测试数据

Answer 6

嗯,是中间件的一个,lua对高并发表现得不够理想.Amoeba重写后听说性能更好,但都对事务不大支持的样子

Answer 7

回复
还有一点 如果说的读写分离是基于主从复制的话，一定要注意某些读操作仍然需要在主机读的，而不是说完全的读写分离

Answer 8

mysql-proxy + lua脚本 见过这样用的 算中间件吧

Answer 9

TDDL（Taobao Distributed Data Layer）是分布式数据库访问引擎。它的作用是将sql路由到正确的分库、分表中去执行，并将执行结果进行汇总、返回。上层可以像单库单表一样使用数据源，无需知道分布式数据库的细节。