1.keepalived+LVS
在LVS+Keepalived环境里面，lvs主要的工作是提供调度算法，把客户端请求按照需求调度在real服务器，keepalived主要的工作是提供lvs控制器的一个冗余，并且对real服务器做健康检查，发现不健康的real服务器，就把它从lvs集群中剔除，real服务器只负责提供服务。
lvs是一个在四层上实现后端realserver的负载均衡的集群，lvs遗留下两个问题，一个是lvs的单点故障；第二个是lvs不能检测后端realserver的健康状态检查。
解决lvs的单点故障就用到了高可用集群：
①、可以是heartbeat+ldirectord这种重量级的；
②、可以是keepalived+lvs这种轻量级的解决方案。
解决lvs不能检测后端realserver的健康状态也后很多种方法：
①、可以在lvs上写脚本ping后端realserver的ip地址，ping几次发现ip地址ping不通则在ipvs规则里面删除，当后端服务器可以ping了，则把后端realserver添加到ipvs规则里面。
②、可以在lvs上写脚本请求后端realserver的测试几次网页文件，查看状态码是否为200，不是则在ipvs规则里面清楚，当测试网页返回的状态吗是200之后，则把后端realserver添加到ipvs规则里面
③、以上两种方法都是依赖于脚本，keepalived的出现解决了不依赖于脚本，也可以对后端realserver的健康状态检查，keepalived的配置文件里面可以自行生成ipvs的规则，并且自行检测后端realserver的状态，当后端realserver不能提供服务了，keepalived会自行将其在ipvs规则里面删除，当后端realserver可以提供服务了，又自行的在ipvs规则里面添加。
2.DRBD
2.1 什么是DRBD
DRBD的全称为：Distributed ReplicatedBlock Device(DRBD)分布式块设备复制,DRBD是由内核模块和相关脚本而构成，用以构建高可用性的集群。其实现方式是通过网络来镜像整个设备。你可以把它看作是一种网络RAID。它允许用户在远程机器上建立一个本地块设备的实时镜像。
DRBD是如何工作的呢?
(DRBD Primary)负责接收数据，把数据写到本地磁盘并发送给另一台主机(DRBD Secondary)。另一个主机再将数据存到自己的磁盘中。目前，DRBD每次只允许对一个节点进行读写访问，但这对于通常的故障切换高可用集群来说已经足够用了。有可能以后的版本支持两个节点进行读写存取。
2.2、DRBD复制模式
2.2.1、协议A：
异步复制协议。一旦本地磁盘写入已经完成，数据包已在发送队列中，则写被认为是完成的。在一个节点发生故障时，可能发生数据丢失，因为被写入到远程节点上的数据可能仍在发送队列。尽管，在故障转移节点上的数据是一致的，但没有及时更新。这通常是用于地理上分开的节点
2.2.2、协议B：
内存同步（半同步）复制协议。一旦本地磁盘写入已完成且复制数据包达到了对等节点则认为写在主节点上被认为是完成的。数据丢失可能发生在参加的两个节点同时故障的情况下，因为在传输中的数据可能不会被提交到磁盘
2.2.3、协议C：
同步复制协议。只有在本地和远程节点的磁盘已经确认了写操作完成，写才被认为完成。没有任何数据丢失，所以这是一个群集节点的流行模式，但I / O吞吐量依赖于网络带宽
一般使用协议C，但选择C协议将影响流量，从而影响网络时延。为了数据可靠性，我们在生产环境使用时须慎重选项使用哪一种协议.
2.3 工作原理
一般情况下文件写入磁盘的步骤是: 写操作 --> 文件系统 --> 内存缓存中 --> 磁盘调度器 --> 磁盘驱动器 --> 写入磁盘。而DRBD的工作机制如上图所示，数据经过buffer cache后有内核中的DRBD模块通过tcp/ip协议栈经过网卡和对方建立数据同步。
3.haproxy+keepalived实现高可用负载均衡
所有的系统，都是先经历一个单台机器搞所有业务的时代，一个程序+一个mysql数据库，就可以满足开发及第一个版本上线的要求。随着，数据的增加以及业务的增长，这些应用就面临一个访问量的扩大以及扩展的问题。最简单的扩展就是水平扩展，原来由一个mysql增加为2个或多个，形成一个集群，这样最简单的能力就是提供更强的服务能力。如原来的访问量支持每秒1000，现在可以支持2000(理想值)，相当于将服务能力分散到多个节点。这里面涉及到多个问题，首先就是数据的相互备份，然后就是如何分配计算能力，外部如何来访问等。本文引入HaProxy和KeepAlived主要处理的就是一个外部访问问题。
在后面的介绍当中，假定有2个mysql，分别为mysqlA和mysqlB.
3.1、haproxy请求分发
可以理解为通过nginx来作后端的负载均衡，haproxy可以通过监听一个统一的端口对外提供能力，然后内部进行分发。除支持http7层处理外，还顺便为mysql支持4层转发。(更高级的可以考虑采用lvs) 在这里，将两个mysql分别配置在backend当中，并且通过option mysql-check进行相应服务的检查。
程序进行访问时，就不再访问具体的mysql机器，而是访问这个haproxy所在的机器。这里就提到需要一个额外的机器来提供服务，但是由于只为haproxy使用，其根据很低，一个最低配机器即可，费用不大。同时，相应的端口也填写haproxy所暴露的端口即可。对外即认为也只仍然只有一个mysql，即对外是透明的。
haproxy在进行处理时，将自己根据相应的策略进行转发，最简单的策略就是轮询(ribbon),当然其它加权或者是随机等，需要具体进行配置。同时，根据设定的具体时间间隔，对后端服务进行有效性检测，当mysqlA或B不能工作时，将自动从可用列表中移除。
在加上haproxy之后，负载的问题被解决，但另一个问题又来了，即服务单点的问题。如果一旦这个haproxy机器挂掉(或网络原因)。虽然,mysql服务器没挂，但整个服务也是不可用了。前端程序不会自动退回到去访问原始的mysql(甚至由于防火墙的问题，它也不能访问)。这时候就要用到另一个东西，保证haproxy不会成为单点，即KeepAlived。
3.2、KeepAlived高可用
保证服务不会单点的作法就是加机器，但加机器就会出现多个ip，如何保证前端程序使用单个ip又能保证后端的实际处理机器为多台，这就是KeepAlived的作用。
我们为了保证haproxy的高可用，已经又加了一个机器，即为haproxyA和haproxyB（相当于原来的2个mysql机器，又加了2台haproxy机器)。
通过KeepAlived，我们可以创造出第3个IP，由ip3来对外提供服务，但是与HaProxy的转发性质不同，这里的ip3实际上就是HaProxyA和HaProxyB的一个同名映射。可以理解为HaProxyA和HaProxyB都在争抢这个ip，哪个争抢到了，就由哪个来提供服务。可以理解为在一定的时间内，保证以下关系
IP3<=>IP1
IP2 wait IP3因为KeepAlived不提供任何处理能力，实际上最终的处理落在能够处理信息的程序上。因此，我们需要将KeepAlived和HaProxy部署在一起，即KeepAlived负责抢ip，接收前端的请求，在接收到了请求之后，由系统自动将请求分发到同一个机器上的HaProxy上进行处理。即一个机器有2个IP，ip1负责接收请求,ip2负责实际的信息处理(比喻而已，就是如何监听请求和端口处理程序)
在前面的处理模型当中，因为KeepAlived不处理请求，因此如果它所在机器上的haproxy如果不可用，实际上这个模型也是有问题的。因此KeepAlived又要来监听自己机器上的haproxy是否有效。在配置中，通过track_script指令可以达到这个效果，与haproxy的工作模式差不多，它可以定时执行监控脚本来查看haproxy是否可用。如果不可用，有2种处理办法，一种就是强行再启动haproxy，另一种就是取消自己的抢占ip位(如将自己给kill掉)，将相应的ip3的位置给让出来。这样IP2就能自动与IP3进行绑定(比喻)，即由IP2来提供处理能力了。
在KeepAlived的配置之上，在单个时刻只有1台机器在进行工作，另一个机器在进行准备，可以理解为这里的服务能力只有1半。好在KeepAlived和HaProxy所占用资源都较小，费用不高。
最终部署模型
a、MysqlA(ip5)和MysqlB(ip6)水平扩展，通过双主进行数据通信，并且同时提供服务能力
b、通过HaProxyA(ip3)和HaProxyB(ip4)提供mysql的负载能力，将请求路由到指定的mysql服务器，同时监控后端的mysql数据库可用性
c、将KeepAlivedA和KeepAlivedB分别和HaProxyA和HaProxyB部署在一起，同时绑定VIP ip1，对外提供访问ip，同时监控本机的HaProxy的可用性
通过以上的部署，一个最前端的数据访问可能是以下的访问路径
IP1=>IP3->IP5
IP1=>IP3->IP6
IP1=>IP4->IP5
IP1=>IP4->IP6
4.nginx LVS haproxy比较
Nginx、LVS、HAProxy 是目前使用最广泛的三种负载均衡软件，本人都在多个项目中实施过，通常会结合Keepalive做健康检查，实现故障转移的高可用功能。
1）在四层（tcp）实现负载均衡的软件：
lvs------>重量级
nginx------>轻量级，带缓存功能，正则表达式较灵活
haproxy------>模拟四层转发，较灵活
2）在七层（http）实现反向代理的软件：
haproxy------>天生技能，全面支持七层代理，会话保持，标记，路径转移；
nginx------>只在http协议和mail协议上功能比较好，性能与haproxy差不多；
apache------>功能较差<br>
总的来说，一般是lvs做4层负载；nginx做7层负载；haproxy比较灵活，4层和7层负载均衡都能做
一般对负载均衡的使用是随着网站规模的提升根据不同的阶段来使用不同的技术。具体的应用需求还得具体分析：
1）如果是中小型的 Web 应用，比如日PV小于1000 万，用 Nginx 就完全可以了；
2）如果机器不少，可以用DNS轮询， LVS所耗费的机器还是比较多的；大型网站或重要的服务，且服务器比较多时， 可以考虑用LVS。
还有一种是通过硬件来进行进行，常见的硬件有比较昂贵的F5和Array等商用的负载均衡器，它的优点就是有专业的维护团队来对这些服务进行维护、缺点就是花销太大，所以对于规模较小
的网络服务来说暂时还没有需要使用；另外一种就是类似于 Nginx/LVS/HAProxy 的基于 Linux 的开源免费的负载均衡软件，这些都是通过软件级别来实现，所以费用非常低廉。目前关于网
站架构一般比较合理流行的架构方案： Web 前端采用Nginx/HAProxy+Keepalived 作负载均衡器；后端采用 MySQL 数据库一主多从和读写分离，采用 LVS+Keepalived 的架构。 当然要根据
项目具体需求制定方案。下面说说各自的特点和适用场合。
------------------------------------------------------------------------------------------------------------------
下面简单说下Nginx、LVS、HAProxy 负载均衡软件的优缺点：
一、Nginx的优点是：
1）工作在网络的7层之上，可以针对 http 应用做一些分流的策略，比如针对域名、目录结构，它的正则规则比 HAProxy 更为强大和灵活，这也是它目前广泛流
行的主要原因之一， Nginx 单凭这点可利用的场合就远多于 LVS 了。
2） Nginx 对网络稳定性的依赖非常小，理论上能 ping 通就就能进行负载功能，这个也是它的优势之一；相反 LVS 对网络稳定性依赖比较大，这点本人深有体会；
3） Nginx 安装和配置比较简单，测试起来比较方便，它基本能把错误用日志打印出来。 LVS 的配置、测试就要花比较长的时间了， LVS 对网络依赖比较大。
4）可以承担高负载压力且稳定，在硬件不差的情况下一般能支撑几万次的并发量，负载度比 LVS 相对小些。
5） Nginx 可以通过端口检测到服务器内部的故障，比如根据服务器处理网页返回的状态码、超时等等，并且会把返回错误的请求重新提交到另一个节点，不过其中缺点就是不支持url来检测。
比如用户正在上传一个文件，而处理该上传的节点刚好在上传过程中出现故障， Nginx 会把上传切到另一台服务器重新处 理，而LVS就直接断掉了，如果是上传一个很大的文件或者很重要的文
件的话，用户可能会因此而不满。
6）Nginx 不仅仅是一款优秀的负载均衡器/反向代理软件，它同时也是功能强大的 Web 应用服务器。 LNMP 也是近几年非常流行的 web 架构，在高流量的环境中稳定性也很好。
7）Nginx 现在作为 Web 反向加速缓存越来越成熟了，速度比传统的 Squid 服务器更快，可以考虑用其作为反向代理加速器。
8）Nginx 可作为中层反向代理使用，这一层面 Nginx 基本上无对手，唯一可以对比 Nginx 的就只有 lighttpd 了，不过 lighttpd 目前还没有做到 Nginx 完全的功能，配置也不那么清晰易读，
社区资料也远远没 Nginx 活跃。
9） Nginx 也可作为静态网页和图片服务器，这方面的性能也无对手。还有 Nginx社区非常活跃，第三方模块也很多。
Nginx 的缺点是：
1）Nginx 仅能支持 http、 https 和 Email 协议，这样就在适用范围上面小些，这个是它的缺点。
2）对后端服务器的健康检查，只支持通过端口来检测，不支持通过 url 来检测。不支持 Session 的直接保持，但能通过 ip_hash 来解决。
二、LVS：使用 Linux 内核集群实现一个高性能、 高可用的负载均衡服务器，它具有很好的可伸缩性（ Scalability)、可靠性（ Reliability)和可管理性（Manageability)。
LVS 的优点是：
1）抗负载能力强、是工作在网络 4 层之上仅作分发之用， 没有流量的产生，这个特点也决定了它在负载均衡软件里的性能最强的，对内存和 cpu 资源消耗比较低。
2）配置性比较低，这是一个缺点也是一个优点，因为没有可太多配置的东西，所以并不需要太多接触，大大减少了人为出错的几率。
3）工作稳定，因为其本身抗负载能力很强，自身有完整的双机热备方案，如LVS+Keepalived，不过我们在项目实施中用得最多的还是 LVS/DR+Keepalived。
4）无流量， LVS 只分发请求，而流量并不从它本身出去，这点保证了均衡器 IO的性能不会收到大流量的影响。
5）应用范围比较广，因为 LVS 工作在 4 层，所以它几乎可以对所有应用做负载均衡，包括 http、数据库、在线聊天室等等。
LVS 的缺点是：
1）软件本身不支持正则表达式处理，不能做动静分离；而现在许多网站在这方面都有较强的需求，这个是 Nginx/HAProxy+Keepalived 的优势所在。
2）如果是网站应用比较庞大的话， LVS/DR+Keepalived 实施起来就比较复杂了，特别后面有 Windows Server 的机器的话，如果实施及配置还有维护过程就比较复杂了，相对而言，
Nginx/HAProxy+Keepalived 就简单多了。
三、HAProxy 的特点是：
1）HAProxy 也是支持虚拟主机的。
2）HAProxy 的优点能够补充 Nginx 的一些缺点，比如支持 Session 的保持，Cookie的引导；同时支持通过获取指定的 url 来检测后端服务器的状态。
3）HAProxy 跟 LVS 类似，本身就只是一款负载均衡软件；单纯从效率上来讲HAProxy 会比 Nginx 有更出色的负载均衡速度，在并发处理上也是优于 Nginx 的。
4）HAProxy 支持 TCP 协议的负载均衡转发，可以对 MySQL 读进行负载均衡，对后端的 MySQL 节点进行检测和负载均衡，大家可以用 LVS+Keepalived 对 MySQL主从做负载均衡。
5）HAProxy 负载均衡策略非常多， HAProxy 的负载均衡算法现在具体有如下8种：
1> roundrobin，表示简单的轮询，这个不多说，这个是负载均衡基本都具备的；
2> static-rr，表示根据权重，建议关注；
3> leastconn，表示最少连接者先处理，建议关注；
4> source，表示根据请求源 IP，这个跟 Nginx 的 IP_hash 机制类似，我们用其作为解决 session 问题的一种方法，建议关注；
5> ri，表示根据请求的 URI；
6> rl_param，表示根据请求的 URl 参数’balance url_param’ requires an URLparameter name；
7> hdr(name)，表示根据 HTTP 请求头来锁定每一次 HTTP 请求；
8> rdp-cookie(name)，表示根据据 cookie(name)来锁定并哈希每一次 TCP 请求。
四、Nginx和LVS 对比的总结：
1）Nginx 工作在网络的 7 层，所以它可以针对 http 应用本身来做分流策略，比如针对域名、目录结构等，相比之下 LVS 并不具备这样的功能，所以 Nginx 单凭这点可利用的场合就远多于LVS了；
但 Nginx 有用的这些功能使其可调整度要高于 LVS，所以经常要去触碰触碰，触碰多了，人为出问题的 几率也就会大。
2）Nginx 对网络稳定性的依赖较小，理论上只要 ping 得通，网页访问正常， Nginx就能连得通，这是 Nginx 的一大优势！ Nginx 同时还能区 分内外网，如果是同时拥有内外网的节点，就相当于
单机拥有了备份线路； LVS 就比较依赖于网络环境，目前来看服务器在同一网段内并且 LVS 使用 direct 方式分流，效果较能得到保证。另外注意， LVS 需要向托管商至少申请多一个 ip 来做
Visual IP，貌似是不能用本身的 IP 来做 VIP 的。要做好 LVS 管理员，确实得跟进学习很多有关网络通信方面的知识，就不再是一个 HTTP 那么简单了。
3）Nginx 安装和配置比较简单，测试起来也很方便，因为它基本能把错误用日志打印出来。 LVS 的安装和配置、测试就要花比较长的时间了； LVS 对网络依赖比较大，很多时候不能配置成功都是
因为网络问题而不是配置问题，出了问题要解决也相应的会麻烦得多。
4）Nginx 也同样能承受很高负载且稳定，但负载度和稳定度差 LVS 还有几个等级：Nginx 处理所有流量所以受限于机器 IO 和配置；本身的 bug 也还是难以避免的。
5）Nginx 可以检测到服务器内部的故障，比如根据服务器处理网页返回的状态码、超时等等，并且会把返回错误的请求重新提交到另一个节点。目前 LVS 中ldirectd 也能支持针对服务器内部的情况
来监控，但 LVS 的原理使其不能重发请求。比如用户正在上传一个文件，而处理该上传的节点刚好在上传过程中 出现故障， Nginx 会把上传切到另一台服务器重新处理，而 LVS 就直接断掉了，如果
是上传一个很大的文件或者很重要的文件的话，用户可能会因此而恼火。
6）Nginx 对请求的异步处理可以帮助节点服务器减轻负载，假如使用 apache 直接对外服务，那么出现很多的窄带链接时 apache 服务器将会占用大 量内存而不能释放，使用多一个 Nginx 做 apache
代理的话，这些窄带链接会被 Nginx 挡住，apache 上就不会堆积过多的请求，这样就减少了相 当多的资源占用。这点使用squid 也有相同的作用，即使 squid 本身配置为不缓存，对 apache 还是有
很大帮助的。
7）Nginx 能支持 http、 https 和 email（ email 的功能比较少用）， LVS 所支持的应用在这点上会比 Nginx 更多。在使用上，一般最 前端所采取的策略应是 LVS，也就是 DNS 的指向应为 LVS 均衡器，
LVS 的优点令它非常适合做这个任务。重要的ip地址，最好交由 LVS 托管，比如数据 库的 ip、 webservice 服务器的 ip等等，这些 ip 地址随着时间推移，使用面会越来越大，如果更换 ip 则故障会接踵
而至。所以将这些重要 ip 交给 LVS 托管是最为稳妥的，这样做的唯一缺点是需要的 VIP 数量会比较多。Nginx 可作为 LVS 节点机器使用，一是可以利用 Nginx的功能，二是可以利 用 Nginx 的性能。当然
这一层面也可以直接使用 squid，squid 的功能方面就比 Nginx 弱不少了，性能上也有所逊色于 Nginx。Nginx 也可作为中层代理使用，这一层面 Nginx 基本上无对手，唯一可以撼动 Nginx 的就只有 lighttpd
了，不过 lighttpd 目前还没有能做到 Nginx 完全的功能，配置也不那么清晰易读。另外，中层代理的 IP 也是重要的，所以中层代理也拥有一个VIP 和 LVS 是最完美的方案了。具体的应用还得 具体分析，如果
是比较小的网站（日 PV 小于 1000 万），用 Nginx 就完全可以了，如果机器也不少，可以用DNS 轮询， LVS 所耗费的机器还是比较多 的；大型网站或者重要的服务，机器不发愁的时候，要多多考虑利用 LVS。
现在对网络负载均衡的使用是随着网站规模的提升根据不同的阶段来使用不同的技术：
1）第一阶段：利用 Nginx 或 HAProxy 进行单点的负载均衡，这一阶段服务器规模刚脱离开单服务器、单数据库的模式，需要一定的负载均衡，但是仍 然规模较小没有专业的维护团队来进行维护，也没有需要进行大规模的网站部署。这样利用Nginx 或 HAproxy 就是第一选择，此时这些东西上手快， 配置容易，在七层之上利用 HTTP 协议就可以。这时是第一选择。
2）第二阶段：随着网络服务进一步扩大，这时单点的 Nginx 已经不能满足，这时使用 LVS 或者商用 Array 就是首要选择， Nginx 此时就作为 LVS 或者 Array 的节点来使用，具体 LVS 或 Array 的是选择是根据
公司规模和预算来选择，Array 的应用交付功能非常强大，本人在某项目中使用过，性价比也远高于 F5，商用首选！但是一般来说这阶段相关人才跟不上业务的提升，所以购买商业负载均衡已经成为了必经之路。
3）第三阶段：这时网络服务已经成为主流产品，此时随着公司知名度也进一步扩展，相关人才的能力以及数量也随之提升，这时无论从开发适合自身产品的定制，以及降低成本来讲开源的 LVS，已经成为首选，这时
LVS 会成为主流。最终形成比较理想的基本架构为： Array/LVS — Nginx/Haproxy —Squid/Varnish — AppServer。软件负载均衡一般通过两种方式来实现：基于操作系统的软负载实现和基于第三方应用的软负载实现。LVS就是基于Linux操作系统实现的一种软负载，HAProxy就是开源的并且基于第三应用实现的软负载。HAProxy相比LVS的使用要简单很多，功能方面也很丰富。当前，HAProxy支持两种主要的代理模式:"tcp"也即4层（大多用于邮件服务器、内部协议通信服务器等），和7层（HTTP）。在4层模式 下，HAProxy仅在客户端和服务器之间转发双向流量。7层模式下，HAProxy会分析协议，并且能通过允许、拒绝、交换、增加、修改或者删除请求 (request)或者回应(response)里指定内容来控制协议，这种操作要基于特定规则。
5.nginx反向代理mysql
默认Nginx只支持http的反向代理，要想nginx支持tcp的反向代理，还需要在编译时增加tcp代理模块支持，即nginx_tcp_proxy_module
下面操作步骤只让nginx支持tcp_proxy，没有加入prce、gzip、ssl等功能，如需要，可自行在编译时加上相关参数。
//编译的时候需要加入这个模块才能进行反代tcp_proxy_module-master
./configure --add-module=../nginx_tcp_proxy_module-master
--prefix=/usr/local/nginx-1.6.3
--with-http_stub_status_module
--with-http_gzip_static_modulenginx配置文件中需要加入以下：
nginx 反向代理TCP mysql
stream {
upstream mysql {
hash $remote_addr consistent;
server 10.26.112.12:3306 max_fails=3 fail_timeout=30s;
}
server {
listen 3307;
proxy_connect_timeout 30s;
proxy_timeout 600s;
proxy_pass mysql;
}
}