什么是發號器
在互聯網場景中，很多業務要求生成唯一的ID號，以用于區分某些資源。常見例子：電商系統中的訂單ID號、聊天群組中的消息ID號、上傳文件到存儲系統中之后生成的文件ID號、用戶注冊系統中的用戶ID號、商戶系統中的商戶ID號、開放平臺中的開發者賬號ID、餐飲店的排隊進餐號、影劇院票據單號、醫院/銀行排隊號等等，這些基本都是基于先來后到的規則生成，以期達到唯一性或稍顯公平的享受某些資源。
你是否想過使用技術應該如何實現呢？下面引出本文主角：發號器（ticket dispenser），也可稱之為ID生成器 (生成的ID號可以是字符串也可以是整數，本文僅探討生成整數id的發號器實現原理)。
在互聯網行業中，為了保證服務的穩定性、可用性、并發性等指標，服務一般是采用集群多節點部署，如何保證在這些不同的節點生成符合業務要求的ID，又引出另一個概念：分布式ID生成器(實現方案有多種)。關于分布式ID的常見實現方式參考筆者文章：分布式ID的5種生成方式以及Go源碼中的一種應用，文章中列舉了常見的5種實現方式以及原理。本文，則重點講解使用redis+DB基于號段的發號器實現原理。
實現發號器需要的關注點
需要關注的點大致有以下幾個：
- 有序性
正序或倒序，發號器基本都是基于某種緯度的正序排列。還有一些不需要有序性，只要保證唯一性即可。
- 遞增性
隨著時間的流逝，號碼的值只能增大不能變小，即：后面生成的一定大于前面生成的。
- 唯一性
在整個生成的號碼值域中，同一個號碼有且僅出現一次。
- 先到先得
先申請號碼的先獲取到，后申請號碼的后獲取到。
基于號段的發號器實現原理
由上圖可知，實現基于號段的發號器邏輯有2個角色：
1. 發號生成器
2. 集中式號段管理器
對于基于號段的發號器來說，發號生成器本身存儲一段可用的值域空間，其數據結構一般為：[currId, maxId]，currId為下一個可用id，maxId為當前號段最大id。每當有號碼申請到達后，發號器先判斷是否有可用號碼。
若currId<=maxId則存在可用id，把currId返回給申請方，然后currId+=1。
若currId>maxId，說明該號段被消耗殆盡。此時，發號器需要申請新的號段值域空間。即：申請新的maxId，一般使用步長的方式，發號器每次申請新的值域空間，會得到長度固定的新值域空間 (判斷發號生成器是否存在可用號碼，一般有2種寫法，只是處理邊界條件不一樣，這里以currId<=maxId視為有可用號碼)。
通常情況下，發號生成器分為進程內發號生成器與進程外發號生成器。即：在進程內部維護[currId, maxId]值域空間還是在進程外部維護[currId, maxId]值域空間。進程內部可以通過全局變量+進程內部鎖(或原子操作)的方式實現，進程外部通過其他中間件(Redis or DB)或服務來實現。
進程內發號生成器與進程外發號生成器的使用場景也有很大不同之處，服務一般存在多個節點，每個節點都存在一個業務進程。若對全部請求都要保證先來后到嚴格的時序性，則需要使用唯一的進程外發號生成器。若不用保證先來后到嚴格的時序性，則進程內發號生成器與進程外發號生成器都可以使用，考慮性能優先選擇進程內發號生成器。
Redis+DB實現基于號段的發號器
通過上面可知，實現發號器功能需要實現2個角色：發號生成器與集中式號段管理器，本文著重講解進程外發號生成器的實現原理。這里使用Redis作為發號生成器，DB作為集中式號段管理器。
Redis發號生成器僅僅是一個hash類型的數值結構，包含2個field：v_l/v_h。
DB集中式號段管理器一般是一張表結構，核心的2個字段：server_name/max_id。
通過上圖可知，業務在通過發號器獲取號碼時需要經歷以下幾個步驟：
1. 業務請求Redis發號生成器獲取號碼
2. 發號生成器判斷是否存在可用號碼
3. 有幾種情況
3.1 正常獲取號碼返回給業務(到這里結束)
3.2 發號生成器數據結構不存在
3.3 發號生成器數值空間耗盡
4. 對于3.2/3.3這兩種情況，業務會加分布式鎖并請求DB集中式號段管理器獲取新的號段
5. DB集中式號段管理器返回新的號段
6. 業務更新發號生成器號段
7. 回到第1步
