背景
在分布式微服務系統中，通常需要全域性唯一的序列號，需求實現簡單高效，通常的做法可以用資料庫的自增id，uuid生成等。但資料庫自增id侷限在於依賴於資料庫表，在效率上有所折扣，尤其是高併發量的場景。而uuid一般比較長，關鍵是無序的。twitter的snowflake解決了這種需求，最初twitter把儲存系統從mysql遷移到cassandra，因為cassandra沒有順序id生成機制，所以開發了這樣一套全域性唯一id生成服務。
snowflake結構
名字說明
1符號位
0，通常不使用
41時間戳
精確到毫秒數，支援 2 ^41 /365/24/60/60/1000=69.7年
10工作程序編號
支援 1024 個程序
12序列號
每毫秒從 0 開始自增，支援 4096 個編號
snowflake生成的id整體上按照時間自增排序，一共加起來剛好64位，為乙個long型(轉換成字串後長度最多19)。並且整個分布式系統內不會產生id碰撞（由datacenter和workerid作區分），工作效率較高，經測試snowflake每秒能夠產生26萬個id。
應用與實現
定義介面keygenerator，有方法generatekey()。實現類defaultkeygenerator，是預設的id生成器。對於工作執行緒的確定，可以借助通過 zookeeper、consul、etcd 等提供分布式配置功能的中介軟體，也可以直接通過該機器的ip獲取工作程序編號。
目前，國內很多大型網際網路公司都是基於這種方式實現的id生成器，一些開元的分布式資料庫中介軟體也是基於此演算法實現資料庫主鍵的，比如mycat, sharding-jdbc等。
自增ID演算法snowflake 雪花
在資料庫主鍵設計上，比較常見的方法是採用自增id 1開始，每次加1 和生成guid。資料庫自增主鍵保證唯一性，但在分布式系統中，部署需要考慮的因素太多 guid設計簡單，能保證主鍵的唯一性，分布式系統中，資料庫部署也簡單，只是guid是一串無物理意義的字串，大量資料查詢的時候效率相對會打折，儲存暫用...
自增ID演算法snowflake 雪花
在資料庫主鍵設計上，比較常見的方法是採用自增id 1開始，每次加1 和生成guid。生成guid的方式雖然簡單，但是由於採用的是無意義的字串，推測會在資料量增大時造成訪問過慢，在基礎網際網路的系統設計中都不推薦採用。自增id的方法雖然比較適合大資料量的場景，當時由於自增id是按照順序增加的，資料記錄...
唯一ID生成器snowflake
sn fle k 很多場景需要使用全域性唯一id，用來標識唯一一條訊息，唯一一筆交易，唯一乙個使用者，唯一一張等等。傳統資料庫表的自增主鍵是很簡單的一種實現方式，前提是你沒有分庫，也沒有分表，如果你分表了，id就會重複，失去唯一性 用時間做唯一id，這個在併發比較高或者分布式環境中基本不可行，統一時...