概述

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

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

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

支持場景

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

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

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

路由策略

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

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

用戶端路由key

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

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

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

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

商家路由key

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

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

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

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

最新評論