目錄
1、HAProxy簡介
2、HAProxy特性
3、HAProxy適用場景
4、HAProxy的調度算法簡介
1、HAProxy簡介
HAProxy是可提供高可用性、負載均衡以及基於TCP(意味着可以反向代理mysql等應用)和HTTP應用的代理，支持虛擬主機，它是免費、快速並且可靠的一種解決方案。HAProxy特別適用於那些併發大（併發在1w或2w左右）web站點，這些站點通常又需要會話保持或七層處理。HAProxy運行在時下的硬件上，完全可以支持數以萬計的併發連接，並且它的運行模式使得它可以很簡單安全的整合進您當前的架構中， 同時可以保護你的web服務器不被暴露到網絡上。
HAProxy實現了一種基於事件驅動的處理模型，並且是單一進程模型工作，此模型穩健且支持非常大的併發連接數。多進程或多線程模型受內存限制 、系統調度器限制以及無處不在的鎖限制，很少能處理數千併發連接，而事件驅動模型因爲在有更好的資源和時間管理的用戶端(User-Space) 實現所有這些任務，所以沒有這些問題。此模型的弊端是，在多核系統上，這些程序通常擴展性較差。這就是爲什麼他們必須進行優化以 使每個CPU時間片(Cycle)做更多的工作。
2、HAProxy特性
1、作者開發的獨特的彈性二叉樹數據結構，使數據結構的複雜性上升到了0(1)，即數據的查尋速度不會隨着數據條目的增加而速度有所下降；
2、支持客戶端的keepalive功能，減少客戶端與haproxy的多次三次握手導致資源浪費，讓多個請求在一個tcp連接中完成；
3、支持TCP加速，零複製功能，類似於mmap機制；
4、支持響應池（response buffering）
5、支持RDP協議
6、基於源的粘性，類似nginx的ip_hash功能，把來自同一客戶端的請求在一定時間內始終調度到上游的同一服務器；
7、更好統計數據接口，有一個web接口顯示後端集羣中各個服務器的接收、發送、拒絕、錯誤等數據的統計信息；
8、詳細的健康狀態檢測，web接口中有關於對上游服務器的健康檢測狀態，並提供了一定的管理功能；
9、基於流量的健康評估機制；
10、基於http認證；
11、基於命令行的管理接口
12、基於ACL，用於訪問控制等；
11、日誌分析器，可對日誌進行分析。
3、HAProxy的適用場景
從上圖中可知HAProxy適用在各種場景，因爲它支持tcp、http的代理場景，所以可以在web服務器前端做負載均衡，也可以在動態服務器前端做負載，如php、tomcat等，也可以用於mysql這樣的數據做負載均衡集羣，當然只是對讀的請求做負載均衡，而對mysql數據庫的讀寫分離HAProxy並不理解，這需要由前端程序或專業的讀寫分離器來完成，讀寫分離器對讀的請求轉發到HAProxy，再由HAProxy做讀的負載均衡。
4、HAProxy的調度算法簡介
簡單說來HAProxy的調度算法分爲靜態算法、動態算法、混合算法三類（注：這裏的分類是作者自己歸納的，可能不準確），而HAProxy是一種能實現傳輸層、應用層的負載均衡器，所以調度算法也可以針對這兩個層次實現。
那怎樣來區分一個算法是動態還是靜態的？靜態算法與動態算法之間的差別，動態算法是指上游服務器的權重(weight)可以在HAProxy運行時動態調整，不需要重新啓動HAProxy，只需要重新讀入配置文件即可；動態算法還支持上游服務器的慢速啓動功能，是指當上遊服務器因故障或維護需要下線維護處理後，服務器的狀態由down恢復爲up後，HAProxy不會一下將目前採用的算法一下把該恢復後的服務器加入進來，而是讓up起來的服務器慢慢的接入業務，給服務器一個預熱時間。
靜態調度算法：
static-rr
類似於roundrobin，每個服務器根據權重進行輪詢，它是靜態算法，意味着在服務器運行時修改權重是無效的，backed後端服務器數量沒有限制，服務器啓動後便會立即進入到集羣中，整個集羣的負載將被打破並重新進行計算分發，所以不支持慢速啓動。
first
此種算法表示把所有請求都轉發到backend的第一個server上，直到連接數據達到maxconn的數目後才把客戶端的請求轉發到下一個server，不常用此種算法。
動態調度算法：
roundrobin
雖然叫roundrobin，但其實是指帶權重的輪詢，不需要會話保持時可用此算法，這是一種最流暢、最公平的算法，此算法常用。此算法後端服務器的權重可動態調整，即修改服務器的權重後，重新載入haproxy.cfg配置文件就可以生效；後端服務器支持慢速啓動，即當一服務器下線維護或故障又重新上線時，haproxy會慢慢的把請求調度到此服務器上，並不會一下打破之前的調度，這給剛上線的服務器一個預熱的時間。後端backed的服務器數量最多不能超過4095臺，實際生產環境中哪能達到這樣的規模，所以相當於沒有限制backed的服務器數量。
leastconn
帶權重的最少活動連接數算法，是動態算法，表示連接數最少的服務器優先選擇，但這種算法不適用於web服務這樣的短會話的協議，建議用於有長會話的服務，比如：LDAP, SQL, TSE, SSH。
混合算法：
source
以源IP地址作爲標準來挑選後端的服務器，此算法可以爲靜態，也可以爲動態，以hash-type來指定。通常情況下以源IP的這種方式會有兩種挑選後端服務器的方法，一是用取餘的方式，還有一種是一致性hash。
當“hash-type map-based”時表示source是靜態算法，此算法把源IP地址做hash後除後端服務器數量得到的餘數就是所選擇的服務器，如果後端backend的服務器數量有變化那將影響全局的調度，影響範圍大。
當“hash-type consistent”時表示source是動態算法，此算法把後端的服務器平均放在一個hash環上，可能還會虛擬出許多虛擬節點，服務器兩兩之間就有了一個hash的取值範圍，把源ip地址的hash值放在這個hash桶上來往順時針方向轉得到的那個服務器就是所挑選出來的服務器，如果後端backend的服務器數量有變化那只是影響一部份服務器的調度，影響範圍較小。
uri
先來看一下一個URL的格式：<scheme>://<user>:<password>@<host>:<port>/<path>;<params>?<query>#<frag>，URI表示URL中的“/<path>;<params>?<query>#<frag>”這一部份。
此種算法以URI的一部分（即是URL中<port>之後，問號之前的部分，即：/<path>;<params>）或全部URI（當使用"whole"作爲uri的參數時是使用全部的URI）做hash，用服務器的總權重來除以此hash值來分配挑選backend後端的服務器，只要後端服務器羣正常，同一個URI的地址總是被調度到同一臺服務器。此種算法常用在後端是緩存服務器的場景，最大限度的提高緩存命中率，此算法是靜態算法還是動態算法取決於hash-type的值，此算法還擁有"len"和”depth“兩個參數，參數後接一個空格再加上一個正整數，可控制uri算法取URI字段中的字節長度或深度。
url-param：
根據url中的參數（即是URL格式中的“<params>”部分）做調度，此算法是靜態算法還是動態算法取決於hash-type值，此種調度算法用在類似這樣的場景，假如一個站點提供對不同的用戶提供不一要的服務，有VIP用戶和非VIP用戶之分，那麼就可以根據這個<params>來區分用戶身份的不同，以達到調度到不同的服務器組，以提供不同的服務。
hdr(<name>)：
<name>更換成相應的請求首部，如"hdr(Host)"，表示以請求首部的Host首部作爲調度。在每個HTTP請求中查找HTTP首部字段，以首部字段爲調度。與ACL函數'hdr()'一樣。括號括起來的首部名稱不區分大小寫。如果hdr()沒有指定任何首部，則使用roundrobin算法代替。
rdp-cookie
rdp-cookie(<name>)
這種調度算法是根據cookie來做調度，不常用，詳細的我也不瞭解。