Keepalived、Haproxy、mycat、mysql集群组件介绍

Keepalived、Haproxy、mycat、mysql集群组件介绍

mysql：主从复制
master库中数据发生更改后会将数据写入日志，slave节点启动IO线程及Sql读取master日志同步数据 ，此时slave作为master的冷备份

mycat：读写分离、负载均衡、高可用

• 负载均衡： 当用户非常多时，通常数据库往往会成为系统的扩展的瓶颈。而mysql提供的优化方案（索引）效果微乎甚微。于是mycat提供读写分离、分库分表等方案对数据库进行优化。可以将一个数据库的压力分散到多个数据库进行负载均衡
  读写分离： 由于mysql自身提供的有主从复制，可以将主库中的数据完整copy到从库。所以可以让从库分担主库读的压力
  （不能向从库写入数据，否则主从数据将不一致）
  高可用（HA）： 虽然主库不承担读的压力，但是主库还是存在宕机的可能。当主库宕机时，用户将不能向数据库中写入数据。很明显这不是我们想要的结果于是我们就想能不能配置两个主库，在其中一个主库宕机后，自动切换到另一个主库。答案当然是可以的
  我们可以在mycat中配置两个主库（写库），两个从库（读库），让两个主库之间互为主从。当其中一个主库宕机后，系统切换到另一个主库正常提供服务，宕机恢复后会自动同步另一台主库的数据。

  分库分表： 当采用读写分离后数据库压力还非常巨大时，就可以采用分库分表提高效率。
  常见的方式有水平切分（切分数据）、垂直切分（切分字段）。切分规则可以自定义

Haproxy： mycat负载均衡，mycat高可用

很显然mycat基本上解决了mysql所有的问题。但是依然还存在一个问题：mycat自身不支持集群，所有的请求都会经过mycat，导致mycat压力剧增。
所以mycat有可能会成为单点故障。即mycat一旦宕机则整个数据库部分将无法访问。
为了解决这个问题，mycat官方推荐使用Haproxy来实现mycat的集群，与Nginx类似。harproxy代理多台mycat（这些mycat提供相同的服务），当用户访问haproxy时，haproxy会通过一定的规则来决定具体访问的mycat。
其实这个过程也就是mycat 的负载均衡

Keepalived：高可用

通过Haproxy代理后Mycat负载均衡、HA都有了，看似很完美。
但是依然还存在一个问题：所有的请求都会经过Haproxy导致Haproxy压力剧增。所以haproxy也有可能会宕机并且Haproxy自身也不支持集群，所以说Haproxy依然会存在单点故障
是不是感觉特别无奈，感觉像是进入了一个死循环。。。。不要灰心。想想我们之前配置Nginx时是怎么做的呢？
宾狗！！！Keepalived 完美解决这个问题：通过keepalived实现haproxy集群。
于是你又会担心了，keepalived不会出现单点故障吗？so。。。。。下面就要讲讲keepalived的原理了。

keepalived原理

keepalived与Nginx、Mycat、Haproxy这些反向代理不同，keepalived自身提供集群方式，并且keepalived是一对一的，也就是说keepalived不提供负载均衡，只负责HA。
keepalived可以理解为一个虚拟路由组（keepalived集群），这个路由组存在多个虚拟路由（每一个路由相当于一个keepalived实例），并且一个虚拟路由组只能代理一个IP地址。
这个组内具有一个唯一的虚拟IP由master路由掌管（主从结构、master ，backup），用户通过VIP访问此集群。

当keepalived集群启动后会根据优先级选出master路由，并且让master路由接管集群中唯一的VIP。当客户端通过VIP访问keepalived时，其实访问的是master路由，然后
master路由将请求转发到对应的haproxy中。

master会时刻向buckup发送信号，表示自己还在活着。如果有一天buckup路由没有接收到master的存活信号，就表示master已经死亡。重新进行master的选举。
此时所有的buckup都会认为自己是master，然后向其他节点发送信号。最终选举出一个新的master接管VIP。 （感觉有点像皇子继承王位的过程。。。脑洞有点大）

抢占模式： keepalived虚拟路由组中的每一个实例默认都是抢占模式，当接收到master发的信号时会比较自己与master的优先级，如果自己的优先级比较大，那么自己成为新的master
非抢占模式： 可以通过（nopreempt）设置当前虚拟路由实例为非抢占实例。但是此实例不能是MASTER标识，即MASTER标识的路由必须是抢占模式

到此为止一个高可用的、负载均衡的、读写分离的、分库分表的mysql集群已经搭建完毕了。

最后还想说一点：mycat其实可以直接通过keepalived进行集群，从而省掉haproxy中间件。但是为什么官方不推荐这么做？
假如现在我们真的这样做了（省略掉了Haproxy，直接使用keepalived实现mycat集群），那么会出现什么问题呢？
客户端的请求通过keepalived直接路由到mycat中，因为keepalived只有master掌管VIP，所以keepalived会所有的请求转发到同一个mycat中处理，
mycat压力并没有被减少，宕机的几率还是非常大。当一个mycat宕机后，keepalived切换master，然后所有的请求又会到达另一个mycat导致另一个mycat也会宕机
虽然实现了mycat的高可用，但是没有负载均衡