分布式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())