说说Linux下的负载均衡
2010-10-11 21:13:40 
阿炯
一、目前网站架构一般分成负载均衡层、Web层和数据库层，我其实一般还会多加一层，即文件服务器层，因为现在随着网站的PV越来越多，文件服务器的压力也越来越大；不过随着moosefs、DRDB+Heartbeat的日趋成熟，这问题也不大了。网站最前端的负载均衡层称之为Director，它起的是分摊请求的作用，最常见的就是轮询。
二、F5是通过硬件的方式来实现负载均衡，它较多应用于CDN系统，用于squid反向加速集群的负载均衡，是专业的硬件负载均衡设备，尤其适用于每秒新建连接数和并发连接数要求高的场景；LVS和Nginx是通过软件的方式来实现的，但稳定性也相当强悍，在处理高并发的情况也有相当不俗的表现。
三、Nginx对网络的依赖较小，理论上只要ping得通，网页访问正常，nginx就能连得通，nginx同时还能区分内外网，如果是同时拥有内外网的节点，就相当于单机拥有了备份线路；lvs就比较依赖于网络环境，目前来看服务器在同一网段内并且lvs使用direct方式分流，效果较能得到保证。
四、目前较成熟的负载均衡高可用技术有LVS+Keepalived、Nginx+Keepalived，以前Nginx没有成熟的双机备份方案，但通过shell脚本监控是可以实现的，有兴趣的可具体参考我在51cto上的项目实施方案；另外，如果考虑Nginx的负载均衡高可用，也可以通过 DNS轮询的方式来实现。
五、集群是指负载均衡后面的web集群或tomcat集群等，但现在的集群意义泛指了整个系统架构，它包括了负载均衡器以及后端的应用服务器集群等，现在许多人都喜欢把Linux集群指为LVS，但我觉得严格意义上应该区分开。
六、负载均衡高可用中的高可用指的是实现负载均衡器的HA，即一台负载均衡器坏掉后另一台可以在<1s秒内切换，最常用的软件就是 Keepalived和Heatbeat，成熟的生产环境下的负载均衡器方案有Lvs+Keepalived、Nginx+Keepalived。
七、LVS的优势非常多：①抗负载能力强；②工作稳定(因为有成熟的HA方案)；③无流量；④基本上能支持所有的应用，基于以上的优点，LVS 拥有不少的粉丝；但世事无绝对，LVS对网络的依赖性太大了，在网络环境相对复杂的应用场景中，可选用Nginx。
八、Nginx对网络的依赖性小，而且它的正则强大而灵活，强悍的特点吸引了不少人，而且配置也是相当的方便和简约，小中型项目实施中我基本是考虑它的；当然，如果资金充足，F5是不二的选择。
九、大型网站架构中其实可以结合使用F5、LVS或Nginx，选择它们中的二种或三种全部选择；如果因为预算的原因不选择F5，那么网站最前端的指向应该是LVS，也就是DNS的指向应为lvs均衡器，lvs的优点令它非常适合做这个任务。重要的ip地址，最好交由lvs托管，比如数据库的 ip、webservice服务器的ip等等，这些ip地址随着时间推移，使用面会越来越大，如果更换ip则故障会接踵而至。所以将这些重要ip交给 lvs托管是最为稳妥的。
十、VIP地址是Keepalived虚拟的一个IP，它是一个对外的公开IP，也是DNS指向的IP；所以在设计网站架构时，你必须向你的IDC多申请一个对外IP。
十一、在实际项目实施过程中发现，Lvs和Nginx对https的支持都非常好，尤其是LVS，相对而言处理起来更为简便。
十二、在LVS+Keepalived及Nginx+Keepalived的故障处理中，这二者都是很方便的；如果发生了系统故障或服务器相关故障，即可将DNS指向由它们后端的某台真实web，达到短期处理故障的效果，毕竟广告网站和电子商务网站的PV就是金钱，这也是为什么要将负载均衡高可用设计于此的原因；大型的广告网站我就建议直接上CDN系统了。
十三、现在Linux集群都被大家神话了，其实这个也没多少复杂；关键看你的应用场景，哪种适用就选用哪种，Nginx和LVS、F5都不是神话，哪种方便哪种适用就选用哪种。
十四、另外关于session共享的问题，这也是一个老生长谈的问题了；Nginx可以用ip_hash机制来解决session的问题，而 F5和LVS都有会话保持机制来解决这个问题，此外，还可以将session写进数据库，这也是一个解决session共享的好办法，当然这个也会加重数据库的负担，这个看系统架构师的取舍了。
十五、我现在目前维护的电子商务网站并发大约是1000左右，以前的证券资讯类网站是100左右，大型网上广告大约是3000，我感觉web层的并发越来越不是一个问题；现在由于服务器的强悍，再加上Nginx作web的高抗并发性，web层的并发并不是什么大问题；相反而言，文件服务器层和数据库层的压力是越来越大了，单NFS不可能胜任目前的工作，现在好的方案是moosefs和DRDB+Heartbeat+NFS；而我喜欢的Mysql 服务器，成熟的应用方案还是主从，如果压力过大，我不得不选择oracle的RAC双机方案。
十六、现在受张宴的影响，大家都去玩Nginx了(尤其是作web)，其实在服务器性能优异，内存足够的情况下，Apache的抗并发能力并不弱，整个网站的瓶颈应该还是在数据库方面；我建议可以双方面了解Apache和Nginx，前端用Nginx作负载均衡，后端用Apache作web，效果也是相当的好。真的？
十七、Heartbeat的脑裂问题没有想象中那么严重，在线上环境可以考虑使用；DRDB+Heartbeat算是成熟的应用了，建议掌握。我在相当多的场合用此组合来替代EMC共享存储，毕竟30万的价格并不是每个客户都愿意接受的。
十八、无论设计的方案是多么的成熟，还是建议要配置Nagios监控机来实时监控服务器情况；邮件和短信报警都可以开启，毕竟手机可以随身携带；有条件的还可以购买专门的商业扫描网站服务，它会每隔一分钟扫描你的网站，如果发现没有alive会向你的邮件发警告信息。
四层七层负载的区别
1. 什么是负载均衡
负载均衡 建立在现有网络结构之上，它提供了一种廉价有效透明的方法扩展网络设备和服务器的带宽、增加吞吐量、加强网络数据处理能力、提高网络的灵活性和可用性。
2. 负载均衡分类
负载均衡根据所采用的设备对象(软/硬件负载均衡)，应用的OSI网络层次(网络层次上的负载均衡)，及应用的地理结构(本地/全局负载均衡)等来分类。根据应用的 OSI 网络层次来分类的两个负载均衡类型。
网络模型图，包含了 OSI 模型及 TCP/IP 模型，两个模型虽然有一点点区别，但主要的目的是一样的，模型图描述了通信是怎么进行的。它解决了实现有效通信所需要的所有过程，并将这些过程划分为逻辑上的层。层可以简单地理解成数据通信需要的步骤。
OSI VS TCP/IP
根据负载均衡所作用在 OSI 模型的位置不同，负载均衡可以大概分为以下几类：
二层负载均衡(mac)
根据OSI模型分的二层负载，一般是用虚拟mac地址方式，外部对虚拟MAC地址请求，负载均衡接收后分配后端实际的MAC地址响应。
三层负载均衡(ip)
一般采用虚拟IP地址方式，外部对虚拟的ip地址请求，负载均衡接收后分配后端实际的IP地址响应。
四层负载均衡(tcp)
在三层负载均衡的基础上，用ip+port接收请求，再转发到对应的机器。
七层负载均衡(http)
根据虚拟的url或IP，主机名接收请求，再转向相应的处理服务器。
在实际应用中，比较常见的就是四层负载及七层负载。这里也重点说下这两种负载。
3. 四层负载均衡(基于IP+端口的负载均衡)
所谓四层负载均衡，也就是主要通过报文中的目标地址和端口，再加上负载均衡设备设置的服务器选择方式，决定最终选择的内部服务器。
在三层负载均衡的基础上，通过发布三层的IP地址(VIP)，然后加四层的端口号，来决定哪些流量需要做负载均衡，对需要处理的流量进行NAT处理，转发至后台服务器，并记录下这个TCP或者UDP的流量是由哪台服务器处理的，后续这个连接的所有流量都同样转发到同一台服务器处理。
以常见的TCP为例，负载均衡设备在接收到第一个来自客户端的SYN 请求时，即通过上述方式选择一个最佳的服务器，并对报文中目标IP地址进行修改(改为后端服务器IP)，直接转发给该服务器。TCP的连接建立，即三次握手是客户端和服务器直接建立的，负载均衡设备只是起到一个类似路由器的转发动作。在某些部署情况下，为保证服务器回包可以正确返回给负载均衡设备，在转发报文的同时可能还会对报文原来的源地址进行修改。
对应的负载均衡器称为四层交换机(L4 switch)，主要分析IP层及TCP/UDP层，实现四层负载均衡。此种负载均衡器不理解应用协议(如HTTP/FTP/MySQL等等)
要处理的流量进行NAT处理，转发至后台服务器，并记录下这个TCP或者UDP的流量是由哪台服务器处理的，后续这个连接的所有流量都同样转发到同一台服务器处理。实现四层负载均衡的软件有：
F5：硬件负载均衡器，功能很好，但是成本很高。
lvs：重量级的四层负载软件
nginx：轻量级的四层负载软件，带缓存功能，正则表达式较灵活
aproxy：模拟四层转发，较灵活
4. 七层的负载均衡(基于虚拟的URL或主机IP的负载均衡)
所谓七层负载均衡，也称为“内容交换”，也就是主要通过报文中的真正有意义的应用层内容，再加上负载均衡设备设置的服务器选择方式，决定最终选择的内部服务器。
在四层负载均衡的基础上(没有四层是绝对不可能有七层的)，再考虑应用层的特征，比如同一个Web服务器的负载均衡，除了根据VIP加80端口辨别是否需要处理的流量，还可根据七层的URL、浏览器类别、语言来决定是否要进行负载均衡。举个例子，如果你的Web服务器分成两组，一组是中文语言的，一组是英文语言的，那么七层负载均衡就可以当用户来访问你的域名时，自动辨别用户语言，然后选择对应的语言服务器组进行负载均衡处理。
以常见的TCP为例，负载均衡设备如果要根据真正的应用层内容再选择服务器，只能先代理最终的服务器和客户端建立连接(三次握手)后，才可能接受到客户端发送的真正应用层内容的报文，然后再根据该报文中的特定字段，再加上负载均衡设备设置的服务器选择方式，决定最终选择的内部服务器。负载均衡设备在这种情况下，更类似于一个代理服务器。负载均衡和前端的客户端以及后端的服务器会分别建立TCP连接。所以从这个技术原理上来看，七层负载均衡明显的对负载均衡设备的要求更高，处理七层的能力也必然会低于四层模式的部署方式。
对应的负载均衡器称为七层交换机(L7 switch)，除了支持四层负载均衡以外，还有分析应用层的信息，如HTTP协议URI或Cookie信息，实现七层负载均衡，此种负载均衡器能理解应用协议。实现七层负载均衡的软件有：
haproxy：天生负载均衡技能，全面支持七层代理，会话保持，标记，路径转移；
nginx：只在http协议和mail协议上功能比较好，性能与haproxy差不多；
apache：功能较差
mysql proxy：功能尚可。
5. 区别
Linux 负载均衡算法存在瑕疵-修复后性能将提升一倍
2020年03月14日，Linux 内核开发者 Vincent Guittot 发现 Linux 完全调度算法 CFS 存在瑕疵，修复之后将进一步提升调度性能。
在 Linux 负载均衡期间，使用 CFS 算法时，系统会从负载较高的运行队列中拉取一些任务交给负载较低的队列，以此分摊 CPU 资源利用率。一般的过程就是系统会从最高利用率的队列往下拉任务，但是 Vincent 在邮件列表中表示，这其中存在一个问题：实际上算法没有考虑到在这个过程中可能有一些待处理任务要拉，如果有这样的待处理任务需要拉，那么与负载均衡分摊利用率的过程就会产生短暂的“冲突”，使得对队列资源利用率的分摊将延后，也就是等到拉完待处理的任务后再进行。
而根据分析，Vincent 发现这种待处理任务至少有两个，也就是说会出现两次短暂的“冲突”，虽然很微小，但是会影响系统的整体性能。同时他也对修复该问题之后的效益进行了具体影响数据的测算，发现每个请求花费的最大时间减少大约一半，平均从 21 ms 减少为 11 ms，考虑空闲负载均衡等因素，最糟糕的情况下从 41 ms 减少到 21 ms（虽然平均每个请求的影响只有 0.1 多）。
平均最大值不能完全反映该值的广泛分布尖端/预定/核心的范围从1.350ms到41ms以上，并且补丁程序在1.350ms到21ms之间。更加具体的分析可以查看邮件列表。
负载均衡（Server Load Balancer, SLB）技术是保证云服务高效、稳定运行的重要组成部分。它通过分配网络或应用流量到多个服务器，确保了服务的高可用性和高性能。
云计算提供了一种灵活、可扩展的服务运行环境，使得企业和开发者能够快速响应市场变化，优化资源配置。而负载均衡技术在其中起到了至关重要的作用。
例如，假设一个电子商务网站在黑色星期五这一天迎来了巨大的流量激增。如果没有负载均衡技术，单一的服务器可能会因为超负荷而崩溃，导致用户无法访问网站，从而造成严重的经济损失。而有了负载均衡技术，网络流量会被均匀分配到多个服务器上，确保每个服务器的负载都保持在一个可接受的范围内，从而保证了网站的正常运行和用户的访问体验。
SLB 的重要性
SLB 作为负载均衡技术在云计算环境中的具体实现，它不仅能够保证服务的高可用性，还能通过优化资源分配，提升服务的响应速度和处理能力。以一个在线视频平台为例，平台需要保证无论用户数量多少，视频的播放都要流畅无卡顿。通过它可使平台可以将用户的请求分配到不同的服务器上，确保每个服务器的负载都在可控范围内，从而为用户提供高质量的观看体验。同时当某个服务器发生故障时，SLB 能够自动将流量重新分配到其他健康的服务器上，保证了服务的持续可用。
通过以上两个实际的例子，我们可以看到负载均衡技术和 SLB 在云计算环境中的重要作用。它们为企业和开发者提供了强大的工具，以应对网络流量的波动和系统负载的变化，是实现高效、稳定云服务的关键。
SLB 核心技术
Server Load Balancer (SLB) 是一种负载均衡技术，它在云计算环境中扮演着至关重要的角色。通过其可以将网络流量和请求有效地分配到多个服务器上，从而保证了应用的高可用性和高性能。在本节中，我们将深入解析 SLB 的核心技术，包括负载均衡算法、会话保持技术以及健康检查。
1、负载均衡算法
负载均衡算法是 SLB 的核心，它决定了如何将流量分配到不同的服务器上。常见的负载均衡算法有轮询法、最少连接法和 IP Hash 法。
1.1 轮询法
轮询法是最简单也最直接的负载均衡算法，它将每个新的请求按照顺序分配到服务器列表中的服务器上。例如，假设有三个服务器 A、B 和 C，轮询法会依次将请求分配给 A、B、C、A、B、C，如此循环。这种方法简单公平，但可能不适用于服务器性能不均的场景。
1.2 最少连接法
最少连接法是一种动态的负载均衡算法，它会将新的请求分配给当前连接数最少的服务器。举例来说，假设在一个购物网站的高峰期，服务器 A 已经有 30 个连接，而服务器 B 只有 10 个连接，最少连接法会将新的请求分配给服务器 B，从而尽量保持服务器之间的负载均衡。
1.3 IP Hash 法
IP Hash 法根据客户端的 IP 地址计算一个哈希值，然后根据哈希值将请求分配给特定的服务器。
这种方法能够保证来自同一 IP 的请求总是被分配到同一个服务器，有助于保持会话的一致性。例如，在一个在线游戏场景中，玩家的所有请求需要被发送到同一个服务器以保证游戏状态的一致。
2、会话保持技术
会话保持是负载均衡中的另一个重要概念，它能保证一个用户的多个请求被发送到同一个服务器。
2.1 Cookie 保持
通过在 HTTP 响应中设置特定的 Cookie，SLB 可以识别来自同一用户的请求，并将它们路由到同一服务器。这对于保持用户登录状态和购物车信息等非常重要。
2.2 IP 绑定
IP 绑定是另一种会话保持技术，它根据用户的 IP 地址将所有请求路由到同一服务器。与 IP Hash 法类似，这种方法适用于需要保持会话状态的应用。
2.3 健康检查
健康检查是 SLB 中用于监控服务器状态的机制。通过定期检查服务器的响应，SLB 能够判断服务器是否健康，从而确保流量只被路由到健康的服务器。
2.3.1 TCP 健康检查
通过发送 TCP 探测包来检查服务器的可达性和响应时间，是判断服务器健康状态的一种简单有效的方法。
2.3.2 HTTP 健康检查
HTTP 健康检查则通过发送 HTTP 请求，并检查 HTTP 响应的状态码和内容，来判断服务器的健康状态。
例如，在一个在线订餐平台中，通过 HTTP 健康检查，SLB 能够实时监控每个服务器的状态，一旦发现某个服务器的响应时间超过预设的阈值或返回错误码，SLB 会将该服务器标记为不健康，从而避免用户请求被路由到出现问题的服务器，保证了服务的高可用性和用户体验。
通过以上深入的技术解析和实际例子可以更清晰地理解 SLB 的核心技术和其在云计算环境中的重要作用。
SLB 用户最佳实践
在实际的云计算环境中，有效地使用 Server Load Balancer (SLB) 是确保应用高可用性和高性能的关键。本节将为读者展示一些 SLB 的用户最佳实践，包括 SLB 的配置和优化，以及如何应对常见的问题和挑战。
1、部署与配置 SLB
部署和配置 SLB 是最基本也是最重要的步骤。正确的配置能确保流量得到有效分配，同时保证应用的稳定运行。
1.1 选择合适的负载均衡算法
不同的负载均衡算法适用于不同的场景。例如，对于请求处理时间相对固定的应用，轮询法可能是一个合适的选择。而对于处理时间波动较大的应用，最少连接法可能更为合适。举例来说，在一个在线视频处理服务中，由于视频文件大小和编码复杂度的不同，处理时间可能会有很大的波动。在这种情况下，最少连接法能够保证新的请求更可能被分配到当前负载较低的服务器，从而实现更好的负载均衡。
1.2 设置合理的会话保持
会话保持对于需要保持用户状态的应用非常重要。通过配置合理的会话保持，可以确保用户的连续请求被发送到同一服务器，从而保持应用的状态一致。例如，在一个在线购物平台中，用户的购物车信息需要在多个请求之间保持一致。通过使用 Cookie 保持或 IP 绑定，可以保证用户的所有请求都被路由到同一服务器，从而保持购物车状态的一致。
2、优化 SLB 性能
SLB 的性能直接影响到应用的响应时间和用户体验。通过一些优化措施，可以进一步提升 SLB 的性能。
2.1 调优负载均衡算法
根据应用的实际负载和服务器性能，调整负载均衡算法的参数，以实现更好的负载均衡效果。
2.2 优化健康检查配置
合理的健康检查配置能够及时发现服务器的故障，同时避免对服务器造成额外的负担。例如，可以通过调整健康检查的间隔和超时时间，来平衡健康检查的准确性和资源消耗。
2.3 使用高效的会话保持机制
选择高效的会话保持机制，如使用 Cookie 保持而非 IP 绑定，可以减少服务器的负担，同时保证应用的状态一致。
3、处理常见问题
在实际使用 SLB 时，可能会遇到一些常见的问题和挑战，如服务器故障、流量激增等。通过一些预防和应对措施，可以减少这些问题对应用的影响。例如，在遭遇流量激增时，可以通过预先扩展服务器资源，或使用自动扩展功能，来应对可能的服务器超负荷问题。同时，通过合理的流量控制和优先级设置，可以保证关键服务的可用性和性能。
通过以上的最佳实践，用户可以更有效地利用 SLB，提升云应用的可用性和性能，同时应对实际运营中可能遇到的各种问题和挑战。
二、F5是通过硬件的方式来实现负载均衡，它较多应用于CDN系统，用于squid反向加速集群的负载均衡，是专业的硬件负载均衡设备，尤其适用于每秒新建连接数和并发连接数要求高的场景；LVS和Nginx是通过软件的方式来实现的，但稳定性也相当强悍，在处理高并发的情况也有相当不俗的表现。
三、Nginx对网络的依赖较小，理论上只要ping得通，网页访问正常，nginx就能连得通，nginx同时还能区分内外网，如果是同时拥有内外网的节点，就相当于单机拥有了备份线路；lvs就比较依赖于网络环境，目前来看服务器在同一网段内并且lvs使用direct方式分流，效果较能得到保证。
四、目前较成熟的负载均衡高可用技术有LVS+Keepalived、Nginx+Keepalived，以前Nginx没有成熟的双机备份方案，但通过shell脚本监控是可以实现的，有兴趣的可具体参考我在51cto上的项目实施方案；另外，如果考虑Nginx的负载均衡高可用，也可以通过 DNS轮询的方式来实现。
五、集群是指负载均衡后面的web集群或tomcat集群等，但现在的集群意义泛指了整个系统架构，它包括了负载均衡器以及后端的应用服务器集群等，现在许多人都喜欢把Linux集群指为LVS，但我觉得严格意义上应该区分开。
六、负载均衡高可用中的高可用指的是实现负载均衡器的HA，即一台负载均衡器坏掉后另一台可以在<1s秒内切换，最常用的软件就是 Keepalived和Heatbeat，成熟的生产环境下的负载均衡器方案有Lvs+Keepalived、Nginx+Keepalived。
七、LVS的优势非常多：①抗负载能力强；②工作稳定(因为有成熟的HA方案)；③无流量；④基本上能支持所有的应用，基于以上的优点，LVS 拥有不少的粉丝；但世事无绝对，LVS对网络的依赖性太大了，在网络环境相对复杂的应用场景中，可选用Nginx。
八、Nginx对网络的依赖性小，而且它的正则强大而灵活，强悍的特点吸引了不少人，而且配置也是相当的方便和简约，小中型项目实施中我基本是考虑它的；当然，如果资金充足，F5是不二的选择。
九、大型网站架构中其实可以结合使用F5、LVS或Nginx，选择它们中的二种或三种全部选择；如果因为预算的原因不选择F5，那么网站最前端的指向应该是LVS，也就是DNS的指向应为lvs均衡器，lvs的优点令它非常适合做这个任务。重要的ip地址，最好交由lvs托管，比如数据库的 ip、webservice服务器的ip等等，这些ip地址随着时间推移，使用面会越来越大，如果更换ip则故障会接踵而至。所以将这些重要ip交给 lvs托管是最为稳妥的。
十、VIP地址是Keepalived虚拟的一个IP，它是一个对外的公开IP，也是DNS指向的IP；所以在设计网站架构时，你必须向你的IDC多申请一个对外IP。
十一、在实际项目实施过程中发现，Lvs和Nginx对https的支持都非常好，尤其是LVS，相对而言处理起来更为简便。
十二、在LVS+Keepalived及Nginx+Keepalived的故障处理中，这二者都是很方便的；如果发生了系统故障或服务器相关故障，即可将DNS指向由它们后端的某台真实web，达到短期处理故障的效果，毕竟广告网站和电子商务网站的PV就是金钱，这也是为什么要将负载均衡高可用设计于此的原因；大型的广告网站我就建议直接上CDN系统了。
十三、现在Linux集群都被大家神话了，其实这个也没多少复杂；关键看你的应用场景，哪种适用就选用哪种，Nginx和LVS、F5都不是神话，哪种方便哪种适用就选用哪种。
十四、另外关于session共享的问题，这也是一个老生长谈的问题了；Nginx可以用ip_hash机制来解决session的问题，而 F5和LVS都有会话保持机制来解决这个问题，此外，还可以将session写进数据库，这也是一个解决session共享的好办法，当然这个也会加重数据库的负担，这个看系统架构师的取舍了。
十五、我现在目前维护的电子商务网站并发大约是1000左右，以前的证券资讯类网站是100左右，大型网上广告大约是3000，我感觉web层的并发越来越不是一个问题；现在由于服务器的强悍，再加上Nginx作web的高抗并发性，web层的并发并不是什么大问题；相反而言，文件服务器层和数据库层的压力是越来越大了，单NFS不可能胜任目前的工作，现在好的方案是moosefs和DRDB+Heartbeat+NFS；而我喜欢的Mysql 服务器，成熟的应用方案还是主从，如果压力过大，我不得不选择oracle的RAC双机方案。
十六、现在受张宴的影响，大家都去玩Nginx了(尤其是作web)，其实在服务器性能优异，内存足够的情况下，Apache的抗并发能力并不弱，整个网站的瓶颈应该还是在数据库方面；我建议可以双方面了解Apache和Nginx，前端用Nginx作负载均衡，后端用Apache作web，效果也是相当的好。真的？
十七、Heartbeat的脑裂问题没有想象中那么严重，在线上环境可以考虑使用；DRDB+Heartbeat算是成熟的应用了，建议掌握。我在相当多的场合用此组合来替代EMC共享存储，毕竟30万的价格并不是每个客户都愿意接受的。
十八、无论设计的方案是多么的成熟，还是建议要配置Nagios监控机来实时监控服务器情况；邮件和短信报警都可以开启，毕竟手机可以随身携带；有条件的还可以购买专门的商业扫描网站服务，它会每隔一分钟扫描你的网站，如果发现没有alive会向你的邮件发警告信息。
四层七层负载的区别
1. 什么是负载均衡
负载均衡 建立在现有网络结构之上，它提供了一种廉价有效透明的方法扩展网络设备和服务器的带宽、增加吞吐量、加强网络数据处理能力、提高网络的灵活性和可用性。
2. 负载均衡分类
负载均衡根据所采用的设备对象(软/硬件负载均衡)，应用的OSI网络层次(网络层次上的负载均衡)，及应用的地理结构(本地/全局负载均衡)等来分类。根据应用的 OSI 网络层次来分类的两个负载均衡类型。
网络模型图，包含了 OSI 模型及 TCP/IP 模型，两个模型虽然有一点点区别，但主要的目的是一样的，模型图描述了通信是怎么进行的。它解决了实现有效通信所需要的所有过程，并将这些过程划分为逻辑上的层。层可以简单地理解成数据通信需要的步骤。
OSI VS TCP/IP
根据负载均衡所作用在 OSI 模型的位置不同，负载均衡可以大概分为以下几类：
二层负载均衡(mac)
根据OSI模型分的二层负载，一般是用虚拟mac地址方式，外部对虚拟MAC地址请求，负载均衡接收后分配后端实际的MAC地址响应。
三层负载均衡(ip)
一般采用虚拟IP地址方式，外部对虚拟的ip地址请求，负载均衡接收后分配后端实际的IP地址响应。
四层负载均衡(tcp)
在三层负载均衡的基础上，用ip+port接收请求，再转发到对应的机器。
七层负载均衡(http)
根据虚拟的url或IP，主机名接收请求，再转向相应的处理服务器。
在实际应用中，比较常见的就是四层负载及七层负载。这里也重点说下这两种负载。
3. 四层负载均衡(基于IP+端口的负载均衡)
所谓四层负载均衡，也就是主要通过报文中的目标地址和端口，再加上负载均衡设备设置的服务器选择方式，决定最终选择的内部服务器。
在三层负载均衡的基础上，通过发布三层的IP地址(VIP)，然后加四层的端口号，来决定哪些流量需要做负载均衡，对需要处理的流量进行NAT处理，转发至后台服务器，并记录下这个TCP或者UDP的流量是由哪台服务器处理的，后续这个连接的所有流量都同样转发到同一台服务器处理。
以常见的TCP为例，负载均衡设备在接收到第一个来自客户端的SYN 请求时，即通过上述方式选择一个最佳的服务器，并对报文中目标IP地址进行修改(改为后端服务器IP)，直接转发给该服务器。TCP的连接建立，即三次握手是客户端和服务器直接建立的，负载均衡设备只是起到一个类似路由器的转发动作。在某些部署情况下，为保证服务器回包可以正确返回给负载均衡设备，在转发报文的同时可能还会对报文原来的源地址进行修改。
对应的负载均衡器称为四层交换机(L4 switch)，主要分析IP层及TCP/UDP层，实现四层负载均衡。此种负载均衡器不理解应用协议(如HTTP/FTP/MySQL等等)
要处理的流量进行NAT处理，转发至后台服务器，并记录下这个TCP或者UDP的流量是由哪台服务器处理的，后续这个连接的所有流量都同样转发到同一台服务器处理。实现四层负载均衡的软件有：
F5：硬件负载均衡器，功能很好，但是成本很高。
lvs：重量级的四层负载软件
nginx：轻量级的四层负载软件，带缓存功能，正则表达式较灵活
aproxy：模拟四层转发，较灵活
4. 七层的负载均衡(基于虚拟的URL或主机IP的负载均衡)
所谓七层负载均衡，也称为“内容交换”，也就是主要通过报文中的真正有意义的应用层内容，再加上负载均衡设备设置的服务器选择方式，决定最终选择的内部服务器。
在四层负载均衡的基础上(没有四层是绝对不可能有七层的)，再考虑应用层的特征，比如同一个Web服务器的负载均衡，除了根据VIP加80端口辨别是否需要处理的流量，还可根据七层的URL、浏览器类别、语言来决定是否要进行负载均衡。举个例子，如果你的Web服务器分成两组，一组是中文语言的，一组是英文语言的，那么七层负载均衡就可以当用户来访问你的域名时，自动辨别用户语言，然后选择对应的语言服务器组进行负载均衡处理。
以常见的TCP为例，负载均衡设备如果要根据真正的应用层内容再选择服务器，只能先代理最终的服务器和客户端建立连接(三次握手)后，才可能接受到客户端发送的真正应用层内容的报文，然后再根据该报文中的特定字段，再加上负载均衡设备设置的服务器选择方式，决定最终选择的内部服务器。负载均衡设备在这种情况下，更类似于一个代理服务器。负载均衡和前端的客户端以及后端的服务器会分别建立TCP连接。所以从这个技术原理上来看，七层负载均衡明显的对负载均衡设备的要求更高，处理七层的能力也必然会低于四层模式的部署方式。
对应的负载均衡器称为七层交换机(L7 switch)，除了支持四层负载均衡以外，还有分析应用层的信息，如HTTP协议URI或Cookie信息，实现七层负载均衡，此种负载均衡器能理解应用协议。实现七层负载均衡的软件有：
haproxy：天生负载均衡技能，全面支持七层代理，会话保持，标记，路径转移；
nginx：只在http协议和mail协议上功能比较好，性能与haproxy差不多；
apache：功能较差
mysql proxy：功能尚可。
5. 区别
| 区别 | 四层负载均衡(layer 4) | 七层负载均衡(layer 7) |
|---|---|---|
| 基于 | 基于IP+Port的 | 基于虚拟的URL或主机IP等。 |
| 类似于 | 路由器 | 代理服务器 |
| 握手次数 | 1 次 | 2次 |
| 复杂度 | 低 | 高 |
| 性能 | 高；无需解析内容 | 中；需要算法识别 URL，Cookie 和 HTTP head 等信息 |
| 安全性 | 低，无法识别 DDoS等攻击 | 高， 可以防御SYN cookie以SYN flood等 |
| 额外功能 | 无 | 会话保持，图片压缩，防盗链等 |
Linux 负载均衡算法存在瑕疵-修复后性能将提升一倍
2020年03月14日，Linux 内核开发者 Vincent Guittot 发现 Linux 完全调度算法 CFS 存在瑕疵，修复之后将进一步提升调度性能。
在 Linux 负载均衡期间，使用 CFS 算法时，系统会从负载较高的运行队列中拉取一些任务交给负载较低的队列，以此分摊 CPU 资源利用率。一般的过程就是系统会从最高利用率的队列往下拉任务，但是 Vincent 在邮件列表中表示，这其中存在一个问题：实际上算法没有考虑到在这个过程中可能有一些待处理任务要拉，如果有这样的待处理任务需要拉，那么与负载均衡分摊利用率的过程就会产生短暂的“冲突”，使得对队列资源利用率的分摊将延后，也就是等到拉完待处理的任务后再进行。
而根据分析，Vincent 发现这种待处理任务至少有两个，也就是说会出现两次短暂的“冲突”，虽然很微小，但是会影响系统的整体性能。同时他也对修复该问题之后的效益进行了具体影响数据的测算，发现每个请求花费的最大时间减少大约一半，平均从 21 ms 减少为 11 ms，考虑空闲负载均衡等因素，最糟糕的情况下从 41 ms 减少到 21 ms（虽然平均每个请求的影响只有 0.1 多）。
平均最大值不能完全反映该值的广泛分布尖端/预定/核心的范围从1.350ms到41ms以上，并且补丁程序在1.350ms到21ms之间。更加具体的分析可以查看邮件列表。
负载均衡（Server Load Balancer, SLB）技术是保证云服务高效、稳定运行的重要组成部分。它通过分配网络或应用流量到多个服务器，确保了服务的高可用性和高性能。
云计算提供了一种灵活、可扩展的服务运行环境，使得企业和开发者能够快速响应市场变化，优化资源配置。而负载均衡技术在其中起到了至关重要的作用。
例如，假设一个电子商务网站在黑色星期五这一天迎来了巨大的流量激增。如果没有负载均衡技术，单一的服务器可能会因为超负荷而崩溃，导致用户无法访问网站，从而造成严重的经济损失。而有了负载均衡技术，网络流量会被均匀分配到多个服务器上，确保每个服务器的负载都保持在一个可接受的范围内，从而保证了网站的正常运行和用户的访问体验。
SLB 的重要性
SLB 作为负载均衡技术在云计算环境中的具体实现，它不仅能够保证服务的高可用性，还能通过优化资源分配，提升服务的响应速度和处理能力。以一个在线视频平台为例，平台需要保证无论用户数量多少，视频的播放都要流畅无卡顿。通过它可使平台可以将用户的请求分配到不同的服务器上，确保每个服务器的负载都在可控范围内，从而为用户提供高质量的观看体验。同时当某个服务器发生故障时，SLB 能够自动将流量重新分配到其他健康的服务器上，保证了服务的持续可用。
通过以上两个实际的例子，我们可以看到负载均衡技术和 SLB 在云计算环境中的重要作用。它们为企业和开发者提供了强大的工具，以应对网络流量的波动和系统负载的变化，是实现高效、稳定云服务的关键。
SLB 核心技术
Server Load Balancer (SLB) 是一种负载均衡技术，它在云计算环境中扮演着至关重要的角色。通过其可以将网络流量和请求有效地分配到多个服务器上，从而保证了应用的高可用性和高性能。在本节中，我们将深入解析 SLB 的核心技术，包括负载均衡算法、会话保持技术以及健康检查。
1、负载均衡算法
负载均衡算法是 SLB 的核心，它决定了如何将流量分配到不同的服务器上。常见的负载均衡算法有轮询法、最少连接法和 IP Hash 法。
1.1 轮询法
轮询法是最简单也最直接的负载均衡算法，它将每个新的请求按照顺序分配到服务器列表中的服务器上。例如，假设有三个服务器 A、B 和 C，轮询法会依次将请求分配给 A、B、C、A、B、C，如此循环。这种方法简单公平，但可能不适用于服务器性能不均的场景。
1.2 最少连接法
最少连接法是一种动态的负载均衡算法，它会将新的请求分配给当前连接数最少的服务器。举例来说，假设在一个购物网站的高峰期，服务器 A 已经有 30 个连接，而服务器 B 只有 10 个连接，最少连接法会将新的请求分配给服务器 B，从而尽量保持服务器之间的负载均衡。
1.3 IP Hash 法
IP Hash 法根据客户端的 IP 地址计算一个哈希值，然后根据哈希值将请求分配给特定的服务器。
这种方法能够保证来自同一 IP 的请求总是被分配到同一个服务器，有助于保持会话的一致性。例如，在一个在线游戏场景中，玩家的所有请求需要被发送到同一个服务器以保证游戏状态的一致。
2、会话保持技术
会话保持是负载均衡中的另一个重要概念，它能保证一个用户的多个请求被发送到同一个服务器。
2.1 Cookie 保持
通过在 HTTP 响应中设置特定的 Cookie，SLB 可以识别来自同一用户的请求，并将它们路由到同一服务器。这对于保持用户登录状态和购物车信息等非常重要。
2.2 IP 绑定
IP 绑定是另一种会话保持技术，它根据用户的 IP 地址将所有请求路由到同一服务器。与 IP Hash 法类似，这种方法适用于需要保持会话状态的应用。
2.3 健康检查
健康检查是 SLB 中用于监控服务器状态的机制。通过定期检查服务器的响应，SLB 能够判断服务器是否健康，从而确保流量只被路由到健康的服务器。
2.3.1 TCP 健康检查
通过发送 TCP 探测包来检查服务器的可达性和响应时间，是判断服务器健康状态的一种简单有效的方法。
2.3.2 HTTP 健康检查
HTTP 健康检查则通过发送 HTTP 请求，并检查 HTTP 响应的状态码和内容，来判断服务器的健康状态。
例如，在一个在线订餐平台中，通过 HTTP 健康检查，SLB 能够实时监控每个服务器的状态，一旦发现某个服务器的响应时间超过预设的阈值或返回错误码，SLB 会将该服务器标记为不健康，从而避免用户请求被路由到出现问题的服务器，保证了服务的高可用性和用户体验。
通过以上深入的技术解析和实际例子可以更清晰地理解 SLB 的核心技术和其在云计算环境中的重要作用。
SLB 用户最佳实践
在实际的云计算环境中，有效地使用 Server Load Balancer (SLB) 是确保应用高可用性和高性能的关键。本节将为读者展示一些 SLB 的用户最佳实践，包括 SLB 的配置和优化，以及如何应对常见的问题和挑战。
1、部署与配置 SLB
部署和配置 SLB 是最基本也是最重要的步骤。正确的配置能确保流量得到有效分配，同时保证应用的稳定运行。
1.1 选择合适的负载均衡算法
不同的负载均衡算法适用于不同的场景。例如，对于请求处理时间相对固定的应用，轮询法可能是一个合适的选择。而对于处理时间波动较大的应用，最少连接法可能更为合适。举例来说，在一个在线视频处理服务中，由于视频文件大小和编码复杂度的不同，处理时间可能会有很大的波动。在这种情况下，最少连接法能够保证新的请求更可能被分配到当前负载较低的服务器，从而实现更好的负载均衡。
1.2 设置合理的会话保持
会话保持对于需要保持用户状态的应用非常重要。通过配置合理的会话保持，可以确保用户的连续请求被发送到同一服务器，从而保持应用的状态一致。例如，在一个在线购物平台中，用户的购物车信息需要在多个请求之间保持一致。通过使用 Cookie 保持或 IP 绑定，可以保证用户的所有请求都被路由到同一服务器，从而保持购物车状态的一致。
2、优化 SLB 性能
SLB 的性能直接影响到应用的响应时间和用户体验。通过一些优化措施，可以进一步提升 SLB 的性能。
2.1 调优负载均衡算法
根据应用的实际负载和服务器性能，调整负载均衡算法的参数，以实现更好的负载均衡效果。
2.2 优化健康检查配置
合理的健康检查配置能够及时发现服务器的故障，同时避免对服务器造成额外的负担。例如，可以通过调整健康检查的间隔和超时时间，来平衡健康检查的准确性和资源消耗。
2.3 使用高效的会话保持机制
选择高效的会话保持机制，如使用 Cookie 保持而非 IP 绑定，可以减少服务器的负担，同时保证应用的状态一致。
3、处理常见问题
在实际使用 SLB 时，可能会遇到一些常见的问题和挑战，如服务器故障、流量激增等。通过一些预防和应对措施，可以减少这些问题对应用的影响。例如，在遭遇流量激增时，可以通过预先扩展服务器资源，或使用自动扩展功能，来应对可能的服务器超负荷问题。同时，通过合理的流量控制和优先级设置，可以保证关键服务的可用性和性能。
通过以上的最佳实践，用户可以更有效地利用 SLB，提升云应用的可用性和性能，同时应对实际运营中可能遇到的各种问题和挑战。