如果面試官讓你設計美團外賣的分庫分表架構，就該這麼說！

文章來源：http://juejin.cn/post/7128726681954549768

目錄

• 支援場景

• 路由策略

• 使用者端路由key

• 商家路由key

概述

分庫分表後設計到的第一個問題就是，如何選擇路由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，然後根據訂單號獲取訂單資訊，然後再把訂單資訊插入到商戶的資料庫表當中。商戶的 路由策略 和使用者的 路由策略 是一樣的。

使用者端和商戶端的完整資料流程圖：

歡迎掃碼加入儒猿技術交流群，每天晚上20:00都有Java面試、Redis、MySQL、RocketMQ、SpringCloudAlibaba、Java架構等技術答疑分享，更能跟小夥伴們一起交流技術

另外推薦儒猿課堂的1元系列課程給您，歡迎加入一起學習~

網際網路Java工程師面試突擊課

（1元專享）

SpringCloudAlibaba零基礎入門到專案實戰

（1元專享）

億級流量下的電商詳情頁系統實戰專案

（1元專享）

Kafka訊息中介軟體核心原始碼精講

（1元專享）

12個實戰案例帶你玩轉Java併發程式設計

（1元專享）

Elasticsearch零基礎入門到精通

（1元專享）

基於Java手寫分散式中介軟體系統實戰

（1元專享）

基於ShardingSphere的分庫分表實戰課

（1元專享）