/ˈsnəʊfleɪk/
很多場景需要使用全域性唯一id，用來標識唯一一條訊息，唯一一筆交易，唯一乙個使用者，唯一一張等等。
傳統資料庫表的自增主鍵是很簡單的一種實現方式，前提是你沒有分庫，也沒有分表，如果你分表了，id就會重複，失去唯一性：
用時間做唯一id，這個在併發比較高或者分布式環境中基本不可行，統一時間生成的id是重複的，不滿足全域性唯一
依然利用資料庫產生自增id，保證唯一性，和開頭提到的不同之處是，單獨使用一張（或固定幾張）資料庫表專門用來產生自增id，與業務無關，後續不再重新分表，資料量大時，可以刪除早一些時候產生的資料。
這樣做的好處是，實現簡單，容易理解。
不好的地方是，嚴重依賴資料庫，id產生速率受資料庫效能以及連線資料庫的網路影響。
好處：實現簡單，容易理解。
壞處：依賴redis，且redis需要持久化。
好處：使用非常簡單，不需要依賴其他設施。
壞處：太長，128bit，不適合做資料庫主鍵。
通常情況下，用時間來表示是最簡單的，如果同一時間（毫秒）有很多請求進來怎麼辦？
時間戳後面拼接上乙個數字，這個數字可以通過鎖控制每次遞增，每毫秒清零，重新開始遞增。
即便這樣，只是解決了單機的問題，如果是分布式環境，不同的機器，還是可能產生一樣的id的，這怎麼解決？
在上述時間戳和數字的基礎上在拼接上機器的id，這樣就不會重複了。
不同的資料中心，機器id是可能重複的，怎麼搞？
再拼接上資料中心的id就行了。
不同的星球上。。。
思想樸實無華，但是大道至簡。
最終產生的id是這個樣子的，時間戳，工作機器id，序列號可以根據實際需要調整長度（通常情況下不需要調整，完全夠用），總體64bit就行：
，時間戳，工作機器id，序列號可以根據實際需要調整長度（通常情況下不需要調整，完全夠用），總體64bit就行：
Java 唯一ID生成器
前段時間，寫了乙個id 生成器，發在群裡，結果遭到別人嘲笑，心有不甘，於是思來想去，決定在重新寫乙個id生成器。此方法生成的id理論上也是會有重複，但是這個概率太低太低，低到可以忽略不計。使用當前時間戳 指定長度的隨機數，並隨機打亂字串。可以生成指定長度的純數字的id。普通 id生成器 用時間戳生成...
IdGenerator 唯一Id生成器
public class idgenerator public idgenerator long processid this.processid processid protected long timegen public synchronized long nextid 剛剛生成的時間戳跟上次...
分布式唯一ID生成器
在應用程式中，經常需要全域性唯一的id作為資料庫主鍵。如何生成全域性唯一id？首先，需要確定全域性唯一id是整型還是字串？如果是字串，那麼現有的uuid就完全滿足需求，不需要額外的工作。缺點是字串作為id占用空間大，索引效率比整型低。如果採用整型作為id，那麼首先排除掉32位int型別，因為範圍太小...