概述

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

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

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

支持場景

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

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

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

路由策略

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

如果在插入訂單的時候有一定的規(guī)則，根據這個規(guī)則插入到數據庫中，查詢的時候也執(zhí)行相應的規(guī)則到對應的表中進行查詢。這樣就能減少數據操作的復雜性。可以通過設計路由策略來實現，用戶和商家查詢數據的時候都遵循相同的路由策略。

用戶端路由key

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

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

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

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

商家路由key

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

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

用戶端和商戶端的完整數據流程圖：

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

最新評論