分散式ID
1 方案選擇
-
UUID
UUID是通用唯一識別碼(Universally Unique Identifier)的縮寫,開放軟體基金會(OSF)規範定義了包括網路卡MAC地址、時間戳、名字空間(Namespace)、隨機或偽隨機數、時序等元素。利用這些元素來生成UUID。
UUID是由128位二進位制組成,一般轉換成十六進位制,然後用String表示。
550e8400-e29b-41d4-a716-446655440000
UUID的優點:
- 通過本地生成,沒有經過網路I/O,效能較快
- 無序,無法預測他的生成順序。(當然這個也是他的缺點之一)
UUID的缺點:
- 128位二進位制一般轉換成36位的16進位制,太長了只能用String儲存,空間佔用較多。
- 不能生成遞增有序的數字
-
資料庫主鍵自增
大家對於唯一標識最容易想到的就是主鍵自增,這個也是我們最常用的方法。例如我們有個訂單服務,那麼把訂單id設定為主鍵自增即可。
-
單獨資料庫 記錄主鍵值
-
業務資料庫分別設定不同的自增起始值和固定步長,如
第一臺 start 1 step 9 第二臺 start 2 step 9 第三臺 start 3 step 9
優點:
- 簡單方便,有序遞增,方便排序和分頁
缺點:
- 分庫分表會帶來問題,需要進行改造。
- 併發效能不高,受限於資料庫的效能。
- 簡單遞增容易被其他人猜測利用,比如你有一個使用者服務用的遞增,那麼其他人可以根據分析註冊的使用者ID來得到當天你的服務有多少人註冊,從而就能猜測出你這個服務當前的一個大概狀況。
- 資料庫當機服務不可用。
-
-
Redis
熟悉Redis的同學,應該知道在Redis中有兩個命令Incr,IncrBy,因為Redis是單執行緒的所以能保證原子性。
優點:
- 效能比資料庫好,能滿足有序遞增。
缺點:
- 由於redis是記憶體的KV資料庫,即使有AOF和RDB,但是依然會存在資料丟失,有可能會造成ID重複。
- 依賴於redis,redis要是不穩定,會影響ID生成。
-
雪花演算法-Snowflake
Snowflake是Twitter提出來的一個演算法,其目的是生成一個64bit的整數:
- 1bit:一般是符號位,不做處理
- 41bit:用來記錄時間戳,這裡可以記錄69年,如果設定好起始時間比如今年是2018年,那麼可以用到2089年,到時候怎麼辦?要是這個系統能用69年,我相信這個系統早都重構了好多次了。
- 10bit:10bit用來記錄機器ID,總共可以記錄1024臺機器,一般用前5位代表資料中心,後面5位是某個資料中心的機器ID
- 12bit:迴圈位,用來對同一個毫秒之內產生不同的ID,12位可以最多記錄4095個,也就是在同一個機器同一毫秒最多記錄4095個,多餘的需要進行等待下毫秒。
上面只是一個將64bit劃分的標準,當然也不一定這麼做,可以根據不同業務的具體場景來劃分,比如下面給出一個業務場景:
- 服務目前QPS10萬,預計幾年之內會發展到百萬。
- 當前機器三地部署,上海,北京,深圳都有。
- 當前機器10臺左右,預計未來會增加至百臺。
這個時候我們根據上面的場景可以再次合理的劃分62bit,QPS幾年之內會發展到百萬,那麼每毫秒就是千級的請求,目前10臺機器那麼每臺機器承擔百級的請求,為了保證擴充套件,後面的迴圈位可以限制到1024,也就是2^10,那麼迴圈位10位就足夠了。
機器三地部署我們可以用3bit總共8來表示機房位置,當前的機器10臺,為了保證擴充套件到百臺那麼可以用7bit 128來表示,時間位依然是41bit,那麼還剩下64-10-3-7-41-1 = 2bit,還剩下2bit可以用來進行擴充套件。
時鐘回撥
因為機器的原因會發生時間回撥,我們的雪花演算法是強依賴我們的時間的,如果時間發生回撥,有可能會生成重複的ID,在我們上面的nextId中我們用當前時間和上一次的時間進行判斷,如果當前時間小於上一次的時間那麼肯定是發生了回撥,演算法會直接丟擲異常.
使用雪花演算法
# Twitter's Snowflake algorithm implementation which is used to generate distributed IDs. # https://github.com/twitter-archive/snowflake/blob/snowflake-2010/src/main/scala/com/twitter/service/snowflake/IdWorker.scala import time import logging class InvalidSystemClock(Exception): """ 時鐘回撥異常 """ pass # 64位ID的劃分 WORKER_ID_BITS = 5 DATACENTER_ID_BITS = 5 SEQUENCE_BITS = 12 # 最大取值計算 MAX_WORKER_ID = -1 ^ (-1 << WORKER_ID_BITS) # 2**5-1 0b11111 MAX_DATACENTER_ID = -1 ^ (-1 << DATACENTER_ID_BITS) # 移位偏移計算 WOKER_ID_SHIFT = SEQUENCE_BITS DATACENTER_ID_SHIFT = SEQUENCE_BITS + WORKER_ID_BITS TIMESTAMP_LEFT_SHIFT = SEQUENCE_BITS + WORKER_ID_BITS + DATACENTER_ID_BITS # 序號迴圈掩碼 SEQUENCE_MASK = -1 ^ (-1 << SEQUENCE_BITS) # Twitter元年時間戳 TWEPOCH = 1288834974657 logger = logging.getLogger('flask.app') class IdWorker(object): """ 用於生成IDs """ def __init__(self, datacenter_id, worker_id, sequence=0): """ 初始化 :param datacenter_id: 資料中心(機器區域)ID :param worker_id: 機器ID :param sequence: 其實序號 """ # sanity check if worker_id > MAX_WORKER_ID or worker_id < 0: raise ValueError('worker_id值越界') if datacenter_id > MAX_DATACENTER_ID or datacenter_id < 0: raise ValueError('datacenter_id值越界') self.worker_id = worker_id self.datacenter_id = datacenter_id self.sequence = sequence self.last_timestamp = -1 # 上次計算的時間戳 def _gen_timestamp(self): """ 生成整數時間戳 :return:int timestamp """ return int(time.time() * 1000) def get_id(self): """ 獲取新ID :return: """ timestamp = self._gen_timestamp() # 時鐘回撥 if timestamp < self.last_timestamp: logging.error('clock is moving backwards. Rejecting requests until {}'.format(self.last_timestamp)) raise InvalidSystemClock if timestamp == self.last_timestamp: self.sequence = (self.sequence + 1) & SEQUENCE_MASK if self.sequence == 0: timestamp = self._til_next_millis(self.last_timestamp) else: self.sequence = 0 self.last_timestamp = timestamp new_id = ((timestamp - TWEPOCH) << TIMESTAMP_LEFT_SHIFT) | (self.datacenter_id << DATACENTER_ID_SHIFT) | \ (self.worker_id << WOKER_ID_SHIFT) | self.sequence return new_id def _til_next_millis(self, last_timestamp): """ 等到下一毫秒 """ timestamp = self._gen_timestamp() while timestamp <= last_timestamp: timestamp = self._gen_timestamp() return timestamp if __name__ == '__main__': worker = IdWorker(1, 2, 0) print(worker.get_id())