接上文

https://editor.csdn.net/md/?articleId=133988963

類snowFlake 方案

• 應(yīng)用舉例 mongoDB ObjectID 就是一個(gè)典型的實(shí)現(xiàn)。

數(shù)據(jù)庫生成

以MySQL舉例 利用給字段設(shè)置AUTO-INCREMENT來保證ID自增,每次業(yè)務(wù)使用SQL拿到MySQL的ID
這種方案的優(yōu)缺點(diǎn):

• 優(yōu)點(diǎn)
  1 簡單。利用數(shù)據(jù)庫實(shí)現(xiàn) 成本小，有專業(yè)的DBA維護(hù)
  2 ID單調(diào)遞增。用來實(shí)現(xiàn)一些對于ID有特殊要求的業(yè)務(wù)
• 缺點(diǎn)
  1 強(qiáng)依賴DB,當(dāng)整個(gè)DB異常整個(gè)系統(tǒng)不可用，屬于致命問題
  2 ID發(fā)號性能瓶頸在于單臺(tái)DB的讀寫性能

對于MySQL的性能問題，可以考慮多部署幾臺(tái)機(jī)器。然后設(shè)置不同的初始值，步數(shù)長和機(jī)器數(shù)相等。
Flickr論文
但是這玩意看起來能滿足。但是存在的問題:

• 系統(tǒng)基本屬于無法水平拓展。因?yàn)槟愣x好了步長 都寫死了。如果后續(xù)發(fā)現(xiàn)性能不夠要加機(jī)器 怎么處理？
• ID沒有單調(diào)遞增。只能趨勢遞增。當(dāng)然對于一般業(yè)務(wù)也沒什么。可以忍受
• 數(shù)據(jù)庫壓力大。畢竟都讀寫一次DB
• 當(dāng)然也可以用redis 但是還是一樣的問題
<