背景
在複雜的分布式系統中，往往需要對大量的資料和訊息進行唯一標識。
如對大量的訂單做分庫分表後，需要有乙個唯一的id來標識一條資料或訊息，資料庫的自增id顯然不能滿足需求。
業務系統對分布式唯一id的要求：
①：全域性唯一性，不能重複
②：趨勢遞增，在mysql innodb引擎中使用的是聚集索引，由於多數rdms使用b-tree的資料結構來儲存索引資料，在主鍵的選擇上面應該盡量使用有序的主鍵保證寫入效能
常用方案
1、uuid
優點：生成簡單，本地生成，沒有網路消耗，效能非常高
缺點：1）每次生成的id是無序的，無法保證趨勢遞增，不能作為資料庫主鍵，否則會引起索引資料位置頻繁變動，嚴重影響效能
2）uuid的字串儲存，查詢效率慢
3）儲存空間大
4）id本事無業務含義，不可讀
2、redis
利用redis的原子性自增，具體實現為：
年份 + 當天距當年第多少天 + 天數 + 小時 + redis自增
優點：有序遞增，可讀性強
缺點：占用頻寬，每次要向redis進行請求
3、雪花snowflake演算法
snowflake是twitter開源的分布式id生成演算法，結果是乙個long型的id。
其核心思想是：使用41bit作為毫秒數，10bit作為work id（5個bit是資料中心，5個bit的機器id），12bit作為毫秒內的流水號（意味著每個節點在每毫秒可以產生 4096 個 id），最後還有乙個符號位，永遠是0。
snowflake演算法生成64位的二進位制正整數，然後轉換成10進製的數。
64位二進位制數組成部分如下：
優點：1）此方案每秒能夠產生409.6萬個id，效能快
2）時間戳在高位，自增序列在低位，整個id是趨勢遞增的，按照時間有序遞增
3）靈活度高，可以根據業務需求，調整bit位的劃分，滿足不同的需求
缺點：只能保證work id相同的情況下生成的id是遞增的
依賴機器的時鐘，如果伺服器時鐘回撥，會導致重複id生成
時鐘回撥問題的解決方案：
1）回撥之後更換work id
2）等時間追上來再去生成id
4、美團leaf
參考：end.
常見的分布式唯一ID方案
最近看乙個新系統，發現裡面有很多場景用到唯一id，便蒐羅了一下常見的方案。對於分布式id，需要滿足下面的基本要求 全域性唯一 趨勢遞增 uuid universally unique identifier 全域性唯一識別符號，定義為乙個字串主鍵，採用32位數字組成，編碼採用16進製制，定義了在時間和...
分布式唯一ID實現
分布式唯一id實現 在業務開發中，大量場景需要用到唯一id，比如系統流水號，訂單號等等。那麼，分布式唯一id有哪些特徵呢？唯一性 生成的id全域性唯一。高可用 可保證在高併發下的可用性，確保任何時候都能正確生成id。自主性 分布式環境下不依賴中心認證，即可自行生成id。安全性 不暴露系統和業務資訊。...
分布式唯一ID的生成方案
不能出現重複的id，這是最基本的要求。有利於關聯式資料庫索引效能。既然是服務於分布式系統，為多個服務提供id服務，訪問壓力一定很大，所以需要保證高可用。如果id是有規律的，就容易被惡意操作，在一些場景下需要id無規則。核心思想是結合機器的網絡卡 當地時間 乙個隨機數來生成。優點 缺點 利用資料庫自增...