所有的系統，都是先經歷乙個單台機器搞所有業務的時代，乙個程式+乙個mysql資料庫，就可以滿足開發及第乙個版本上線的要求。隨著，資料的增加以及業務的增長，這些應用就面臨乙個訪問量的擴大以及擴充套件的問題。最簡單的擴充套件就是水平擴充套件，原來由乙個mysql增加為2個或多個，形成乙個集群，這樣最簡單的能力就是提供更強的服務能力。如原來的訪問量支援每秒1000，現在可以支援2000(理想值)，相當於將服務能力分散到多個節點。這裡面涉及到多個問題，首先就是資料的相互備份，然後就是如何分配計算能力，外部如何來訪問等。本文引入haproxy和keepalived主要處理的就是乙個外部訪問問題。
在後面的介紹當中，假定有2個mysql，分別為mysqla和mysqlb.
1、haproxy請求分發
可以理解為通過nginx來作後端的負載均衡，haproxy可以通過監聽乙個統一的埠對外提供能力，然後內部進行分發。除支援http7層處理外，還順便為mysql支援4層**。(更高階的可以考慮採用lvs) 在這裡，將兩個mysql分別配置在backend當中，並且通過option mysql-check進行相應服務的檢查。
程式進行訪問時，就不再訪問具體的mysql機器，而是訪問這個haproxy所在的機器。這裡就提到需要乙個額外的機器來提供服務，但是由於只為haproxy使用，其根據很低，乙個最低配機器即可，費用不大。同時，相應的埠也填寫haproxy所暴露的埠即可。對外即認為也只仍然只有乙個mysql，即對外是透明的。
haproxy在進行處理時，將自己根據相應的策略進行**，最簡單的策略就是輪詢(ribbon),當然其它加權或者是隨機等，需要具體進行配置。同時，根據設定的具體時間間隔，對後端服務進行有效性檢測，當mysqla或b不能工作時，將自動從可用列表中移除。
在加上haproxy之後，負載的問題被解決，但另乙個問題又來了，即服務單點的問題。如果一旦這個haproxy機器掛掉(或網路原因)。雖然,mysql伺服器沒掛，但整個服務也是不可用了。前端程式不會自動退回到去訪問原始的mysql(甚至由於防火牆的問題，它也不能訪問)。這時候就要用到另乙個東西，保證haproxy不會成為單點，即keepalived。
2、keepalived高可用
保證服務不會單點的作法就是加機器，但加機器就會出現多個ip，如何保證前端程式使用單個ip又能保證後端的實際處理機器為多台，這就是keepalived的作用。
我們為了保證haproxy的高可用，已經又加了乙個機器，即為haproxya和haproxyb（相當於原來的2個mysql機器，又加了2臺haproxy機器)。
通過keepalived，我們可以創造出第3個ip，由ip3來對外提供服務，但是與haproxy的**性質不同，這裡的ip3實際上就是haproxya和haproxyb的乙個同名對映。可以理解為haproxya和haproxyb都在爭搶這個ip，哪個爭搶到了，就由哪個來提供服務。可以理解為在一定的時間內，保證以下關係
ip3<=>ip1ip2 wait ip3
因為keepalived不提供任何處理能力，實際上最終的處理落在能夠處理資訊的程式上。因此，我們需要將keepalived和haproxy部署在一起，即keepalived負責搶ip，接收前端的請求，在接收到了請求之後，由系統自動將請求分發到同乙個機器上的haproxy上進行處理。即乙個機器有2個ip，ip1負責接收請求,ip2負責實際的資訊處理(比喻而已，就是如何監聽請求和埠處理程式)
在前面的處理模型當中，因為keepalived不處理請求，因此如果它所在機器上的haproxy如果不可用，實際上這個模型也是有問題的。因此keepalived又要來監聽自己機器上的haproxy是否有效。在配置中，通過track_script指令可以達到這個效果，與haproxy的工作模式差不多，它可以定時執行監控指令碼來檢視haproxy是否可用。如果不可用，有2種處理辦法，一種就是強行再啟動haproxy，另一種就是取消自己的搶占ip位(如將自己給kill掉)，將相應的ip3的位置給讓出來。這樣ip2就能自動與ip3進行繫結(比喻)，即由ip2來提供處理能力了。
在keepalived的配置之上，在單個時刻只有1臺機器在進行工作，另乙個機器在進行準備，可以理解為這裡的服務能力只有1半。好在keepalived和haproxy所占用資源都較小，費用不高。
最終部署模型
a、mysqla(ip5)和mysqlb(ip6)水平擴充套件，通過雙主進行資料通訊，並且同時提供服務能力
b、通過haproxya(ip3)和haproxyb(ip4)提供mysql的負載能力，將請求路由到指定的mysql伺服器，同時監控後端的mysql資料庫可用性
c、將keepaliveda和keepalivedb分別和haproxya和haproxyb部署在一起，同時繫結vip ip1，對外提供訪問ip，同時監控本機的haproxy的可用性
所有的系統，都是先經歷乙個單台機器搞所有業務的時代，乙個程式+乙個mysql資料庫，就可以滿足開發及第乙個版本上線的要求。隨著，資料的增加以及業務的增長，這些應用就面臨乙個訪問量的擴大以及擴充套件的問題。最簡單的擴充套件就是水平擴充套件，原來由乙個mysql增加為2個或多個，形成乙個集群，這樣最簡單的能力就是提供更強的服務能力。如原來的訪問量支援每秒1000，現在可以支援2000(理想值)，相當於將服務能力分散到多個節點。這裡面涉及到多個問題，首先就是資料的相互備份，然後就是如何分配計算能力，外部如何來訪問等。本文引入haproxy和keepalived主要處理的就是乙個外部訪問問題。
在後面的介紹當中，假定有2個mysql，分別為mysqla和mysqlb.
1、haproxy請求分發
可以理解為通過nginx來作後端的負載均衡，haproxy可以通過監聽乙個統一的埠對外提供能力，然後內部進行分發。除支援http7層處理外，還順便為mysql支援4層**。(更高階的可以考慮採用lvs) 在這裡，將兩個mysql分別配置在backend當中，並且通過option mysql-check進行相應服務的檢查。
程式進行訪問時，就不再訪問具體的mysql機器，而是訪問這個haproxy所在的機器。這裡就提到需要乙個額外的機器來提供服務，但是由於只為haproxy使用，其根據很低，乙個最低配機器即可，費用不大。同時，相應的埠也填寫haproxy所暴露的埠即可。對外即認為也只仍然只有乙個mysql，即對外是透明的。
haproxy在進行處理時，將自己根據相應的策略進行**，最簡單的策略就是輪詢(ribbon),當然其它加權或者是隨機等，需要具體進行配置。同時，根據設定的具體時間間隔，對後端服務進行有效性檢測，當mysqla或b不能工作時，將自動從可用列表中移除。
在加上haproxy之後，負載的問題被解決，但另乙個問題又來了，即服務單點的問題。如果一旦這個haproxy機器掛掉(或網路原因)。雖然,mysql伺服器沒掛，但整個服務也是不可用了。前端程式不會自動退回到去訪問原始的mysql(甚至由於防火牆的問題，它也不能訪問)。這時候就要用到另乙個東西，保證haproxy不會成為單點，即keepalived。
2、keepalived高可用
保證服務不會單點的作法就是加機器，但加機器就會出現多個ip，如何保證前端程式使用單個ip又能保證後端的實際處理機器為多台，這就是keepalived的作用。
我們為了保證haproxy的高可用，已經又加了乙個機器，即為haproxya和haproxyb（相當於原來的2個mysql機器，又加了2臺haproxy機器)。
通過keepalived，我們可以創造出第3個ip，由ip3來對外提供服務，但是與haproxy的**性質不同，這裡的ip3實際上就是haproxya和haproxyb的乙個同名對映。可以理解為haproxya和haproxyb都在爭搶這個ip，哪個爭搶到了，就由哪個來提供服務。可以理解為在一定的時間內，保證以下關係
ip3<=>ip1ip2 wait ip3
因為keepalived不提供任何處理能力，實際上最終的處理落在能夠處理資訊的程式上。因此，我們需要將keepalived和haproxy部署在一起，即keepalived負責搶ip，接收前端的請求，在接收到了請求之後，由系統自動將請求分發到同乙個機器上的haproxy上進行處理。即乙個機器有2個ip，ip1負責接收請求,ip2負責實際的資訊處理(比喻而已，就是如何監聽請求和埠處理程式)
在前面的處理模型當中，因為keepalived不處理請求，因此如果它所在機器上的haproxy如果不可用，實際上這個模型也是有問題的。因此keepalived又要來監聽自己機器上的haproxy是否有效。在配置中，通過track_script指令可以達到這個效果，與haproxy的工作模式差不多，它可以定時執行監控指令碼來檢視haproxy是否可用。如果不可用，有2種處理辦法，一種就是強行再啟動haproxy，另一種就是取消自己的搶占ip位(如將自己給kill掉)，將相應的ip3的位置給讓出來。這樣ip2就能自動與ip3進行繫結(比喻)，即由ip2來提供處理能力了。
在keepalived的配置之上，在單個時刻只有1臺機器在進行工作，另乙個機器在進行準備，可以理解為這裡的服務能力只有1半。好在keepalived和haproxy所占用資源都較小，費用不高。
最終部署模型
a、mysqla(ip5)和mysqlb(ip6)水平擴充套件，通過雙主進行資料通訊，並且同時提供服務能力
b、通過haproxya(ip3)和haproxyb(ip4)提供mysql的負載能力，將請求路由到指定的mysql伺服器，同時監控後端的mysql資料庫可用性
c、將keepaliveda和keepalivedb分別和haproxya和haproxyb部署在一起，同時繫結vip ip1，對外提供訪問ip，同時監控本機的haproxy的可用性
mysql執行原理 mysql 執行原理
闡述mysql系統的各個模組是如何相親相愛的完成乙個我們認為的很簡單的查詢工作的。我們對啟動mysql，客戶端建立連線，請求query，得到返回結果，最終退出。這樣一整個過程來進行分析。第一步 當我們執行啟動mysql系統的命令之後，mysql的初始化模組就從系統配置檔案中讀取系統引數和命令列引數，...
小程式執行執行過程原理 程式執行原理
計算機中包含有較多的硬體，但是乙個程式要執行，有三個核心的硬體，分別是 cpu 記憶體 硬碟 計算機中哪乙個硬體裝置負責執行程式？記憶體的速度快還是硬碟的速度快？我們的程式是安裝在記憶體中的，還是安裝在硬碟中的？我買了乙個記憶體條，有 500g 的空間！這句話對嗎？計算機關機之後，記憶體中的資料都會...
Struts執行原理
對於struts的執行原理，首先來看如下執行原理圖 1 瀏覽器發出http請求給伺服器，然後伺服器解析主機 解析web應用 解析資源 2 伺服器 請求給actionservlet 總控制器 該類由struts提供 只需配置就可以這時候需要配置在struts config.xml的檔案，actions...