http://blog.yxwang.me/2012/08/twitter-snowflake/

這是一篇兩年前 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）。

總結

以上是生活随笔為你收集整理的Twitter Snowflake的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。