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分庫分錶後路由策略設計實例分析的詳細內容。更多資訊請關注PHP中文網其他相關文章！