2021-01-29 分類(lèi): 網(wǎng)站建設(shè)
隨著互聯(lián)網(wǎng)產(chǎn)業(yè)的蓬勃發(fā)展,在互聯(lián)網(wǎng)應(yīng)用上產(chǎn)生的數(shù)據(jù)也是與日俱增。產(chǎn)生大量的交易記錄和行為記錄,它們的存放和分析是我們需要面對(duì)的問(wèn)題。
用 ID 取模的分表方式分配記錄
ID 分別為 01-04 的四條記錄,如果分配到 3 個(gè)表中,那么對(duì) 3 取模得到的余數(shù)分別是:
當(dāng)然這里只是一個(gè)例子,實(shí)際情況需要對(duì) ID 做 Hash 之后再計(jì)算。同時(shí)還可以針對(duì)不同表所在的不同的數(shù)據(jù)庫(kù)的資源來(lái)設(shè)置存儲(chǔ)數(shù)據(jù)的多少。針對(duì)每個(gè)表所在的庫(kù)的資源設(shè)置權(quán)值。
用這種方式存放數(shù)據(jù)以后,在訪問(wèn)具體數(shù)據(jù)的時(shí)候需要通過(guò)一個(gè) Mapping Table 獲取對(duì)應(yīng)要響應(yīng)的數(shù)據(jù)來(lái)自哪個(gè)數(shù)據(jù)表。目前比較流行的數(shù)據(jù)庫(kù)中間件已經(jīng)幫助我們實(shí)現(xiàn)了這部分的功能。
也就是說(shuō)不用大家自己去建立這個(gè) Mapping Table,在做查詢(xún)的時(shí)候中間件幫助你實(shí)現(xiàn)了 Mapping Table 的功能。所以,我們這里只需要了解其實(shí)現(xiàn)原理就可以了。
按照時(shí)間做的數(shù)據(jù)分表
需要注意的是由于分表造成一系列記錄級(jí)別的問(wèn)題,例如 Join 和 ID 生成,事務(wù)處理,同時(shí)存在這些表需要跨數(shù)據(jù)庫(kù)的可能性:
Snowflake 示意圖
排序/分頁(yè):數(shù)據(jù)分配到水平的幾個(gè)表中的時(shí)候,做排序和分頁(yè)或者一些集合操作是不容易的。
這里根據(jù)經(jīng)驗(yàn)介紹兩種方法。對(duì)分表的數(shù)據(jù)先進(jìn)行排序/分頁(yè)/聚合,再進(jìn)行合并。對(duì)分表的數(shù)據(jù)先進(jìn)行合并再做排序/分頁(yè)/聚合。
事務(wù):存在分布式事務(wù)的可能,需要考慮補(bǔ)償事務(wù)或者用 TCC(Try Confirm Cancel)協(xié)助完成,這部分的內(nèi)容我們下面會(huì)為大家介紹。
數(shù)據(jù)分庫(kù)
說(shuō)完了分表,再來(lái)談?wù)劮謳?kù)。每個(gè)物理數(shù)據(jù)庫(kù)支持?jǐn)?shù)據(jù)都是有限的,每一次的數(shù)據(jù)庫(kù)請(qǐng)求都會(huì)產(chǎn)生一次數(shù)據(jù)庫(kù)鏈接,當(dāng)一個(gè)庫(kù)無(wú)法支持更多訪問(wèn)的時(shí)候,我們會(huì)把原來(lái)的單個(gè)數(shù)據(jù)庫(kù)分成多個(gè),幫助分擔(dān)壓力。
這里有幾類(lèi)分庫(kù)的原則,可以根據(jù)具體場(chǎng)景進(jìn)行選擇:
單個(gè)表會(huì)分到不同的數(shù)據(jù)庫(kù)中
通常數(shù)據(jù)分庫(kù)之后,每一個(gè)數(shù)據(jù)庫(kù)包含多個(gè)數(shù)據(jù)表,多個(gè)數(shù)據(jù)庫(kù)會(huì)組成一個(gè) Cluster/Group,提高了數(shù)據(jù)庫(kù)的可用性,并且可以把讀寫(xiě)做分離。
Master 庫(kù)主要負(fù)責(zé)寫(xiě)操作,Slave 庫(kù)主要負(fù)責(zé)讀操作。在應(yīng)用訪問(wèn)數(shù)據(jù)庫(kù)的時(shí)候會(huì)通過(guò)一個(gè)負(fù)載均衡代理,通過(guò)判斷讀寫(xiě)操作把請(qǐng)求路由到對(duì)應(yīng)的數(shù)據(jù)庫(kù)。
如果是讀操作,也會(huì)根據(jù)數(shù)據(jù)庫(kù)設(shè)置的權(quán)重或者平均分配請(qǐng)求。另外,還有數(shù)據(jù)庫(kù)健康監(jiān)控機(jī)制,定時(shí)發(fā)送心跳檢測(cè)數(shù)據(jù)庫(kù)的健康狀況。
如果 Slave 出現(xiàn)問(wèn)題,會(huì)啟動(dòng)熔斷機(jī)制停止對(duì)其的訪問(wèn);如果 Master 出現(xiàn)問(wèn)題,通過(guò)選舉機(jī)制選擇新的 Master 代替。
兩個(gè)集群中的兩個(gè)主從,分別擴(kuò)展成四個(gè)集群中的四個(gè)
從兩個(gè)集群擴(kuò)展成四個(gè)集群
雙寫(xiě)數(shù)據(jù)庫(kù)擴(kuò)容
在沒(méi)有數(shù)據(jù)庫(kù)主從配置的情況下的擴(kuò)容,假設(shè)有數(shù)據(jù)庫(kù) M1 M2 如下圖:
擴(kuò)展前的兩個(gè)主庫(kù)
需要對(duì)目前的兩個(gè)數(shù)據(jù)庫(kù)做擴(kuò)容,擴(kuò)容之后是 4 個(gè)庫(kù)如下圖。新增的庫(kù)是 M3,M4 路由的方式分別是 ID%2=0 和 ID%2=1。
新增兩個(gè)主庫(kù)
這個(gè)時(shí)候新的數(shù)據(jù)會(huì)同時(shí)進(jìn)入 M1 M2 M3 M4 四個(gè)庫(kù)中,而老數(shù)據(jù)的使用依舊從 M1 M2 中獲取。
與此同時(shí),后臺(tái)服務(wù)對(duì) M1 M3,M2 M4 做數(shù)據(jù)同步,建議先做全量同步再做數(shù)據(jù)校驗(yàn)。
老庫(kù)給新庫(kù)做數(shù)據(jù)同步
當(dāng)完成數(shù)據(jù)同步之后,四個(gè)庫(kù)的數(shù)據(jù)保持一致了,修改負(fù)載均衡代理的配置為 ID%4 的模式。此時(shí)擴(kuò)容就完成了,從原來(lái)的 2 個(gè)數(shù)據(jù)庫(kù)擴(kuò)展成 4 個(gè)數(shù)據(jù)庫(kù)。
當(dāng)然會(huì)存在部分的數(shù)據(jù)冗余,需要像上面一個(gè)方案一樣通過(guò)后臺(tái)服務(wù)刪除這些冗余數(shù)據(jù),刪除的過(guò)程不會(huì)影響業(yè)務(wù)。
數(shù)據(jù)同步以后做 Hash 切分
分布式事務(wù)原理
架構(gòu)設(shè)計(jì)的分表分庫(kù)帶來(lái)的結(jié)果是我們不得不考慮分布式事務(wù),今天創(chuàng)新互聯(lián)來(lái)看看分布式事務(wù)需要記住哪兩個(gè)原理。
CAP
互聯(lián)網(wǎng)應(yīng)用大多會(huì)使用分表分庫(kù)的操作,這個(gè)時(shí)候業(yè)務(wù)代碼很可能會(huì)同時(shí)訪問(wèn)兩個(gè)不同的數(shù)據(jù)庫(kù),做不同的操作。同時(shí)這兩個(gè)操作有可能放在同一個(gè)事務(wù)中處理。
這里引出分布式系統(tǒng)的 CAP 理論,他包括以下三個(gè)屬性:
一致性(Consistency):分布式系統(tǒng)中的所有數(shù)據(jù),同一時(shí)刻有同樣的值。
業(yè)務(wù)代碼往數(shù)據(jù)庫(kù) 01 這個(gè)節(jié)點(diǎn)寫(xiě)入記錄 A,數(shù)據(jù)庫(kù) 01 把 A 記錄同步到數(shù)據(jù)庫(kù) 02,業(yè)務(wù)代碼再?gòu)臄?shù)據(jù)庫(kù) 02 中讀出的記錄也是 A。那么兩個(gè)數(shù)據(jù)庫(kù)存放的數(shù)據(jù)就是一致的。
一致性簡(jiǎn)圖
可用性(Availability):分布式系統(tǒng)中一部分節(jié)點(diǎn)出現(xiàn)故障,分布式系統(tǒng)仍舊可以響應(yīng)用戶(hù)的請(qǐng)求。
假設(shè)數(shù)據(jù)庫(kù) 01 和 02 同時(shí)存放記錄 A,由于數(shù)據(jù)庫(kù) 01 掛掉了,業(yè)務(wù)代碼不能從中獲取數(shù)據(jù)。
那么業(yè)務(wù)代碼可以從數(shù)據(jù)庫(kù) 02 中獲取記錄 A。也就是在節(jié)點(diǎn)出現(xiàn)問(wèn)題的時(shí)候,還保證數(shù)據(jù)的可用性。
可用性簡(jiǎn)圖
分區(qū)容錯(cuò)性(Partition tolerance):假設(shè)兩個(gè)數(shù)據(jù)庫(kù)節(jié)點(diǎn)分別在兩個(gè)區(qū),而兩個(gè)區(qū)的通訊發(fā)生了問(wèn)題。就不能達(dá)成數(shù)據(jù)一致,這就是分區(qū)的情況,我就需要從 C 和 A 之間做出選擇。
是選擇可用性(A),獲取其中一個(gè)區(qū)的數(shù)據(jù)。還是選擇一致性(C),等待兩個(gè)區(qū)的數(shù)據(jù)同步了再去獲取數(shù)據(jù)。
這種情況的前提是兩個(gè)節(jié)點(diǎn)的通訊失敗了,寫(xiě)入數(shù)據(jù)庫(kù) 01 記錄的時(shí)候,需要鎖住數(shù)據(jù)庫(kù) 02 記錄不讓其他的業(yè)務(wù)代碼修改,直到數(shù)據(jù)庫(kù) 01 記錄完成修改。因此 C 和 A 在此刻是矛盾的。兩者不能兼得。
BASE
Base 原理廣泛應(yīng)用在數(shù)據(jù)量大,高并發(fā)的互聯(lián)網(wǎng)場(chǎng)景。一起來(lái)看看都包含哪些:
基本可用(Basically Available): 不會(huì)因?yàn)槟硞€(gè)節(jié)點(diǎn)出現(xiàn)問(wèn)題就影響用戶(hù)的請(qǐng)求。
即使在流量激增的情況下,也會(huì)考慮通過(guò)限流降級(jí)的辦法保證用戶(hù)的請(qǐng)求是可用的。
比如,電商系統(tǒng)在流量激增的時(shí)候,資源會(huì)向核心業(yè)務(wù)傾斜,其他的業(yè)務(wù)降級(jí)處理。
軟狀態(tài)( Soft State):一條數(shù)據(jù)如果存在多個(gè)副本,允許副本之間同步的延遲,在較短時(shí)間內(nèi)能夠容忍不一致。這個(gè)正在同步并且還沒(méi)有完成同步的狀態(tài)稱(chēng)為軟狀態(tài)。
最終一致性( Eventual Consistency):最終一致性是相對(duì)于強(qiáng)一致性來(lái)說(shuō)的,強(qiáng)一致性是要保證所有的數(shù)據(jù)都是一致的,是實(shí)時(shí)同步。
而最終一致性會(huì)容忍一小段時(shí)間數(shù)據(jù)的不一致,但過(guò)了這段時(shí)間以后數(shù)據(jù)會(huì)保證一致。其包含以下幾種“一致性”:
①因果一致性(Causal Consistency)
如果有兩個(gè)進(jìn)程 1 和 2 都對(duì)變量 X 進(jìn)行操作,“進(jìn)程 1” 寫(xiě)入變量 X,“進(jìn)程 2”需要讀取變量 X,然后用這個(gè) X 來(lái)計(jì)算 X+2。
這里“進(jìn)程 1”和“進(jìn)程 2” 的操作就存在因果關(guān)系。“進(jìn)程 2” 的計(jì)算依賴(lài)于進(jìn)程 1 寫(xiě)入的 X,如果沒(méi)有 X 的值,“進(jìn)程 2”無(wú)法計(jì)算。
②讀己之所寫(xiě)(Read Your Writes)
“進(jìn)程 1”寫(xiě)入變量 X 之后,該進(jìn)程可以獲取自己寫(xiě)入的這個(gè)值。
進(jìn)程寫(xiě)入的值的同時(shí)獲取值
③會(huì)話一致性(Session Consistency)
如果一個(gè)會(huì)話中實(shí)現(xiàn)來(lái)讀己之所寫(xiě)。一旦數(shù)據(jù)更新,客戶(hù)端只要在同一個(gè)會(huì)話中就可以看到這個(gè)更新的值。
④單調(diào)寫(xiě)一致性(Monotonic Write Consistency)
“進(jìn)程 1”如果有三個(gè)操作分別是 1,2,3。“進(jìn)程 2”有兩個(gè)操作分別是 1,2。當(dāng)進(jìn)程請(qǐng)求系統(tǒng)時(shí),系統(tǒng)會(huì)保證按照進(jìn)程中操作的先后順序來(lái)執(zhí)行。
分布式事務(wù)方案
說(shuō)完了分布式的原理,再來(lái)提一下分布式的方案。由于所處場(chǎng)景不一樣,所以方案也各有不同,這里介紹兩種比較流行的方案,兩段式和 TCC(Try,Confirm,Cancel)。
兩階段提交
顧名思義,事務(wù)會(huì)進(jìn)行兩次提交。這里需要介紹兩個(gè)概念,一個(gè)是事務(wù)協(xié)調(diào)者,也叫事物管理器。
它是用來(lái)協(xié)調(diào)事務(wù)的,所有事務(wù)什么時(shí)候準(zhǔn)備好了,什么時(shí)候可以提交了,都由它來(lái)協(xié)調(diào)和管理。
另一個(gè)是參與者,也叫資源管理器。它主要是負(fù)責(zé)處理具體事務(wù)的,管理者需要處理的資源。例如:訂票業(yè)務(wù),扣款業(yè)務(wù)。
第一階段(準(zhǔn)備階段):事務(wù)協(xié)調(diào)者(事務(wù)管理器)給每個(gè)參與者(資源管理器)發(fā)送 Prepare 消息,發(fā)這個(gè)消息的目的是問(wèn)“大家是不是都準(zhǔn)備好了,我們馬上就要執(zhí)行事務(wù)了”。
參與者會(huì)根據(jù)自身業(yè)務(wù)和資源情況進(jìn)行檢查,然后給出反饋。這個(gè)檢查過(guò)程根據(jù)業(yè)務(wù)內(nèi)容不同而不同。
例如:訂票業(yè)務(wù),就要檢查是否有剩余票??劭顦I(yè)務(wù)就要檢查,余額是否足夠。一旦檢查通過(guò)了才能返回就緒(Ready)信息。
否則,事務(wù)將終止,并且等待下次詢(xún)問(wèn)。由于這些檢查需要做一些操作,這些操作可能再之后回滾時(shí)用到,所以需要寫(xiě) redo 和 undo 日志,當(dāng)事務(wù)失敗重試,或者事務(wù)失敗回滾的時(shí)候使用。
第二階段(提交階段):如果協(xié)調(diào)者收到了參與者失敗或者超時(shí)的消息,會(huì)給參與者發(fā)送回滾(rollback)消息;否則,發(fā)送提交(commit)消息。兩種情況處理如下:
情況 1,當(dāng)所有參與者均反饋 yes,提交事務(wù):
情況 2,當(dāng)有一個(gè)參與者反饋 no,回滾事務(wù):
TCC(Try,Confirm,Cancel)
對(duì)于一些要求高一致性的分布式事務(wù),例如:支付系統(tǒng),交易系統(tǒng),我們會(huì)采用 TCC。
它包括,Try 嘗試,Confirm 確認(rèn),Cancel 取消??聪旅嬉粋€(gè)例子能否幫助大家理解。
假設(shè)我們有一個(gè)轉(zhuǎn)賬服務(wù),需要把“A 銀行”“A 賬戶(hù)”中的錢(qián)分別轉(zhuǎn)到“B銀行”“B 賬戶(hù)”和“C 銀行”“C 賬戶(hù)”中去。
假設(shè)這三個(gè)銀行都有各自的轉(zhuǎn)賬服務(wù),那么這次轉(zhuǎn)賬事務(wù)就形成了一次分布式事務(wù)。
我們來(lái)看看用 TCC 的方式如何解決:
首先是 Try 階段,主要檢測(cè)資源是否可用,例如檢查賬戶(hù)余額是否足夠,緩存,數(shù)據(jù)庫(kù),隊(duì)列是否可用等等。
并不執(zhí)行具體的邏輯。如上圖,這里從“A 賬戶(hù)”轉(zhuǎn)出之前要檢查,賬戶(hù)的總金額是否大于 100,并且記錄轉(zhuǎn)出金額和剩余金額。
對(duì)于“B 賬戶(hù)”和“C 賬戶(hù)”來(lái)說(shuō)需要知道賬戶(hù)原有總金額和轉(zhuǎn)入的金額,從而可以計(jì)算轉(zhuǎn)入后的金額。
這里的交易數(shù)據(jù)庫(kù)設(shè)計(jì)除了有金額字段,還要有轉(zhuǎn)出金額或者轉(zhuǎn)入金額的字段,在 Cancel 回滾的時(shí)候使用。
如果 Try 階段成功,那么就進(jìn)入 Confirm 階段,也就是執(zhí)行具體的業(yè)務(wù)邏輯。
這里從“A 賬戶(hù)”轉(zhuǎn)出 100 元成功,剩余總金額=220-100=120,把這個(gè)剩余金額寫(xiě)入到總金額中保存,并且把交易的狀態(tài)設(shè)置為“轉(zhuǎn)賬成功”。
“B 賬戶(hù)”和“C 賬戶(hù)”分別設(shè)置總金額為 80=50+30 和 130=60+70,也把交易狀態(tài)設(shè)置為“轉(zhuǎn)賬成功”。則整個(gè)事務(wù)完成。
如果 Try 階段沒(méi)有成功,那么服務(wù) A B C 都要做回滾的操作。對(duì)于“A賬戶(hù)”來(lái)說(shuō)需要把扣除的 100 元加回,所以總金額 220=120+100。
那么“B 服務(wù)”和“C 服務(wù)”需要把入賬的金額從總金額里面減去,也就是 50=80-30 和 60=130-70。
TCC 接口實(shí)現(xiàn)
這里需要注意的是,需要針對(duì)每個(gè)服務(wù)去實(shí)現(xiàn) Try,Confirm,Cancel 三個(gè)階段的代碼。
例如上面所說(shuō)的檢查資源,執(zhí)行業(yè)務(wù),回滾業(yè)務(wù)等操作。目前有很多開(kāi)源的架構(gòu)例如:ByteTCC、TCC-transaction 可以借鑒。
TCC 可靠性
TCC 通過(guò)記錄事務(wù)處理日志來(lái)保證可靠性。一旦 Try,Confirm,Cancel 操作的時(shí)候服務(wù)掛掉或者出現(xiàn)異常,TCC 會(huì)提供重試機(jī)制。另外如果服務(wù)存在異步的情況可以采用消息隊(duì)列的方式通信保持事務(wù)一致。
分庫(kù)表中間件介紹
如果覺(jué)得分表分庫(kù)之后,需要考慮的問(wèn)題很多,可以使用市面上的現(xiàn)成的中間件幫我們實(shí)現(xiàn)。
這里介紹幾個(gè)比較常用的中間件:
另外著重介紹 Sharding-JDBC 的架構(gòu),它的構(gòu)成和“服務(wù)注冊(cè)中心”很像。
Sharding-JDBC 會(huì)提供一個(gè) Sharding-Proxy 做代理,他會(huì)連接一個(gè)注冊(cè)中心(registry center),一旦數(shù)據(jù)庫(kù)的節(jié)點(diǎn)掛接到系統(tǒng)中,會(huì)在這個(gè)中心注冊(cè),同時(shí)也會(huì)監(jiān)控?cái)?shù)據(jù)庫(kù)的健康狀況做心跳檢測(cè)。
而 Sharding-Proxy 本身在業(yè)務(wù)代碼(Business Code)請(qǐng)求數(shù)據(jù)庫(kù)的時(shí)候可以協(xié)助做負(fù)載均衡和路由。
同時(shí) Sharding-Proxy 本身也可以支持被 MySQL Cli 和 MySQL Workbench 查看。
實(shí)際上如果我們理解了分表分庫(kù)的原理之后,實(shí)現(xiàn)并不難,很多大廠都提供了產(chǎn)品。
總結(jié)
因?yàn)閿?shù)據(jù)量的上升,為了提高性能會(huì)對(duì)系統(tǒng)進(jìn)行分表分庫(kù)。從分表來(lái)說(shuō),有水平分表和垂直分表兩種方式。
可以根據(jù)業(yè)務(wù),冷熱數(shù)據(jù)等來(lái)進(jìn)行分庫(kù),分庫(kù)以后通過(guò)主從庫(kù)來(lái)實(shí)現(xiàn)讀寫(xiě)分離。
如果對(duì)分庫(kù)之后數(shù)據(jù)庫(kù)做擴(kuò)容,有兩種方式,主從數(shù)據(jù)庫(kù)擴(kuò)容和雙寫(xiě)數(shù)據(jù)庫(kù)擴(kuò)容。
分表分庫(kù)會(huì)帶來(lái)分布式事務(wù),我們需要掌握 CAP 和 BASE 原理,同時(shí)介紹了兩階段提交和 TCC 兩個(gè)分布式事務(wù)方案。最后,介紹了流行的分表分庫(kù)中間件,以及其實(shí)現(xiàn)原理。
當(dāng)前標(biāo)題:終于明白為什么要“分庫(kù)分表”了!
網(wǎng)站路徑:http://m.rwnh.cn/news17/98067.html
成都網(wǎng)站建設(shè)公司_創(chuàng)新互聯(lián),為您提供企業(yè)建站、網(wǎng)站內(nèi)鏈、ChatGPT、關(guān)鍵詞優(yōu)化、App開(kāi)發(fā)、虛擬主機(jī)
聲明:本網(wǎng)站發(fā)布的內(nèi)容(圖片、視頻和文字)以用戶(hù)投稿、用戶(hù)轉(zhuǎn)載內(nèi)容為主,如果涉及侵權(quán)請(qǐng)盡快告知,我們將會(huì)在第一時(shí)間刪除。文章觀點(diǎn)不代表本網(wǎng)站立場(chǎng),如需處理請(qǐng)聯(lián)系客服。電話:028-86922220;郵箱:631063699@qq.com。內(nèi)容未經(jīng)允許不得轉(zhuǎn)載,或轉(zhuǎn)載時(shí)需注明來(lái)源: 創(chuàng)新互聯(lián)
猜你還喜歡下面的內(nèi)容