讀寫分離
- 在主從同步正常時，解析sql語句，根據行爲轉發到主庫寫或者從庫讀
- 當主庫宕掉後，以Proxy和MYSQL的心跳來判斷，讀寫操作都會發到從庫上
- 從庫宕掉後，以Proxy和MYSQL的心跳來判斷，讀寫操作都會發到主庫上
分片
-
分片原則
- 與拆分表有關係的表一起分表，例如事務，業務關聯
- 依據業務來分片，如果沒有，才用主鍵分片
- 選擇的業務字段，應該是最頻繁的或者最重要的查詢條件
- 選擇的業務字段，應該能儘可能均勻的分佈到所有的節點
-
水平拆分
- 多維拆分
如果我按照oid拆分，但是我現在查詢語句只有uid，那麼就會全表掃描
如果我按照uid拆分，但是我現在查詢語句只有oid，那麼也會全表掃描
那麼我可以進行二維拆分，同時按照oid和uid進行拆分
此時如果我的查詢條件既有oid又有uid，那麼我很容易找到我需要的數據
如果查詢條件只有oid，那麼就會掃描帶有oid的那一個系列
同理，如果查詢條件只有uid，那麼就會掃描帶有uid的那一個系列
拆分問題
- 分多少片合適？
- 路由算法怎麼選擇？
- 數據增長以後如果遷移
- 有沒有熱點問題
路由算法
- 枚舉(能夠窮舉)，春夏秋冬
- 固定hash(通用固定hash算法)，hashcode % 16
- 範圍，[0,100),[100,500),[500,20000),[20000,∞)
- 日期列(數據時間特徵明顯)，銀行賬單
- 一致性hash，實質是一種特殊的範圍hash
一致性hash
- 固定哈希算法足夠簡單實用，根據數據特點能夠均勻分佈，但是在數據庫擴容的時候，固定哈希算法遷移非常複雜，由於取模的結果變化，絕大部分數據都要進行遷移，當數據庫倍增的時候，數據遷移最少，但也高達 50%，而且倍增的成本比較高。
- 一致性hash的原理就是通過該算法計算出 key 的 hashcode 之後進行 2^32 取模，那麼數據就會落在 0~2^32 所組成的環中；然後對現在提供的節點進行範圍分配，假設我有8個節點，將0～2^32的範圍均分到每個節點，然後根據取模之後的值計算落到哪個節點。好處是現在我發現第5號節點壓力過大，我想加一個節點，那麼我只需要將5號節點的範圍縮小一半，然後使用新加入的節點負責另一半，此時只需要遷移5號節點的另一半數據，如果數據分佈均勻，遷移的數據就只有16分之一
- 虛擬節點，有時候會出現熱點問題，一致性哈希並不能解決。所以可以引入虛擬節點的概念，它是物理節點的映射，一個物理節點可以複製出多個虛擬節點，儘可能的讓它均勻分佈在環上，那麼即使數據再集中，其實也會存儲在不同的節點上，可以起到負載均衡的作用。