🔍 一、查看短鏈的實現方式
👥 1. 從普通用戶角度
- 短鏈接中直接包含庫表位資訊，
- 用戶可以通過短鏈中的 code 字段解析，直接定位到對應的庫表，從而實現快速訪問。
- ✅ 特點：解析簡單、響應速度快，無需額外的數據映射層。
🏬 2. 從商家角度
- 因為系統採用了分庫分表策略，數據分散存儲在不同的庫表中。
- 商家在獲取短鏈時，無法僅通過 code 直接解析定位對應的庫表。
- ⚠ 問題：分庫分表帶來的數據路由複雜性，無法像用戶端一樣快速解析。
🛠 二、解決方案：使用 MQ + 冗餘雙寫策略
💡 核心思路
透過MQ（消息隊列）配合冗餘雙寫策略 來解決分庫分表帶來的解析問題，並確保數據在多庫之間的最終一致性。
🌐 三、詳細設計方案
🏛 1. 賣家庫與買家庫的分離設計
為減少查詢複雜性並提升查詢效率，將數據按照業務角色分為賣家庫 與買家庫。
-
買家庫：
- 分片策略 ：以 用戶 ID 為分片鍵進行分庫分表。
- 優勢：買家可以快速查詢自己的訂單數據，提升用戶端體驗。
-
賣家庫：
- 分片策略 ：以 商家 ID 為分片鍵進行分庫分表。
- 優勢：商家可以高效檢索與管理與自身相關的業務數據。
📝 2. 數據冗餘設計（冗餘雙寫）
-
目的：確保買家庫與賣家庫之間數據同步，支持多角度高效查詢。
-
具體方案：
- 下訂單時同步寫入兩份數據
- 寫入買家庫（根據用戶 ID 定位）
- 寫入賣家庫（根據商家 ID 定位）
- 寫入方式 ：採用冗餘雙寫策略，在業務層確保訂單生成時數據同時落盤至兩個庫。
- 下訂單時同步寫入兩份數據
🔄 3. 分佈式事務與數據一致性保證
在分庫分表與冗餘雙寫的場景下，分佈式事務是關鍵問題，尤其是確保數據在多庫間的一致性。
-
問題：
- 多庫寫入可能出現部分失敗，導致數據不一致。
- 傳統分布式事務解決方案（如兩階段提交 2PC）存在性能開銷大、可用性低的問題。
-
解決方案 ：
✅ 使用 MQ 實現最終一致性
- 當業務系統寫入主庫成功後，通過 MQ 發送同步消息。
- 消費端根據消息異步寫入冗餘庫。
- 如果消費失敗，可通過 MQ 的重試機制或補償策略確保數據最終一致。
-
優勢：
- ✅ 解耦業務流程，減少同步開銷
- ✅ 高可用性，即使部分系統異常也能最終達成一致
- ✅ 提升系統吞吐量，避免分布式鎖帶來的性能瓶頸
🎯 四、整體流程總結
| 🌟 流程步驟 | ⚡ 描述 |
|---|---|
| 1. 訂單創建 | 用戶下單時，根據用戶 ID 寫入買家庫，商家 ID 寫入賣家庫。 |
| 2. 冗餘雙寫 | 業務層採用雙寫策略，同時提交兩份數據。 |
| 3. 發送 MQ 消息 | 主庫寫入成功後，向 MQ 發送同步消息。 |
| 4. MQ 消費與異步同步 | 消費端接收消息，將數據寫入冗餘庫。 |
| 5. 數據一致性校驗 | 若異步寫入失敗，通過補償機制（如定時任務或重試機制）達成最終一致性。 |
| 6. 短鏈解析查詢 | - 用戶：透過 code 直接定位庫表。 - 商家：通過冗餘庫間接定位。 |
🏹 五、技術亮點與優勢
| 🚀 特性 | 🌟 優勢說明 |
|---|---|
| 無侵入式多端展示 | 短鏈 code 為用戶提供直接解析能力，體驗一致。 |
| 高效分庫分表策略 | 根據用戶/商家 ID 自然分片，提升單庫性能並減少跨庫查詢。 |
| 冗餘雙寫設計 | 支持多角色（用戶、商家）高效檢索，查詢延遲低。 |
| 分布式事務一致性 | MQ 實現異步最終一致性，避免傳統分布式事務帶來的性能問題。 |
| 高可用性與容錯能力 | MQ 的重試與補償機制保證在異常情況下數據不丟失。 |
✨ 六、總結
在 分庫分表架構 下，WebRelease 搭配 MQ + 冗餘雙寫 的策略，不僅能解決短鏈解析的庫表定位問題 ，同時通過最終一致性機制確保多庫數據的一致性與高可用性。
- 🔑 對用戶而言：短鏈可即時解析，體驗流暢且快速。
- 🏬 對商家而言：透過冗餘數據存儲，即使在分布式架構中也能高效檢索訂單資料。
- 🏃 對系統而言：高可用性、低延遲且具備強大的容錯能力。
💬 是否需要針對特定場景進行深入的代碼範例或架構細節解讀？隨時可以討論！ 🚀✨
實現查看短鏈的方式
1.普通用戶角度 ，短鏈接直接包含了庫表位，直接使用code可以解析到對應的庫表
2.商家角度， 因爲使用了分庫分表，數據分佈在不同的庫表，所以，商家無法直接根據code解析對應的庫表
解決方法
使用mq+冗餘雙寫的方法實現
拆分賣家，買家庫
1.買家庫使用 用戶id分庫分表
2.賣家庫使用 商家id分庫分表
數據榮譽
1.下訂單同時寫入兩份表
2.在買家庫和賣家庫分別寫入一份數據
分佈式事務問題
1.使用mq實現最終一致性實現數據同步。