分庫分表思維導圖
一、分庫分表的原因
- MySQL單機能力有限
- 百萬級表可以通過主從、讀寫分離、優(yōu)化索引等方式解決性能問題
- 千萬級表時，性能開始下降，成為系統(tǒng)瓶頸
- 需要做數(shù)據(jù)切分（Sharding），使用分布式的思路解決性能問題
二、切分方式
1、垂直切分
(1) 垂直分庫
??根據(jù)業(yè)務內(nèi)容將不同的業(yè)務數(shù)據(jù)分庫保存，彼此之間通過API接口獲取數(shù)據(jù)。
(2) 垂直分表
??即寬表拆分，減少每條數(shù)據(jù)的容量
優(yōu)點
- 業(yè)務解耦
缺點
- 增加開發(fā)復雜度，必須使用接口聚合數(shù)據(jù)
- 要解決分布式事務問題
- 單表數(shù)據(jù)量大的問題仍未解決。必須結合水平拆分
2、水平切分
(1) 單庫分表
??將一張大表，切分成多張表結構相同、只保存一部分數(shù)據(jù)的子表，所有子表存于同一個庫內(nèi)。
??問題點在于所有的子表仍然會競爭同一臺服務器的資源（CPU、內(nèi)存、IO）
(2) 分庫分表
??拆分出的子表散列到不同的數(shù)據(jù)庫中
優(yōu)點
- 業(yè)務系統(tǒng)改造工作量不大
缺點
- 要解決跨分片的事務一致性
- 跨庫做關聯(lián)查詢（join）時性能差
- 維護工作量大
三、主要技術點
1、挑選適合的主流分庫分表中間件
- MyCAT
- atlas
- sharding-jdbc
……
2、水平拆分時數(shù)據(jù)如何散列
(1)根據(jù)主鍵（比如ID）或者增改時間的區(qū)間散列到相應的表
優(yōu)點：
- 擴容方便，不用做數(shù)據(jù)遷移
- 數(shù)據(jù)定位速度快
- 單表數(shù)據(jù)量可控
缺點：
- 由于冷熱數(shù)據(jù)的問題，造成負載不均衡
(2)hash函數(shù)散列。比如hash值取模
優(yōu)點：
- 數(shù)據(jù)分布均衡，系統(tǒng)負載均衡
缺點：
- 系統(tǒng)擴容時需要大量數(shù)據(jù)遷移，維護工作量大
3、解決事務一致性問題
- 有強一致需求時：兩段提交（XA協(xié)議）等。開發(fā)難度大，系統(tǒng)性能差。
- 盡可能爭取只需要保證最終一致性：做事務補償即可
4、全局唯一主鍵問題
??twitter的snowflake算法（雪花算法）及其各種衍生算法
5、分頁、排序
??需要先做各個分片數(shù)據(jù)的聚合，然后再做分頁、排序，開發(fā)工作量大
