三、因子分表法
唯一性（必要）：每個訂單號全域性唯一代表乙個訂單；
安全性（必要）：訂單號不能透露訂單量、運營規模等業務資訊（資料安全性）；
高效能：訂單號的建立成本越低越好；
擴充套件性：能夠較好的支撐後續業務發展變大帶來的分庫分表、訂單長度擴充套件等場景；
不安全：訂單號能夠反映出系統的訂單量，存在業務資料外露的風險；
效能問題：需要資料庫插入一條記錄獲取主鍵id，效能受限於資料庫，且存在單點；
擴充套件性：不利於後續的分庫分表（見方案3）；
思路：jdk自帶uuid工具類，生成uuid足夠快速、方便，業界不使用uuid作為分布式唯一id，或者訂單號的原因在於：
效能問題：在訂單表中，訂單號為主鍵或者唯一索引，uuid是無序的(36位字串)，如果作為資料庫主鍵，在innodb引擎下，uuid的無序性會引起資料位置頻繁變動，嚴重影響資料庫效能；（uuid生成是很快的，作為訂單號影響的是訂單表的寫效能）
擴充套件性：不利於後續的分庫分表（見方案3）；
分布式唯一id生成器，主要有類snowflake方案和分庫分表形式的資料庫自增id方案。目前分布式唯一id方案已經很成熟，能做到高效能、高可用、遞增等。在訂單場景下，主要問題在於不利於分庫分表，如下圖。將分布式唯一id作為訂單號不利於分庫分表原因如下：
無法滿足多維護查詢，當查詢條件中沒有訂單id時，會全表掃瞄，效能低下；（全表掃瞄）
為了避免全表掃瞄，可以通過db或者快取儲存訂單號與使用者id、商戶id的對映關係，每次在使用者id和商戶id維度查詢時，先通過對映關係查詢到對應的訂單id，然後路由到對應的分表；（多一次查詢）
思路：犧牲通用性，根據訂單場景將影響分庫分表的業務因子融入到訂單號中，比如使用者id，根據訂單號分庫分表路由時，通過位移對業務因子取模路由即可，實現訂單號和業務因子路由的一致性，如下圖所示（需要哪些因子，占用幾位看實際情況）。這樣做的好處是：
趨勢遞增：時間戳在高位，利用時間的遞增性，保證訂單號趨勢遞增；
高效能：沒有第三方依賴，且基本零消耗；
分庫分表：分庫分表因子融入到了訂單號中，避免了全表掃瞄或者多一次查詢；
唯一性：同一使用者在同一店鋪的同一時間內下多個單才有可能重複，對於正常使用者行為是不可能出現的；
以使用者的訂單庫為例進行說明，訂單號由三部分組成：時間戳+分庫分表因子+隨機數。使用者因子為使用者id雜湊後的某10位，這樣無論是按照訂單id還是使用者id查詢，最終都會使用者因子分庫分表，從而路由的分表也會一致，如下所示：
分布式唯一id是一種通用的基礎服務，為各業務系統提供唯一id，不包含任何業務屬性；（通用方案）
訂單號是一種特殊的分布式唯一id，為了便於業務處理，通常會結合一些業務資訊來生成；(結合業務場景的個性化方案)
參考：leaf——美團點評分布式id生成系統
老司機設計了乙個能扛住雙11併發的訂單號生成方案，同事說「666」
單key業務，資料庫水平切分架構實踐 | 架構師之路
設計訂單號規則和依據
訂單號是用來標記 查詢訂單 查詢的時候可能更關注於物流單號 用的，一般會在訂單有支付 售後 異常問題的時候會用到，也就是說訂單號主要是拿給客服 運營 開發部門用的。根據訂單號就能得到一些資訊 訂單號 1 純數字，盡量短 2 盡量能結合當前的業務情況有特定的標識，如渠道編號 包括平台 下單渠道 支付方...
訂單號生成
之前用uuid 因為太長改用16位因此在網上找到一下這種做法,年月日擷取 時間戳 在加隨機數 生成乙個訂單 獲取年份 var date j f c d e b h i a date gettime tostring var ordersn date new date getfullyear 2015...
訂單系統訂單表設計方案
一年前，在上一家公司接手了乙個含有訂單系統的專案，業務並不複雜，但是當時令我比較困惑的是訂單表的設計。困惑的點主要是隨著訂單量增加，單錶的儲存能力將達到瓶頸，必然要採用分表的方案，那麼按照什麼維度拆分合適呢？分表之後帶來的最大的挑戰是訂單查詢。如果以使用者為中心，採用userid取模，可以很方便的處...