分布式ID的特性

全局唯一。不能出現重複的ID，這是最基本的要求。
遞增。遞增有利於關係數據庫索引性能。除了常見的連續遞增，如1001，1002，1003等等，分布式ID還存在趨勢遞增的形式，即保證下一個ID大於上一個ID但不連續。這樣的好處可以防止關鍵信息被泄露，例如toc業務中暴露給用戶的ID，可能會暴露用戶數量。（訂單id同理）
高可用。為多個服務提供ID服務，一旦宕機，會造成嚴重影響。
好接入。秉着拿來即用的設計原則，接入文檔要儘可能的簡單。
高性能：必須要在壓測下表現良好，如果達不到要求則在高並發環境下會導致系統癱瘓。
靈活多變：每個業務場景對ID的要求也各不相同，ID生成要做到靈活多變可配置，儘可能多的滿足需求。

解決方案

1. UUID

UUID是Universally Unique Identifier的縮寫，包含32個16進制數字，以連字號分為五段，形式為8-4-4-4-12包含36個字符的字符串，例如：
321dsa13-das2-d231-gfdd-213as8asd899

UUID經由一定的算法機器生成，為了保證UUID的唯一性，規範定義了包括網卡MAC地址、時間戳、名字空間、隨機或偽隨機數、時序等元素，以及從這些元素生成UUID的算法。

優點：

性能非常高，本地生成，沒有網絡消耗。
生成簡單，沒有高可用風險。
有利於信息安全，因為可讀性差，無規律。

缺點：

太長，不易於存儲。
無序，對MySQL索引不利，在InnoDB中，UUID的無序性可能會引起數據位置頻繁變動，嚴重影響性能。
UUID不能標識業務含義，可讀性差。

2. 數據庫自增 ID

利用數據庫自增ID的特性來生成，如MySQL的auto_increment。其優點是數字類型，並且可以自增。當然缺點就是並發場景下的性能瓶頸。

優點：

簡單，利用數據庫自有功能實現。
ID嚴格連續自增，可以實現一些對ID有特殊要求的業務。

缺點：

有重複發號的風險，例如MySQL數據庫主從切換的場景。
發號性能限制於數據庫性能。
強依賴數據庫，當數據庫異常時整個系統不可用。

進一步優化：
放棄主從複製的高可用架構，採用多主架構。每個主庫設置不同的起始值和相同的步長，保證了號段的隔離。

3. Redis

Redis中的incr命令，可以實現原子自增。相比較數據庫而言，Redis可支撐的並發量非常高，性能好。

但需要考慮下面兩種情況造成的數據不一致問題：

宕機後重啟恢復但存在未及時初始化。
主從切換，主從數據同步延遲。

優點：

簡單，自有能力。
高並發環境下性能好，優於數據庫。

缺點：

可能會重複發號。
需要保障Redis服務的高可用。

4. Zookeeper 實現

使用ZooKeeper作為分段節點協調工具，每台服務器首先從Zookeeper 獲取一段號碼，如[1,1000]的ID，此時Zookeeper上保存最大值 1000，每次獲取的時候都會進行判斷，如果ID <=1000，則更新本地的當前值，如果為1001，則會將Zookeeper 上的最大值更新至2000，本地緩存段更新為1001-2000，更新的時候使用分布式鎖來實現。（相當於用Zookeeper實現了基於數據庫的號段模式）

優點：

效率高。

缺點：

維護成本較高，不能同時滿足多個系統對ID的需求，不夠靈活。

5、基於數據庫的號段模式

號段模式的思想是客戶端每次從數據庫中取出一批ID供程序使用，從表中獲取本次ID值的範圍，如[1,1000]，然後客戶端將申請的號段[1,1000]加載到內存。表結構參考如下：

CREATE TABLE id_generator (
  id int(10) NOT NULL,
  max_id bigint(20) NOT NULL COMMENT '當前最大id',
  step int(20) NOT NULL COMMENT '號段的布長',
  biz_type    int(20) NOT NULL COMMENT '業務類型',
  version int(20) NOT NULL COMMENT '樂觀鎖版本號',
  PRIMARY KEY (`id`)
)

等這批號段ID用完，再次向數據庫申請新號段，對max_id字段做一次update操作（update id_generator set max_id = #{max_id+step}, version = version + 1 where version = # {version} and biz_type = XXX），update成功則說明新號段獲取成功，新的號段範圍是(max_id ,max_id +step]