Mysql分片

分片

數據庫分片概述

  1. 什麼是數據切分:
    將數據量大的表或表比較多的數據庫切分成多個部分放到同一數據庫不同表、同一數據庫實例節點不同數據庫或不同數據庫實例節點上

  2. 爲什麼要數據切分
    優點:分散單臺設備的負載,提高數據的安全性,性能
    缺點:增加系統複雜度,跨節點Join,跨節點的count,order by,group by以及聚合函數問題)

分片策略

  1. 分片枚舉
  2. hash
  3. 約定範圍
  4. 取模
  5. 按日期分片

分片需要解決的問題

事務問題

什麼是分佈式事務

分佈式事務就是指事務的參與者、資源服務器以及事務管理器分別位於不同節點之上。簡單的說,就是一次大的操作由不同的小操作組成,這些小的操作分佈在不同的服務節點或資源節點上,分佈式事務需要保證這些小操作要麼全部成功,要麼全部失敗。本質上來說,分佈式事務就是爲了保證不同數據庫的數據一致性。

分佈式事務產生的原因

從上面事務概念來看,分佈式事務產生的原因是因爲跨網絡通信,我們可以看爲兩塊,一個是service產生多個節點,另一個是resource產生多個節點。

service多個節點

隨着互聯網快速發展,微服務,SOA等服務架構模式正在被大規模的使用,舉個簡單的例子,一個公司之內,用戶的資產可能分爲好多個部分,比如餘額,積分,優惠券等等。在公司內部有可能積分功能由一個微服務團隊維護,優惠券又是另外的團隊維護
在這裏插入圖片描述

這樣的話就無法保證積分扣減了之後,優惠券能否扣減成功。

resource多個節點

同樣的,互聯網發展得太快了,我們的Mysql一般來說裝千萬級的數據就得進行分庫分表,對於一個支付寶的轉賬業務來說,你給的朋友轉錢,有可能你的數據庫是在北京,而你的朋友的錢是存在上海,所以我們依然無法保證他們能同時成功。

在這裏插入圖片描述

解決事務問題可行的方案:

分佈式事務和通過應用程序與數據庫共同控制實現事務下面對兩套方案進行一個簡單的對比。

方案一:使用分佈式事務
優點:交由數據庫管理,簡單有效
缺點:性能代價高,特別是shard越來越多時 ,對跨service不適用
方案二:由應用程序和數據庫共同控制
原理:將分佈式事務分拆成多個小事務,每個小事務僅處 於單個數據庫上面的,並通過應用程序來總控 各個小事務。 優點:性能上有優勢
缺點:需要應用程序在事務控制上做靈活設計。如果使用 了spring的事務管理,改動起來會面臨一定的困難。

方案一:

  1. 全局事務(數據庫XA協議)

方案二:

  1. 異步消息最終一致型
  2. TCC(兩階段提交型,補償型)
  3. 最大努力通知型

跨節點Join的問題

只要是進行切分,跨節點Join的問題是不可避免的。但是良好的設計和切分卻可以減少此類情況的發生。解決這一問題的普遍做法是分兩次查詢實現。在第一次查詢的結果集中找出關聯數據的id,根據這些id發起第二次請求得到關聯數據。

跨節點的count,order by,group by以及聚合函數問題

這些是一類問題,因爲它們都需要基於全部數據集合進行計算。多數的代理都不會自動處理合並工作。解決方案:與解決跨節點join問題的類似,分別在各個節點上得到結果後在應用程序端進行合併。和join不同的是每個結點的查詢可以並行執行,因此很多時候它的速度要比單一大表快很多。但如果結果集很大,對應用程序內存的消耗是一個問題。

全局序列號

可靠性是週期內正常運行的概率
可用性是從災難中恢復的時間
提高可靠性需要強調減少系統中斷(故障)的次數,提高可用性需要強調減少從災難中恢復的時間。

示例:
A系統每年因故障中斷十次,每次恢復平均要20分鐘,B系統每年因故障中斷2次,每次需5小時恢復。則A系統可用性比B系統高,但可靠性比B系統差。

發表評論
所有評論
還沒有人評論,想成為第一個評論的人麼? 請在上方評論欄輸入並且點擊發布.
相關文章