為什么需要分布式id生成系統
在復雜分布式系統中，往往需要對大量的數據和消息進行唯一標識。如在美團點評的金融、支付、餐飲、酒店、貓眼電影等產品的系統中，數據日漸增長，對數據分庫分表后需要有一個唯一ID來標識一條數據或消息，數據庫的自增ID顯然不能滿足需求；特別一點的如訂單、騎手、優惠券也都需要有唯一ID做標識。此時一個能夠生成全局唯一ID的系統是非常必要的。概括下來，那業務系統對ID號的要求有哪些呢？
分布式id創建的業務需求
| 1.全局唯一性：不能出現重復的ID號，既然是唯一標識，這是最基本的要求。 2.趨勢遞增：在MySQL InnoDB引擎中使用的是聚集索引，由於多數RDBMS使用B-tree的數據結構來存儲索引數據，在主鍵的選擇上面我們應該盡量使用有序的主鍵保證寫入性能。 3.單調遞增：保證下一個ID一定大於上一個ID，例如事務版本號、IM增量消息、排序等特殊需求。 4.信息安全：如果ID是連續的，惡意用戶的扒取工作就非常容易做了，直接按照順序下載指定URL即可；如果是訂單號就更危險了，競對可以直接知道我們一天的單量。所以在一些應用場景下，會需要ID無規則、不規則。 5.分布式id里面最好包含時間戳，這樣就能夠在開發中快速了解這個分布式id的生成時間 |
上述123對應三類不同的場景，3和4需求還是互斥的，無法使用同一個方案滿足。
同時除了對ID號碼自身的要求，業務還對ID號生成系統的可用性要求極高，想象一下，如果ID生成系統癱瘓，整個美團點評支付、優惠券發券、騎手派單等關鍵動作都無法執行，這就會帶來一場災難。由此我總結下一個ID生成系統應該做到如下幾點：
| 可用性高：就是我用戶發了一個獲取分布式id的請求，那么你服務器就要保證99.999%的情況下給我創建一個分布式id 延遲低：就是我用戶給你一個獲取分布式id的請求，那么你服務器給我創建一個分布式id的速度就要快 高QPS：這個就是用戶一下子有10萬個創建分布式id請求同時過去了，那么你服務器要頂的住，你要一下子給我成功創建10萬個分布式id |
分布式ID其他系列快捷鍵：
分布式ID系列（1）——為什么需要分布式ID以及分布式ID的業務需求
分布式ID系列（3）——數據庫自增ID機制適合做分布式ID嗎