題目背景：
之前做電商運營，打算轉行做開發，參加了幾個面試，幾乎每家都會問到大資料量時的解決方案。暫時不討論問這個題目的合理性，既然有需求，那自己就加強吧。所以基於目前個人做的一個系統，計劃向大資料量做擴充套件設計。

涉及的業務場景：
（1）市場中有多個賣家（seller），可檢視、處理包含該賣家商品的訂單（order）
（2）買家（user）可檢視跟蹤自己的訂單

訂單表設計方案及查詢時處理邏輯
方案1(初始方案)
（1） 原始訂單表按照買家id取模分表
（2） 新建買家與訂單的對映關係表（也會資料量很大，可再按orderID取模分表）

查詢處理邏輯：
1買家查詢自己所有的訂單：按照userId取模找到對應的訂單分表，取資料
2買家按照訂單號查詢訂單：根據orderId從買家訂單對映中獲得userId，然後仍然是按照userID取模找到對應的訂單分表
問題：這樣拆分後，與賣家有關的訂單就被拆在多張表中，賣家檢視自己的訂單時還是要掃描所有資料

方案2（修改方案1）
對原始訂單也按照賣家id取模分表，然後再建立賣家與訂單的對映關係
問題：該方案雖然能實現設定的業務邏輯，但訂單資料要儲存兩份，要維護兩個對映表

方案3（修改方案2）
學習了淘寶的訂單系統設計，將訂單拆分為買家庫、賣家庫，訊息中介軟體進行訂單同步（類似於方案1、2的對買家、賣家分表麼），似乎是不關注訂單資料冗餘，但沒想明白如何按照訂單查詢，所以借鑑設計了方案3:
（1）按照userId取模分表
（2）按照sellerId取模分表
（3）按照orderId取模分表
相比方案1、2，少維護了一張表，但有兩份資料冗餘