從單塊架構到分布式架構之資料庫集群（三）

資料庫集群主要有主備、主從、分庫、分表等方案。

主要用來做儲存高可用，當主庫掛了之後可以利用備庫來代替主庫，備庫不提供任何的訪問能力。

問題所在：主備資料同步是有延時的，資料量非常大的情況下可能會達到一分鐘以上。如果這個時候主庫所在伺服器宕機，可能會造成備庫資料不一致的情況。當主庫恢復正常執行之後，是把主庫設定成新的備庫來使用，還是仍然當成主庫來使用呢。

讀寫分離，主庫負責寫入資料，從庫負責讀取。可以是一主一從，也可以是一主多從。主要用來分散高併發時的訪問壓力，並且主庫掛掉之後，不會影響讀取相關業務。

問題所在：由於主庫只有乙個，所以不用擔心資料丟失的問題。但是跟主備一樣，資料同步是需要時間的，當使用者在主庫新增一條資料之後，立馬做了查詢操作，這個時候資料可能還沒有同步到從庫中，導致了資料不一致。比如使用者註冊系統之後，登陸的時候卻提示賬號不存在。

2、從庫未查找到的情況下再次查詢主庫；當大量訪問不存在的資源會造成主庫壓力山大。

3、重要業務讀寫都在主庫，非重要業務採用讀寫分離。

也可以針對不同的業務資料採取不同的方式處理。

將資料庫按一定的方式拆分成多個資料庫。這些資料庫可以分開部署在不同的伺服器或者例項上面。

雖然讀寫分離可以分散訪問壓力，但是所有的資料都要存放在每乙個節點上，不能解決儲存壓力。

問題所在：1、連線查詢；如果乙個查詢所需資料分散在不同的庫中，需要多次查詢組裝起來後才能得到結果；

2、分布式事務；單庫的情況下可以使用資料庫自帶的acid保證資料的完整。分庫後，表分散到不同的資料庫中，無法通過事務統一修改。可以了解一下cap、base、兩階段提交、三階段提交、事務補償機制、重試機制、人工干預等解決方式；

3、開發成本增加；伺服器數量也要相應的增加；

拆分方式有垂直拆分和水平拆分

4.1 垂直拆分

將乙個表的拆分成多個表。以主外來鍵的方式關聯。資料庫在查詢的時候會將整行資料都載入至記憶體中，拆分成多個表可以減少io和記憶體的使用。例如：將商品基本資訊和商品詳情拆分開。如果拆分後的兩個表在大部分的業務。

4.2 水平拆分

水平分表適合錶行數特別高的表，一般資料量超過5000萬行必須分表；將表的資料拆分到多個表中，

4.2.1 範圍拆分

例如：使用者id範圍在1-999999的資料放在table1中，使用者id範圍在1000000-1999999的資料放在table2中。

好處是擴充套件方便，使用者量增加只需要多加幾個表就可以了。

壞處是資料分布不均勻，可能幾個表的資料量差異比較大，老使用者可能沒有新使用者這麼活躍。

4.2.2 hash路由拆分

選取某個列的值進行雜湊運算，然後根據雜湊結果將資料分散到不同的表中。雜湊路由的複雜點在於表數量的選擇上面。表太多了維護麻煩，表太少了效能可能會受影響；

優缺點和範圍拆分相反，資料量分布比較均勻，但是擴充套件麻煩。增加新的表之後需要將資料重新遷移分布。

4.2.3 配置路由

增加一張路由表，用來記錄路由資訊。將使用者id與tableid做個對映；

配置路由設計簡單，使用起來方便；在擴充表的時候只需要遷移指定的資料，然後修改路由表就可以了。

配置路由的缺點就是查詢必須多查詢一次，會影響整體效能，當路由表資料量變得特別大之後也會成為效能瓶頸。

水平分表問題所在：1、join查詢更複雜，需要在**中進行多次查詢

2、count統計操作需要統計多個表之後加起來。

3、order by 操作沒法在資料庫中進行，需要載入至業務**或者資料庫中介軟體中彙總排序。