什麼是分布式
如專案分布：訂單模組，商品模組，支付模組。由於每個模組之間的訪問壓力的不同，可以根據需要各自部署在不同數量的伺服器上，如訂單模組3臺，商品4臺，支付模組2臺。
分布式環境下訂單號的生成要求
必要：全域性唯一
其他的：趨勢遞增，高併發，高可用，資訊保安，長度（過長會造成儲存壓力過大）
生成策略：
uuid
組成：當前日期+時間+時鐘序列+機器識別碼
優點：實現簡單，不占用頻寬
缺點：無序，不適合建立索引。
優點：生成簡單，不占用寬頻，本地生成，資料遷移不影響。
缺點：字母儲存，無序，無法保證趨勢遞增，查詢慢，不可讀
資料庫自增
關係型資料庫都實現了主鍵自增的特點；如在集群環境下，有3臺資料庫，分別設定其起始值為1,2,3，以及步長為3；進而實現集群環境下資料庫的主鍵唯一的要求。
設定語法：
set global auto_increment_increment = 3;
set gloabl auto_increment_offset = ;
缺點：位數不確定，有溢位風險，高併發情況下有效能瓶頸。
適應場景：併發小，資料增長慢的情況
snowflake
組成：41位時間戳 + 10為機器id + 12位序列號（自增），並轉化為18位的長整型。
優點：本地生成，不佔寬頻，毫秒在高位，低位是趨勢遞增。
缺點：依賴時鐘 如果時間回撥可能會重複，效率比uuid慢
場景：elk，mq，併發大的業務系統
redis自增id
redis實現了incr(key) api用於將key的值遞增1，並返回結果。如果key不存在，則建立並複製為0，然後直行incr操作後返回1.
優點：不依賴資料庫，靈活，沒有單點故障，效能優於資料庫
缺點：占用網路資源，需要增加額外服務外掛程式
場景：併發大的業務系統
對比
uuid
實現簡單，不占用頻寬
id是無序的，查詢慢，不適合建立索引
32位元組
資料庫自增
**簡單，資料遞增
db單點故障，新增加db時有瓶頸
遞增snowflake
低位趨勢遞增，不佔頻寬，效能到
依賴於伺服器時間
18位元組
redis自增id
無單點故障，效能高，遞增
占用頻寬，redis集群維護
自定義
高併發，分布式電商訂單號生成
優點 簡單 uuid.randomuuid 缺點 1.使用者不友好，無序，不可讀 2.索引關聯效率較低，查詢慢 3.分布式集群情況下有機率重複 在資料庫集群環境下，不同的資料庫節點可以設定不同的起步值 相同的步長值來實現訂單號唯一 tab a 起步值1 步長值10111 2131 41tab b 起...
電商交易系統高併發分布式訂單號生成策略
商交易系統高併發分布式訂單號生成策略 一 要求 1.全域性唯一性，不能重複 2.資訊保安加密防止使用者根據id規則獲取資料 二，策略 1.uuid 唯一識別碼，16個位元組 128位 uuid 有幾個實現版本，比如jdk 自帶的uuid 優點 生成簡單，不占用寬頻，本地生成，資料遷移不影響。缺點 字...
電商平台訂單號生成策略
訂單是整個電子商務的核心。整個電子商務的流程也是圍繞訂單的狀態執行的。這篇部落格主要向大家介紹訂單號的生成方式。現在大型電商 大多都有好幾種下單途徑。比如 通過web 下單，通過打 到呼叫中心下單 callcenter 使用手機wap下單。如果只採用單資料庫來儲存訂單資訊的話，其隨著訂單量的增加，單...