一、概述

sven_ 2013-09-13

展開全文

在具體的分析程序源代碼之前，我準備先看一下Haproxy的doc目錄下的architecture.txt文件。

作者在此文件中說，由于涉及到解釋性的腳本語言，一個網(wǎng)絡應用程序的前端服務器SERVER往往都會承受非常大的壓力；當然這也可能依賴于相對壓力不是很大的后端的數(shù)據(jù)庫服務器DB。(對于后者，我的理解是當DB慢一點的話，SERVER對于請求的響應就沒那么快，新的請求又來到，又要分配新的資源，造成累積，自然也就會使SERVER的壓力變大。)

對于網(wǎng)絡服務器來說，用戶的上下文也是存儲在SERVER中，而不是存儲在DB中，因此如果為了解決上述問題而通過簡單的IP/TCP負載均衡來增加另一個SERVER的話是不能正常工作的。(因為用戶相關(guān)的上下文是在SERVER中，如果后續(xù)連接通過負載均衡分配到其他機器上的話，那么將會找不到相應信息)

而將SERVER換成大型機系統(tǒng)的花費比增加幾臺便宜點的機器要高得多。對此，作者說可以買幾臺便宜的機器，在原來的老機器上安裝Haproxy，將系統(tǒng)壓力分散到多個機器中。也就是將架構(gòu)從圖(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數(shù)據(jù)流處理流程如下：

(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會話的保持方式。首先客戶端發(fā)出第一個請求時，通過負載均衡算法找出一個SERVER對其進行處理，SERVER在處理完返回信息的時候?qū)贖TTP的頭中增加一個Cookie，SERVERID=A。在客戶端的后續(xù)請求中將會使用此Cookie來確定其對應的SERVER。由于客戶端已經(jīng)知道了Cookie，因此對于以后的響應數(shù)據(jù)，Haproxy不會在插入此Cookie。

對于屬于KEEP-ALIVE的連接，Haproxy對Cookie不敏感，因為只要已連接之后，后續(xù)的請求肯定都是在此session上進行處理。

對于那些由于某種原因客戶端只支持一個Cookie的情況下，并且應用程序返回的響應中已經(jīng)設置了一個Cookie，那么可以使用前置Cookie來進行標記，也就是在響應信息返回時在Haproxy中修改Cookie增加前置信息，在接收到后續(xù)的請求時將Cookie中的前置部分清除掉在發(fā)送到SERVER。

從這兒可以看出Haproxy主要是使用Cookie來解決session的問題，那么對于不支持Cookie的瀏覽器怎么辦？可以使用適當?shù)呢撦d均衡算法來解決，比如用對源IPHASH來進行負載均衡，那么可以保持同一IP總是在同一機器上。對于多IP的客戶端怎么辦？那就要求它使用單一IP，或則支持Cookie。

對architecture.txt就看到這兒，因為這主要是為了知道Haproxy的工作原理。

那么為什么architecture.txt只講了HTTP層次的SESSION保持，而不講TCP層次SESSION保持呢？從我的感覺來說，TCP層次沒有所謂SESSION概念。假設某TCP層次程序的某兩筆業(yè)務A和B的關(guān)系是B的處理需要A的處理結(jié)果，那么A的處理結(jié)果一般都會保存于DB中。