1) 分布式DB水平切分中用到的主要關鍵技術：分庫，分表，M-S,集群，負載均衡
2) 需求分析：一個大型互聯網應用每天幾十億的PV對DB造成了相當高的負載，對系統的穩定性的擴展性帶來極大挑戰。
3) 現有解決方式：通過數據切分提高網站性能，橫向擴展數據層
水平切分DB，有效降低了單台機器的負載，也減小了宕機的可能性。
集群方案：解決DB宕機帶來的單點DB不能訪問問題。
讀寫分離策略：極大限度提高了應用中Read數據的速度和並發量。
典型例子：Taobao,Alibaba,Tencent，它們大都實現了自己的分布式數據訪問層（DDAL）。Taobao的基於ibatis和Spring的的分布式數據訪問層，已有多年的應用，運行效率和生產實效性得到了開發人員和用戶的肯定。
水平切分需要考慮的后續問題：分庫后路由規則的選擇和制定，以及后期擴展。如，如何以最少的數據遷移達到最大容量的擴展。因些路由表分規則以及負載均衡的考慮很重要。
4）對於DB切分，實質上就是數據切分。下面從What, Why, How三個方面來講述。
What？什么是數據切分？
。
具體將有什么樣的切分方式呢和路由方式呢？舉個簡單的例子：我們針對一個Blog應用中的日志來說明，比如日志文章（article）表有如下字段：
article_id(int),title(varchar(128)),content(varchar(1024)),user_id(int)
面對這樣的一個表，我們怎樣切分呢？怎樣將這樣的數據分布到不同的數據庫中的表中去呢？其實分析blog的應用，我們不難得出這樣的結論：blog的應用中，用戶分為兩種：瀏覽者和blog的主人。瀏覽者瀏覽某個blog，實際上是在一個特定的用戶的blog下進行瀏覽的，而blog的主人管理自己的blog，也同樣是在特定的用戶blog下進行操作的（在自己的空間下）。所謂的特定的用戶，用數據庫的字段表示就是“user_id”。就是這個“user_id”，它就是我們需要的分庫的依據和規則的基礎。我們可以這樣做，將user_id為1～10000的所有的文章信息放入DB1中的article表中，將user_id為10001～20000的所有文章信息放入DB2中的article表中，以此類推，一直到DBn。這樣一來，文章數據就很自然的被分到了各個數據庫中，達到了數據切分的目的。接下來要解決的問題就是怎樣找到具體的數據庫呢？其實問題也是簡單明顯的，既然分庫的時候我們用到了區分字段user_id，那么很自然，數據庫路由的過程當然還是少不了user_id的。考慮一下我們剛才呈現的blog應用，不管是訪問別人的blog還是管理自己的blog，總之我都要知道這個blog的用戶是誰吧，也就是我們知道了這個blog的user_id，就利用這個user_id，利用分庫時候的規則，反過來定位具體的數據庫，比如user_id是234，利用該才的規則，就應該定位到DB1，假如user_id是12343，利用該才的規則，就應該定位到DB2。以此類推，利用分庫的規則，反向的路由到具體的DB，這個過程我們稱之為“DB路由”。
當然考慮到數據切分的DB設計必然是非常規，不正統的DB設計。那么什么樣的DB設計是正統的DB設計呢？
我們平常規規矩矩用的基本都是。平常我們會自覺的按照范式來設計我們的數據庫，負載高點可能考慮使用相關的Replication機制來提高讀寫的吞吐和性能，這可能已經可以滿足很多需求，但這套機制自身的缺陷還是比較顯而易見的。上面提到的“自覺的按照范式設計”。考慮到數據切分的DB設計，將違背這個通常的規矩和約束，為了切分，我們不得不在數據庫的表中出現冗余字段，用作區分字段或者叫做分庫的標記字段，比如上面的article的例子中的user_id這樣的字段（當然，剛才的例子並沒有很好的體現出user_id的冗余性，因為user_id這個字段即使就是不分庫，也是要出現的，算是我們撿了便宜吧）。當然冗余字段的出現並不只是在分庫的場景下才出現的，在很多大型應用中，冗余也是必須的，這個涉及到高效DB的設計。
Why?為什么要切分數據？
1) 像Oracle這樣成熟穩定的DB可以支撐海量數據的存儲和查詢，但是價格不是所有人都承受得起。
2) 負載高點時，Master-Slaver模式中存在瓶頸。現有技術中，在負載高點時使用相關的Replication機制來實現相關的讀寫的吞吐性能。這種機制存在兩個瓶頸：一是有效性依賴於讀操作的比例，這里Master往往會成為瓶頸所在，寫操作時需要一個順序隊列來執行，過載時Master會承受不住，Slaver的數據同步延遲也會很大，同時還會消耗CPU的計算能力，為write操作在Master上執行以后還是需要在每台slave機器上都跑一次。而Sharding可以輕松的將計算，存儲，I/O並行分發到多台機器上，這樣可以充分利用多台機器各種處理能力，同時可以避免單點失敗，提供系統的可用性，進行很好的錯誤隔離。
3) 用免費的MySQL和廉價的Server甚至是PC做集群，達到小型機+大型商業DB的效果，減少大量的資金投入，降低運營成本，何樂而不為呢？
How？如何切分數據？
先對數據切分的方法和形式進行比較詳細的闡述和說明。
數據切分可以是物理上的，對數據通過一系列的切分規則將數據分布到不同的DB服務器上，通過路由規則路由訪問特定的數據庫，這樣一來每次訪問面對的就不是單台服務器了，而是N台服務器，這樣就可以降低單台機器的負載壓力。
數據切分也可以是數據庫內的，對數據通過一系列的切分規則，將數據分布到一個數據庫的不同表中，比如將article分為article_001,article_002等子表，若干個子表水平拼合有組成了邏輯上一個完整的article表，這樣做的目的其實也是很簡單的。舉個例子說明，比如article表中現在有5000w條數據，此時我們需要在這個表中增加（insert）一條新的數據，insert完畢后，數據庫會針對這張表重新建立索引，5000w行數據建立索引的系統開銷還是不容忽視的。但是反過來，假如我們將這個表分成100個table呢，從article_001一直到article_100，5000w行數據平均下來，每個子表里邊就只有50萬行數據，這時候我們向一張只有50w行數據的table中insert數據后建立索引的時間就會呈數量級的下降，極大了提高了DB的運行時效率，提高了DB的並發量。當然分表的好處還不知這些，還有諸如寫操作的鎖操作等，都會帶來很多顯然的好處。
綜上，分庫降低了單點機器的負載；分表，提高了數據操作的效率，尤其是Write操作的效率。
上文中提到，要想做到數據的水平切分，在每一個表中都要有相冗余字符作為切分依據和標記字段，通常的應用中我們選用user_id作為區分字段，基於此就有如下三種分庫的方式和規則：（當然還可以有其他的方式）
按號段分：
(1) user_id為區分，1～1000的對應DB1，1001～2000的對應DB2，以此類推；
優點：可部分遷移
缺點：數據分布不均
(2) hash取模分：
對user_id進行hash（或者如果user_id是數值型的話直接使用user_id的值也可），然后用一個特定的數字，比如應用中需要將一個數據庫切分成4個數據庫的話，我們就用4這個數字對user_id的hash值進行取模運算，也就是user_id%4,這樣的話每次運算就有四種可能：結果為1的時候對應DB1；結果為2的時候對應DB2；結果為3的時候對應DB3；結果為0的時候對應DB4，這樣一來就非常均勻的將數據分配到4個DB中。
優點：數據分布均勻
缺點：數據遷移的時候麻煩，不能按照機器性能分攤數據
(3) 在認證庫中保存數據庫配置
就是建立一個DB，這個DB單獨保存user_id到DB的映射關系，每次訪問數據庫的時候都要先查詢一次這個數據庫，以得到具體的DB信息，然后才能進行我們需要的查詢操作。
優點：靈活性強，一對一關系
缺點：每次查詢之前都要多一次查詢，性能大打折扣
以上就是通常的開發中我們選擇的三種方式，有些復雜的項目中可能會混合使用這三種
方式。
4) 接下來對分布式數據庫解決海量數據的存訪問題做進一步介紹
分布式數據方案提供功能如下：
（1）提供分庫規則和路由規則（RouteRule簡稱RR），將上面的說明中提到的三中切分規則直接內嵌入本系統，具體的嵌入方式在接下來的內容中進行詳細的說明和論述；
（2）引入集群（Group）的概念，解決容錯性的問題，保證數據的高可用性；
（3）引入負載均衡策略（LoadBalancePolicy簡稱LB）；
（4）引入集群節點可用性探測機制，對單點機器的可用性進行定時的偵測，以保證LB策略的正確實施，以確保系統的高度穩定性；
（5）引入讀/寫分離，提高數據的查詢速度；