1. 引言
什么情况下我们需要ID生成器？
- 数据库水平拆分的情况下，主键由于需要作为业务标识使用，需要唯一。
- 业务编号需要暴露给用户，但是又不想被用户猜到需要被隐藏的业务编号
- 业务编号需要体现业务信息，比如订单分类订单渠道等等
ID生成器设计目标：
- 全局唯一
- 每秒可生成100W+
- 趋于递增（对索引友好）
- 高可用
- 可伸缩
2. 常见ID生成方案
2.1 UUID
UUID 是 通用唯一识别码（Universally Unique Identifier）的缩写，是一种软件建构的标准，亦为开放软件基金会组织在分布式计算环境领域的一部分
UUID是由一组32位数的16进制数字所构成，是故UUID理论上的总数为1632=2128，约等于3.4 x 1038。也就是说若每纳秒产生1兆个UUID，要花100亿年才会将所有UUID用完。
UUID的标准型式包含32个16进制数字，以连字号分为五段，形式为8-4-4-4-12的32个字符。示例： 550e8400-e29b-41d4-a716-446655440000
每秒产生10亿笔UUID，100年后只产生一次重复的机率是50%
优点：
- 本地生成，没有网络消耗
- 可以任意水平扩展
- 生成效率高
- 生成节点不限
缺点：
- 没有排序，无法保证趋势递增。
- UUID往往是使用字符串存储，查询的效率比较低。
- 存储空间比较大，如果是海量数据库，就需要考虑存储量的问题。
- 传输数据量大
- 不可读
2.2 数据库自增列
可以通过设置bigint类型的数据库自增列，在事务中通过Insert操作获取主键Id
优点:
- 可以实现ID完全递增
- 部署简单，有DB就可以
缺点:
- 生成效率差，取决于数据库性能指标，每秒生成一万ID都很难
- 依赖于数据库，如果DB发生故障，在做主从切换的时候可能会引发BUG
2.3 Redis生成ID
当使用数据库来生成ID性能不够要求的时候，我们可以尝试使用Redis来生成ID。这主要依赖于Redis是单线程的，所以也可以用生成全局唯一的ID。可以用Redis的原子操作 INCR和INCRBY来实现。
可以使用Redis集群来获取更高的吞吐量。假如一个集群中有5台Redis。可以初始化每台Redis的值分别是1,2,3,4,5，然后步长都是5。各个Redis生成的ID为：
- A：1,6,11,16,21
- B：2,7,12,17,22
- C：3,8,13,18,23
- D：4,9,14,19,24
- E：5,10,15,20,25
这个，随便负载到哪个机确定好，未来很难做修改。但是3-5台服务器基本能够满足器上，都可以获得不同的ID。但是步长和初始值一定需要事先需要了。使用Redis集群也可以防止单点故障的问题。
另外，比较适合使用Redis来生成每天从0开始的流水号。比如订单号=日期+当日自增长号。可以每天在Redis中生成一个Key，使用INCR进行累加。
优点：
- 不依赖于数据库，灵活方便，且性能优于数据库。
- 数字ID天然排序，对分页或者需要排序的结果很有帮助。
缺点：
- 如果系统中没有Redis，还需要引入新的组件，增加系统复杂度。
- 需要编码和配置的工作量比较大。
2.4 MongoDB的ObjectIdD
MongoDB的ObjectId和snowflake算法类似。它设计成轻量型的，不同的机器都能用全局唯一的同种方法方便地生成它。MongoDB 从一开始就设计用来作为分布式数据库，处理多个节点是一个核心要求。使其在分片环境中要容易生成得多。
其格式如下：
前4 个字节是从标准纪元开始的时间戳，单位为秒。时间戳，与随后的5 个字节组合起来，提供了秒级别的唯一性。由于时间戳在前，这意味着ObjectId 大致会按照插入的顺序排列。这对于某些方面很有用，如将其作为索引提高效率。这4 个字节也隐含了文档创建的时间。绝大多数客户端类库都会公开一个方法从ObjectId 获取这个信息。
接下来的3 字节是所在主机的唯一标识符。通常是机器主机名的散列值。这样就可以确保不同主机生成不同的ObjectId，不产生冲突。
为了确保在同一台机器上并发的多个进程产生的ObjectId 是唯一的，接下来的两字节来自产生ObjectId 的进程标识符（PID）。
前9 字节保证了同一秒钟不同机器不同进程产生的ObjectId 是唯一的。后3 字节就是一个自动增加的计数器，确保相同进程同一秒产生的ObjectId 也是不一样的。同一秒钟最多允许每个进程拥有2563（16 777 216）个不同的ObjectId。
2.5 Twitter的snowflake算法
snowflake是Twitter开源的分布式ID生成算法，结果是一个long型的ID。其核心思想是：使用41bit作为毫秒数，10bit作为机器的ID（5个bit是数据中心，5个bit的机器ID），12bit作为毫秒内的流水号（意味着每个节点在每毫秒可以产生 4096 个 ID），最后还有一个符号位，永远是0。
| 分段 | 作用 | 说明 |
| 1bit | 保留 | — |
| 41bit | 时间戳，精确到毫秒 | 可以支持69年的跨度 |
| 5bit | DatacenterId | 可以最多支持32个节点 |
| 5bit | WorkerId | 可以最多支持32个节点 |
| 12bit | 毫秒内的计数 | 支持每个节点每毫秒产生4096个ID |
理论上单机每秒400W+，最多每秒可以生成41亿+的ID
优点：
- ID趋势递增
- 生成效率高，单机每秒400W+
- 支持线性扩充
- 稳定性高，不依赖DB等服务
缺点：
- 依赖服务器时间，如果服务器时间发生回拨，可能导致生成重复ID
- 在单机上是递增的，但是由于涉及到分布式环境，每台机器上的时钟不可能全同步，也许有时候也会出现不是全局递增的情况
