1、分佈式集羣架構
2、分佈式高併發環境的訂單號要求
- 全局唯一
- 訂單號信息安全要求
- 趨勢遞增要求
3、訂單號生成策略總結
| 策略 | 優點 | 缺點 | 格式 |
|---|---|---|---|
| uuid | 實現簡單不佔用帶寬 | 無序、不可讀、查詢慢 | 32位 |
| db自增 | 無代碼、遞歸 | DB單點故障、擴展有瓶頸 | |
| snowflake | 不佔用帶寬、低位趨勢遞增 | 依賴服務器時間 | 18位 |
| redis | 無單點故障、性能優於DB遞增 | 佔用帶寬、Redis集羣需要維護 | 12位 |
3.1、策略一：UUID(通用唯一識別碼)
組成：當前日期+時間+時鐘序列+機器識別號（MAC地址或其他）
分佈式系統中，所有元素（web服務器）都不需要通過中央控制端來判斷數據唯一性。
3.2、策略二：數據庫自增ID
關係型數據庫都實現數據庫自增ID;mysql通過auto_increment實現、oralce通過sequence實現。
在數據庫集羣環境下，不同數據庫節點可設置不同起步值、相同步長值來實現集羣下生成全局唯一、遞增ID。
3.3、策略三：snowflake算法
組成：41位時間戳+10爲機器ID+12位序列號（自增），轉換位長度爲18的長整型。
twitter位滿足每秒上萬條消息的創建，每條消息都必須分配全局唯一id，這些id要趨勢遞增，方便客戶排序。
Github上可以下載到snowflake源碼
3.4、策略四：Redis自增ID
Redis實現了incr(key)API用於將key的值遞增1並返回結果。若key不存在，則創建並賦值爲0。
Redis id自增的方法 ：格式 ：前綴+自增id 使用超時時間是爲了防止自增到9999時訂單號的位數變長
4、四種ID自增的格式示例
- uudi：205f1537-7991-4ed3-a2c7-c05aa8f8428b
- 數據庫自增：自增ID
- snowflake：386992679587676176
- redis：173372100001