背景：
互聯網的發展和普及，海量數據訪問成爲系統瓶頸，對數據庫也造成了高負載，隨之而來，系統的穩定性和可靠性也有了問題。數據切分和橫向擴展數據層的方案便應運而生。
具體策略：
1. 水平或垂直拆分數據庫 ：減少對單臺數據庫壓力，
2. 減少宕機的損失； 數據庫集羣：解決宕機時數據不能訪問的問題；
3. 負載均衡：減少對單臺及其的訪問壓力，降低宕機發生的機率；
4. 讀寫分離：master負載write，slave負載read，提高系統的訪問效率
數據切分
Why：
當單臺機器物理性能達到上限，爲了滿足業務的需求，需要添置更多的機器，共同負載。以及隨考慮着業務的增長，能否實現機器線性增長滿足業務需要。Sharding可以輕鬆的將計算 存儲 IO流分散到各個機器上，降低單點的壓力，提供系統的可用性
How：
如何做到數據切分：
（1）通過切分規則將數據分散在不同的機器，根據路由找到特定的數據庫，減少單點負載
（2）在數據庫內部通過數據切分規則將數據分散在數據庫的不同表中，比如一張訂單表order，有2000w條數據，並且是有索引的，如果存在一張表中，那麼在對order表進行insert操作，將大大降低表操作效率，但是如果將這2000w條數據分佈在100張表中，那麼每張表大約是20w條數據，進行insert操作的時候效率就會大大提高,分庫降低了單點機器的負載；分表，提高了數據操作的效率
規則：
A. 號段分區
id爲1～1000的對應DB1，1001～2000的對應DB2，以此類推；
優點：可部分遷移
缺點：數據分佈不均
B.hash取模分區
比如應用中需要將一個數據庫切分成4個數據庫的話，我們就用4這個數字對id的hash值進行取模運算，也就是id%4,這樣的話，每次運算就有四種可能：結果爲1的時候對應DB1；結果爲2的時候對應DB2；結果爲3的時候對應DB3；結果爲0的時候對應DB4。這樣一來就非常均勻的將數據分配到4個DB中。
優點：數據分佈均勻
缺點：數據遷移的時候麻煩，不能按照機器性能分攤數據
C.在認證庫中保存數據庫配置
建立一個DB，這個DB單獨保存字段和DB的映射關係，每次訪問數據庫的時候都要先查詢一次這個數據庫，以得到具體的DB信息，然後才能進行我們需要的查詢操作。
優點：靈活配置，關係一對一
缺點：每次都會多一次查詢，性能大大降低
以上就是常用三種方式，有些複雜的項目中可能會混合使用這三種方式。當然還會有更好更完善的分庫方式，有待探究
分佈式數據方案
（1）分庫規則和路由規則（RouteRule簡稱RR）；
（2）集羣，保證數據的高可用性；
（3）引入負載均衡策略（LoadBalancePolicy簡稱LB）；
（4）引入集羣節點可用性探測機制，對單點機器的可用性進行定時的偵測，以保證LB策略的正確實施，以確保系統的高度穩定性；
（5）引入讀/寫分離，提高數據的查詢速度；
分庫分表的數據層設計是不夠完善了的，當採取了數據切分方案，N臺機器組成一個完整的DB，一臺機器掛掉了，也將導致的是N分之一的數據不可訪問，但是假設就因爲一臺機器宕機了，引發的經濟損失也是非常嚴重的，所以現在的方案還是存在問題，容錯性能經不起考驗，於是引入了集羣這一概念：每一個分庫的節點引入多臺機器，每臺機器保存的數據是完全一致的，多臺機器分攤負載，這樣一臺機器出現宕機的時候，其他機器頂上，解決容錯性問題
整個數據層有Group1，Group2，Group3三個集羣組成，這三個集羣就是數據水平切分的結果，三個集羣也就組成了一個包含完整數據的DB。每一個Group包括1個Master和 N個Slave，每個分庫的數據是一致的。 比如Group1中的一個slave發生了宕機現象，那麼還有兩個slave是可以用的，這樣的模型總是不會造成某部分數據不能訪問的問題，除非整個 Group裏的機器全部宕掉，但是考慮到這樣的事情發生的概率非常小（除非是斷電了）。
我們的路由器上規則和策略其實只能路由到具體的Group，也就是隻能路由到一個虛擬的Group，這個Group並不是某個特定的物理服務器。接下來需要做的工作就是找到具體的物理的DB服務器，以進行具體的數據操作。
基於這個環節的需求，我們引入了負載均衡器的概念 （LB），負載均衡器的職責就是定位到一臺具體的DB服務器。具體的規則如下：負載均衡器會分析當前sql的讀寫特性，如果是寫操作或者是要求實時性很強的操作的話，直接將查詢負載分到Master，如果是讀操作則通過負載均衡策略分配一個Slave。
負載均衡的策略
負載分發策略，通常情況下負載均衡包括隨機負載均衡和加權負載均衡。隨機負載均衡就是從N個Slave中隨機選取一個Slave。這樣的隨機負載均衡是不考慮機器性能的，它默認爲每臺機器的性能是一樣的。假如真實的情況是這樣的，這樣做也是無可厚非的。假如實際情況並非如此呢？每個Slave的機器物理性能和配置不一樣的情況，再使用隨機的不考慮性能的負載均衡，是非常不科學的，這樣一來會給機器性能差的機器帶來不必要的高負載，甚至帶來宕機的危險，同時高性能的數據庫服務器也不能充分發揮其物理性能。基於此考慮，我們引入了加權負載均衡，也就是在我們的系統內部通過一定的接口，可以給每臺DB服務器分配一個權值，然後再運行時LB根據權值在集羣中的比重，分配一定比例的負載給該DB服務器。當然這樣的概念的引入，無疑增大了系統的複雜性和可維護性。
可用性探測機制
數據庫的客戶端，定時的對數據庫的各個節點進行檢查，查看是否可用在，實現的原理是嘗試性連接或數據庫端口訪問
數據推送機制
DBA手動的將數據庫的當前狀態通過程序的方式推送到客戶端，也就是分佈式數據層的應用端，然後更新一個本地的DB狀態的列表。並告知LB，這個數據庫節點不能使用，請不要給它分配負載
一個是主動的監聽機制，一個是被動的被告知的機制，都可以達到同樣的效果
master和slave
Master負責寫操作的負載，也就是說一切寫的操作都在Master上進行，而讀的操作則分攤到Slave上進行。這樣一來的可以大大提高讀取的效率。讀/寫的比例大概在 10：1左右
但是爲什麼要分離讀和寫呢？寫操作涉及到鎖的問題，不管是行鎖還是表鎖還是塊鎖，都是比較降低系統執行效率的事情。我們這樣的分離是把寫操作集中在一個節點上，而讀操作其其他 的N個節點上進行，從另一個方面有效的提高了讀的效率，保證了系統的高可用性。