MySQL的读写分离的实现，有两种方式，第一种方式即我们手动在代码层实现逻辑，来解析读请求或者写请求，分别分发到不同的数据库中，实现读写分离；第二种方式就是基于MyCat中间件来实现读写分离的效果；这两种方式我都会在这篇博客中进行详细地介绍、搭建，并且分析其中的优劣。
从MySQL的主从同步开始谈起，最开始我们的数据库架构是这样的。
主库负责了所有的读写操作，而从库只对主库进行了备份，就像我在上一篇文章中说的那样，我认为如果只实现了一个备份，不能读写分离和故障转移，不能降低Master节点的IO压力，这样的主从架构看起来性价比似乎不是很高。
我们所希望的主从架构是，当我们在写数据时，请求全部发到Master节点上，当我们需要读数据时，请求全部发到Slave节点上。并且多个Slave节点最好可以存在负载均衡，让集群的效率最大化。
那么这样的架构就不够我们使用了，我们需要找寻某种方式，来实现读写分离。那么实际上有两种方式。
MyCat配置读写分离
MyCat配置故障转移
我们希望看到的场景是：当主库宕机，某一个从库自动变为主库，承担写的功能，保证整个集群的可用性。
那么我们开始进行配置，其实思路很简单，MyCat的标签中有一个switchType属性，其决定了切换的条件。
当然，此时我们MySQL的主从架构已经被破坏，如果需要恢复主从结构，就需要手动地重新去恢复我们的主从架构。我们需要将201和203作为Slave，202作为Master，因为Master拥有最完整的数据。
参考：
• MyISAM管理非事务表。它提供高速存储和检索，以及全文搜索能力。如 果应用中需要执行大量的SELECT查询，那么MyISAM是更好的选择。
• InnoDB用于事务处理应用程序，具有众多特性，包括ACID事务支持。如 果应用中需要执行大量的INSERT或UPDATE操作，则应该使用InnoDB， 这样可以提高多用户并发操作的性能。
这样的话，就会有一个问题：如果我的业务中同时需要执行大量的查询和插入语句，该怎么选择呢？鱼和熊掌就真的没法兼得吗？No，是可以兼得的。那么就不得不提出MyCat这个东西了。
总的来说，可以通过MyCat来实现这样的效果：
首先，需要一个MySql的主从配置，假设主：master，从：slave，在两个节点里分别创建同一个数据库db1,并在master的db1里创建一个InnoDB表，在slave里创建一个同样的MyISAM表，然后通过Mycat的读写分离配置，可以使插入或者更新操作都去Master里的InnoDB表执行，查询操作都去slave里的MyISAM表执行。
