MySQL分庫分表后路由策略設計實例分析

這篇“MySQL分庫分表后路由策略設計實例分析”文章的知識點大部分人都不太理解，所以小編給大家總結了以下內容，內容詳細，步驟清晰，具有一定的借鑒價值，希望大家閱讀完這篇文章能有所收獲，下面我們一起來看看這篇“MySQL分庫分表后路由策略設計實例分析”文章吧。

概述

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

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

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

支持場景

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

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

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

路由策略

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

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

用戶端路由key

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

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

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

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

商家路由key

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

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

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

以上就是關于“MySQL分庫分表后路由策略設計實例分析”這篇文章的內容，相信大家都有了一定的了解，希望小編分享的內容對大家有幫助，若想了解更多相關的知識內容，請關注億速云行業資訊頻道。