谈谈MYSQL 集群那些事儿
我们开发了一款对向K7-K12的教育类APP软件，数据库层使用的是MY SQL集群，在架构设计过程中，对常用的MYSQL相关中间件和技术做了些研究，现在就谈谈MYSQL集群那些事儿，都是产品研究过程中经历过的经验之谈，边想边写，供交流之用，行文不畅之处也不必理会，本文不对涉及的中间件和技术详细说明（诸如安装/配置/故障排查之类），这类文章百度一下多得是。
做为一名架构师，必须对所做产品的需求有非常深透的理解，要比SA更理解产品的用户特点，要比测试人员更理解产品的业务，要比设计人员更理解产品的设计细节。如果说不理解软件需求谈大数据，是耍流氓，那么不理解产品需求谈架构，也同样是在耍流氓（话粗理不粗）。只有对软件需求有了深刻了理解，才能设计出高性能、可伸缩的软件架构。顺便说一下，架构师还要能很好地掌握前台（HTML5/CSS/JS等等）、CDN加速、云服务平台、网络等技术，方可通盘考虑，眼于全局设计。
MYSQL集群的中间件和方案有很多，选择哪一种方案，要根据软件产品的需要来定，必竟技术是为需求服务的。
MYDQL集群的方式：
1、一主一从 最常见的MYSQL集群是一主一从，应用服务只操作主库，从库仅做为份备之外。
2、一主一从，读写分离 再复杂一点的，做个读写分离，主写从读。虽说MYSQL数据复制是异步方式，但一般的业务来讲，对实时性的要求不是非常高，这种异步复制的速度也够用了。说到集群效率，虽然二台数据库服务器的读写分离设计，但是不见得效率就比一台数据库服务器高，因为从服务器同样需要与主库等量的写入数据，它的数据是从主的BinLog中获取的，同时从服务器还要提供查询服务。
我们一开始就采用的这种一主一从的读写方式。读写分离的中间件采用的是MYSQ PROXY，开发过程一切都很正常，在第一次压力测试时，本人构建了20多亿条数据，数据库的尺寸为260多个GB，MYSQL PROXY的性能令人满意。但是在3、4个月后的第二次压力测试，却发现在用JMETER压测某特定接口时，经常出现锁表的现象，虽然JAVA代码我很有信心，但还是仔细地复查了一遍代码，SQL语句的执行顺序完全没有问题。同样的WEB Service接口在第一次压测正常，第二次压测却频繁锁表，到底是怎么回事？无耐之下，只好步步排查，当我们去除了MYSQL PROXY时，WEB Service接口不再锁表，加上MYSQL RPOXY 又开始锁表了。于是我们开始分析MYSQL PROXY的LUA代码，开始我也没当回事，不都是代码吗？LUA很难吗？找项目经理去读了三、四天LUA代码之后，他明显的头大了，跟他交流之后我又花了半天的时间去读LUA代码，发现里面的数据库事务管理逻辑复杂度，比我之前预想的要大得多，不是一时半会儿能读懂的。加之MYSQL PROXY开源项目已经停了，没人去维护和升级，我们只得重新研究MYSQL的读写分离方案。
期间也考虑的阿里的Amoeba，但它的源码似乎已经不更新了，所以没有深入研究就放弃了。
JDBC的com.mysql.jdbc.ReplicationDriver，也可以实现读写分离，支持DB事务的负载均衡，配置也很方便，这没测试过，但是性能上应该优于读写分离中间件。
3、一主多从，读写分离 这种多从的方式，可以比较明显地提高SQL查询性能，需要注意的时， SQL的查询性能，随着添加的从机的数量，呈现出性能提升幅度递减的趋势，即性能的提升是非线性。这方面有人做过专门的详细研究，可百度一下。
4、双主，双读双写 放弃了MYSQL PROXY之后，本人对MYSQL集群的理解又深入了一层，我在思考：我为什么一定要用中间件？MYSQL PROXY的LUA代码那么复杂，性能上一定有不少损耗（具体多少我没有测试过）!换了其它的中间件，损耗也不会少。
MYSQL 可以配置成主-主复制模式，这种模式很神奇。
假如能在JAVA 的WEB Service层做到SQL事务级别的路由，效率不是最优的吗？我们以软件100万的用户规模来计算，双读双写可以满足业务要求。
在SPRING MVC框架中，可以配置二个JDBC数据源，采用轮查的路由机制，以数据库事务为粒度，将MYSQL的操作平均分配到二台MSYQL服务器上。
这又读双写模式，改善了一写一读模式中从库负荷偏重的问题，使得二台MYSQL服务器的负载非常均衡。并且，对于同一个DB事务中写后即查的操作，可满足实时性非常高的业务，因为它不需要数据的复制过程。
双读双写模式，加上Keep A Lived 双VIP，可实现任意MYSQL服务器宕机后，故障平滑转移。经测试，效果还是令人满意的。
5、双主多从，分布式DB 适合于大型应用，海量数据，如360的Atlas，是一款MSYQL读写分离、负载均衡的中间件产品，美团在在其上又开发了一些功能。以MYSQL PROXY为基础，重新用C写的一个软件，扩展性非常不错，支持表的水平切分、垂直切分。
在业务规模增加之后，可以考虑在双读双写模式的基础上，加入MTAtlas或Atlas中间件。数据的切分是以技术为手段的艺术活儿，需要架构师对产品需求的深刻理解才能做好，推荐的方式是：建立业务模型，通过参数的修改，能预测出3、5年之后的各种可能的数据规模、不同业务场景下的并发量。没有一双看穿未来的眼睛，很难设计出优秀的架构，业务模型就是未来的预演。
其它中间件：
TDDL（Taobao Distributed Data Layer）是分布式数据库访问引擎，的作用是将sql路由到正确的分库、分表中去执行，并将执行结果进行汇总、返回。上层可以像单库单表一样使用数据源，无需知道分布式数据库的细节。没用过不多说了，参考下这个《剖析淘宝TDDL》
Mycat 基于是Cobar二次开发的MYSQL中间件。没用过不多说了，参考下这个《Mycat前世今生》
MHA是日本高人写的一个MYSQL高可用的中间件（与读写分离、负载均衡无关的）。需要安装好多相关的软件，版本差一点也行，有些镜像下载网站访问不了，安装麻烦得很，当初我找了好几套安装文档，才安装好，一周能安装配置完毕算是运气了。