haproxy學習筆記

HAProxy: 實現了一種事件驅動,單一進程模型,支持數萬計的併發鏈接,用於爲tcp和http應用程序提供高可用,負載均衡和代理服前端

務的解決方案,尤爲適用於高負載且須要持久鏈接或7層處理機制的web站點nginx


代理(http): 
正向代理:
反向代理:web

代理做用:web緩存(加速)、反向代理、內容路由(根據流量及內容類型等將請求轉發至特定服務器)、轉碼器;redis

在代理服務器上添加Via首部;算法

緩存的做用:
減小冗餘內容傳輸;
節省帶寬、緩解網絡瓶頸;
下降了對原始服務器的請求壓力;
下降了傳輸延遲vim

yum -y install haproxy,安裝haproxy  rpm -ql haproxy,查看安裝了哪些包,找到主配置文件/etc/haproxy/haproxy.cfg後端

全局配置段:瀏覽器

除去全局配置段,其餘的都是代理配置段緩存

chroot 切換根目錄,將haproxy都運行在/var/lib/haproxy 這樣作是爲了增長haproxy的安全安全

pidfile 指定主進程文件  maxconn  默認最大鏈接數   user 以哪一個用戶運行haproxy   group 以哪一個組運行haproxy  daemon 運行

位守護進程 stats socket 圖中有解釋(這樣作是爲了基於共享內存訪問數據,而不須要經過tcp鏈接以提升運行性能)

 

第一項log 指全部日誌都記錄到本機, 經過local2設備輸出,所以還得去/etc/rsyslog.conf中添加和修改必要參數vim

/etc/rsyslog.conf (在全局配置段log 最多能夠指定兩個)

開啓日誌監聽 tcp和udp的端口都開啓   

local2.*  定義haproxy的日誌記錄位置,service rsyslog restart 重啓日誌服務

跳過defaults配置段去配置一臺簡單的負載均衡服務器

frontend 指的是代理的前端,  main是名字  *:80  全部地址都監聽在80端口,default_backend:爲frontend指明使用的默認後

端,使用use_backend:指明使用哪一個後端

bind 能夠用來指定監聽多個端口

backend 指的是代理的後端,  叫作webservers

server 指定後端服務器  web1指定名字後面是該server的ip地址 check  健康檢測單位爲毫秒默認2秒檢測一次,  weight 權重默認

爲1, backup指其餘服務器都不可用時啓用此server

balance: 指明調度算法;
動態:權重可動態調整
靜態:調整權重不會實時生效

roundrobin: 輪詢,動態算法,每一個後端主機最多支持4128個鏈接

static-rr: 輪詢,靜態算法,每一個後端主機支持的數量無上限

leastconn: 根據後端主機的負載數量進行調度;僅適用長鏈接的會話;動態

source :將客戶端源地址hash,並由後端服務器的權重相除後發送至匹配的服務器,這使得同一個ip地址總會被髮送給同一臺服務器,

默認爲靜態

 

uri :將uri hash 此算法經常使用後端是代理緩存或反病毒代理以提升緩存命中率,默認爲靜態

url_param: 根據url中的指定的參數的值進行調度;把值作hash計算,併除以總權重,默認爲靜態

hdr(<name>) :根據請求報文中指定的header(如use_agent, referer, hostname)進行調度;把指定的header的值作hash計

,默認爲靜態

在hash算法中 map-based是取模法,靜態 consistent是一致性哈希法,動態  下面是一個示例:

 

 再說下check,haproxy默認的健康檢測時基於第四層的tcp協議,會根據配置對後端服務器的指定端口進行檢測

另一種檢測是基於http協議的第七層檢測,有三種方法此處只介紹兩種,第一種:

此種方法不推薦使用,在有些狀況下會檢測失誤,好比後端是nginx+fpm時,本人親測

 

第二種:

此種檢測方法(經過去後端服務器獲取頁面資源)能夠準確檢測服務是否可用,推薦使用

健康檢測還可指定失敗次數如: fall 3   指定檢測時間間隔如: inter  1000

 

如何啓用haproxy的狀態監控頁配置以下

listen 它表明既是前端,又是後端,enable激活監控頁面,hide-version隱藏haproxy的版本,auth 用戶密碼認證 if TRUE admin

用戶認證成功了將在監控頁面的底部打開調試功能

 

 

haproxy實現另外一個功能:基於瀏覽器cookie實現session sticky

加入了這幾條指令: cookie serverid insert(在響應報文中插入serverid) cookie websrv1 當響應報文是web1發送回給

haproxy,haproxy從新構建響應首部時在Cookie首部插入serverid=websrv1,當客戶端再次請求時,haproxy就會根據首部中剛插

入的serverid再次將請求調度到同一臺服務器上

 

介紹defaults配置段的參數,defaults中的參數若是frotend和backend段都沒有定義默認就是用defaults段的參數

mode  定義haproxy工做在哪一種模式http | tcp   log  global  表示日誌就使用全句段中定義的記錄日誌方法 

httplog  豐富日誌記錄格式, dontlognull 不記錄健康檢測日誌

 forwardfor if-none execpt x.x.x.x/mask 容許在發日後端服務器的請求首部中添加X-Forwarded-For首部 except排除哪些網

段, if-none 僅在X-Forwarded-For這個首部不存在時才添加,若是不指定if-none那麼回覆蓋原來X-Forwarded-For,代理若是有

多級這個if-none參數就必須了,這樣作只是爲了後端server記錄真實的客戶端ip地址 

redispatch 是否容許將session從新分配到健康的後端服務器上(在與後端服務器session創建失敗時) redispatch表示容許 http-

server-close 通常http-keep-alive啓用時它才起做用,容許haproxy端主動斷開客戶端的鏈接(客戶端創建了server鏈接但沒發起

請求並且持久鏈接超時的狀況下或者客戶端請求的資源達到必定個數)

3 表示3次與後端服務器鏈接失敗就認定服務器不可用  queue 設定請求隊列的超時時長  http-request  等待客戶端http請求超時時長

(若是客戶端發送請求發了一半但客戶端掛了的狀況下) http-keep-alive 指定客戶端與haproxy的持久鏈接超時時長, connect與

後端服務器成功創建tcp鏈接須要等待的超時時長,server等待後端服務器發送響應報文的超時時長,client  haproxy發送了響應報文

等待client肯定的超時時長 maxconn haproxy最多能創建多少個併發鏈接

 

haproxy 還能夠向響應報文首部添加自定義首部

rspadd Via:\ nihao   向對客戶端的響應報文中添加Via首部,\是由於後面跟了一個空格,要對空格轉義

 

haproxy 經過acl功能根據http請求報文中的請求方法實現對後端不一樣服務器組的調度

read 定義acl的名字, method匹配請求報文中首部Request Method的值

 if write 若是匹配write這條acl 就使用tag_engine這個服務器組(if後面若是給了多個名字則要同時知足)

 

haproxy經過acl實現動靜網頁分離

 

這裏的應用服務器我使用了cookie作會話綁定,insert 後面加nocache是官方給出的建議

這樣就實現了動靜分離 很簡單吧

相關文章
相關標籤/搜索