linux文件删除原理

目前线上用的负载均衡器硬件有F5，BIG-IP，软件有LVS，Nginx和HAProxy，高可用软件有Heartbeat，Keepalived，成熟的框架有LVS+Keepalived，Nginx+Keepalived，HAProxy+Keepalived以及DRBD+Heartbeat。

实际应用中，在Web服务器集群之前有一台负载均衡服务器，负载均衡设备的任务就是作为Web服务器流量的入口，挑选最合适的一台Web服务器，将客户端的请求转发给它处理，实现客户端到真实服务端的透明转发；LVS、Nginx、HAProxy是目前使用最广泛的三种负载均衡软件。

一般对负载均衡的使用是随着网站规模的提升根据不同的阶段来使用不同的技术：如果是中小型的Web应用，比如日PV小于1000万，用Nginx就完全可以；如果机器不少，可以用DNS轮询，LVS所耗费的机器还是比较多的；大型网站或重要的服务，且服务器比较多时，可以考虑用LVS。

目前关于网站架构一般比较流行的架构方案：Web前端采用Nginx/HAProxy+Keepalived作负载均衡器；后端采用MySQL数据库一主多从和读写分离，采用LVS+Keepalived的架构。

1 LVS

LVS是Linux Virtual Server的简称，即Linux虚拟服务器。现在LVS已经是Linux标准内核的一部分，从Linux2.4内核以后，已经完全内置了LVS的各个功能模块，无需给内核打任何补丁就可以直接使用LVS提供的各种功能。
DS：Director Server，指的是前端负载均衡器节点
RS：Real Server，后端真实的工作服务器
VIP：向外部直接面向用户请求，作为用户请求的目标IP地址
DIP：Director Server IP，主要用于和内部主机通讯的IP地址
RIP：Real Server IP，后端服务器的IP地址
CIP：Client IP，访问客户端的IP地址

1.1 LVS体系结构

LVS架设的服务器集群系统由三个部分组成：
(1) 最前端的负载均衡层，用Load Balancer表示；
(2) 中间的服务器集群层，用Server Array表示；
(3) 最底端的数据共享存储层，用Shared Storage表示；

1.2 LVS负载均衡机制

LVS不像HAProxy等七层软负载均衡面向的是HTTP包，所以七层负载可以做URL解析等工作，LVS无法完成，因为LVS是四层负载均衡，就是说建立在OSI模型的第四层——传输层之上，传输层上有我们熟悉的TCP/UDP，LVS支持TCP/UDP的负载均衡。因为LVS是四层负载均衡，所以它相对于其它高层负载均衡，比如DNS域名轮询解析、应用层负载的调度、客户端的调度等，效率较高。

所谓四层负载均衡，即主要通过报文中的目标地址和端口；七层负载均衡，也称为内容交换，即主要通过报文中的应用层内容。
LVS的转发主要通过修改IP地址(NAT模式，分为SNAT源地址修改和DNAT目标地址修改、修改目标MAC(DR模式)来实现。

1.2.1 NAT模式：网络地址转换

NAT(Network Address Translation)是一种外网和内网地址映射的技术。NAT模式下，网络数据报的进出都要经过LVS的处理。LVS 需要作为RS(真实服务器)的网关。

当包到达LVS时，LVS做目标地址转换(DNAT)，将目标IP改为RS的IP，RS接收到包以后，和客户端直接发给它的一样。RS处理完，返回响应时，源IP是RS的IP，目标IP是客户端的IP，这时RS的包通过网关(LVS)中转，LVS会做源地址转换(SNAT)，将包的源地址改为VIP，这样，客户端看起来这个包就是LVS直接返回给它。


用户请求LVS到达director，director将请求的报文的目的IP改为RIP，同时将报文的目标端口也改为realserver的相应端口，最后将报文发送到realserver上，realserver将数据返回给director，director再把数据发送给用户；
NAT特性：
NAT模式修改的是目的ip，直接走的是switch不需要修改mac地址，所以VIP和RIP不需要在同一个网段内；
NAT的包进出都需要经过LVS，所以LVS可能会成为一个系统的瓶颈问题；

1.2.2 IP TUN模式

用户请求LVS到达director，director通过IP-TUN加密技术将请求报文的包封装到一个新的IP包里面，目的IP为VIP(不变)，然后director将报文发送到realserver，realserver基于IP-TUN解密，然后解析出来包的目的IP为VIP，检测网卡是否绑定了VIP，绑定了就处理这个包，如果在同一个网段，将请求直接返回给用户，否则通过网关返回给用户；如果没有绑定VIP就直接丢掉这个包；
IP TUN特性：

• TUNNEL必须在有所的realserver上绑定VIP；
• realserver直接把包发给client；
• 隧道模式运维起来比较难，一般不用；

1.2.3 DR模式：直接路由

DR模式下需要LVS和RS集群绑定同一个VIP(RS通过将VIP绑定在loopback实现)，但与NAT的不同点在于：请求由LVS接收，由真实提供服务的服务器(RealServer，RS)直接返回给用户，返回的时候不经过LVS。

请求过来时，LVS只需要将网络帧的MAC地址修改为某一台RS的MAC，该包就会被转发到相应的RS处理，注意此时的源IP和目标IP都没变，RS收到LVS转发来的包时，链路层发现MAC是自己的，到上面的网络层，发现IP也是自己的，于是这个包被合法地接受，RS感知不到前面有LVS的存在，而当RS返回响应时，只要直接向源IP(即用户的IP)返回即可，不再经过LVS。

DR负载均衡模式数据分发过程中不修改IP地址，只修改mac地址，由于实际处理请求的真实物理IP地址和数据请求目的IP地址一致，所以不需要通过负载均衡服务器进行地址转换，可将响应数据包直接返回给用户浏览器，避免负载均衡服务器网卡带宽成为瓶颈。因此，DR模式具有较好的性能，也是目前大型网站使用最广泛的一种负载均衡手段。

用户请求LVS到达director，director将请求的报文的目的MAC地址改为后端的realserver的MAC地址，目的IP为VIP(不变)，源IP为client IP地址(不变)，然后director将报文发送到realserver，realserver检测到目的地址为自己本地的VIP，如果在同一网段，将请求直接返回给用户，如果用户跟realserver不在同一个网段，则需要通过网关返回给用户；
DR特性：

• 前端路由将目标地址为VIP的报文发给Director Server；
• RS跟Director Server必须有一个网卡在同一个物理网络中；
• 所有的请求报文经由Director Server，但响应报文必须不经过Director Server；
• 所有的real server机器上都有VIP地址

1.2.4 FULLNAT模式

FULLNAT特性：

• FULLNAT模式也不需要DIP和RIP在同一网段；
• FULLNAT和NAT相比的话：会保证RS的回包一定可到达LVS；
• FULLNAT需要更新源IP，所以性能正常比NAT模式下降10%；

1.2.5 LVS的优点

• 抗负载能力强，工作在传输层上仅作分发，没有流量的产生，这个特点也决定了它在负载均衡软件里的性能最强，对内存和CPU资源消耗比较低；
• 配置性比较低，这是一个缺点也是一个优点，因为没有可太多配置的东西，所以并不需要太多接触，大大减少了人为出错的几率；
• 工作稳定，因为其本身抗负载能力很强，自身有完整的双机热备方案，如LVS+Keepalived；
• 无流量，LVS只分发请求，而流量并不从它本身出去，这点保证了负载均衡器IO的性能不会受到大流量的影响；
• 应用范围比较广，因为LVS工作在传输层，所以它几乎可以对所有应用做负载均衡，包括http、数据库、在线聊天室等；

1.2.6 LVS的缺点

• 软件本身不支持正则表达式处理，不能做动静分离；而现在许多网站在这方面都有较强的需求，这个是Nginx、HAProxy+Keepalived的优势所在；
• 如果网站应用比较庞大，LVS/DR+Keepalived实施起来比较复杂，相对而言Nginx/HAProxy+Keepalived较为简单；

1.2.7 四种模式比较

(1) 是否需要VIP和realserver在同一网段？
DR模式因为只修改包的MAC地址，需要通过ARP广播找到realserver，所以VIP和realserver必须在同一个网段，也就是说DR模式需要先确认这个IP是否只能挂在这个LVS下面；其他模式因为都会修改目的地址为realserver的IP地址，所以不需要在同一个网段内；
(2) 是否需要在realserver上绑定VIP？
realserver在收到包之后会判断目的地址是否是自己的IP；
DR模式的目的地址没有修改，还是VIP，所以需要在realserver上绑定VIP；
IP TUN模式只是对包重新包装了一层，realserver解析后的包的IP仍然是VIP，所以也需要在realserver上绑定VIP；
(3) 性能比较
DR模式、IP TUN模式都是在包进入的时候经过LVS，在包返回的时候直接返回给client，所以二者的性能比NAT高；
但TUN模式更加复杂，所以性能不如DR；
FULLNAT模式不仅更换目的IP还更换了源IP，所以性能比NAT下降10%；
性能比较：DR > TUN > NAT > FULLNAT

2 nginx

Nginx是一个强大的Web服务器软件，用于处理高并发的HTTP请求和作为反向代理服务器做负载均衡，具有高性能、轻量级、内存消耗少，强大的负载均衡能力等优势。

2.1 nginx架构

相对于传统基于进程或线程的模型(Apache就采用这种模型)在处理并发连接时会为每一个连接建立一个单独的进程或线程，且在网络输入/输出操作时阻塞，这将导致内存和CPU的大量消耗，因为新起一个单独的进程或线程需要准备新的运行时环境，包括堆和栈内存的分配，以及新的执行上下文，当然这些也会导致多余的CPU开销，最终会由于过多的上下文切换而导致服务器性能变差。

Nginx的架构设计是采用模块化的、基于事件驱动、异步、单线程且非阻塞。Nginx大量使用多路复用和事件通知，Nginx启动以后，会在系统中以daemon方式在后台运行，其中包括一个master进程，n(n>=1)个worker进程，所有的进程都是单线程(即只有一个主线程)，且进程间通信主要使用共享内存的方式。其中master进程用于接收外部信号，并给worker进程发送信号，同时监控worker进程的工作状态，worker进程则是外部请求真正的处理者，每个worker相互独立且平等的竞争来自客户端的请求，请求只能在一个worker进程中被处理，且一个worker进程只有一个主线程，所以同时只能处理一个请求。

2.2 nginx负载均衡

Nginx负载均衡主要是针对七层网络通信模型中的第七层应用层的http、https。

Nginx是以反向代理的方式进行负载均衡的，反向代理方式是指以代理服务器来接收Internet上的连接请求，然后将请求转发给内部网络服务器，并将服务器的结果返回给请求客户端，此时代理服务器对外就表现为一个服务器。Nginx实现负载均衡的分配策略有很多，Nginx的upstream目前支持以下几种方式：

• 轮询(默认)：每个请求按时间顺序逐一分配到不同的后端服务器，如果后端服务器down掉，能自动剔除；
• weight：指定轮询几率，weight和访问比率成正比，用于后端服务器性能不均的情况；
• ip_hash：每个请求按访问ip的hash结果分配，这样每个客户端固定访问一台后端服务器，可以解决session的问题；
• fair(第三方)：按后端服务器的响应时间来分配请求，响应时间短的优先分配；
• url_hash(第三方)：按访问url的hash结果来分配请求，使每个url定向到同一台后端服务器，后端服务器为缓存时比较有效；

2.3 nginx优点

• 跨平台：Nginx可以在大多数Unix like OS编译运行，而且也有Windows的移植版本；
• 配置简单：非常容易上手，配置风格跟程序开发一样；
• 非阻塞、高并发连接：官方测试能够支撑5万并发连接，实际生产环境中跑到2～3万并发连接数；
• 事件驱动：通信机制采用epoll模型，支持更大的并发连接；
• Master/Worker结构：一个master进程，生成一个或多个worker进程；
• 内存消耗小：处理大并发的请求内存消耗非常小，在3万并发连接下，开启的10个Nginx进程才消耗150M内存(15M*10=150M)；
• 内置的健康检查功能：如果Nginx代理的后端某台Web服务器宕机了，不会影响前端访问；
• 节省带宽：支持GZIP压缩，可以添加浏览器本地缓存的Header头；
• 稳定性高：用于反向代理，宕机的概率小；

2.4 nginx缺点

• Nginx仅支持http、https和Email协议，适用范围小；
• 对后端服务器的健康检查，只支持通过端口来检测，不支持通过url来检测；不支持Session的直接保持，但能通过ip_hash来解决；

3 HAProxy

HAProxy支持两种代理模式TCP(四层)和HTTP(七层)，也支持虚拟主机；
HAProxy支持Session保持，Cookie引导，同时支持通过获取指定的url来检测后端服务器的状态；HAProxy跟LVS类似，本身只是一款负载均衡软件，单纯从效率上来讲HAProxy比Nginx有更出色的负载均衡速度，在并发处理上也优于Nginx；
HAProxy支持TCP协议的负载均衡转发，可以对后端MySQL读进行负载均衡；对后端MySQL节点检测和主从做负载均衡，可以用LVS+Keepalived。
HAProxy负载均衡策略非常多：Round-robin(轮询)，Weight-round-robin(带权轮询)，source(原地址保持)，RI(请求URL)，rdp-cookie(根据cookie)。

4 keepalived和heartbeat

两款流行的高可用开源方案：Keepalived和Heartbeat，将资源(ip以及程序服务等)从一台已经故障的机器快速转移到另一台正常的机器上继续提供服务，称之为高可用服务。

heartbeat和keepalived有很多相同之处，但是也有区别：
(1) Keepalived使用简单：从安装、配置、使用、维护等角度上对比，Keepalived都比Heartbeat要简单；
(2) Heartbeat功能更强大：Heartbeat虽然复杂，但功能更强大，配套工具更全，适合做大型集群管理，而Keepalived主要用于集群切换，基本没有管理功能；
(3) 协议不同：Keepalived使用VRRP即虚拟路由冗余协议(Virtual Router Redundancy Protocol，简称VRRP，思科交换就是使用这个协议做双机)进行通信和选举；Heartbeat使用心跳(IBM POWER小型机就是用心跳线做双机)进行通信和选举，Heartbeat通过UDP协议或串口通信。

应用场景
Heartbeat是基于主机或网络服务的高可用方式；
keepalived的目的是模拟路由器的双机；
heartbeat的目的是用户service的双机
lvs的高可用建议用keepavlived；
业务的高可用建议heartbeat；

4.1 工作原理

主备模式 一台heartbeat服务器作为主服务器，另一台自动成为热备服务器，在热备服务器上面配置heartbeat守护程序来监听来自主服务器的心跳信息，如果在规定时间内，无法监听到心跳信息，那么就启动故障转移，取得主服务器上的相关资源的所有权，接替主服务器继续不间断的提供服务，从而达到资源和服务高可用的目的。
主主模式 heartbeat还支持主主模式，即两台服务器互为主备，一般故障切换时间在5~20s之间。

(1) 服务器宕机
a. heartbeat软件故障
b. 心跳连接线故障
c. 服务故障不会导致切换，可以通过服务宕机把heartbeat服务停掉；

(2) 两台heartbeat服务之间通信:
a. 串行电缆，服务器上装专门串口卡(距离不能太远，一般是上下机架位)
b. 交叉网线分别直连服务器的两块网卡
c. 通过交换机用网线连接(受交换机故障影响)

(3) Heartbeat裂脑
两台服务器在一定时间内，无法相互检测到对方心跳而各自启动故障转移功能，取得资源和服务的所有权，会导致同一个IP在两端同时启动服务，存在两个相同的VIP，造成冲突的严重问题

(4) 裂脑的原因
a. 心跳链路故障，导致无法正常通信
b. 开启了防火墙阻挡了心跳信息传输
c. 心跳网卡地址等配置不正确
d. 心跳方式，心跳广播冲突，软件bug

(5) 防止裂脑方案
a. 同时使用串行电缆和以太网电缆连接，同时使用两条心跳线
b. 检测到裂脑时，强制关闭一个节点
c. 做好监控预警
d. 仲裁机制(确定让哪个节点接管服务)

(6) 消息类型
a. 心跳消息(单播，广播或者多播)：150字节的数据包
b. 集群转换消息：ip-request，ip-request-rsp
c. 重传消息：rexmit-request

4.2 IP地址接管和故障转移

heartbeat通过ip地址接管和arp广播进行故障转移。
ARP广播：在主服务器故障时，备用节点接管资源后，会立即强制更新所有客户端本地的arp表(即清除客户端本地缓存的故障服务器的vip和mac地址的解析记录)，确保客户端和新的主服务器的对话，这里所说的客户端是和Heartbeat高可用服务器所在同一网络的客户机，并不是最终的互联网用户，这里的客户端机器是相对Heartbeat高可用服务器来说的；
实IP，又称为管理ip，一般指配置在物理网卡上面的ip，在负载均衡高可用环境中，管理IP是不对外提供访问服务的，仅仅作为管理服务器使用，如SSH可以通过这个进行服务连接管理；
VIP是虚拟ip，实际上就是eth0:X，x为0~255的任意数字，你可以在一个网卡上面绑定多个别名，VIP当主服务器故障时，可以自动漂移到备用服务器；

4.3 常用配置

nginx + keepalived双主模式(双机互为主备)；

LVS + keepalived双主模式；

HAProxy + keepalived双主模式；

这个架构中要实现的功能是：通过haproxy1服务器将www.zb.com的访问请求发送到webapp1和webapp2两台主机上，实现www.zb.com的负载均衡；通过haproxy2将img.zb.com的访问请求发送到webimg1和webimg2两台主机上，实现img.zb.com的负载均衡；同时，如果haproxy1或haproxy2任何一台服务器出现故障，都会将用户访问请求发送到另一台健康的负载均衡节点，进而继续保持两个网站的负载均衡。

为了保证haproxy1和haproxy2服务器资源得到充分利用，这里对访问进行了分流操作：将www.zb.com的域名解析到10.0.0.40这个IP上，将img.zb.com域名解析到10.0.0.50这个IP上。

5 为什么会同时使用LVS+Nginx负载均衡？

LVS是四层负载均衡，Nginx是七层负载均衡，四层是数据转发，没有"请求"的概念；

从两者各自的优势来说：
nginx用来做http的反向代理，能够用upsteam实现http请求的多种方式的均衡转发，由于采用的是异步转发可以做到如果一个服务器请求失败，立即切换到其他服务器，直到请求成功或者最后一台服务器失败为止，这可以最大程度的提高系统的请求成功率。

lvs采用的是同步请求转发策略，同步转发是在lvs服务器接收到请求之后，立即转发到一个后端服务器，由客户端直接和后端服务器建立连接；异步转发是nginx在保持客户端连接的同时，发起一个相同内容的新请求到后端，等后端返回结果后，由nginx返回给客户端。

因此，当做为负载均衡服务器的nginx和lvs处理相同的请求时，所有的请求和响应流量都会经过nginx，但是使用lvs时，仅请求流量经过lvs的网络，响应流量由后端服务器的网络返回；故当后端服务器规模庞大时，nginx的网络带宽就成了一个巨大的瓶颈，但是仅仅使用lvs作为负载均衡的话，一旦后端接受到请求的服务器出了问题，那么这次请求就失败了，但如果在lvs的后端在添加一层nginx(多个)，每个nginx后端再有几台业务服务器，那么结合两者的优势，既能避免单nginx的流量集中瓶颈，又能避免单lvs请求成功率的问题。

nginx处理静态文件；
nginx作为中间环节减小后端压力，以及做一些业务切换、分流、前置缓存的功能；

一般流量大的网站，会有好几层负载均衡器，而不是只有一层，这些层可以按不同的维度去分类，比如按四层或七层协议，按硬件还是软件；

负载均衡这个领域还是以高可用和性能为2个最重要因素，下面是在系统量级达到每小时上亿PV之后最被广泛使用的一种。理论上，利用第一步DNS的域名解析所带的负载均衡效果，只要复制多套LVS主备出来，绑上多个不同的虚IP，可以做到无限横向扩展，以支撑不断增长的流量

6 为什么MySQL需要LVS+Keepalived？

MySQL复制(主主，主从)能在保证数据备份的同时，也能够做读写分离分摊系统压力，但是发生单点故障时，需要手动切换到另外一台主机。LVS和Keppalived可以设定一个VIP来实现统一访问入口，实现单点故障时VIP自动切换至另外一台主机达到高可用，同时LVS可以提供多种调度算法来实现负载均衡。

在主主复制结构中，两台服务器上的任何一台数据库存发生了改变都会同步到另一台服务器上， 这个改变是基于sql语句的改变，如果删除系统数据库源文件或删除后新创建同名MYSQL表实现同步则无效。这样两台服务器互为主从，并且都能向外提供服务，因比使用主从复制具有更好的性能。理论上，双主只要数据不冲突就可以工作的很好，但实际情况中还是很容发生数据冲突，比如在同步完成之前，双方都修改同一条记录，因此在实际中最好不要让两边同时修改，即逻辑上仍按照主从的方式工作。借助keepalived这样的软件实现自动主从切换，工作时候仍然按照主从方式复制，并且只允许一台主节点写数据，这样就不会产生冲突，一旦主库出现问题可以自动切换。

通常说的双机热备是指两台机器都在运行，但并不是两台机器同时提供服务。当提供服务的一台出现故障的时候，另外一台会马上自动接管并且提供服务，而且切换的时间非常短。MySQL双主复制，即互为Master-Slave(只有一个Master提供写操作)，可以实现数据库服务器的热备，但是一个Master宕机后不能实现动态切换，使用Keepalived，可以通过虚拟IP，实现双主对外的统一接口以及自动检查、失败切换机制，从而实现MySQL数据库的高可用方案。

双主：Keepalived
读负载均衡：LVS + Keepalived

---

转载请注明来源，欢迎对文章中的引用来源进行考证，欢迎指出任何有错误或不够清晰的表达。可以在下面评论区评论，也可以邮件至yj.mapple@gmail.com