haproxy作為mysql中間層是很成熟的方案，特別是解決從庫的負載均衡和故障切換，在生產環境中有著廣泛的應用。
在實際使用過程中，有兩個問題比較容易發生：
1. tcp埠耗盡
2. 網絡卡頻寬跑滿
本文重點講講如何優化問題1，問題2暫不討論。
優化一： 使用盡可能多的埠
linux系統預設提供了65k個埠，每當haproxy建立了乙個到mysql的連線，就會消耗乙個埠；當haproxy斷開和mysql的連線時，該埠並不會立即釋放，而是會處於time_wait狀態(2*msl)，超時後才會釋放此埠供新的連線使用。
我的環境中，tcp_fin_timeout為15秒，也就是說如果我環境中的haproxy可以承載的最大併發連線數為64k/(15*2)=2.1k，可實際上達不到這個上限，原因如下：
$ sysctl net . ipv4 . ip_local_port_range
net . ipv4 . ip_local_port_range = 15000 65000
linux會保留一段埠，實際能參與分配的埠數只有50k，為了獲得盡可能多的可分配埠，做如下調整：
# sysctl net.ipv4.ip_local_port_range="1025 65000"
記得修改/etc/sysctl.conf中對應的內容
優化二： 復用處於time_wait的埠
調整兩個引數：
net . ipv4 . tcp_tw_reuse = 1
net . ipv4 . tcp_tw_recycle = 1
第乙個引數很安全，可以不用過多關注。需要注意的是第二個引數，某些情況下會導致資料報被丟棄。
例如：client通過nat連線haproxy，並且haproxy端開啟了tcp_tw_recycle,同時saw_tstamp也沒有關閉，當第乙個連線建立並關閉後，此埠(控制代碼)處於time_wait狀態，在2*msl時間內又乙個client(相同ip，如果開啟了xfrm還要相同port)發乙個syn包，此時linux核心就會認為這個資料報異常，從而丟掉這個包,並傳送rst包.
不過通常情況下，client都是通過內網直接連線haproxy，所以可以認為tcp_tw_recycle是安全的，只是需要記住此坑。
優化三： 縮短time_wait時間
linux系統預設msl為60秒，也就是正常情況下，120秒後處於time_wait的埠(控制代碼)才會釋放，可以將msl的時間縮小，縮短埠的釋放週期。
# cat /proc/sys/net/ipv4/tcp_fin_timeout
# echo 15 > /proc/sys/net/ipv4/tcp_fin_timeout
這是乙個折中的數值，太小也會導致其它問題
優化四： 使用多ip
如優化一中所說，我們已經盡可能多的使用了系統提供的埠範圍。但最多依然不超過65k。
haproxy提供了內建的埠管理方法，可以充分利用以擴大我們的埠範圍。
server mysql0 10.0.3.1 : 3306 check source 10.0.3.100 : 1025 - 65000
server mysql1 10.0.3.1 : 3306 check source 10.0.3.101 : 1025 - 65000
如果使用兩個ip，我們可用的埠數就接近130k。擴充套件多個ip，就可以不斷增加埠數。
優化五： 使用長連線 服務最好使用長連線，一是避免頻繁的申請連線，導致埠耗盡；二是避免建立連線帶來的時間消耗。
MYSQL 均衡負載
利用mysql的主從複製可以有效的分流更新操作和查詢操作，具體的實現是乙個主伺服器，承擔更新操作，多台從伺服器，承擔查詢操作，主從之間通過複製實現資料的同步。多台從伺服器一方面用來確保可用性，一方面可以建立不同的索引滿足不同查詢的需要。對於主從之間不需要複製全部表的情況，可以通過在主的伺服器上搭建乙...
mysql負載均衡
一 docker安裝haproxy docker pull haproxy global 工作目錄 chroot usr local etc haproxy 日誌檔案，使用rsyslog服務中local5日誌裝置 var log local5 等級info log 127.0.0.1 local5 ...
mysql負載均衡筆記
mysql 雙機集群 rhel 4上做mysql負載均衡 sysbench壓力測試工具 centos 5.2安裝負載均衡 需要的rpm包 mysql cluster gpl client 6.3.20 0.rhel5.i386.rpm mysql的客戶端 mysql cluster gpl serv...