這是一篇兩年前 Twitter 開發團隊寫的文章，今天挖出來研究了一下。原文地址 http://engineering.twitter.com/2010/06/announcing-snowflake.html
Twitter 早期用 MySQL 存儲數據，隨著用戶的增長，單一的 MySQL 實例沒法承受海量的數據，開發團隊就開始用 Cassandra 和 sharded MySQL 替代原有的系統。然而和 MySQL 不同的是，Cassandra 沒有內置為每一條數據生成唯一 ID 的功能，因為在一個分布式環境下，很難有完美的 ID 生成方案。
對于 Twitter 而言，這樣的 ID 生成方案要滿足兩個基本的要求，一是每秒能生成幾十萬條 ID 用于標識不同的 tweet；二是這些 ID 應該可以有個大致的順序，也就是說發布時間相近的兩條 tweet，它們的 ID 也應當相近，這樣才能方便各種客戶端對 tweet 進行排序。
第一個要求意味著 ID 生成要以一種非協作的（uncoordinated）的方式進行，例如不能有一個全局的原子變量。
第二個要求使得 tweet 按 ID 排序后滿足 k-sorted 條件。如果序列 A 要滿足 k-sorted，當且僅當對于任意的 p, q，如果 1 <= p <= q - k (1 <= p <= q <= n)，則有 A[p] <= A[q]。換句話說，如果元素 p 排在 q 前面，且相差至少 k 個位置，那么 p 必然小于或等于 q。如果 tweet 序列滿足這個條件，要獲取第 r 條 tweet 之后的消息，只要從第 r - k 條開始查找即可。
Twitter 解決這兩個問題的方案非常簡單高效：每一個 ID 都是 64 位數字，由時間戳、節點號和序列編號組成。其中序列編號是每個節點本地生成的序號，而節點號則由 ZooKeeper 維護。
具體的參數可以在這個 IdWorker.scala 中看到。序列編號有 12 位，意味著每個節點在每毫秒可以產生 4096 個 ID。節點號在源碼中被分成兩部分，數據中心的 ID 和節點 ID，各自占 5 位。時間戳則是記錄了從 1288834974657 (Thu, 04 Nov 2010 01:42:54 GMT) 這一時刻到當前時間所經過的毫秒數，占 41 位（還有一位是符號位，永遠為 0）。