roundrobin：動态輪詢；支援權重的運作時調整，支援慢啟動，每個後端中最多支援4095個server；什麼意思呢？動态調整權重就是說不重新開機服務的情況下調整權重；慢啟動說的是，前端的流量不會一下子全部給打進來，而是一部分一部分的打到後端伺服器上；這樣可以有效防止流量過大時一下子把後端伺服器壓垮的情況；後端最多支援4095個server表示在一個backend或listen中使用該算法最多隻能定義4095個server；
前文我們聊了下haproxy的global配置段中的常用參數的說明以及使用，回顧請參考https://www.cnblogs.com/qiuhom-1874/p/12763245.html；今天我們來說說haproxy的代理配置段中比較重要的參數配置的用法；
代理配置段中分三段配置，第一段是defaults配置段，這一段我們在上一篇部落格中也說過，主要用于定義一些預設參數配置；第二段是frontend配置段，該段主要用來定義haporxy面向用戶端怎樣提供服務的；比如監聽在那個位址的那個端口啊，排程那個後端伺服器組呀等等；第三段就是後端伺服器的配置段，通常frontend和backend是聯合使用，也就是說frontend必須調用一個已經定義好的backend這樣才能夠完全的把使用者的請求排程到對應伺服器或者伺服器組上；而對于listen來講，它更像一個代理的角色，它既可以定義前端對于使用者端監聽位址資訊，同時它也能定義後端server的屬性；簡單講listen指令融合了frontend和backend的功能；了解了如何定義前端監聽位址以及後端被代理的server的方式後，接下來我們一一來看下代理配置段中的配置；
defaults裡的配置
mode：該指令用于指定haporxy的工作類型的；http表示haproxy基于http協定代理後端伺服器，這也是預設haproxy的工作類型；如果我們在後端backend或listen中沒有配置haporxy的工作類型，預設就會繼承defaults裡的配置；tcp表示haproxy基于tcp協定代理後端伺服器響應用戶端請求；
option redispatch ：當後端server當機後，強制把請求定向到其他健康的伺服器上；正是因為這個參數，就確定了使用者端請求不會被排程到一個當機的伺服器上；
示例：我們把option redispatch 這個配置注釋掉，重新開機haproxy，然後把後端容器給停掉一台，看看haproxy會不會把對應的請求排程到停掉的server上呢？
提示：我們隻是注釋了option redispatch 這段配置；對于後端伺服器并沒有人為手動的去修改；正常情況下，三台伺服器如果都是正常的情況，是能夠輪詢的方式響應用戶端請求的；現在我們把後端伺服器停一台看看使用者的請求會不會排程到停掉的那台伺服器上呢？
提示：現在我們可以看到web2的狀态是退出狀态，不能夠響應用戶端的請求的；接下來我們用浏覽器通路haproxy對外提服務的IP位址和端口；看看是否把使用者請求排程到當機的主機上
提示：可以看到haproxy還是把使用者端請求往當機的主機上排程；我們把option redispatch 配置打開，然後重新開機haproxy，在看看會不會把使用者請求排程到當機的主機上
提示：我們打開option redispatch 配置，然後重新開機haproxy；對于web2現在還是當機的狀态，我們再用浏覽器通路，看看這次會不會把使用者請求排程到當機的web2上呢
提示：我們把option redispatch 配置加上後，我們用浏覽器通路haproxy的80端口，它不會把使用者端請求排程到web2上去，原因就是因為檢測web2沒有通過，強制把請求排程到下一個伺服器上去了；之是以我們看到中間有一段時間要等，是因為haproxy在對web2進行檢測；
option abortonclose：當伺服器負載很高的時候，自動結束掉目前隊列處理比較久的連結；
option http-keep-alive 60：開啟會話保持，并設定時長為60s
option forwardfor：開啟IP透傳；這個參數的意思是把用戶端的源ip資訊通過X-Forwarded-For首部傳給後端server，後端server可通過撲捉haproxy發來的請求封包，把對應X-Forwarded-For首部的值記錄下來；通常需要後端伺服器更改日志格式，把對應首部的值加入到日志中顯示；
示例：配置後端server記錄haproxy發來的請求封包中X-Forwarded-For首部的值；
提示：我們在web1上修改了httpd的日志格式，讓第一個字段記錄X-Forwarded-For首部的值；然後讓httpd重讀配置檔案；接下來我們就可以用浏覽器通路haproxy，看看web1是否能夠把用戶端的源ip記錄下來
提示：可以看到當haproxy把我們的請求排程到web1上時，對應web1的日志就會把X-Forwarded-For的值記錄下來；這個首部的值就是記錄用戶端的源ip位址的；這樣一來我們後端server上的日志就不再隻有haproxy代理的的位址了；
timeout connect 60s：轉發用戶端請求到後端server的最長連接配接時間；這個時間是定義代理連接配接後端伺服器的逾時時長；
timeout server 600s ：轉發用戶端請求到後端服務端的逾時逾時時長；這個時間是服務端響應代理的逾時時長；
timeout client 600s ：與用戶端的最長空閑時間；
timeout http-keep-alive 120s：session 會話保持逾時時間，範圍内會轉發到相同的後端伺服器；
timeout check 5s：對後端伺服器的檢測逾時時間；
retries 3：定義重試次數；
maxconn 3000：server的最大連接配接數（通常這個會配置在各server後面，用來指定該server的最大連接配接數）
以上就是haproxy defaults配置段的常用配置說明和使用；接下來我們來說一下frontend 配置段和backend配置段
frontend配置段裡的指令配置
bind:該指令用于指定綁定IP和端口的，通常用于frontend配置段中或listen配置段中；用法是bind [IP]:<PORT>,……
示例：
提示：以上配置表示前端監聽80端口和8080端口，這兩個端口都可以把使用者端請求代理到後端指定的伺服器組上進行響應；
測試：重新開機haproxy 用浏覽器通路192.168.0.22：8080端口，看看是否能夠響應？
提示：可以看到我們用浏覽器通路8080也是能夠正常響應的；
除此以外，前端監聽端口我們也可以不用bind參數指定 我們直接在frontend 或listen名字後面加要監聽的位址和端口即可，如下所示
提示：listen的配置也是支援以上兩種的形式去監聽端口的；通常不寫IP位址表示監聽本機是以ip位址對應的端口；
balance：指定後端伺服器組内的伺服器排程算法；這個指令隻能用于listen和backend或者defaults配置段中；
roundrobin：動态輪詢；支援權重的運作時調整，支援慢啟動，每個後端中最多支援4095個server；什麼意思呢？動态調整權重就是說不重新開機服務的情況下調整權重；慢啟動說的是，前端的流量不會一下子全部給打進來，而是一部分一部分的打到後端伺服器上；這樣可以有效防止流量過大時一下子把後端伺服器壓垮的情況；後端最多支援4095個server表示在一個backend或listen中使用該算法最多隻能定義4095個server；通常對于生産環境這個也是夠用了；
static-rr：靜态輪詢，不支援權重的運作時調整，不支援慢啟動；這也是靜态算法的缺點；但這種算法對後端server沒有限制；
leastconn：最少連接配接算法；該算法本質上同static-rr沒有太多的不同，通常情況下static-rr用于短連接配接場景中；而leastconn多用于長連接配接的場景中，如MySQL、LDAP等；
first：根據伺服器在清單中的位置，自上而下進行排程；前面伺服器的連接配接數達到上限，新請求才會配置設定給下一台服務；
source：源位址hash算法；類似LVS中的sh算法；hash類的算法動态與否取決于hash-type的值；如果我們定義hash-type的值為map-based（除權取餘法）就表示該算法是靜态算法，靜态算法就不支援慢啟動，動态調整權重；如果hash-type的值是consistent（一緻性哈希）就表示該算法是動态算法，支援慢啟動，動态權重調整；
uri：對URI的左半部分做hash計算，并由伺服器總權重相除以後派發至某挑出的伺服器；這裡說一下一個完整的rul的格式；<scheme>://[user:password@]<host>:<port>[/path][;params][?query][#frag]其中scheme，host，port這三項是必須有的，其他可有可無；這裡說的uri就是指[/path][;params][?query][#frag]這一部分，而uri的左半部份指的是[/path][;params]；是以uri算法是對使用者請求的資源路徑+參數做hash計算；
url_param：對使用者請求的uri的<params>部分中的參數的值作hash計算，并由伺服器總權重相除以後派發至某挑出的伺服器；通常用于追蹤使用者，以確定來自同一個使用者的請求始終發往同一個Backend Server；
hdr(<name>)：對于每個http請求，此處由<name>指定的http首部将會被取出做hash計算； 并由伺服器總權重相除以後派發至某挑出的伺服器；沒有有效值的會被輪詢排程； 如hdr(Cookie)使用cookie首部做hash，把同一cookie的通路始終排程到某一台後端伺服器上；
示例：使用uri算法，并指定使用一緻性hash算法
提示：這樣配置後，使用者通路80端口的某一個uri始終會發往同一台伺服器上；不管是那個使用者去通路都會被排程到同一台伺服器上進行響應
我們在後端伺服器上提供一些預設的頁面，分别用不同的客戶主機去通路相同的rul看看haproxy會怎麼排程？
提示：在三個容器内部分别建立了一個test.html的檔案，其内容都是不相同的；接下來我們用浏覽器通路/test.html看看會怎麼排程
提示：可以看到我們不管是用windows上的浏覽器通路還是用Linux中的curl通路 都是被排程到web1上去了；其他算法我這裡就不過多去測試了，有興趣的小夥伴可自己動手去試試，看看效果；
default_backend <backend>：設定預設的backend，用于frontend中；
use_backend <backend>：調用對應的backend，用于frontend中；
提示：以上配置表示使用者通路80端口或8081端口，都會被排程到webservs這個後端伺服器組上進行響應；
server <name> <address>[:[port]] [param*]：定義後端主機的各伺服器及其選項；name表示伺服器在haproxy上的内部名稱；出現在日志及警告資訊中；address表示伺服器位址，支援使用主機名；port：端口映射；省略時，表示同bind中綁定的端口；param表示參數；常用的參數有如下幾個：
maxconn <maxconn>：目前server的最大并發連接配接數；
backlog <backlog>：目前server的連接配接數達到上限後的後援隊列長度；
backup：設定目前server為備用伺服器；和nginx裡的sorry server 是一樣的；
cookie <value>：為目前server指定其cookie值，用于實作基于cookie的會話黏性；
disabled：标記為不可用；相當于nginx裡的down;
redir <prefix>：将發往此server的所有GET和HEAD類的請求重定向至指定的URL；
weight <weight>：權重，預設為1;
on-error <mode>：後端服務故障時采取的行動政策；政策有如下幾種：
fastinter：表示縮短健康狀态檢測間的時長；
fail-check：表示即健康狀态檢測失敗，也要檢測；這是預設政策；
sudden-death:模拟一個緻命前的失敗的健康檢查，一個失敗的檢查将标記伺服器關閉，強制fastinter
mark-down：立即标記伺服器不可用，并強制fastinter；
check：對目前server做健康狀态檢測；
addr ：檢測時使用的IP位址；
port ：針對此端口進行檢測；
inter <delay>：連續兩次檢測之間的時間間隔，預設為2000ms;
rise <count>：連續多少次檢測結果為“成功”才标記伺服器為可用；預設為2；
fall <count>：連續多少次檢測結果為“失敗”才标記伺服器為不可用；預設為3；
提示：以上配置表示對web1進行健康狀态檢測 每隔3000毫秒檢測一次，檢測2次失敗就立刻标記為不可用，并強制縮短檢測間隔時長；權重為2，意思是該伺服器被排程兩次，其他伺服器排程一次；最大連接配接為1000；web2配置為backup角色，隻有當web1和web3當機後，web2才被排程；通路web3的請求直接重定向到http://nginx.org上響應；接下來我們如果通路haproxy的80或8081端口，應該是可以通路到web1和web3；如果web1和web3當機後，web2就會被排程；
測試：在web1和web3都正常的情況下，看看web2是否被排程？
提示：可以看到web2是沒有被排程的，web1被排程兩次後，直接跳過web2，排程web3去了；
測試：把web1和web3停了，看看web2是否被排程？
提示：我們把web1和web3給停了，用浏覽器通路，它還是跳轉了；這說明redir不關心所在server是否存活，它都會做跳轉，隻不過所在server存活的情況下，使用者請求偶爾幾次會不跳轉，但一定會有跳轉的情況；這樣來說吧，隻要有跳轉所在server，且沒有做健康狀态檢測，那麼不管該組是否有存活server backup都是不能被激活的；要想backup被激活必須讓haproxy知道對應後端伺服器組裡是否有活躍的伺服器，如果有，它就不會激活backup，如果沒有就會激活；但現在haproxy不知道，原因是web3壓根沒有做健康狀态檢測；是以要想激活backup，我們需要在web3上配置一個check即可；如下
提示：我們在web3上加入健康狀态檢測後服務能夠正常起來；這樣配置後，backup伺服器就會被激活，如下
現在我們把web3啟動起來，看看它是否還會跳轉呢？
提示：可以看到我們把web3啟動起來，對應的跳轉就失效了；從上面的結果我這裡總結了一條，redir和check建議不要一起用，一起用的話，對應redir就會失效；
作者：Linux-1874
出處：https://www.cnblogs.com/qiuhom-1874/
本文版權歸作者和部落格園共有，歡迎轉載，但未經作者同意必須保留此段聲明，且在文章頁面明顯位置給出原文連接配接，否則保留追究法律責任的權利.