mysql读写分离原因_MySQL读写分离的方法及思考

MySQL读写分离的方法及思考

在实际的项目中我们可能经常会考虑做Mysql读写分离，把Mysql的读操作和写操作

分别放到不同的服务器实例上，而这些实例之间从写的实例上进行复制操作。

做读写分离的部署主要的原因：增加了整个数据库系统的吞吐量.由于Mysql的免

费和基于x86版本的服务器成本不高，使部署大规模的只读服务场成为了可能。

Mysql的读写分离的目前主要方法可以分为以下几类:1,基于中间件模式，比如Mysql自己的mysql-proxy,

国内360基于Mysql-proxy修改的atlas;2,应用程序实现；3，基于Galera的集群.

基于中间件的方式主要是过程是应用程序连接到中间件所在的服务器ip,由中间件对客户端的请求

语句进行分析，根据操作的类型不同被路由到不同的服务器上去.比如解析select，请求被转发到只读服务器(

等于从库)上去.这种方式的好处在于应用程序不需要做任修改，直接部署中间件，连接到中间件即可。

但是数据一致性风险较高，在这种严格要求数据一致性场景下并不适用。因为写和读服务器之间是通过

异步复制(半同步复制)来实现的，读写之间必定存在一定的延迟.

基于应用程序的实现的方式是在应用程序设计阶段，分别定义写和只读数据源，根据操作类型和对时间的敏

感程度不同，分别使用不同的数据源.比如DBA保证只读服务器和写服务器之间有十秒的延迟,这样应用程序在做一

些基于时间条件的查询，比如半个小时以前数据，就可以切到只读服务器上去.可见这种方法的好处是应用程序

可以较好的控制一致性问题，但是需要对于应用程序需要在设计阶段做好，或是做很大的修改。

基于Galera的集群，集群节点之前通过全同步复制来实现数据的实时一致性，但是Galera写的时候使用的是

分布式事务，响应时间可能会到影响。如果部署的话应用程序可以连接任意节点都是一样的。Galera也有自己的

局限性，详情可以参考我之前的文章(http://blog.chinaunix.net/uid-20785090-id-4644761.html)