在互联网场景中，很多业务要求生成唯一的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步
