MY SQL 的读写分离

每日一句

去过的地方越多，越知道自己想回到什么地方去。见过的人越多，越知道自己真正想待在什么人身边. from 夏正正

MY SQL 读写分离

1

MySQL读写分离原理

MySQL的主从复制和MySQL的读写分离两者有着紧密联系，首先部署主从复制，只有主从复制完了，才能在此基础上进行数据的读写分离。

这就是典型的并发问题，单机数据库承担了太多的请求，导致作者无法提交编辑的内容。一个直觉的想法是，多加几台服务器，把压力分担到多台服务器上，但是这样会带来一个问题，多台数据库之间的数据同步，这是一个很复杂的问题，一个简化的方案是主从结构 - 一台主库负责写，多台从库负责读，这样数据同步方案就会变得简单，让所有的从库及时从主库同步数据即可。而这正是前面介绍的 - MySQL主从复制（BinaryLog）。

2

在实现上有两种方式

应用层实现：在应用层，比如使用SpringJDBC/myBatis/Hibernate访问数据库时配置多数据源，这些组件会通过算法把请求分流到不同的数据源。

代理实现：这种方式是在应用层和数据库集群之间添加一个代理服务，应用层访问代理，代理根据请求类型(读/写)自动分流到不同的数据库服务器。

3

下面简单的介绍这两种方案

应用层实现

基于应用层实现的读写分离拓扑结构如下图，这种方式在Web层已经决定了读写的方向，所有的写操作写到Master，所有的读操作按一定算法分流到不同的Slave服务器。

基于这种方案的实现，由于应用框架的不同实现方式各不相同，在基于SpringJDBC的框架一种简单的方式，就是定义多个数据库连接，一个MasterDataSource和一个SlaveDataSource。更新数据时我们读取MasterDataSource，查询数据时我们读取SlaveDataSource。

这种做法在只有一个从库（Slave）的情况下还好说，但是有多个从库的时候就不好办了。解决的办法也很多，比如集成 AbstractRoutingDataSource 自己实现算法。

代理实现

代理实现的拓扑结构大概如下图，Web请求集中到单一的数据源（代理），但是代理会重新根据读/写不同，把请求分流到不同的数据服务器。

MySQL-Proxy MySQL官方提供的一个基于代理的负载均衡，可以理解SQL语言，在接收到SQL请求后，会根据请求类型自动把请求分流到Master和Slaves。

注：MySQL-Proxy现在是Alpha版本，不建议在生产环境使用

安装

MySQL-Proxy提供多种安装方式，比较推荐的还是通过官方提供的二进制文件安装（在不支持的平台上，再考虑自己通过源码编译安装）。

shell> cd /usr/local

shell> tar zxf mysql-proxy-0.8.5-platform.tar.gz

安装后可以把 $MYSQL-PROXY-DIR/bin 目录添加到环境变量，方便使用。主要使用 mysql-proxy 命令，这个命令可以用来启动SQL代理。同时设定了主库和从库的地址，这个命令可以使用多次，从而设置多个从库地址.