概述

分庫分表后設(shè)計(jì)到的第一個(gè)問題就是，如何選擇路由key，應(yīng)該如何對key進(jìn)行路由。路由key應(yīng)該在每個(gè)表中都存在而且唯一。路由策略應(yīng)盡量保證數(shù)據(jù)能均勻進(jìn)行分布。

如果是對大數(shù)據(jù)量進(jìn)行歸檔類的業(yè)務(wù)可以選擇時(shí)間作為路由key。比如按數(shù)據(jù)的創(chuàng)建時(shí)間作為路由key，每個(gè)月或者每個(gè)季度創(chuàng)建一個(gè)表。按時(shí)間作為分庫分表后的路由策略可以做到數(shù)據(jù)歸檔，歷史數(shù)據(jù)訪問流量較小，流量都會打到最新的數(shù)據(jù)庫表中。

也可以設(shè)計(jì)其與業(yè)務(wù)相關(guān)的路由key。這樣可以保證每個(gè)數(shù)據(jù)庫的資源都能很好的承擔(dān)流量。

支持場景

外賣訂單平臺分庫分表后需要支持的場景，用戶的角度，需要實(shí)時(shí)查看所點(diǎn)外賣訂單的狀態(tài)，跟蹤訂單信息。商家需要查詢訂單信息，通過訂單分析菜品的質(zhì)量，進(jìn)行商業(yè)決策。

用戶Consumer = C端 商家Business = B端

用戶下單后訂單可能會落到不同的表中，查詢的時(shí)候可能需要查詢多張表。

路由策略

如果創(chuàng)建訂單時(shí)隨機(jī)插入到某一張表中，或者不知道插入到那張表中，查詢訂單的時(shí)候都需要查詢所有的表才能確保查詢的準(zhǔn)確信。

如果在插入訂單的時(shí)候有一定的規(guī)則，根據(jù)這個(gè)規(guī)則插入到數(shù)據(jù)庫中，查詢的時(shí)候也執(zhí)行相應(yīng)的規(guī)則到對應(yīng)的表中進(jìn)行查詢。這樣就能減少數(shù)據(jù)操作的復(fù)雜性?？梢酝ㄟ^設(shè)計(jì)路由策略來實(shí)現(xiàn)，用戶和商家查詢數(shù)據(jù)的時(shí)候都遵循相同的路由策略。

用戶端路由key

根據(jù)上一小節(jié)的路由策略分析，現(xiàn)在需要選定一個(gè)路由key。用戶端讓同一個(gè)用戶id的數(shù)據(jù)保存到某固定的表中，所以可以選用用戶id最為路由key。

在單庫的情況下，用戶下單，生成一個(gè)訂單，把用戶id作為路由key，對user_id取hash值然后對表的數(shù)量進(jìn)行取模，得到對應(yīng)需要路由的表，然后寫入數(shù)據(jù)。

多庫多表的情況下需要先找到對應(yīng)的庫然后再找到對應(yīng)的表。多庫多表的路由策略：用戶下達(dá)->生成訂單->路由策略：根據(jù)用戶id的hash值對數(shù)據(jù)庫的數(shù)量進(jìn)行取模找到對應(yīng)的數(shù)據(jù)庫->根據(jù)用戶id的hash值除以對表的數(shù)量，然后在對表的數(shù)量進(jìn)行取模即可找到對應(yīng)的表。

路由策略設(shè)計(jì)的要點(diǎn)是根據(jù)具體的業(yè)務(wù)業(yè)務(wù)場景設(shè)計(jì)，跟用戶信息關(guān)聯(lián)度比較大的作為路由key進(jìn)行hash值取模

商家路由key

單獨(dú)為商家B端設(shè)計(jì)了一套表(C端和B端是獨(dú)立的)。

用戶的角度以user_id作為路由key，商戶的角度以商家id作為路由key。商家是如何通過路由key路由數(shù)據(jù)的呢。游湖在下單的時(shí)候把隊(duì)友的訂單號發(fā)送到MQ里，商家可以去消費(fèi)這個(gè)MQ，然后根據(jù)訂單號獲取訂單信息，然后再把訂單信息插入到商戶的數(shù)據(jù)庫表當(dāng)中。商戶的路由策略和用戶的路由策略是一樣的。

用戶端和商戶端的完整數(shù)據(jù)流程圖：

到此這篇關(guān)于MySQL分庫分表后路由策略設(shè)計(jì)詳情的文章就介紹到這了,更多相關(guān)MySQL分庫分表內(nèi)容請搜索腳本之家以前的文章或繼續(xù)瀏覽下面的相關(guān)文章希望大家以后多多支持腳本之家！

最新評論