# :-: 分布式ID生成器解决方 ## 一、介绍 ### 1\. 什么情况下我们需要ID生成器 * 数据库水平拆分的情况下，主键由于需要作为业务标识使用，需要唯一。 * 业务编号需要暴露给用户，但是又不想被用户猜到需要被隐藏的业务编号 * 业务编号需要体现业务信息，比如订单分类订单渠道等等 ### 2\. ID生成器设计目标 * 全局唯一 * 每秒可生成100W+ * 趋于递增（对索引友好） * 高可用 * 可伸缩 ## 二、常见ID生成方案 ### 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\. 数据库自增列 可以通过设置bigint类型的数据库自增列，在事务中通过Insert操作获取主键Id * 优点 * 可以实现ID完全递增 * 部署简单，有DB就可以 * 缺点 * 生成效率差，取决于数据库性能指标，每秒生成一万ID都很难 * 依赖于数据库，如果DB发生故障，在做主从切换的时候可能会引发BUG ### 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,21B：2,7,12,17,22C：3,8,13,18,23D：4,9,14,19,24E：5,10,15,20,25        这个，随便负载到哪个机确定好，未来很难做修改。但是3-5台服务器基本能够满足器上，都可以获得不同的ID。但是步长和初始值一定需要事先需要了。使用Redis集群也可以方式单点故障的问题。        另外，比较适合使用Redis来生成每天从0开始的流水号。比如订单号=日期+当日自增长号。可以每天在Redis中生成一个Key，使用INCR进行累加。 * 优点 * 不依赖于数据库，灵活方便，且性能优于数据库。 * 数字ID天然排序，对分页或者需要排序的结果很有帮助。 * 缺点 * 如果系统中没有Redis，还需要引入新的组件，增加系统复杂度。 * 需要编码和配置的工作量比较大。 ### 4\. MongoDB的ObjectId MongoDB的ObjectId和snowflake算法类似。它设计成轻量型的，不同的机器都能用全局唯一的同种方法方便地生成它。MongoDB 从一开始就设计用来作为分布式数据库，处理多个节点是一个核心要求。使其在分片环境中要容易生成得多。其格式如下：        前4 个字节是从标准纪元开始的时间戳，单位为秒。时间戳，与随后的5 个字节组合起来，提供了秒级别的唯一性。由于时间戳在前，这意味着ObjectId 大致会按照插入的顺序排列。这对于某些方面很有用，如将其作为索引提高效率。这4 个字节也隐含了文档创建的时间。绝大多数客户端类库都会公开一个方法从ObjectId 获取这个信息。        接下来的3 字节是所在主机的唯一标识符。通常是机器主机名的散列值。这样就可以确保不同主机生成不同的ObjectId，不产生冲突。为了确保在同一台机器上并发的多个进程产生的ObjectId 是唯一的，接下来的两字节来自产生ObjectId 的进程标识符（PID）。        前9 字节保证了同一秒钟不同机器不同进程产生的ObjectId 是唯一的。后3 字节就是一个自动增加的计数器，确保相同进程同一秒产生的ObjectId 也是不一样的。同一秒钟最多允许每个进程拥有2563（16 777 216）个不同的ObjectId。 ### 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 * 在单机上是递增的，但是由于涉及到分布式环境，每台机器上的时钟不可能完全同步，也许有时候也会出现不是全局递增的情况