一、概述

最新推荐文章于 2024-08-16 13:28:24 发布

白色的乌云

最新推荐文章于 2024-08-16 13:28:24 发布

阅读量1.5k

点赞数 1

分类专栏： Haproxy源码分析文章标签： haproxy 源码分析

本文链接：https://blog.csdn.net/solaris_zune/article/details/8836666

版权

本文介绍了Haproxy如何通过Cookie实现HTTP会话保持，详细阐述了客户端请求、Haproxy负载均衡及服务器响应的过程。对于不支持Cookie的情况，可以通过IPHASH等算法保持会话。此外，文章提到TCP层次的SESSION保持在架构中未涉及，因为TCP层通常不涉及会话概念。

摘要由CSDN通过智能技术生成

在具体的分析程序源代码之前，我准备先看一下Haproxy的doc目录下的architecture.txt文件。

作者在此文件中说，由于涉及到解释性的脚本语言，一个网络应用程序的前端服务器SERVER往往都会承受非常大的压力；当然这也可能依赖于相对压力不是很大的后端的数据库服务器DB。(对于后者，我的理解是当DB慢一点的话，SERVER对于请求的响应就没那么快，新的请求又来到，又要分配新的资源，造成累积，自然也就会使SERVER的压力变大。)

对于网络服务器来说，用户的上下文也是存储在SERVER中，而不是存储在DB中，因此如果为了解决上述问题而通过简单的IP/TCP负载均衡来增加另一个SERVER的话是不能正常工作的。(因为用户相关的上下文是在SERVER中，如果后续连接通过负载均衡分配到其他机器上的话，那么将会找不到相应信息)

而将SERVER换成大型机系统的花费比增加几台便宜点的机器要高得多。对此，作者说可以买几台便宜的机器，在原来的老机器上安装Haproxy，将系统压力分散到多个机器中。也就是将架构从图(1)改成图(2)

+-------+
|clients| clients and/or reverse-proxy
+---+---+
|
-+-----+--------+----
|       _|_db
+--+--+   (___)
| web |   (___)
+-----+   (___)
192.168.1.1   192.168.1.2

图(1)

192.168.1.1 192.168.1.11-192.168.1.14 1