前段時間正值開發ID生成中心，看到很多業界大神分享了自己公司的ID生成器的設計思路。現在分享一下自己的思路，供大家參考、吐槽。

業務需求及業內方案，在許多文章中都有介紹，我在這裡就不多介紹了。現在直入主題，談談自己的設計思路。

基本介紹

1.MySQL記錄註冊的應用服務資訊及生成的應用唯一標識authID。

2.高可用的Redis記錄註冊的IDKey(應用中ID的唯一標識，一個應用可以申請多個ID)並負責生成、分發ID區間(利用Redis中incr特性)。這裡Redis必須保證高可用，至少為雙機熱備保證資料不丟失。當然這裡的IDKey註冊可以記錄在MySQL中。

3.ID生成中心使用L1、L2快取從Redis中獲取到的ID區間，並實時同步。

4.下游服務可以直接通過Http/RPC，從ID生成中心獲取ID。

5.下游服務也可以通過在專案中引入ID生成客戶端依賴包來獲取ID。因為目前我們並沒有那麼高頻的需求，所以暫時沒有開發。

對外介面

1.註冊應用服務。

2.註冊應用IDKey服務。

3.獲取ID服務。

4.獲取ID區間服務。

ID生成機制

1.ID生成中心每次從Redis（使用incr命令）中獲取一定範圍的遞增ID區間（該區間範圍相對大一些，eg:10000），並同步快取至L1、L2（避免大量ID區間丟失）。

2.當該應用的該IDKey的ID區間使用率超過一定閾值（eg:>50%）時，ID生成中心自動從Redis（使用incr命令

3.當ID生成中心宕機，再次啟動時，會優先同步L2中的ID區間至L1中，如果沒有再從Redis中通過incr獲取，已達到節約ID的目的。

4.這裡L1、L2的ID資料同步是非同步進行的。

5.ID生成客戶端的基本設計思路也是差不多一樣的。只不過這是獲取的ID區間相對ID生成中心從Redis獲取的ID區間會小很多，這裡儘量保證倆者區間段有一個相當大的比例區間。對於獲取的ID區間具體大小，可以根據個人的需求取捨。

測試結果

單執行緒呼叫5000次，RPC平均耗時1ms，Http平均耗時3.7ms

參考連結