最近学习mysql集群的体会

        作为程序员，前段时间学习了下mysql的集群方案，对高可用，负载均衡有了一定认识，现在写写自己的看法，大家多交流，提高水平~
        高可用，负载均衡是实际生产中，mysql及其他所有数据库都需要保证的，两者又是相辅相成的。
        先说说高可用，对mysql而言，有主主，主从，多主多从等架构方案，对应不同的架构，对应有不同的HA方案。这里需要针对mysql主备，主从分别描述。
        主备方案，一般是某个主机作为热备，并没有被使用，主主之间又互为主从，两者进行数据同步。在使用时，不需要实现读写分离。
        常用的主备高可用方案有keepalived，heartbeat 两种，这两种方案使用的场景很多，对于别的需要实现主备的服务而言，也是可行的。
        keepalived，配置比较简单，使用的vrrp协议方式，虚拟路由冗余协议 (Virtual Router Redundancy Protocol，简称VRRP)，提供的是4层的负载均衡，能通过编写脚本实现对mysql服务的监控，再配合虚拟IP使用，检测到一台主机down之后，能迅速切换到另一台主机。
        heartbeat是linux的ha方案，配置较复杂，是基于主机或网络的高可用方式，一旦其无法检测到主服务器的“心跳”则自动接管主服务器的资源。但是如果配置不当，会产生“split-brain”，即两个节点同时认为自已是唯一处于活动状态的服务器从而出现争用资源的情况，如VIP(虚拟IP)争用。keepalived则能够很好地解决这个问题。一般是lvs的高可用建议用keepavlived，业务的高可用用heartbeat。
        对于mysql主从，一般是结合多主多从使用较多，相应的高可用方案有mysql-mmm，mysql-mha方案比较常用。
        mysql-mmm(Master-Master Replication Manager for MySQL)，高可用方案，同时也是读写分离方案，优点：部署简单，稳定性比较好；缺点：如果两台master挂掉，slave不会自动的升级到master，整个集群只能读不能写数据。
        mysql-mha(mysql-master-ha)，有以下特点：主服务器的自动监控和故障转移，交互式主服务器故障转，非交互式的主故障转移，在线切换主服务器。相比mmm方案，mha方案的优缺点，优点：可以自动同步差异的日志，可以自己写故障转移的脚本，比较灵活；缺点：如果故障转移了需要重新修改配置文件，重新启动masterha_manager服务(这点比较不好)。
        对于mysql负载均衡方案，主要有LVS，haproxy方案，nginx也是可行的。
        LVS,通过vrrp协议进行数据包转发的，提供的是4层的负载均衡。特点是效率高，只要机器网卡抗的住就不是问题。
        haproxy，可以提供4层或7层的数据转发服务，能做到7层的好处是可以根据服务所处的状态等进行负载。
        Nginx，工作在网络的7层，也常作为web服务的负载均衡服务器，且支持插件安装，也很好地开源了，能根据各自的业务，编写相应的插件，如控制nginx负载路由的规则的等。但是，这些方案本身也是存在单点故障的，故还需要实现负载均衡方案本身的高可用。
        一般实现负载均衡，和负载均衡服务本身的高可用的组合是：
                LVS+keepalived (都是通过vrrp协议来实现的)
                haproxy+heartbeat
                nginx+heartbeat
        高可用，负载均衡是生产环境中，几乎所有服务都需要满足的，针对mysql有些特殊的地方，如实现读写分离，分库分表等。 目前常用的能够实现读写分离的方案有mysql-proxy，amoeba等。
        mysql-proxy提供MySQL协议接口（非JDBC），主从结构，可以负载平衡，读写分离，failover等，lua语法复杂，不支持大数据量的分库分表。
        Amoeba，相当于一个SQL请求的路由器， 目的是为负载均衡、读写分离、高可用性提供机制，而不是完全实现它们。
        Amoeba主要解决以下问题：
                a). 数据切分后复杂数据源整合；
                b). 提供数据切分规则并降低数据切分规则给数据库带来的影响；
                c). 降低数据库与客户端连接；
                d). 读写分离路由；
                f).支持分库，分表，事务。
        不足：
                a)、目前还不支持事务；
                b)、暂时不支持存储过程（近期会支持）；
                c)、不适合从amoeba导数据的场景或者对大数据量查询的query并不合适（比如一次请求返回10w以上甚至更多数据的场合）；
                d)、暂时不支持分库分表。
        amoeba目前只做到分数据库实例，每个被切分的节点需要保持库表结构一致。淘宝的TDDL(这个比较复杂，但功能很强大)。amoeba在使用时，可以理解是实现sql层面的读写分离。mysql-mmm方案可以对外提供一个读VIP，一个写VIP，至于读命令或写命令怎么分配到哪台机器是该方案实现的，但是用户的一条sql语句发过来了，怎么将对应的sql进行分析，将读相关操作给读VIP，写相关操作给写VIP，这是amoeba需要处理的了。
        总之，这些方案只有配合使用，才能很好的实现mysql的高可用，负载均衡，如：使用mysql-mmm+ameoba+keepalived方案，其中mysql-mmm是mysql的高可用方案，ameoba是读写分离方案，keepalived保证ameoba的高可用。当然还得根据各自的业务需要，主机数量等因素，来进行权衡。