HAProxy: 實現了一種事件驅動，單一進程模型，支持數萬計的並發連接，用於為tcp和http應用程序提供高可用，負載均衡和代理服
務的解決方案，尤其適用於高負載且需要持久連接或7層處理機制的web站點
代理(http):
正向代理：
反向代理：
代理作用：web緩存（加速）、反向代理、內容路由（根據流量及內容類型等將請求轉發至特定服務器）、轉碼器；
在代理服務器上添加Via首部；
緩存的作用：
減少冗余內容傳輸；
節省帶寬、緩解網絡瓶頸；
降低了對原始服務器的請求壓力；
降低了傳輸延遲
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是官方給出的建議
這樣就實現了動靜分離 很簡單吧