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是官方給出的建議
這樣就實現了動靜分離 很簡單吧