實驗示例：

2.1.2 first

1.根據服務器在列表中的位置，自上而下進行調度

2.其只會當第一臺服務器的連接數達到上限，新請求才會分配給下一臺服務

3.其會忽略服務器的權重設置

4.不支持用socat進行動態修改權重,可以設置0和1,可以設置其它值但無效

實驗示例：

?
#測試

2.2 動態算法

動態算法

基于后端服務器狀態進行調度適當調整，

新請求將優先調度至當前負載較低的服務器

權重可以在haproxy運行時動態調整無需重啟

2.2.1 roundrobin

1. 基于權重的輪詢動態調度算法，

2. 支持權重的運行時調整，不同于lvs中的rr輪訓模式，

3. HAProxy中的roundrobin支持慢啟動(新加的服務器會逐漸增加轉發數)，

4. 其每個后端backend中最多支持4095個real server，

5. 支持對real server權重動態調整，

6. roundrobin為默認調度算法,此算法使用廣泛

實驗示例

2.2.2 leastconn

leastconn加權的最少連接的動態

支持權重的運行時調整和慢啟動，即:根據當前連接最少的后端服務器而非權重進行優先調度(新客戶端連接)

比較適合長連接的場景使用，比如：MySQL等場景。

?

#測試

2.3 其他算法

其它算法即可作為靜態算法，又可以通過選項成為動態算法

2.3.1 source

????????源地址hash，基于用戶源地址hash并將請求轉發到后端服務器，后續同一個源地址請求將被轉發至同一個后端web服務器。此方式當后端服務器數據量發生變化時，會導致很多用戶的請求轉發至新的后端服務器，默認為靜態方式，但是可以通過hash-type支持的選項更改這個算法一般是在不插入Cookie的TCP模式下使用，也可給拒絕會話cookie的客戶提供最好的會話粘性，適用于session會話保持但不支持cookie和緩存的場景源地址有兩種轉發客戶端請求到后端服務器的服務器選取計算方式，分別是取模法 和一致性hash

2.3.1.1?map-base 取模法(靜態)

map-based：取模法，對source地址進行hash計算，再基于服務器總權重的取模，最終結果決定將此請求轉發至對應的后端服務器。

2.3.6?各算法使用場景

first ????????????????????????????????????#使用較少

static-rr? ? ? ? ? ? ? ? ? ????????????#做了session共享的web集群

roundrobin

random

leastconn? ? ? ? ? ? ? ? ? ? ? ? ?#數據庫

source? ? ? ? ? ? ? ? ? ???????????#基于客戶端公網IP的會話保持

Uri--------------->http???????? #緩存服務器，CDN服務商，藍汛、百度、阿里云、騰訊

url_param--------->http? ? #可以實現session保持

hdr? ? ? ? ? ? ? ? ? ? ? ? ·? ? ? ? ??#基于客戶端請求報文頭部做下一步處理

三.高級功能及配置

3.1 基于cookie的會話保持

cookie value：為當前server指定cookie值，實現基于cookie的會話黏性，相對于基于 source 地址hash調度算法對客戶端的粒度更精準，但同時也加大了haproxy負載，目前此模式使用較少， 已經被session共享服務器代替

注意：不支持 tcp mode，使用 http mode

3.1.1 配置選項

cookie name [ rewrite | insert | prefix ][ indirect ] [ nocache ][ postonly ] [ preserve ][ httponly ] [ secure ][ domain ]* [ maxidle <idle> ][ maxlife ]

name： #cookie 的 key名稱，用于實現持久連接

insert： #插入新的cookie,默認不插入cookie

indirect： #如果客戶端已經有cookie,則不會再發送cookie信息

nocache： #當client和hapoxy之間有緩存服務器（如：CDN）時，不允許中間緩存器緩存

cookie，因為這會導致很多經過同一個CDN的請求都發送到同一臺后端服務器

3.1.2?配置示例

3.1.3 驗證cookie信息

#也可以這樣

#curl訪問時指定cookie

#也可以這樣

3.2 HAProxy狀態頁

通過web界面，顯示當前HAProxy的運行狀態

3.2.1 狀態頁配置項

3.2.2 啟用狀態頁

#進入配置文件編輯

#測試

#瀏覽器

#自動刷新狀態頁

#測試

3.3 IP透傳

web服務器中需要記錄客戶端的真實IP地址，用于做訪問統計、安全防護、行為分析、區域排行等場景。

3.3.2四層IP透傳

實驗示例：

#在RS1和RS2上

?

?

#測試

#現在haproxy主機上訪問一下

#然后再RS2或者RS2上查看日志

3.3.3 七層IP透傳

實驗示例：

#haproxy主機上

#RS1和RS2主機上配置相同指令（在訪問日志中通過變量$proxy_protocol_addr 記錄透傳過來的客戶端IP）

?

3.4 ACL

訪問控制列表ACL，Access Control Lists）

是一種基于包過濾的訪問控制技術

它可以根據設定的條件對經過服務器傳輸的數據包進行過濾(條件匹配)即對接收到的報文進行匹配和過濾，基于請求報文頭部中的源地址、源端口、目標地址、目標端口、請求方法、URL、文件后綴等信息內容進行匹配并執行進一步操作，比如允許其通過或丟棄。

實驗前期準備

RS1和RS2主機（配置一樣）

client主機配置

#測試是否能連接上

注意事項

實驗示例：

#測試

實驗示例：

haproxy主機上

RS1主機上

創建文件

#測試

3.4.1 ACL配置選項

3.4.1.1 ACL-Name 名稱

#ACL名稱，可以使用大字母A-Z、小寫字母a-z、數字0-9、冒號：、點.、中橫線和下劃線，并且嚴格區分大小寫，比如:my_acl和My_Acl就是兩個完全不同的acl5.8.1.2 ACL-criterion

3.4.1.2?ACL-flags 匹配模式

-i? ? ?不區分大小寫

-m? ?使用指定的正則表達式匹配方法

-n? ??不做DNS解析

-u? ??禁止acl重名，否則多個同名ACL匹配或關系

實驗示例：

haproxy主機

RS2和RS1主機上

#測試

3.4.2?ACL示例-基于源IP或子網調度訪問

3.4.2.1指定IP訪問

實驗示例

#測試（haproxy）

#測試（client）

3.4.2.2 拒絕指定ip

實驗示例

3.4.3?ACL示例-基于文件后綴名實現動靜分離

實驗前期準備（RS1和RS2安裝PHP）：

RS2主機上配置

#測試（RS2可以登錄此界面）

RS1主機上配置（（不能登錄）

實驗示例：

#測試

3.4.4?ACL-匹配訪問路徑實現動靜分離

實驗前期準備（RS1和RS2）：

RS2

RS1

haproxy主機上

#測試

實驗示例

#測試

3.5 自定義HAProxy 錯誤界面

對指定的報錯進行重定向，進行優雅的顯示錯誤頁面

使用errorfile和errorloc指令的兩種方法，可以實現自定義各種錯誤頁面

實驗示例：

#haproxy默認使用的錯誤錯誤頁面

3.5.1 基于自定義的錯誤頁面文件

#進入該界面文件編寫

#再進入此界面編寫

#測試

關閉RS1和RS2上的后端

進入瀏覽器測試

3.6 HAProxy 四層負載

針對除HTTP以外的TCP協議應用服務訪問的應用場景

應用場景有：MySQL，?Redis，?Memcache ，RabbitMQ

實驗示例（MySQL為例）：

（RS1和RS2上）

#下載

#進入此文件（RS2為例）

RS1

#測試（RS2上測試），在RS1上測試結果差不多

注意：此時是不能遠程連接的，那么解決這個問題的話就要以下這些步驟

#實驗示例（在RS2上）：

#測試（在RS1上遠程連接）

#對 MySQL 服務實現四層負載

#測試

3.7 HAProxy https 實現

haproxy可以實現https的證書安全,從用戶到haproxy為https,從haproxy到后端服務器用http通信

但基于性能考慮,生產中證書都是在后端服務器比如nginx上實現

3.7.1 證書制作

實驗示例

#設置密鑰

#查看密鑰

。

#在xurui.pem里面添加密鑰

#進入此文件編寫

#測試（在client上測試）

#測試（也可以在網頁上）