從應用層面來實現資料庫負載均衡
問題的由來：
以前維護的系統經常宕機，究其原因是開發管理不善，造成程式質量不佳。撇開制度管理的原因不談（那是技術人員無法解決的），其表象原因有二：一、授權程式設計不佳，造成整個系統執行緩慢；二、有很多程式中有幾個大表的join語句，只要這種程式多跑幾個，管你是什麼ibm小型機通通垮掉。
問題的解決方案：
我曾想把所有系統翻一遍，但由於成本原因不可行。後來上了bigip，算是解決了中介軟體的負載問題，但中介軟體的負載一解決，所有的壓力都集中到資料庫，經常是資料庫的問題造成整個系統垮掉。其表象原因為有很多程式中有幾個大表的join語句，只要這種程式多跑幾個，管你是什麼ibm小型機通通垮掉。直到我離開維護崗，這個問題也沒解決。現如今閒下來，我總在想，能用什麼便宜的方法來實現資料庫負載均衡，使得一些病入膏肓的系統能死得慢一點。
1、多寫少讀。
其實，資料庫之所以壓力大，主要是讀取的原因造成的。因為寫入總是很快的，主要是頻繁的多表聯合查詢造成資料庫資源消耗。那麼除了在資料表中增加冗餘欄位來避免聯合查詢外，有沒有比較好的辦法來解決呢？
假如能有2個或多個資料庫，都有一樣的表，互為映象，那麼應用程式在寫入資料時可以寫入多個資料庫，讀的時候可以按系統別或壓力值來分別讀取不同的資料庫，那麼相當於把查詢的壓力分散開，便於問題的定位和負載均衡，可這帶來乙個問題，那就是如何保證這多個資料庫的表的記錄都是一樣的？
假如我們在應用和資料庫之間再加入一層，把所有的寫入請求都向這一層**，這一層我們姑且稱之為負載控制層，當負載控制層向多個資料庫寫入時，發現其中乙個資料庫有問題，所有操作立即回滾，以保證所有資料庫的資料一致。
並且在這一層有日誌功能，如發生斷電或其它災難性故障，可根據日誌來前滾或後滾，保證所有資料庫資料一致。
讀取資料庫的時候就不通過這一層來**了，直接在應用底層根據對照表或資料庫壓力表來決定讀哪乙個資料庫，這樣可以保證系統架構不會太複雜。
SQL Server資料庫實現負載均衡
微軟官方方案 1 通過分庫分表 分庫磁碟io share disk架構 2 alwayson 第三方軟體服務 1 dbtwin 2 負載均衡產品moebius for sql server 3 資料庫路由器軟體icx 提供ms sql server資料庫伺服器的集群功能，可以實現資料庫伺服器的並行處...
資料庫負載均衡（上）
雖然搭建了集群,但是不使用資料庫負載均衡,單節點處理所有請求，負載高，效能差 使用haproxy做負載均衡，請求被均勻分發給每個節點，單節點負載低，效能好 1.安裝haproxy映象 從docker倉庫拉取haproxy映象 docker pull haproxy2.建立haproxy配置檔案 ha...
資料庫負載均衡（下）
單節點haproxy不具備高可用,必須要有冗餘設計 雙機就是兩個請求處理程式，比如兩個haproxy，當乙個掛掉的時候，另外 乙個可以頂上。linux系統可以在乙個網絡卡中定義多個ip位址，把這些位址分配給多個應用程式，這些位址就是虛擬ip，haproxy的雙機熱備方案最關鍵的技術就是虛擬ip。定義...