當我們使用讀寫分離、緩存后，數據庫的壓力還是很大的時候，這就需要使用到數據庫拆分了。
數據庫拆分簡單來說，就是指通過某種特定的條件，按照某個維度，將我們存放在同一個數據庫中的數據分散存放
到多個數據庫（主機）上面以達到分散單庫（主機）負載的效果。
切分模式： 垂直（縱向）拆分、水平拆分。
垂直拆分
一個數據庫由很多表的構成，每個表對應着不同的業務，垂直切分是指按照業務將表進行分類，分布到不同的數據
庫上面，這樣也就將數據或者說壓力分擔到不同的庫上面，如下圖：
優點：
1. 拆分后業務清晰，拆分規則明確。
2. 系統之間整合或擴展容易。
3. 數據維護簡單。
缺點：
1. 部分業務表無法join，只能通過接口方式解決，提高了系統復雜度。
2. 受每種業務不同的限制存在單庫性能瓶頸，不易數據擴展跟性能提高。
3. 事務處理復雜。
水平拆分
垂直拆分后遇到單機瓶頸，可以使用水平拆分。相對於垂直拆分的區別是：垂直拆分是把不同的表拆到不同的數據
庫中，而水平拆分是把同一個表拆到不同的數據庫中。
相對於垂直拆分，水平拆分不是將表的數據做分類，而是按照某個字段的某種規則來分散到多個庫之中，每個表中
包含一部分數據。簡單來說，我們可以將數據的水平切分理解為是按照數據行的切分，就是將表中 的某些行切分到
一個數據庫，而另外的某些行又切分到其他的數據庫中，主要有分表，分庫兩種模式，如圖：
優點：
1. 不存在單庫大數據，高並發的性能瓶頸。
2. 對應用透明，應用端改造較少。
3. 按照合理拆分規則拆分，join操作基本避免跨庫。
4. 提高了系統的穩定性跟負載能力。
缺點：
1. 拆分規則難以抽象。
2. 分片事務一致性難以解決。
3. 數據多次擴展難度跟維護量極大。
4. 跨庫join性能較差。
拆分的處理難點
兩張方式共同缺點
1. 引入分布式事務的問題。
2. 跨節點Join 的問題。
3. 跨節點合並排序分頁問題。
針對數據源管理，目前主要有兩種思路：
A. 客戶端模式，在每個應用程序模塊中配置管理自己需要的一個（或者多個）數據源，直接訪問各個 數據庫，在
模塊內完成數據的整合。
優點：相對簡單，無性能損耗。
缺點：不夠通用，數據庫連接的處理復雜，對業務不夠透明，處理復雜。
B. 通過中間代理層來統一管理所有的數據源，后端數據庫集群對前端應用程序透明；
優點：通用，對應用透明，改造少。
缺點：實現難度大，有二次轉發性能損失。
拆分原則
1. 盡量不拆分，架構是進化而來，不是一蹴而就。(SOA)
2. 最大可能的找到最合適的切分維度。
3. 由於數據庫中間件對數據Join 實現的優劣難以把握，而且實現高性能難度極大，業務讀取 盡量少使用多表Join -
盡量通過數據冗余，分組避免數據垮庫多表join。
4. 盡量避免分布式事務。
5. 單表拆分到數據1000萬以內。
切分方
范圍、枚舉、時間、取模、哈希、指定等
案例分析
場景一
建立一個歷史his系統，將公司的一些歷史個人游戲數據保存到這個his系統中，主要是寫入，還有部分查詢，讀寫
比約為1:4；由於是所有數據的歷史存取，所以並發要求比較高；
分析：
歷史數據
寫多都少
越近日期查詢越頻繁？
什么業務數據？用戶游戲數據
有沒有大規模分析查詢？
數據量多大？
加微信獲取更多Java架構資料：jiang10086
微信獲取更多Java架構資料：jiang10086
保留多久？
機器資源有多少？
方案1：按照日期每月一個分片
帶來的問題：1.數據熱點問題（壓力不均勻）
方案2：按照用戶取模， --by Jerome 就這個比較合適了
帶來的問題：后續擴容困難
方案3：按用戶ID范圍分片（1-1000萬=分片1，xxx）
帶來的問題：用戶活躍度無法掌握，可能存在熱點問題
場景二
建立一個商城訂單系統，保存用戶訂單信息。
分析：
電商系統
一號店或京東類？淘寶或天貓？
實時性要求高
存在瞬時壓力
基本不存在大規模分析
數據規模？
機器資源有多少？
維度？商品？用戶？商戶？
方案1：按照用戶取模，
帶來的問題：后續擴容困難
方案2：按用戶ID范圍分片（1-1000萬=分片1，xxx）
帶來的問題：用戶活躍度無法掌握，可能存在熱點問題
方案3：按省份地區或者商戶取模
數據分配不一定均勻
場景3
上海公積金，養老金，社保系統
分析：
社保系統
實時性要求不高
不存在瞬時壓力
大規模分析？
加微信獲取更多Java架構資料：jiang10086
微信獲取更多Java架構資料：jiang10086
數據規模大
數據重要不可丟失
偏於查詢？
方案1：按照用戶取模，
帶來的問題：后續擴容困難
方案2：按用戶ID范圍分片（1-1000萬=分片1，xxx）
帶來的問題：用戶活躍度無法掌握，可能存在熱點問題
方案3：按省份區縣地區枚舉
數據分配不一定均勻