分庫分表後路由策略設計

概述

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

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

作者：人間湊個數

來源：juejin.cn/post/7128726681954549768

本文由 Readfog 進行 AMP 轉碼，版權歸原作者所有。
來源：https://mp.weixin.qq.com/s/qmJQ0NdLN6SttzzreTzPRw