（5.17）mysql集群技术概述（LVS、Keepalived、HAproxy）
【1】集群技术的分类
【1.1】高可用集群（Hight Availability，HA）
高可用的含义是最大限度地可以使用。主要是保障程序业务的不间断性和可扩展性。
【1.2】负载均衡集群（LoadBalance）
主要分为前端负载调度和后端服务两个部分。
负载调度部分负责把客户端的请求分配给后端服务节点，而后端节点是真正提供应用程序服务的部分。
与高可用集群不同，负载均衡集群中所有的后端节点都处于活动状态，他们都对外提供同样的服务，分摊系统的工作负载。
【1.3】科学计算集群（High Performance Computing，HPC）
高性能计算集群，这类集群致力于提供单个计算机所不能提供的强大计算力，包括数值计算和数据处理，并倾向追求综合性能。一般情况见不到这列。
【2】常用的负载均衡概述
【2.1】常用软件与设备
开源软件：nginx、lvs、haproxy
商业硬件负载设备：F5、Array、思科/华为等负载设备
【2.2】常用的 MySQL 从库负载均衡方案
（1）F5之类的硬件负载设备 --优选
（2）Keepalived + HAProxy（CPU、内存相对LVS占用的多一点） --次选
（3）Lvs + Keepalived （LVS有长连接问题的缺陷，比如A机挂掉之后仍然会往A机分发）--次次选
【3】LVS
【3.1】LVS的概念
LVS：全称为Linux Virtual Server，LVS本质上是一个内核模块（ip_vs.so）。
因为LVS的负载调度是在Linux内核中实现，使用Linux内核集群实现一个高性能、高可用的负载均衡服务器。
【3.2】LVS的优点
《1》 抗负载能力强，是工作在网络4层之上仅做分发只用，没有流量产生，这个特点也决定了它在负载均衡软件里的性能最强，对内存和CPU的消耗也比较低。
《2》 配置性比较低，这是一个缺点也是一个优点，因为没有太多需要配置的东西，所以并不需要太多接触，大大减少了人为出错的几率，但缺点是功能比较少。
《3》工作稳定，因为其本身抗负载能力很强，自身有完整的双击热备方案，如LVS+Keepalived。项目中最常用的是LVS/DR+Keepalived（这里LVS/DR指的是 使用LVS的DR模式，DR指的是路由转发）
《4》无流量，LVS只分发强求，而流量并不从它本身出去，这点保证了均衡器IO的性能几乎不会受到大流量的影响。
《5》应用范围比较广，因为LVS工作在4层，所以它几乎可以对所有应用做负载均衡，包括http、数据库、在线聊天室等等。
【3.3】LVS的缺点
《1》软件本身不支持正则表达式处理，不能做动静分离；而现在许多网站在这方面都有较强的需求，这个是Nginx/HAProxy+Keepalived的优势所在。
相关概念：动静分离（简单概括就是静态数据和动态数据放开存放在不同机器上,分开访问）
在做web开发的时候大家都清楚，js、html、图片资源、文件资源这些其实都属于静态资源，供用户直接访问，并不需要编译或者解释，是一些放在那里就可以用的东西，而jsp、java文件这些东西其实都需要被tomcat服务器解释一遍才能被机器识别，但是如果把它们都放在一起供用户访问，那每台服务器的压力岂不是很大，这个时候我们就可以做动静的分离，将这些静态的文件放置到Nginx服务器上，后面的tomcat服务器用来放动态的jsp、java文件，这样的话就变向的给服务器降低了压力。
《2》如果是网站应用比较庞大的话，LVS/DR+Keepalived实施起来就比较复杂了。特别是如果有Windows Server的机器的话，实施及配置还有维护过程就比较复杂了。（LVS相当于C/S架构）
相对而言，Nginx/HAProxy+Keepalived就简单许多。（当相遇B/S架构）
《3》LVS长连接缺陷
LVS走的TCP协议，当read库挂掉了，LVS也不会将其踢掉。
另外LVS对长连接的应用支持的不好，因为LVS的检查时长一般在30s，但长连接的设置一般都是30分钟，或者不设置timeout。
这样，当业务断开连接后，LVS还认为它是沉睡着的，所以连接到db的thread不会减少。
由此，很容易引起 thread_connect 占满，导致 MySQL 不可用。
所以，我们不能只用LVS，我们需要用LVS的内核，然后由keepalived来判断 Mysql的存活。
【3.4】LVS的三种部署模式
（1）NAT：地址转换（即多个地址转换成同一个出口地址）
（2）DR（Director Server）：直接路由（通过路由的地址，都可以访问，无论是否在同一个网段）
（3）Tunnel：隧道模式，对 package 重新封装一层，realserver 需要重新解析
我们mysql常用的部署模式为DR模式，且DR模式的性能也是三者最好的。
【3.5】LVS的基本访问原理
轮询调度算法举例：如上图，客户端发起请求到LVS的VIP，然后LVS机器把请求路由转发给S1，然后S1处理好后响应回去给客户端。lo:0 就是我们常说的循环口（loopback口的别名）
下一次客户端继续发起请求到LVS的VIP，这次LVS机器把请求路由转发给S2机器，然后S2处理好响应回去给客户端。
就这样，轮流发送请求给S1、S2，比如：第一次请求给S1，第二次请求给S2，第三次请求又给S1，第四次请求给S2....以此达到负载均衡的效果。
注意：S1、S2机器，必须是同网段的IP
【4】LVS-DR模式的原理
【4.1】MAC地址替换（ARP欺骗）
将发送给LVS请求包的目标MAC地址替换为某一个（由调度器根据算法调度分配）Server的MAC地址；
然后将这个修改过目标的MAC地址请求包发送给对应的Server
【4.2】虚拟IP（即我们说的VIP）
虚拟IP存在于LVS上，用于接受用户的请求，同事虚拟IP还版本在实际server的 lo:0 上（loopback口的别名）
访问过程案例：假如没有绑定虚拟IP在 lo:0 上
1）结合MAC替换，此时数据包调度给了某一个server；
2）server收到这个数据包后，首先检查目标 MAC 是否是自己的，由于之前做了MAC地址替换，所以检查的结果为真；
3）最后检查目标IP，由于虚拟IP没有绑定在 io:0 上，导致检查结果为假，则 server 会丢弃该数据包。
【4.3】io:0 接口的ARP抑制
问题：由于 server 上绑定虚拟IP 在 lo:0 上，那此时看来，同一个网络（VLAN）中存在多个同样的IP，那不就IP地址冲突了嘛？
回答：
1）IP地址是否冲突主要是在一个网络内（比如VLAN）询问某一个IP地址，是否有多台主机应答（ARP广播）；
2）在 server 的 lo:0 上启用ARP抑制，这样一来当网络中有设备询问虚拟IP地址时，server将不做应答，此时只有LVS进行应答，确保不会引起冲突（即IP-MAC的映射关系在该网络中唯一）。
举例：
我们做了LVS之后，映射了2台server，这2台server的 lo:0 端口都是绑定了VIP的，假设VIP地址是 192.168.135.210。
当有请求访问 192.168.135.210 IP地址的时候，server1/server2/LVS机器都有192.168.135.210的IP地址；因为ARP抑制，网口 lo:0 不会响应（且该网口也没有对应的MAC），而LVS会响应请求然后根据调度算法转发到具体的某一台server上去。
以此在避免冲突，达到IP-MAC映射关系在当前网络中唯一的效果。
【5】LVS10种调度算法
【5.1】Fixed Scheduling Method 静态调度算法（RR与SH使用的多）
（1）RR：轮询
举个例子：假如LVS下有2台server，第一次请求给S1，第二次请求给S2，第三次请求又给S1，第四次请求给S2....等等轮流着来去访问。
（2）WRR：加权轮询
LVS下面的server有权重值，同样假设LVS下有2台server，比如S1为55，S2为45；
那么可能100个请求有55个给S1，45个给S2，也可以全部给权重高的S1，等S1有出问题才轮到S2；
（3）DH：目标地址hash
就是同一个客户端的请求经过LVS 的HASH调度，选择到了目标 server，比如是server1，那么即使你server1机器出问题了，换了一个新机器一样的IP来顶替server1，hash算法的目标地址仍然是该机器。而不会是server2；
（4）SH：源地址hash
解决session会话保持问题。客户端的会话一直在源地址上。
服务端的响应通过LVS使用hash调度算法 指定了的对应的响应server，比如是server2，那么即使换了一台新机器一样的IP来顶替server2，hash算法的响应地址仍然是该机器。
总结
（1）（2）没什么好说的。
（3）（4）算法会永远固定一个LVS下的server ip 来做请求的目标地址 或者 响应的源地址，只要server的IP地址不变，换了机器也没关系。
【5.2】Dynamic Scheduling Method 动态调度算法（用的少）
（1）LC：最少连接
意思就是，查看一下LVS下负载均衡server的客户端连接情况，哪台server客户端连接数最少，这次的客户端连接就分配给它。
（2）WLC：加权最少连接
（3）SED：最少期望延迟
（4）NQ：从不排队调度算法
（5）LBLC：基于本地的最少连接
（6）LBLCR：带复制的基于本地的最少连接
【6】KeepAlived的基本概念与原理
双主KeepAlived
利用KeepAlived实现故障转移（功能上类似于MSSQL的镜像，形式上类似于windows的故障转移群集）
【6.1】keepalived 简介
参考：（5.1）mysql高可用系列——高可用架构方案概述 中的【4】双主keepalive
（1.1.1）Keepalived服务的工作原理
Keepalived服务对之间通过VRRP进行通信的，VRRP是通过竞选机制来确定主备的（有点像故障转移群集中的投票仲裁形式），主的优先级高于备，因此工作时主会优先获得所有的资源，备节点处于等待状态，当主挂了的时候，备节点就会接管主节点的资源，然后顶替主节点对外服务。
在Keepalived服务对之间，只有作为主的服务器会一直发送VRRP广播包，告诉备它还活着，此时备不会抢占主，当主不可用（也就是备没有受到VRRP广播包信息），就会启动相关服务接管资源，保证业务的连续性，接管速度最快可以小于1秒。
（1.1.2）keepalived 的三个核心模块
分别是core/check/vrrp
core：keepalived的核心，负责主进程的启动、维护以及全局配置文件的加载和解析。
check：负责健康检查，包括常见的各种检查方式。
vrrp：是用来实现VRRP协议的；（VRRP：全称 virtual router redundancy protocol，虚拟路由冗余协议）
（1.1.3）什么是VRRP？
VRRP,全称 virtual router redundancy protocol，虚拟路由冗余协议。
VRRP的出现就是为了解决静态路由的单点故障问题，VRRP是通过一种竞选机制来将路由的任务交给某台VRRP路由器的。
【6.2】keepalived的三种工作模式
Keepalived通过组播（默认）、单播（自定义），实现keepalived主备推选，工作模式分为抢占和非抢占。
《1》抢占模式
主服务器正常工作时，虚拟IP会在主上，备不提供服务，当主服务优先级低于备的时候，备会自动抢占虚拟IP，这时，主不供服务，备提供服务。
也就是说，抢占模式下，不分主备，只管优先级。
不管 keepalived.conf 里的 state 配置成 master 还是 backup ，只看谁的priority 优先级高， priority 优先级高的那一个，在故障恢复后，会自动将VIP资源再次抢回来。
举例：
1）俩台都为master/backup时，比如server1的优先级大于server2，keepalived启动后server1获得master，server2自动降级为backup。
此时server1宕机的话，server2接替 服务，当server1恢复后,server1又变为master，重新接管服务，server2变为backup。属于抢占式。
2) server1为master,server2位backup,且master优先级大于backup。keepalived启动后server1获得master，server2为backup。
当server1宕机后， server2接管服务。当server1恢复后，server1重新接管服务变为master，而server2变为backup。属于抢占式
3) server1为master,server2位backup,且master优先级低于backup。keepalived启动后server2获得master，server1为backup。
当server2宕机后， server1接管服务。此时server2恢复后抢占服务，获得master，server1降级将为backup。属于抢占式
《2》非抢占模式
这种方式通过参数nopreempt（一般设置在advert_int 的那一行下面）来控制。不管priority优先级，只要master机器发生故障，VIP资源就会被切换到backup上。
并且，当master机器恢复后，也不会将VIP资源抢回来。除非Backup机器发生故障，才能自动把VIP等资源切换会主库。
nopreempt 这个参数只能用户state为backup的情况，所以在配置的时候要把master和backup的state都设置成backup，这样才会实现keepalived的非抢占模式！
也就是说
d) 当state状态都为master或者都为backup的时候，没有加nopreempt参数，那么
a）当state状态一个为master，一个为backup的时候，加不加nopreempt 这个参数都是一样的效果。
即都是根据priority优先级来决定谁抢占VIP资源，属于抢占模式！
b）当state状态都设置成backup，如果不配置nopreempt参数。
也是根据priority优先级来决定谁抢占VIP资源，属于抢占模式！
c）当state状态都设置成backup，如果配置了 nopreempt 参数，那么久不会去考虑priority优先级了。
是非抢占模式！ 即只有VIP当前所在机器发生故障，另一台机器才能接管VIP。 不考虑优先级问题。
注意：这样配置后，我们要注意启动服务的顺序，优先启动的获取master权限，与优先级没有关系了
【6.3】keepalived软件包组成
Keepalived是一个高度模块化设计的软件，从源代码结构似乎也很容易看出这一点。Keepalived 1.2.13源代码中只有如下目录：check core etc include libipvs-2.4 libipvs-2.6 vrrp
check：Keepalived的healthchecker子进程的目录，包括了所有的健康检查方式以及对应配置的解析，LVS的配置解析也在这个里面。
core：Keepalived的核心程序，如全局配置的解析，进程启动等等。
etc：包含Keepalived的配置模板和启动脚本等文件。
include：头文件目录。
libipvs*：LVS使用的库文件。
vrrp：Keepalived的vrrpd子进程以及相关的代码。
（1） 多进程模式
Keepalived采用了多进程的设计模式，每个进程负责不同的功能，我们在使用LVS的机器上通常可以看到三个Keepalived进程：
111 keepalived < 父进程，负责内存管理、监控子进程等
112 \_ keepalived < VRRP子进程
113 \_ keepalived < healthchecker子进程
（2） 控制面板
这里所谓的控制面板就是对配置文件的编译和解析。Keepalived的配置文件解析比较另类，并不是一次解析所有配置，而是只在用到某模块时才解析相应的配置。在源文件里面可以看到类似XXX_parser.c的文件，就是做这个用的。
（3） 看门狗
WatchDog框架提供了对VRRP和healthchecker子进程的监控。
（4）IPVS封装
Keepalived里面所有对LVS的相关操作并不直接使用ipvsadm客户端程序，而是使用IPVS提供的函数进行操作，这些代码都在check/ipwrapper.c中。
【6.4】Keepalived在MySQL上有的作用
mysql双主复制，即互为Master-Slave（只有一个Master提供写操作），可以实现数据库服务器的热备。
但一个Master宕机后不能实现动态切换，使用Keepalived，可以通过虚拟IP，实现双主对外的统一接口以及自动检查、失败切换机制，从而实现MySQL数据库的高可用方案。
【6.5】Keepalived 在 LVS 上的作用
（1）管理LVS负载均衡软件
（2）实现LVS集群节点的健康检查
（3）作为系统网络服务的高可用性（failover）
（6.6）Keepalived的主从切换时间
结论：
（1）检查脚本挂掉，关闭keepalived ，1秒内（服务关闭+VRRP广播时间）
（2）服务器宕机，advert_int 为 1 的话，默认超时3次就启动故障转移，所以则是 3*1（advert_int）+1（VRRP）
【7】HAproxy
【7.1】HAproxy软件介绍
HAProxy提供高可用性、负载均衡以及基于TCP和HTTP应用层的代理，支持虚拟主机，它是免费、快速并且可靠的一种解决方案。
基于TCP (四层)，HTTP (七层) 应用的负载均衡软件，HAProxy特别适用于那些负载特别大的web站点，这些站点通常有需要会话保持或七层处理。
HAProxy运行在当前的硬件上，完全可以支持数以万计的并发连接，并且它的运行模式使得它可以很简单安全的整合进您现有的架构中，同事可以保护你的web服务器不被暴露到网络上。国内生产环境上使用HAProxy的公司很多，比如淘宝的CDN系统。
【7.2】HAProxy软件优点
（1）可靠性和稳定性非常好，可以与硬件级F5负载均衡设备媲美
（2）最高可同事维护4W-5W个并发连接，单位时间内最大请求为20000个，最大数据处理能力可达10Gbps。
（3）支持多于8中负载均衡算法，同事支持会话保持。
（4）支持虚拟主机功能
（5）从1.3版本后支持拒绝连接，全透明代理，这些功能室其他负载均衡所不具备的
（6）HAProxy拥有一个强大的服务器状态监控页面，可以通过此页面实时了解系统状况
（7）HAproxy拥有功能强大的ACL支持，给使用上带来很大方面
（8）HAProxy是借助于操作系统的技术特性来实现性能最大化的，因此，在使用HAProxy时对操作系统的性能调优是非常重要的。
（9）能够补充Nginx的一些缺点，比如Session的保持，Cookie的引导等工作，支持url检测后端的服务器出问题的检查会有很好的帮助，它和LVS一样，本身仅仅就只是一款负载均衡软件。
【7.3】HAProxy的常见8种算法（RR与source常用）
（1）RR（roundrobin）：轮询
（2）static-rr：表示根据权重，建议关注；
（3）leastconn：表示根据最少连接，建议关注；
（4）source：表示根据请求源IP，这个和Nginx的IP_hash机制类似，我们用其作为解决 session 问题的一种方法，建议关注；
（5）ri：表示根据请求的URL
（6）rl_param：表示根据请求的URL参数
（7）hdr（name）：表示根据HTTP请求头来锁定每一次HTTP请求；
（8）rdp-cookie（name）：表示根据cookie（name）来锁定并 hash 每一次TCP请求。
【8】比较流行的架构方案
【8.1】WEB端使用的负载均衡
采用Nginx/HAProxy + Keepalived作负载均衡器；
【8.2】后端数据库mysql集群
后端采用 mysql 数据库一主多从和读写分离，也可以MHA+Keepalived
（1）LVS+Keepalived
（2）HAProxy+Keepalived
（3）硬件F5之类的架构
【8.3】总结
mysql节点是集群的基础，组成 Server Array，其中每个节点作为 Real Server。
LVS服务器提供了负载均衡的作用，将用户请求分发到 Real Server，一台 Real Server故障并不会影响整个集群。
Keepalived搭建主备LVS服务器，避免LVS服务器单点故障，出现故障时可以自动切换到正常的节点。
