一、概述

sven_ 2013-09-13

展开全文

在具体的分析程序源代码之前，我准备先看一下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   192.168.1.2
-------+-----------+-----+-----+-----+--------+----
        |           |     |     |     |       _|_db
     +--+--+      +-+-+ +-+-+ +-+-+ +-+-+    (___)
     | LB1 |      | A | | B | | C | | D |    (___)
     +-----+      +---+ +---+ +---+ +---+    (___)
     haproxy        4 cheap web servers

图(2)

Haproxy数据流处理流程如下：

(client)                           (haproxy)                         (server A)
>-- GET /URI1 HTTP/1.0 ------------> |
               ( no cookie, haproxy forwards in load-balancing mode. )
                                       | >-- GET /URI1 HTTP/1.0 ---------->
                                       | <-- HTTP/1.0 200 OK -------------<
               ( the proxy now adds the server cookie in return )
<-- HTTP/1.0 200 OK ---------------< |
      Set-Cookie: SERVERID=A           |
>-- GET /URI2 HTTP/1.0 ------------> |
      Cookie: SERVERID=A               |
      ( the proxy sees the cookie. it forwards to server A and deletes it )
                                       | >-- GET /URI2 HTTP/1.0 ---------->
                                       | <-- HTTP/1.0 200 OK -------------<
   ( the proxy does not add the cookie in return because the client knows it )
<-- HTTP/1.0 200 OK ---------------< |
>-- GET /URI3 HTTP/1.0 ------------> |
      Cookie: SERVERID=A               |
                                    ( ... )

这就是Haproxy对于http会话的保持方式。首先客户端发出第一个请求时，通过负载均衡算法找出一个SERVER对其进行处理，SERVER在处理完返回信息的时候将会在HTTP的头中增加一个Cookie，SERVERID=A。在客户端的后续请求中将会使用此Cookie来确定其对应的SERVER。由于客户端已经知道了Cookie，因此对于以后的响应数据，Haproxy不会在插入此Cookie。

对于属于KEEP-ALIVE的连接，Haproxy对Cookie不敏感，因为只要已连接之后，后续的请求肯定都是在此session上进行处理。

对于那些由于某种原因客户端只支持一个Cookie的情况下，并且应用程序返回的响应中已经设置了一个Cookie，那么可以使用前置Cookie来进行标记，也就是在响应信息返回时在Haproxy中修改Cookie增加前置信息，在接收到后续的请求时将Cookie中的前置部分清除掉在发送到SERVER。

从这儿可以看出Haproxy主要是使用Cookie来解决session的问题，那么对于不支持Cookie的浏览器怎么办？可以使用适当的负载均衡算法来解决，比如用对源IPHASH来进行负载均衡，那么可以保持同一IP总是在同一机器上。对于多IP的客户端怎么办？那就要求它使用单一IP，或则支持Cookie。

对architecture.txt就看到这儿，因为这主要是为了知道Haproxy的工作原理。

那么为什么architecture.txt只讲了HTTP层次的SESSION保持，而不讲TCP层次SESSION保持呢？从我的感觉来说，TCP层次没有所谓SESSION概念。假设某TCP层次程序的某两笔业务A和B的关系是B的处理需要A的处理结果，那么A的处理结果一般都会保存于DB中。