數據庫唯一ID生成策略是什么

這篇文章主要介紹“數據庫唯一ID生成策略是什么”，在日常操作中，相信很多人在數據庫唯一ID生成策略是什么問題上存在疑惑，小編查閱了各式資料，整理出簡單好用的操作方法，希望對大家解答”數據庫唯一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

優點

1. 時間有序，毫秒數在高位，自增序列在低位，整個ID都是趨勢遞增的。

2. 不依賴數據庫等第三方系統，以服務的方式部署，穩定性更高，生成ID的性能也是非常高的。

3. 可以根據自身業務特性分配bit位，非常靈活。

4. Long型。

缺點

依賴于機器的時鐘，如果機器上時鐘回撥，會導致發號重復或者服務會處于不可用狀態。

百度UidGenerator

百度基于snowflake的一種實現

優點

同上 Twitter的snowflake算法生成ID

缺點

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

美團Leaf

優點

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來保證唯一性。

到此，關于“數據庫唯一ID生成策略是什么”的學習就結束了，希望能夠解決大家的疑惑。理論與實踐的搭配能更好的幫助大家學習，快去試試吧！若想繼續學習更多相關知識，請繼續關注億速云網站，小編會繼續努力為大家帶來更多實用的文章！