記得在上一篇文章“Java集群--大型網站是怎樣解決多用戶高並發訪問的”的結尾處本人闡述了數據庫的高可用的一種方案----實現主從部署，那么今天，就讓我聊聊本人關於數據庫的一些所思所想吧！
下面是本人對數據庫的高可用性的一些看法：
提出原因：當網站或運用為用戶提供服務時，防止單點故障問題，並且通過一定的分發策略來提升數據庫的安全性和可用性。
問題注重點：架構的可拓展性，而常用的拓展手段有兩種，分別是Scale-up和Scale-out。那么何為Scale-up和Scale-out呢？Scale-up即縱向拓展，通過替換為更好的機器和資源來實現伸縮，提升服務能力；Scale-out即橫向拓展，通過加節點(機器)來實現伸縮，提升服務能力。然而對於互聯網的高並發運用來說，無疑Scale-out才是出路，它的理想狀態是一個服務，當面臨更高的並發的時候，能夠通過簡單增加機器來提升服務支撐的並發度，且增加機器過程中對線上服務無影響。
對於大部分的小型運用，我們經常會把所有的數據存放在一個服務器上的一個數據庫上，以此來滿足小型數據的讀取和寫入功能(架構圖如下)。
對於這種架構，它的瓶頸是：
1.讀寫都在同一個數據庫實體上，使得數據庫的讀寫壓力增大，響應用戶的時間就會相應的加長
2.而且隨着數據量的增大，大到數據庫的實體的容量已經放不下，那么這種架構拓展起來就非常麻煩了。看到這里千萬別說“直接再加一台服務器不就行了嗎？”
3.所有的數據都放在同一個服務器上，如果這台服務器掛掉了，這個系統也癱瘓了，更坑的是，如果這台服務器已經被破壞的體無完膚了(可能是地震)，那么之前的數據也就無法再次獲取了，即系統的容災性差。(PS:也許你很期盼某個網站出現這種情況，這樣女朋友的賬單就不用付了。。。別想太多，一般比較大型的網站，都會把數據備份到不同的服務器的數據庫上，而且相鄰兩台服務器不止相隔甚遠，連在同一個經度和緯度都是盡量避諱的)
通過上面的分析可知，在單庫中，運用的系統性能是比較低的，而且容災性差，所以作為一名比較負責任的代碼寫手，怎么能夠忍受這種響應速度慢且又不可靠的架構出現在自己的項目中呢？看到這里，也許你會想到把我們的數據放到多台的服務器上的數據庫中，這樣容災性就好很多了，而且如果在數據庫的前面再加上一個代理，實現數據庫操作語句的分發策略，這樣子每台服務器的數據庫的操作的壓力也就減少了，也就是程序響應用戶的速度也相應加快了，恩恩，你的想法已經能解決上面的單機版的有些問題了，但你可知道你的這種架構有個很好聽的名字嗎？不繞彎子了，它就是負載均衡技術（這里就以數據庫按垂直切分來討論討論這套架構吧！PS：另外一種數據庫切分方案是水平切分）
如何通過負載均衡技術來實現數據庫的集群呢？先上總體架構圖（這里的數據庫暫時以mysql為例）
實現原理：首先要有一個可以控制連接數據庫的控制端（比如這里的mycat，mycat的前生是阿里巴巴的cobar，所以感覺不會太差），在這里，它截斷了數據庫與程序的直接連接，由所有的程序來訪問這個中間層，然后再由中間層來訪問數據庫。這樣我們就可以根據數據庫的當前負載采取有效的均衡策略，來調整每次連接到哪個數據庫。
如果采用mycat來作為mysql集群的代理，我們可以比較容易的實現上圖的總體架構，在正常的情況下，只有一台“寫”節點（上圖的Master1）負責數據庫的所有寫操作，其他的從（上圖的slave1~5和Master2）或主從數據庫來充當“讀”的角色，一旦Master1掛掉之后，mycat會把它切換到Master2，且把Master1下的所有從節點（slave1~3）也同時從“讀”節點剔除掉（PS：想想這樣有什么好處），這樣負責“讀”的就有Slave4、5，一旦Master1心跳恢復，他就變成了“寫”節點Master2的主從節點了。
當然，mycat是沒有幫我們實現數據庫之間數據的同步的問題的，但我們可以使用mysql自帶的Master-Slave Replication方式來實現每個數據庫的同步，但又很不幸，這種方式並不能完全的保證服務器上的數據都是實時同步的，如果你的程序沒有做一些特殊的處理，那么這種方式只能說是“保證數據最終結果的一致性”。
其實，針對mysql來說，這種架構其實還有一項非常重要的優化措施，不知讀者有沒有發現，我們在上面的第二個架構中使用了數據庫的讀寫分離，我們都知道，mysql的數據庫引擎主要是有兩大類（Innodb和MyIsam），其中，我們知道MyIsam在查詢時的性能會比較高，所以，在本次架構中，我們會把“寫”節點的數據庫引擎改為Innodb，而把“讀”節點改為MyIsam引擎。
一家之言，歡迎各位前輩的拍磚。
最近在看“深入理解Java虛擬機”一書，所以后續會寫一篇文章來簡潔介紹關於Java GC的秘密。
http://www.cnblogs.com/wanggangjia/p/5400353.html