web集群時代
隨著業務的不斷增加，我們的單臺服務器承受不住需求，那麽我們就需要對此進行伸縮，有兩種維度，一種是縱向的也就是增大該臺服務器的硬件，再者就是加新服務器與之前的機器組成集群對外提供服務，我們都知道前者是有瓶頸的，so，集群技術是對web架構極其重要的！
集群的定義，我萌百度下就可以了：集群是一組相互獨立的、通過高速網絡互聯的計算機，它們構成了一個組，並以單一系統的模式加以管理。一個客戶與集群相互作用時，集群像是一個獨立的服務器
集群的作用：提高可用性和可縮放性
集群的種類：高可用、負載均衡、高性能
可縮放性我們很容易理解，高可用性其實也不難，因為我提供同一服務的機器多了，那麽其中一臺機器掛了其他機器撐住就可以了。由此可以看出，作為集群的機器的可用性不需要十分的高（是服務器都會有保證的，不會自己沒事就壞），所以我們在硬件采購時就可以節約一些成本，比如購買單電源的插頭，網卡也不需要太多，雙網卡就好等等，能節約成本老板一定會很開心的~
貌似不該有右上角的緩存，好吧，圖是書上的，我也不會ps，先忽略吧，我們可以看出應用服務器變多了，前面還加了一個負載均衡調度器，只畫了一個，其實這是存在單點故障的，它的高可用性也是必需的！so，我們從它入手，常用的高可用集群軟件有heartbeat、keepalived、rhcs，最簡單常用大家都喜歡的是keepalived，它的安裝非常簡單，直接yum就可以，如果對版本有需求用編譯也還是那三步，這個不介紹了，我們來看配置文件，默認是在/etc/keepalived/keepalived.conf，編譯的自然就在你設置的目錄下了，如果你想看參數的意義，請搜索keepalived權威指南，這書很短，10分鐘就夠了，但是是絕對權威的~
1 主機： 2 ! Configuration File for keepalived 3 global_defs { 4 notification_email { 5 [email protected] 6 } 7 notification_email_from [email protected] 8 smtp_server 127.0.0.1 9 smtp_connect_timeout 30 10 router_id haproxy_ha 11 } 12 13 vrrp_instance haproxy_ha {14 state MASTER 15 interface eth0 16 virtual_router_id 36 17 priority 150 18 advert_int 1 19 authentication { 20 auth_type PASS 21 auth_pass 1111 22 } 23 virtual_ipaddress { 24 192.168.56.21 25 } 26 }
1 備機： 2 ! Configuration File for keepalived 3 global_defs { 4 notification_email { 5 [email protected] 6 } 7 notification_email_from [email protected] 8 smtp_server 127.0.0.1 9 smtp_connect_timeout 30 10 router_id haproxy_ha 11 } 12 13 vrrp_instance haproxy_ha { 14 state BACKUP 15 interface eth0 16 virtual_router_id 36 17 priority 100 18 advert_int 1 19 authentication { 20 auth_type PASS 21 auth_pass 1111 22 } 23 virtual_ipaddress { 24 192.168.56.21 25 } 26 }
我們啟動後會發現主機成功備機失敗，wtf，這是什麽情況？那是因為我們需要更改一個內核保護參數，/proc/sys/net/ipv4/ip_nonlocal_bind，顧名思義，是否需要綁定非本地ip，因為我們的虛擬ip不是本地ip嘛，默認是0我們改成1，就可以了，此時主備機之間就建立了不可描述的關系~~~，停掉主機，備機會即可接管虛擬ip，速度極快我們根本感覺不到，如果你一直ping虛擬ip的話你可能會看到會頓上很小的毫秒數，我們的負載均衡器實現了高可用，這個虛擬ip是幹嘛的？其實這個虛擬ip有兩個作用，為負載均衡集群準備，再者它就是你的整個對外的ip了，也就是用戶只需要訪問此ip就可以了，後面的他不需要知道
再說負載均衡集群，註意是集群，實現負載均衡的方式有很多，網卡，dns，鏈路算，但是我們這裏討論服務器集群，組建服務器集群有軟硬件兩種方式，硬件使用F5跟Array，然而都不便宜，尤其是F5，價格真是頂小北方幾年工資了，so，我們還是整軟件吧~軟件也分為兩種
四層負載：轉發，維護一條tcp連接
七層負載：代理，維護兩條獨立的tcp連接
四層負載的lvs是很有名氣的，它有四種模式，十多種算法，幾乎支持任何場景，我們列舉四種模式需要註意的點就好了
1 NAT：他的瓶頸在於後端主機的路由必須為調度器，這樣才能保證回包時再通回調度器，因此進出都需要調度器來進行轉發，網卡流量扛不住。它比dr慢，但是這並不是致命缺點，其實這個所謂的“慢”幾乎可以忽略不計的 2 TUN：幾乎沒人用了，還得打專線... 3 DR：後端服務器都要綁定VIP並拒收VIP的訪問包，需要調度器與真機在一個vlan段內 4 FULL-NAT：你需要會跟ospf結合，並且編譯阿裏的內核
我所知道的10種算法
1.輪叫調度（Round Robin）(簡稱rr) 調度器通過“輪叫”調度算法將外部請求按順序輪流分配到集群中的真實服務器上，它均等地對待每一臺服務器，而不管服務器上實際的連接數和系統負載。 2.加權輪叫（Weighted Round Robin）（簡稱wrr) 調度器通過“加權輪叫”調度算法根據真實服務器的不同處理能力來調度訪問請求。這樣可以保證處理能力強的服務器能處理更多的訪問流量。調度器可以自動問詢真實服務器的負載情況，並動態地調整其權值。 3.最少鏈接（Least Connections）(LC) 調度器通過“最少連接”調度算法動態地將網絡請求調度到已建立的鏈接數最少的服務器上。如果集群系統的真實服務器具有相近的系統性能，采用“最小連接”調度算法可以較好地均衡負載。 4.加權最少鏈接（Weighted Least Connections）(WLC) 在集群系統中的服務器性能差異較大的情況下，調度器采用“加權最少鏈接”調度算法優化負載均衡性能，具有較高權值的服務器將承受較大比例的活動連接負載。調度器可以自動問詢真實服務器的負載情況，並動態地調整其權值。 5.基於局部性的最少鏈接（Locality-Based Least Connections）(LBLC) “基於局部性的最少鏈接”調度算法是針對目標IP地址的負載均衡，目前主要用於Cache集群系統。該算法根據請求的目標IP地址找出該目標IP地址最近 使用的服務器，若該服務器是可用的且沒有超載，將請求發送到該服務器；若服務器不存在，或者該服務器超載且有服務器處於一半的工作負載，則用“最少鏈接” 的原則選出一個可用的服務器，將請求發送到該服務器。 6.帶復制的基於局部性最少鏈接（Locality-Based Least Connections with Replication）(LBLCR) “帶復制的基於局部性最少鏈接”調度算法也是針對目標IP地址的負載均衡，目前主要用於Cache集群系統。它與LBLC算法的不同之處是它要維護從一個 目標 IP地址到一組服務器的映射，而LBLC算法維護從一個目標IP地址到一臺服務器的映射。該算法根據請求的目標IP地址找出該目標IP地址對應的服務器 組，按“最小連接”原則從服務器組中選出一臺服務器，若服務器沒有超載，將請求發送到該服務器；若服務器超載，則按“最小連接”原則從這個集群中選出一臺 服務器，將該服務器加入到服務器組中，將請求發送到該服務器。同時，當該服務器組有一段時間沒有被修改，將最忙的服務器從服務器組中刪除，以降低復制的程 度。 7.目標地址散列（Destination Hashing）(DH) “目標地址散列”調度算法根據請求的目標IP地址，作為散列鍵（Hash Key）從靜態分配的散列表找出對應的服務器，若該服務器是可用的且未超載，將請求發送到該服務器，否則返回空。 8.源地址散列（Source Hashing）(SH) “源地址散列”調度算法根據請求的源IP地址，作為散列鍵（Hash Key）從靜態分配的散列表找出對應的服務器，若該服務器是可用的且未超載，將請求發送到該服務器，否則返回空。 9.最短的期望的延遲（Shortest Expected Delay Scheduling SED）(SED) 基於wlc算法。這個必須舉例來說了 ABC三臺機器分別權重123 ，連接數也分別是123。那麽如果使用WLC算法的話一個新請求進入時它可能會分給ABC中的任意一個。使用sed算法後會進行這樣一個運算 A(1+1)/1 B(1+2)/2 C(1+3)/3 根據運算結果，把連接交給C 10.最少隊列調度（Never Queue Scheduling NQ）(NQ) 無需隊列。如果有臺 realserver的連接數＝0就直接分配過去，不需要在進行sed運算
再來七層負載haproxy，它的配置文件在/etc/haproxy/haproxy.cfg
1 主機備機 2 global 3 maxconn 100000 4 chroot /var/lib/haproxy 5 user haproxy 6 group haproxy 7 daemon 8 nbproc 1 9 pidfile /var/run/haproxy.pid 10 stats socket /var/lib/haproxy.sock mode 600 level admin 11 log 127.0.0.1 local3 info 12 13 defaults 14 option http-keep-alive 15 maxconn 100000 16 mode http 17 timeout connect 5000ms 18 timeout client 50000ms 19 timeout server 50000ms 20 21 listen stats 22 mode http 23 bind 0.0.0.0:8888 24 stats enable 25 stats uri /haproxy-status 26 stats auth haproxy:bfmq 27 28 frontend frontend_www_example_com 29 bind 192.168.56.21:80 30 mode http 31 option httplog 32 log global 33 default_backend backend_www_example_com 34 35 backend backend_www_example_com 36 option forwardfor header X-REAL-IP 37 option httpchk HEAD / HTTP/1.0 38 balance roundrobin 39 server web-node1 192.168.56.11:8080 check inter 2000 rise 30 fall 15 40 server web-node2 192.168.56.12:8080 check inter 2000 rise 30 fall 15
很明顯我們監聽的就是剛才虛擬ip192.168.56.21並將關於它80端口的訪問轉發到了兩臺web機器上，這兩臺機器的ip是真實存在的，並且也是提供了相應的端口服務
haproxy的算法（百度的~）：
① roundrobin，表示簡單的輪詢，這個不多說，這個是負載均衡基本都具備的； ② static-rr，表示根據權重，建議關註； ③ leastconn，表示最少連接者先處理，建議關註； ④ source，表示根據請求源IP，這個跟Nginx的IP_hash機制類似，我們用其作為解決session問題的一種方法，建議關註； ⑤ ri，表示根據請求的URI； ⑥ rl_param，表示根據請求的URl參數’balance url_param’ requires an URL parameter name； ⑦ hdr(name)，表示根據HTTP請求頭來鎖定每一次HTTP請求； ⑧ rdp-cookie(name)，表示根據據cookie(name)來鎖定並哈希每一次TCP請求。
關於haproxy如何動態的啟用禁用配置那就需要我們配置的/var/lib/haproxy.sock了，我們直接對sock進行通信需要用到socat這個包
1 echo "disable server backend_www_example_com / web-node1" | socat /usr/local/haproxy/haproxy.sock stdio 2 echo "enable server backend_www_example_com / web-node1" | socat /usr/local/haproxy/haproxy.sock stdio
當然他還有其它的功能echo "help"| socat stdio /usr/local/haproxy/haproxy.sock可以自行查看，十分實用！
好了，haproxy的基本安裝就這樣，我們該對他進行優化了，在此之前我們還是要先把單機上本身該做的事情都做了哦，這樣其實就已經優化的不錯了。但是我們記得不論如何優化端口範圍是死的。
But，haproxy是專業的反向代理負載均衡調度器，它可以擴展多個IP以充分利用以擴大我們的端口範圍
1 server web-node1 192.168.56.11:8080 check source 192.168.56.100:10000-65000 2 server web-node2 192.168.56.11:8080 check source 192.168.56.101:10000-65000
這樣我們就的端口範圍就直接擴展了一倍，當然，我們可以繼續添加ip擴展
web集群時代