微服務之惟一ID生成策略

數據庫自增ID

最簡單的實現方式是使用數據庫的id自增策略，如 MySQL 的 auto_increment。若是兩臺數據庫分別設置不一樣步長，能夠生成不重複ID，從而實現高可用。

優勢

實現簡單，容易理解，單調自增，絕對有序。

缺點

1. 強依賴DB，當DB異常時整個系統不可用，屬於致命問題。
2. ID發號性能瓶頸限制在單臺MySQL的讀寫性能。

UUID系列

結合機器的網卡、當地時間、一個隨記數來生成UUID。存在一些UUID的變種也是不錯的實現。

優勢

本地生成，生成簡單，性能很是好，高可用。

缺點

1. 長度過長，不易存儲，無序不可讀，查詢效率低。
2. 信息不安全，基於MAC地址生成UUID的算法可能會形成MAC地址泄露，這個漏洞曾被用於尋找梅麗莎病毒的製做者位置。
3. UUID的無序性可能會引發數據位置頻繁變更，嚴重影響性能。

Redis實現ID

Redis的全部命令操做都是單線程的，自己提供像 incr 和 increby 這樣的自增原子命令，因此能保證生成的 ID 確定是惟一有序的。

舉例，使用 Redis 來生成天天從0開始的流水號。好比訂單號 = 日期 + 當日自增加號。能夠天天在 Redis 中生成一個 Key ，使用 INCR 進行累加。

優勢

1. 靈活方便，且性能優於數據庫。
2. 數字ID自然排序，經過合理設計能夠獲得更具備表達能力的ID。

缺點

1. 引入Redis，編碼和配置的工做量比較大。
2. 若是ID是連續的，惡意用戶的扒取工做就很是容易作了，直接按照順序下載指定URL便可；若是是訂單號就更危險了，競對能夠直接知道咱們一天的單量。因此在一些應用場景下，會須要ID無規則、不規則。

Twitter的snowflake算法生成ID

詳細能夠參照 github.com/twitter/sno…

優勢

1. 時間有序，毫秒數在高位，自增序列在低位，整個ID都是趨勢遞增的。
2. 不依賴數據庫等第三方系統，以服務的方式部署，穩定性更高，生成ID的性能也是很是高的。
3. 能夠根據自身業務特性分配bit位，很是靈活。
4. Long型。

缺點

依賴於機器的時鐘，若是機器上時鐘回撥，會致使發號重複或者服務會處於不可用狀態。

百度UidGenerator

百度基於snowflake的一種實現，參見 github.com/baidu/uid-g…

優勢

同上 Twitter的snowflake算法生成ID

缺點

須要MySQL(內置WorkerID分配器, 啓動階段經過DB進行分配; 如自定義實現, 則DB非必選依賴）

美團Leaf

參見 tech.meituan.com/2017/04/21/…

優勢

1. 高可用容災。
2. ID號碼是趨勢遞增的8byte的64位數字，知足數據庫存儲的主鍵要求。

缺點

1. DB宕機會形成整個系統不可用。
2. 比較複雜。

MongoDB的ObjectId

經過「時間+機器碼+pid+inc」共12個字節，經過4+3+2+3的方式最終標識成一個24長度的十六進制字符。

優勢

1. 輕量型的，不一樣的機器都能用全局惟一的同種方法方便地生成它。
2. 本地生成，含時間戳，有序，成本低。
3. 安全性高。
4. 比較短，24位，好比掘金的ID，juejin.im/editor/post…

缺點

1. 比較長，難於記憶。
2. 使用機器ID和進程ID，64位Long沒法存儲，只能生成特殊ObjectId對象。

本身編程實現雪花算法

參照 Twitter的snowflake算法生成ID，參考MongoDB的ObjectId的生成策略，使用相似機器ID，進程ID來保證惟一性。