MySQL分庫分表後路由策略設計詳情

2022-08-08 18:01:09

概述

分庫分表後設計到的第一個問題就是，如何選擇路由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分庫分表後路由策略設計詳情的文章就介紹到這了,更多相關MySQL分庫分表內容請搜尋it145.com以前的文章或繼續瀏覽下面的相關文章希望大家以後多多支援it145.com！

MySQL分庫分表後路由策略設計詳情

目錄

概述

支援場景

路由策略

使用者端路由key

商家路由key

熱門文章