因爲用戶的增多，數據的增多，單機的數據庫往往支撐不住快速發展的業務，所以數據庫集羣就產生了！今天來說說讀寫分離的數據庫集羣方式！
讀寫分離顧名思義就是讀和寫分離了，對應到數據庫集羣一般都是一主一從(一個主庫，一個從庫)或者一主多從(一個主庫，多個從庫)，業務服務器把需要寫的操作都寫到主數據庫中，讀的操作都去從庫查詢。主庫會同步數據到從庫保證數據的一致性。
這種集羣方式的本質就是把訪問的壓力從主庫轉移到從庫，也就是在單機數據庫無法支撐併發讀寫的時候，並且讀的請求很多的情況下適合這種讀寫分離的數據庫集羣。如果寫的操作很多的話不適合這種集羣方式，因爲你的數據庫壓力還是在寫操作上，即使主從了之後壓力還是在主庫上和單機區別就不大了。
在單機的情況下，一般我們做數據庫優化都會加索引，但是加了索引對查詢有優化，但是會影響寫入，因爲寫入數據會更新索引。所以做了主從之後，我們可以單獨的針對從庫(讀庫)做索引上的優化，而主庫(寫庫)可以減少索引而提高寫的效率。
看起來還是很簡單的，但是有兩點要注意：主從同步延遲、分配機制的考慮；
主從同步延遲
主庫有數據寫入之後，同時也寫入在binlog(二進制日誌文件)中，從庫是通過binlog文件來同步數據的，這期間會有一定時間的延遲，可能是1秒，如果同時有大量數據寫入的話，時間可能更長。
這會導致什麼問題呢？比如有一個付款操作，你付款了，主庫是已經寫入數據，但是查詢是到從庫查，從庫裏還沒有你的付款記錄，所以頁面上查詢的時候你還沒付款。那可不急眼了啊，吞錢了這還了得！打電話給客服投訴！
所以爲了解決主從同步延遲的問題有以下幾個方法：
1、二次讀取
二次讀取的意思就是讀從庫沒讀到之後再去主庫讀一下，只要通過對數據庫訪問的API進行封裝就能實現這個功能。很簡單，並且和業務之間沒有耦合。但是有個問題，如果有很多二次讀取相當於壓力還是回到了主庫身上，等於讀寫分離白分了。而且如有人惡意攻擊，就一直訪問沒有的數據，那主庫就可能爆了。
2、寫之後的馬上的讀操作訪問主庫
也就是寫操作之後，立馬的讀操作指定訪問主庫，之後的讀操作採取訪問從庫。這就等於寫死了，和業務強耦合了。
3、關鍵業務讀寫都由主庫承擔，非關鍵業務讀寫分離
類似付錢的這種業務，讀寫都到主庫，避免延遲的問題，但是例如改個頭像啊，個人簽名這種比較不重要的就讀寫分離，查詢都去從庫查，畢竟延遲一下影響也不大，不會立馬打客服電話哈哈。
分配機制的考慮
分配機制的考慮也就是怎麼制定寫操作是去主庫寫，讀操作是去從庫讀。
一般有兩種方式：代碼封裝、數據庫中間件。
1、代碼封裝
代碼封裝的實現很簡單，就是抽出一箇中間層，讓這個中間層來實現讀寫分離和數據庫連接。講白點就是搞個provider封裝了save,select等通常數據庫操作，內部save操作的dataSource是主庫的，select操作的dataSource是從庫的。
優點：就是實現簡單，並且可以根據業務定製化變化，隨心所欲。
缺點：就是是如果哪個數據庫宕機了，發生主從切換了之後，就得修改配置重啓。並且如果你的系統很大，一個業務可能包含多個子系統，一個子系統是java寫的一個子系統用go寫的，這樣的話得分別爲不同語言實現一套中間層，重複開發。
2、數據庫中間件
就是有一個獨立的系統，專門來實現讀寫分離和數據庫連接管理，業務服務器和數據庫中間件之間是通過標準的SQL協議交流的，所以在業務服務器看來數據庫中間件其實就是個數據庫。
優點：因爲是通過sql協議的所以可以兼容不同的語言不需要單獨寫一套，並且有中間件來實現主從切換，業務服務器不需要關心這點。
缺點：多了一個系統其實就等於多了一個關心。。如果數據庫中間件掛了的話對吧，而且多了一個系統就等於多了一個瓶頸，所以對中間件的性能要求也高，並且所有的數據庫操作都要經過它。並且中間件實現很複雜，難度比代碼封裝高多了。
但是有開源的數據庫中間件例如Mysql Proxy,Mysql Route,Atlas。
總結
讀寫分離相對而言是比較簡單的，比分表分庫簡單，但是它只能分擔訪問的壓力，分擔不了存儲的壓力，也就是你的數據庫表的數據逐漸增多，但是面對一張表海量的數據，查詢還是很慢的，所以如果業務發展的快數據暴增，到一定時間還是得分庫分表。
但是正常情況下，只要當單機真的頂不住壓力了纔會集羣，不要一上來就集羣，沒這個必要。有關於軟件的東西都是越簡單越好，複雜都是形勢所迫。
一般我們是先優化，優化一些慢查詢，優化業務邏輯的調用或者加入緩存等，如果真的優化到沒東西優化了然後才上集羣，先讀寫分離，讀寫分離之後頂不住就再分庫分表。
覺得不錯請點贊支持，歡迎留言或進我的個人羣855801563領取【架構資料專題目合集90期】、【BATJTMD大廠JAVA面試真題1000+】，本羣專用於學習交流技術、分享面試機會，拒絕廣告，我也會在羣內不定期答題、探討。