lvs-nat：类似于DNAT, 但支持多目标转发； 它通过修改请求报文的目标地址为根据调度算法所挑选出的某RS的RIP来进行转发； 架构特性： (1) RS应该使用私有地址，即RIP应该为私有地址；各RS的网关必须指向DIP； (2) 请求和响应报文都经由Director转发；高负载场景中，Director易于成为系统瓶颈； (3) 支持端口映射； (4) RS可以使用任意类型的OS; (5)

lvs-dr：直接路由 Director在实现转发时不修改请求的IP首部，而是通过直接封装MAC首部完成转发；目标MAC是Director根据调度方法挑选出某RS的MAC地址；拓扑结构有别有NAT类型； 架构特性： (1) 保证前端路由器将目标地址为VIP的请求报文通过ARP地址解析后送往Director 解决方案： 静态绑定：在前端路由直接将VIP对应的目标MAC静态配置为Director的MA

varnish: www.varnish-cache.org varnish是一款开源应用程序，高性能且开源的反向代理服务器，同时也是http加速器，采用较新的开发技术和体系结构，较为现代的硬件体系紧密结合，于传统squid相比，varnish性能更高，速度更快，管理更方便等一系列优点。目前大多大型网站已经用varnish来替换squid。 varnsh只要有两个进程，management和chi

补充下概念拓扑 状态引擎 sub vcl_recv #vim /etc/varnish/default.vcl 启用node0 -varnish sub vcl_recv { if (req.restarts == 0) { if (req.http.x-forwarded-for) { set req.http.X-Forwarded-For = req.http.X-Forwarded-For

常用变量： 1、在任何引擎中均可使用： now, .host, .port 2、用于处理请求阶段： client.ip, server.hostname, server.ip, server.port req.request：请求方法 req.url: 请求的URL req.proto: HTTP协议版本 req.backend: 用于服务此次请求的后端主机； req.backend.health

作为一个缓存来讲，它首先的是一个代理。varnish本身来讲http协议的反向代理，后端可以拖动多个主机来提供内容，一旦有多个主机，varnish如何从多个后端挑选一个主机来响应用户的请求。有实现定制的必要性。因此，它也能支持负载均衡调度的方式实现对后端主机的指定。 在官方文档中说明了如何实现，backend，方法非常简单、 Varnish使用多台后端主机 Varnish中可以使用director

varnish的线程模型： cache-worker线程 cache-main线程：此线程只有一个，用于启动caceh； ban luker：实现缓存清理 acceptor：接受用户请求 epoll：线程池管理器 expire：清理过期缓存 varnish工作特性： ***** varnish> param.show -l 定义acceptor线程工作特性 acceptor_sleep_de

  从最根本应用来讲，haproxy是一个代理，或者说是一个httpd的代理 代理类型分为两种，正向代理和反向代理 代理类型：私有代理，为本地或有限用户的 公共代理：如谷歌   Haproxy代理作用：访问控制，web缓存（加速），反向代理，内容请求路由（根据流量及内容类型等条件将请求转发至特定的服务器），转码器 缓存的作用，减少冗余内容的传输，从而节省了带宽，缓解了后端网络瓶颈，降低了对原始请求

HAproxy下载安装包 yum install gcc vim wget wget http://www.haproxy.org/download/1.6/src/haproxy-1.6.5.tar.gz 解压编译 tar xf haproxy-1.6.5.tar.gz cd haproxy-1.6.5 make TARGET=linux31 PREFIX=/usr/local/haproxy

我们试图将后端的业务通过lvs转到nginx代理，nginx分别作为4成和7层代理，这里使用DR模型，那就意味着只能进行做4层代理。类似如：tomcat，mq等也可以进行代理，试图减少代码的耦合度，将他们拆分，使用一个vpi加端口的形式。 我准备了4台机器加一台redis做测试 lvs 10.10.240.144 and 10.10.240.143 nginx-proxy 10.10.240.11

haproxy在1.8就官方就开始支持很多的新的功能，如：reload的功能，至今从2001年12月到现在已经过去了17年，改进是非常的多，并且在未来haproxy将会以每年2次的发布更新，版本先后兼容旧的配置。 PS：内容谷歌翻译 在haproxy1.9中更新了很多的内容，其中包括： 缓冲区改进 HAProxy 已经支持HTTP / 2到客户端。此版本的主要目标是支持端到端HTTP / 2，包括

HAProxy配置文件指导HAProxy负载均衡器的行为。在这篇文章中，我们展示了它最重要的四个部分。 HAProxy配置文件有四个基本部分。他们是global，defaults和frontend，和backend。这四个部分定义了整个服务器的执行方式，默认设置以及客户端请求的接收方式和路由到后端服务器的方式。 如果反向代理的世界比作一个奥运接力赛，那么global，defaults，fronte

有两种方法可以让HAProxy在多个CPU核心上运行： 通过使用多进程模型，HAProxy自动启动许多单独的系统进程（自HAProxy版本1.1.7起可用的方法） 通过使用多线程模型，HAProxy在单个进程中自动启动多个线程（自HAProxy版本1.8起可用的方法） 传统的多进程方法目前实现了更好的性能，但新的多线程模型解决了通常与多进程配置相关的所有限制，对于喜欢易于管理而不是最大性能的早期采

在操作日志数据时，HAProxy提供了丰富的信息。在这篇博文中，我们将演示如何设置HAProxy日志记录，定位Syslog服务器，了解日志字段以及建议一些用于解析日志文件的有用工具。 HAProxy位于基础架构的关键拓扑中。无论是用作load balancer，sidecar还是作为Kubernetes ingress controller，从HAProxy中获取有意义的日志都是必须的。 日志记录

在这篇博文中，你将学习如何使用Runtime API动态配置HAProxy。 要了解有关HAProxy配置的更多信息，请参阅我们的博客文章HAProxy配置的四个基本部分。 在过去的15年中，HAProxy以其可靠性，卓越的性能，可扩展的功能和先进的安全性而闻名。这是相对较少众所周知，HAProxy的核心基石之一是运行时API，它提供了非常强大的动态配置功能，没有服务重载或重新启动。 Runtim

HAProxy Technologies的研发部门发布了一个补丁集，可以在不丢弃数据包的情况下实现HAProxy的无缝重新加载。该补丁集最早合并到HAProxy 1.8开发分支中，而后在每个版本持续支持。 这项工作是HAProxy Technologies更大的路线图计划的一部分，以支持更多的微服务用例，因为我们看到这些用例变得越来越频繁。这个特定的修复应该很好地解决大型环境，其中多个服务都共享相

在之前的博客文章HAProxy Logging简介中，你了解了如何利用HAProxy的强大功能，通过日志记录将可观察性提高到负载均衡器和服务的状态。HAProxy还附带一个名为HAProxy Stats页面的仪表板，该页面向你显示涵盖服务器运行状况，当前请求率，响应时间等的大量指标。这些指标为你提供了基于每个前端，后端和服务器的精细数据。你只需要添加一个stats enable指令，该指令通常放在

通过HAProxy ACL，你可以定义用于阻止恶意请求，选择后端，重定向到HTTPS以及使用缓存对象的自定义规则。 当相关人员将负载均衡器添加到他们的基础架构中时，他们正在寻找能够扩展其网站和服务，获得更好的可用性以及获得更多宁静的夜晚，因为他们知道他们的关键服务不再是单点故障。然而，不久之后，他们意识到使用像HAProxy 这样的负载均衡器，他们可以智能的来检查传入的流量并在运行中做出决策。例如

HAProxy映射文件存储键值对，并且是一些创造性行为的起点，包括动态速率限制和蓝绿色部署。 字典。Map。哈希值。关联数组。这些列为HAProxy负载均衡器的广泛功能集。它们被称为map。 想要设置蓝绿色部署？也许你想通过URL路径设置速率限制？如何动态切换哪些后端服务器用于域？这一切都是用map完成的！ 在本文中，你将学习如何创建map文件，将其存储在系统中，在HAProxy配置中引用它，并实

在此前的几篇文章在中，简单的记录了haproxy在1.9之后的一些变化（部分来自谷歌翻译），这其中包括多线程，Runtime API, ACL,配置文件,以及日志和统计页面和map。 在这篇文章中，我将简单叙述haproxy的docker配置，我重构了haproxy的docker配置，作为简单的使用中，可以重载配置文件。这借用了supervisor与inotifywait的配置。一旦配置文件发生改